7.1编码

编码:编码就是把软件设计结果翻译成用某种程序设计语言书写的程序,是对设计的进一步具体化。 测试:程序的质量主要取决于软件设计的质量。软件测试是保证软件质量的关键步骤,是对软件规格说明、设 计和编码的最后复审。

7.1.1 选择程序设计语言

程序设计语言是人和计算机通信的最基本的工具,会影响人的思维和解题方式,影响人和计算机通信的方式和质量,影响其他人阅读和理解程序的难易程度。
选择适宜的程序设计语言的原因:

  • 根据设计去完成编码时,困难最少;
  • 可以减少需要的程序测试量;
  • 可以得到更容易阅读和更容易维护的程序。

高级语言优于汇编语言:
●汇编语言编码需要把软件设计翻译成机器操作的序列, 既困难又容易出差错;
●高级语言写程序比用汇编语言写程序生产率可以提高好几倍;
●用高级语言写的程序容易阅读、容易测试、容易调试、容易维护。
实用标准:
·系统用户的要求;
·可以使用的编译程序;
·可以得到的软件工具;
·工程规模;
·程序员的知识;
·软件可移植性要求;
·软件的应用领域。

7.1.2 编码风格

1.程序内部的文档
2.数据说明
3.语句构造
4.输入输出
5.效率

7.2 软件测试基础

7.2.1 软件测试的目标

G.Myers给出的关于测试的一些规则如下:

  • 测试是为了发现程序中的错误而执行程序的过程。
  • 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。
  • 成功的测试是发现了至今为止尚未发现的错误的测试。

    7.2.2 软件测试准则

    主要的软件测试准则如下:

  • 所有测试都应该能追溯到用户需求;

  • 应该远在测试开始之前就制定出测试计划;
  • 把Pareto原理应用到软件测试中;
  • 应该从“小规模”测试开始,并逐步进行“大规模”测试;
  • 穷举测试是不可能的;
  • 为了达到最佳的测试效果,应该由独立的第三方从事测试工作。

    7.2.3 测试方法

    黑盒测试(又称功能测试)把程序看作一个黑盒子,完全不考虑程序的内部结构和处理过程。黑盒测试是在程序接口进行的测试,只检查程序 功能是否能按照规格说明书的规定正 常使用,程序是否能适当地接收输入 数据并产生正确的输出信息,程序运 行过程中能否保持外部信息(例如数据库或文件)的完整性。
    白盒测试(又称结构测试)是把程序看成装在一个透明的白盒子里,测试者完全知道程序的结构和处理算法。这种方法按照程序内部的逻辑测试程序,检测程序中的主要执行通路是否都能按预定要求正确工作。

    7.2.4 测试步骤

    根据第4条测试准则,测试过程也必须分步骤进行,后 一个步骤在逻辑上是前一个步骤的继续。
    大型软件系统通常由若干个子系统组成,每个子系统又由许多模块组成,因此,大型软件系统的测试过程基本上由模块测试、子系统测试、系统测试、验收测试和平行运行等五个步骤组成。
    1.模块测试
    在设计得好的软件系统中,每个模块完成一个清晰定义的子功能,而且这个子功能和同级其他模块的功能之间没有相互依赖关系。因此,有可能把每个模块作为一个单独的实体来测试,而且通常比较容易设计检验模块正确性的测试方案。
    模块测试的目的是保证每个模块作为一个单元能正确运行所以模块测试通常又称为单元测试。在这个测试步骤中所发现的往往是编码和详细设计的错误。
    2.子系统测试
    子系统测试是把经过单元测试的模块放在一起形成一个子系统来测试。模块相互间的协调和通信是这个测试过程中的主要问题,因此,这个步骤着重测试模块的接口。
    3.系统测试
    系统测试是把经过测试的子系统装配成一个完整的系统来测试。在这个过程中不仅应该发现设计和编码的错误,还应该验证系统确实能提供需求说明书中指定的功能,而且系统的动态特性也符合预定要求。在这个测试步骤中发现的往往是软件设计中的错误,也可能发现需求说明中的错误。
    子系统测试和系统测试,都兼有检测和组装两重含义,通常称为集成测试。
    4.验收测试
    验收测试把软件系统作为单一的实体进行测试,测试内容与系统测试基本类似,但是它是在用户积极参与下进行的, 而且可能主要使用实际数据(系统将来要处理的信息)进行测 试。 验收测试的目的是验证系统确实能够满足用户的需要,在这个测试步骤中发现的往往是系统需求说明书中的错误。 验收测试也称为确认测试。

    5.平行运行
    所谓平行运行就是同时运行新开发出来的系统和将被它取代的旧系统,以便比较新旧两个系统的处理结果。这样做 的具体目的有如下几点:
    (1)可以在准生产环境中运行新系统而又不冒风险。
    (2)用户能有一段熟悉新系统的时间。
    (3)可以验证用户指南和使用手册之类的文档。
    (4)能够以准生产模式对新系统进行全负荷测试,可以用 测试结果验证性能指标。

    7.2.5.测试阶段的信息流

    image.png
    上图描绘了测试阶段的信息流,这个阶段的输入信息有两类:
    (1)软件配置,包括需求说明书、设计说明书和源程序清单等;
    (2)测试配置,包括测试计划和测试方案。

测试用例包括:

  • 输入数据
  • 预期结果

如果看起来软件功能完成得很正常,遇到的错误也很容易改正,则仍然应该考虑两种可能:(1)软件的可靠性是可以接受的;(2)所进行的测试尚不足以发现严重的错误。 如果经过测试,一个错误也没有被发现,则很可能是因为对测试配置思考不充分,以致不能暴露软件中潜藏的错误。
软件可靠性模型使用错误率数据估计将来出现错误的情况,并进而对软件可靠性进行预测。

7.3 单元测试

  • 单元测试集中检测软件设计的最小单元——模块。
  • 单元测试和编码属于软件过程的同一个阶段。
  • 在源程序代码通过编译程序的语法检査后,可以用详细设计描述作指南,对重要的执行通路进行测试,以便发现模块内部的错误。(白盒测试为主,模块可以进行并行运行)

    7.3.1.测试重点

    1. 在单元测试期间着重从以下5个方面对模块进行测试。<br />**1.模块接口**<br /> 对模块接口进行测试时主要检查以下几个方面:
  • 参数的数目、次序、属性或单位系统与变元是否一致;

  • 是否修改了只作输入用的变元;
  • 全局变量的定义和用法在各个模块中是否一致。

2.局部数据结构
对于模块来说,局部数据结构是常见的错误来源。应该仔细设计测试方案,以便发现局部数据说明、初始化、默认值等方面的错误。
3.重要的执行通路
由于通常不可能进行穷尽测试,因此,在单元测试期间选择最有代表性、最可能发现错误的执行通路进行测试是十分关键的。应该设计测试方案用来发现由于错误的计算、不正确的比较或不适当的控制流而造成的错误。
4.出错处理通路
好的设计应该能预见出现错误的条件,并且设置适当的处理错误的通路。不仅应该在程序中包含出错处理通路,而且应 该认真测试这种通路。评价出错处理通路应该着重测试下述一 些可能发生的错误。
(1)对错误的描述是难以理解的;
(2)记下的错误与实际遇到的错误不同;
(3)在对错误进行处理之前,错误条件已经引起系统干预;
(4)对错误的处理不正确;
(5)描述错误的信息不足以帮助确定造成错误的位置。
5.边界条件

  • 边界测试是单元测试中最后的也可能是最重要的任务。
  • 软件常常在它的边界上失效,例如,处理 n 元数组的第 n 个元素时,或做到 i 次循环中的第 i 次重复时,往往会发生错误。
  • 使用刚好小于、刚好等于和刚好大于最大值或最小值的数据结构、控制量和数据值的测试方案,非常可能发现软件中的错误。

    7.3.2 代码审查

    代码检查是指由审查小组正式对源程序进行人工测试。 它是一种非常有效的程序验证技术,对于典型的程序来说, 可以查出30%~70%的逻辑设计错误和编码错误。审查小组最好由下述4人组成。
    (1)组长,应该是一个很有能力的程序员,而且没有直接 参与这项工程;
    (2)程序的设计者;
    (3)程序的编写者;
    (4)程序的测试者。
    在审查会上由程序的编写者解释他是怎样用程序代码实现设计的,通常是逐个语句地讲述程序的逻辑,小组其他成员仔细倾听他的讲解,并力图发现其中的错误。
    审查会上需要对照程序设计常见错误清单,分析审查这个程序。当发现错误时由组长记录下来,审查会继续进行 (审查小组的任务是发现错误而不是改正错误)。
    审查会另外一种常见的进行方法,称为预排:由一个人扮演“测试者”,其他人扮演“计算机”。会前测试者准备好测试方案,会上由扮演计算机的成员模拟计算机执行被测试的程序。
    代码审查比计算机测试优越的是:一次审查会上可以发现许多错误;用计算机测试的方法发现错误之后,通常需要先改正这个错误才能继续测试,即:采用代码审查的方法可以减少系统验证的总工作量。
    人工测试和计算机测试是互相补充,相辅相成的,缺少其中任何一种方法都会使查找错误的效率降低。

    7.3.3 计算机测试

    模块不是一个独立的程序,因此必须为每个单元测试开发驱动软件和(或)存根软件。
    驱动程序是一个“主程序”,它接收测试数据,把这些数据传送给被测试的模块,并且印出有关的结果。
    存根程序代替被测试的模块所调用的模块,它使用被它代替的模块的接口,可能做最少量的数据操作,印出对入口 的检验或操作结果,并且把控制归还给调用它的模块。

下图是一个正文加工系统的部分层次图,假定要测试编号为3.0的关键模块—正文编辑模块。正文编辑模块不是一个独立的程序,需要有一个测试驱动程序来调用它。这个驱动程序说明必要的变量,接收测试数据——字符串,设置正文编辑模块的编辑功能。并且需要有存根程序简化地模拟正文编辑模块的下层模块来完成具体的编辑功能。
image.png
image.pngimage.png

7.4 集成测试

集成测试是测试和组装软件的系统化技术。
由模块组装成程序时有两种方法。一种方法是先分别测试每个模块,再把所有模块按设计要求放在一起结合成所要的程序,这种方法称为非渐增式测试方法;另一种方法是把下一个要测试的模块同已经测试好的那些模块结合起来进行测试,测试完以后再把下一个应该测试的模块结合进来测试。这种每次增加一个模块的方法称为渐增式测试,这种方法实际上同时完成单元测试和集成测试。
非渐增式测试把所有模块放在一起,作为一个整体来测试。测试时会遇到许多的错误,改正错误非常困难,因为在庞大的程序中想要诊断定位一个错误非常困难,而且改正一个错误之后,马上又会遇到新的错误,这个过程会继续下去,没有尽头。
渐增式测试与“一步到位”的非渐增式测试相反,它把程序划分成小段来构造和测试,在这个过程中比较容易定位和改正错误;对接口可以进行更彻底的测试;可以使用系统化的测试方法。因此,目前在进行集成测试时普遍采用渐增式测试方法。

  • 当使用渐增方式把模块结合到程序中去时,有自顶向下和自底向上两种集成策略。

    7.4.1 自顶向下集成

  • 自顶向下集成方法是从主控制模块开始,沿着程序的控制 层次向下移动,逐渐把各个模块结合起来。在把附属于(及最终附属于)主控制模块的那些模块组装到程序结构中去时,或者使用深度优先的策略,或者使用宽度优先的策略。

  • 深度优先的结合方法先组装在软件结构的一条主控制通路上的所有模块。选择一条主控制通路取决于应用的特点,并且有很大任意性。
  • 宽度优先的结合方法是沿软件结构水平地移动,把处于同个控制层次上的所有模块组装起来。

    模块结合进软件结构的具体过程由下述4个步骤完成:

  1. 对主控制模块进行测试,测试时用存根程序代替所有直接附属于主控制模块的模块;
  2. 根据选定的结合策略(深度优先或宽度优先),每次用一个实际模块代换一个存根程序(新结合进来的模块往往又需要新的存根程序);
  3. 在结合进一个模块的同时进行测试;
  4. 为了保证加入模块没有引进新的错误,可能需要进行回归测试(即全部或部分地重复以前做过的测试)。

    1. 从②开始不断地重复进行上述过程,直到构造起完整的软件结构为止。
  • 自顶向下的结合策略能够在测试的早期对主要的控制或关键的抉择进行检验。在一个分解得好的软件结构中,关键 的抉择位于层次系统的较上层,因此首先碰到。
  • 如果选择深度优先的结合方法,可以在早期实现软件的一个完整的功能并且验证这个功能。在自顶向下测试的初期,存根程序代替了低层次的模块,
  • 因此,在软件结构中没有重要的数据自下往上流。为了解 决这个问题,测试人员有两种选择:①把许多测试推迟到 用真实模块代替了存根程序以后再进行;②从层次系统的 底部向上组装软件。
  • image.png

    7.4.2 自底向上集成

    image.png

    7.4.3 不同集成测试策略的比较

  • 自顶向下测试方法的主要优点是不需要测试驱动程序,能够在测试阶段的早期实现并验证系统的主要功能,而 且能在早期发现上层模块的接口错误。

  • 自顶向下测试方法的主要缺点是需要存根程序,可能遇到与此相联系的测试困难,低层关键模块中的错误发现较晚,而且用这种方法在早期不能充分展开人力。
  • 自底向上测试方法的优缺点与上述自顶向下测试方法的优缺点刚好相反。

    一般说来,纯粹自顶向下或纯粹自底向上的策略可能都不实用,人们在实践中创造出许多混合策略。
    (1)改进的自顶向下测试方法。基本上使用自顶向下的测试方法,但是在早期使用自底向上的方法测试软件中的少数关键模块。一般的自顶向下方法所具有的优点在这种方法中也都有,而且能在测试的早期发现关键模块中的错误;但是,它的缺点也比自顶向下方法多一条,即测试关键模块时需要驱动程序。
    (2)混合法。对软件结构中较上层使用的自顶向下方法与对软件结构中较下层使用的自底向上方法相结合。这种方法兼 有两种方法的优点和缺点,当被测试的软件中关键模块比较多 时,这种混合法可能是最好的折衷方法。

    7.4.4 回归测试

    ●在集成测试过程中,每当一个新模块结合进来时,程序就发生了变化:建立了新的数据流路径,可能出现了新的 I/O 操作,激活了新的控制逻辑。在集成测试的范畴中,回归测试是指重新执行已经做过的测试的某个子集,以保证上述这些变化没有带来非预期的副作用。
    回归测试就是用于保证由于调试或其他原因引起的变化,不会导致非预期的软件行为或额外错误的测试活动。
    回归测试可以通过人工地进行,也可以使用自动化的捕获回放工具自动进行。利用捕获回放工具,软件工程师能够捕获测试用例和实际运行结果,然后可以回放(即重新执行测试用例),并且比较软件变化前后所得到的运行结果。

  • 回归测试集(已执行过的测试用例的子集)包括下述3类不同的测试用例。

    1. 1)检测软件全部功能的代表性测试用例。<br /> 2)专门针对可能受修改影响的软件功能的附加测试。<br /> 3)针对被修改过的软件成分的测试。<br />在集成测试过程中,回归测试用例的数量可能变得非常大。因此,应该把回归测试集设计成只包括可以检测程序每个主要功能中的一类或多类错误的那样一些测试用例。

    7.5 确认测试

    ●确认测试也称为验收测试,它的目标是验证软件的有效性。
    ●通常,验证指的是保证软件正确地实现了某个特定要求的一系列活动;确认指的是为了保证软件确实满足了用 户需求而进行的一系列活动。
    ●需求分析阶段产生的软件需求规格说明书,准确地描述了用户对软件的合理期望,因此是软件有效性的标准, 也是进行确认测试的基础。软件有效性的一个简单定义是:如果软件的功能和性能 如同用户所合理期待的那样,软件就是有效的。

    7.5.1 确认测试的范围

    用户,内部结构错误发现不了,可以找到功能的缺失(黑盒测试)
    确认测试有下述两种可能的结果:
    (1)功能和性能与用户要求一致,软件是可以接受的。
    (2)功能和性能与用户要求有差距。

    7.5.2 软件配置复查

    软件配置复查是确认测试的一个重要内容。复查的目的是保证软件配置的所有成分都齐全,质量符合要求,文档与程序完全一致,具有完成软件维护所必须的细节,而且已经编好目录。
    除了按合同规定的内容和要求,由人工审查软件配置之外,在确认测试过程中还应该严格遵循用户指南及其他操作程序,以便检验这些使用手册的完整性和正确性。必须仔细 记录发现的遗漏或错误,并且适当地补充和改正。

    7.5.3 Alpha和Beta测试

  • 如果一个软件是为许多客户开发的(例如,向大众公开出售的盒装软件产品),那么绝大多数软件开发商都使用被称为Alpha测试和Beta测试的过程,来发现那些看起来只有最终用户才能发现的错误。

  • Alpha测试由用户在开发者的场所进行,并且在开发者对用户的“指导”下进行测试。开发者负责记录发现的错误和使用中遇到的问题。
  • Alpha测试是在受控的环境中进行的。
  • Beta测试由软件的最终用户们在一个或多个客户场所进行。与Alpha测试不同,开发者通常不在Beta测试的现场。
  • Beta测试是软件在开发者不能控制的环境中的“真实”应用。

    7.6 白盒测试技术(发现内部结构问题)

    通常把测试数据和预期的输出结果称为测试用例。

    7.6.1 逻辑覆盖

    逻辑覆盖是对一系列测试过程的总称,这组测试过程逐渐进行越来越完整的通路测试。

    1.语句覆盖

    语句覆盖的含义是,选择足够多的测试数据,使被测程序中每个语句至少执行一次。
    语句覆盖对程序的逻辑覆盖很少,在上面例子中两个判定条件都只测试了条件为真的情况,如果条件为假时处理有错误,显然不能发现。

    2.判定覆盖

    判定覆盖又叫分支覆盖,它的含义是,不仅每个语句必须至少执行一次,而且每个判定的每种可能的结果都应该至少执行一次,也就是每个判定的每个分支都至少执行一次。

    3. 条件覆盖

    条件覆盖的含义是,不仅每个语句至少执行一次,而且使判定表达式中的每个条件都取到各种可能的结果。
    通常情况下,条件覆盖比判定覆盖逻辑性强,但不一定。

    4.判定/条件覆盖

    判定/条件覆盖是一种能同时满足判定覆盖和条件覆盖的逻辑覆盖,它的含义是,选取足够多的测试数据,使得判定表达式中的每个条件都取到各种可能的值,而且每个判定表达式也都取到各种可能的结果。

    5.条件组合覆盖

    条件组合覆盖是更强的逻辑覆盖标准,它要求选取足够多的测试数据,使得每个判定表达式中条件的各种可能组合都至少出现一次。
    显然,满足条件组合覆盖标准的测试数据,也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准。因此,条件组合覆盖是前述几种覆盖标准中最强的。但是,满足条件组合覆盖标准的测试数据并不一定能使程序中的每条路径都执行到。
    6.点覆盖(语句覆盖)
    从对程序路径的覆盖程度分析,能够提出下述一些主要的逻辑覆盖标准。
    图论中点覆盖的定义如下:如果连通图G的子图G’是连通的,而且包含G的所有结点,则称G’是G的点覆盖。
    在第6.5节中已经讲述了从程序流程图导出流图的方法。在正常情况下流图是连通的有向图。满足点覆盖标准要求选取足够多的测试数据,使得程序执行路径至少经过流图的每个结点一次,由于流图的每个结点与一条或多条语句相对应,显然,点覆盖标准和语句覆盖标准是相同的。

    7.边覆盖和路径覆盖

    图论中边覆盖的定义是:如果连通图 G 的子图 G” 是连通的,而且包含 G 的所有边,则称 G″ 是 G 的边覆盖。为了满足边覆盖的测试标准,要求选取足够多测试数据,使得程序执行路径至少经过流图中每条边一次。通常边覆盖和判定覆盖是一致的。 路径覆盖的含义是,选取足够多测试数据,使程序的每条可能路径都至少执行一次(如果程序图中有环,则要求每个环至少经过一次)。

    7.6.2.控制结构测试

    基本路径测试是Tom McCabe 提出的一种白盒测试技术。使用基本路径测试设计测试用例时,首先计算程序的环形复杂度,并用该复杂度为指南定义执行路径的基本集合,从该基本几个导出的测试用例可以保证程序中的每条语句至少执行一次,而且每个调教在执行时都将分别取真、假两种值。

  • 使用基本路径测试技术设计测试用例的步骤如下:

  1. 根据过程设计结果画出相应的流图。

    1. 例如,为了用基本路径测试技术测试下列的用PDL描述的求平均值过程,首先画出下图所示的流图。注意,为了正确地画出流图,这里把被映射为流图结点的PDL语句编了序号。 <br />![image.png](https://cdn.nlark.com/yuque/0/2020/png/1118250/1586824920495-f4c20ae7-a5a3-4e07-9a96-4a5169627411.png#align=left&display=inline&height=415&margin=%5Bobject%20Object%5D&name=image.png&originHeight=829&originWidth=1369&size=178237&status=done&style=none&width=684.5)
  2. 计算流图的环形复杂度。

    环形复杂度定量度量程序的逻辑复杂性。使用第6.5.1小节讲述的3种方法之一计算环形复杂度。经计算,流图 的环形复杂度为6。

  3. 确定线性独立路径的基本集合。

独立路径是指至少引入程序的一个新处理语句集合或一个新条件的路径,即独立路径至少包含一条在定义该路径之前不曾用过的边。 程序的环形复杂度决定了程序中独立路径的数量,而且这个数是确保程序中所有语句至少被执行一次所需的测试数量的上界。上述程序的环形复杂度为6,因此共有6条独立路径。
路径1:1-2-10-11-13
路径2:1-2-10-12-13
路径3:1-2-3-10-11-13
路径4:1-2-3-4-5-8-9-2-
路径5:1-2-3-4-5-6-8-9-2-…
路径6:1-2-3-4-5-6-7-8-9-2-…

  1. 设计可强制执行基本集合中每条路径的测试用例

    1. 应该选取测试数据使得在测试每条路径时都适当地设置好各个判定结点的条件。测试第 3 步得出的基本集合 的测试用例如下。<br /> 路径1的测试用例:<br /> value[k]=有效输入值,其中 k<ii 的定义在下面)<br /> value [i]=-999,其中 2i100<br /> 预期结果:基于k的正确平均值和总数<br /> 注意,路径1无法独立测试,必须作为路径 4 5 6 的一部分来测试。<br /> 路径2的测试用例:<br /> value[1]=-999<br /> 预期结果:average=-999,其他都保持初始值
  2. 条件测试(了解)

    1. ![image.png](https://cdn.nlark.com/yuque/0/2020/png/1118250/1586826909591-f108ef5e-f374-4203-85f4-d38eb80522f7.png#align=left&display=inline&height=337&margin=%5Bobject%20Object%5D&name=image.png&originHeight=674&originWidth=1117&size=370995&status=done&style=none&width=558.5)

    7.7 黑盒测试技术

    黑盒测试着重测试软件功能。黑盒测试并不能取代白盒测试,它是与白盒测试互补的测试方法,它很可能发现白盒 测试不易发现的其他类型的错误。黑盒测试力图发现下述类型的错误:

  3. 功能不正确或遗漏了功能;

  4. 界面错误;
  5. 数据结构错误或外部数据库访问错误;
  6. 性能错误;
  7. 初始化和终止错误。

    7.7.1 等价划分

    等价分类:就是把输入数据的可能值划分为若干等价类(输入域的子集合,各个输入数据对于揭露程序中的错误都是等价的)。在每一个等价类中取一个数据作为测试的输入条件,这样就可以少量的代表性测试数据,来取得较好的测试结果。
    有效等价类:是指对于程序的规格说明来说,是合理的有意义的输入数据构成的集合。利用它可以检验程序是否实现预先规定的功能和性能。
    无效等价类:是指对于程序的规格说明来说,是不合理的,是无意义的输入数据构成的集合。程序员主要利用这一类测试用例来检查程序中功能和性能的实现是否不符合规格说明要求。
    确定等价类的原则:1、如果输入条件规定了取值范围,或者是值的个数,则可以确立一个有效等价类和两个无效
    等价类。2、如果输入条件规定了输入值的集合,或者是规定了“必须如何”的条件,这时 可确立一个有效等价类和一个无效等价类。4、如果规定了输入数据必须遵守的规则,则可以确定一个有效等价类(符合规则),和若干个无效等价类(从不同角度违反则)。(5)如果规定了输入数据为整型,则可以划分出正整数、零和负整数3个有效类。 (6)如果程序的处理对象是表格,则应该使用空表,以及含一项或多项的表。
    划分出等价类以后,根据等价类设计测试方案时主要使用下面两个步骤:**
    (1) 设计一个新的测试用例,使其尽可能多地覆盖未被覆盖的有效等价类,此项工作重复进行,直到所有的有效等价类都被覆盖为止。
    (2) 设计一个新的测试用例,使其覆盖一个(而且仅仅一个)尚未被覆盖的无效等价类,此项工作重复进行,直到所有的无效等价类都被覆盖为止。

    7.7.2.边界值分析

    7.7.3 错误推测

    直觉+经验
    基本思路:列举出程序中可能有的错误和容易发生错误的特殊情况,并且根据他们选择测试方案。

    7.8 调试

    “找出错误的位置,并设法改正”
    image.png
    常用方法:
    (1)试探法:猜测故障位置,检查程序获得对错误的准确定位。
    (2)回溯法:从发现症状的地方开始,沿程序的控制流往回追踪源程序代码,以找出错误原因。
    (3)对分查找法:定位关键点,运行定位错误。
    (4)归纳法:通过错误数据,查找并排除错误。
    (5)演绎法:设想错误原因,通过测试逐个排除。

    7.9 软件可靠性

    7.9.1

    一段时间内,软件能够正常运行的概率

    7.9.2 估算平均无故障时间的方法

    image.png
    image.png
    image.png
    image.png

    7.10习题

    image.png
    输入数据,输出结果,执行路径
输入数据 输出数据 执行路径
x y z z
语句覆盖 1 1 2 4 abd
判定覆盖 1 1 1 2 abe
0 1 2 4 acd
条件覆盖 2 1 2 3 abd
0 0 1 1 ace
分支/条件覆盖 2 1 2 3 abd
0 0 1 1 ace
条件组合覆盖 2 1 4 4 abd
2 0 1 2 acd
0 1 4 6 acd
0 0 1 1 ace