第七章-测试（下）

第七章-测试

1)了解软件测试的目标，测试的过程和步骤。
2)掌握软件工程测试阶段中单元测试、集成测试、确认测试中的相关内容。
3)掌握软件调试中的概念及主要工作，调试与测试的区别，调试的步骤及主要的调试方法。
4)掌握软件测试方法中白盒测试及黑盒测试原理，掌握等价类划分、边界值分析、路径覆盖、条件覆盖等测试用例设计技术。

1、白盒测试

（1）语句覆盖

设计若干个测试用例，运行被测程序，使得每一个可执行语句至少执行一次。

只关心判定表达式的值，而没有分别测试判定表达式中每个条件取不同值时的情况。

对程序的逻辑覆盖很少

（2）判定覆盖（分支覆盖）

不仅每个语句必须至少执行一次，而且每个判定的每种可能的结果都应该至少执行一次，也就是每个判定的每个分支都至少执行一次。

比语句覆盖强，但是对程序逻辑的覆盖程度仍然不高

（3）条件覆盖

不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取到各种可能的结果。

通常比判定覆盖强，但也有相反的情况

（4）判定/条件覆盖

选取足够多的测试数据，使得判定表达式中的每个条件都取到各种可能的值，而且每个判定表达式也都取到各种可能的结果。

同时满足判定覆盖和条件覆盖

有时判定/条件覆盖也并不比条件覆盖更强

（5）条件组合覆盖

选取足够多的数据，使得每个判定表达式中的条件的各种可能组合都至少出现一次。

同时满足判定覆盖、条件覆盖和判定/条件覆盖

最强，但并不一定能使程序中的每条路径都执行到。

（6）路径覆盖

选取足够多的测试数据，使程序的每条可能路径都至少执行一次（如果程序图中有环，则要求每个环至少经过一次）。

（7）边覆盖

要求选取足够多的测试数据，使得程序执行路径至少经过流图中每条边一次。

定义：如果连通图G的子图G‘’是连通的，而且包含G的所有边，则称G‘’是G的边覆盖。

边覆盖标准和判定覆盖标准是相同的。

（8）点覆盖

要求选取足够多的测试数据，使得程序执行路径至少经过流图的每个结点一次。

定义：如果连通图G的子图G‘是连通的，而且包含G的所有结点，则称G’是G的点覆盖。

流图是连通的有向图。

点覆盖标准和语句覆盖标准是相同的。

控制结构测试

• 基本路径测试
• 条件测试
• 循环测试

2、黑盒测试

（1）等价划分

等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的。测试某等价类的代表值就等价于对这一类其它值的测试。

等价类划分法是一种典型的黑盒测试方法，使用这一方法时，完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。

把程序的输入域划分成若干个数据类，据此导出测试用例。

力图设计出能发现若干类程序错误的测试用例，从而减少必须设计的测试用例的数目。

使用等价划分设计测试方案首先需要划分输入数据的等价类，为此需要研究程序的功能说明，从而确定输入数据得到有效等价类和无效等价类。

在确定输入数据的等价类时常常还需要分析输出数据的等价类，以便根据输出数据的等价类导出对应的输入数据等价类。

等价类的划分有两种不同的情况

• 有效等价类
  是指对于程序的规格说明来说，是合理的、有意义的输入数据构成的集合。
• 无效等价类
  是指对于程序的规格说明来说，是不合理的、无意义的输入数据构成的集合。

在设计测试用例时，要同时考虑有效等价类和无效等价类的设计。

划分等价类的原则：

• 如果规定了输入值的范围，则可以划分出一个有效的等价类（输入值在此范围内）和两个无效的等价类（小于最小值或大于最大值）。
• 如果规定了输入数据的个数，则类似地也可以划分出一个有效的等价类和两个无效的等价类。
• 如果规定了输入数据的一组值，而且程序对不同输入值做不同处理，则每个允许的输入值是一个有效的等价类，此外还有一个无效的等价类（任一个不允许的输入值）。
• 如果规定了输入数据必须遵守的规则，则可以划分出一个有效的等价类（符合规则）和若干个无效的等价类（从各种角度违反规则）。
• 如果输入条件规定了输入值的集合，或者是规定了“必须如何”的条件，这时可确立一个有效等价类和一个无效等价类。
• 如果规定了输入数据为整型，则可以划分出正整数、零和负整数三个有效类。
• 如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类。
• 如果程序的处理对象是表格，则应该使用空表，以及含一项或多项的表。

根据等价类设计测试方案时的步骤：

• 设计一个新的测试方案以尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步骤直到所有有效等价类都被覆盖为止。
• 设计一个新的测试方案，使他覆盖一个而且只覆盖一个尚未被覆盖的无效等价类，重复这一步骤直到所有无效等价类都被覆盖为止。
  因为程序发现一类错误后就不再检查是否还有其他错误

确立测试用例
在确立了等价类之后，建立等价类表，列出所有划分出的等价类。

输入条件	有效等价类	无效等价类
…	…	…

从划分出的等价类中按以下原则选择测试用例：

• 为每一个等价类规定一个唯一的编号
• 设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止
• 设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止

（2）边界值分析

边界值分析是一种黑盒测试方法，是对等价类划分方法的补充。

人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

使用边界值分析方法设计测试用例，首先应确定边界情况。应当选取正好等于，刚刚大于，或刚刚小于边界的值做为测试数据，而不是选取等价类中的典型值或任意值做为测试数据。

（3）错误推测法

基本想法：列举出程序中可能有的错误和容易发生错误的特殊情况，并且根据他们选择测试方案。

很大程度上靠直觉和经验进行。

在一段程序中已经发现的错误数目往往和尚未发现的错误数成正比，因此，在进一步测试时要着重测试那些已经发现了较多错误的程序段。

3、系统测试

（1）α测试

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。

目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持）。尤其注重产品的界面和特色。

α测试可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。

（2）β测试

β测试是由软件的多个用户在实际使用环境下进行的测试。这些用户返回有关错误信息给开发者。

β测试主要衡量产品的FLURPS。着重于产品的支持性，包括文档、客户培训和支持产品生产能力。

只有当α测试达到一定的可靠程度时，才能开始β测试。它处在整个测试的最后阶段。

4、调试

任务：设法确定错误的准确位置并且改正它

由程序的编写者负责

是在进行了成功的测试之后才开始的工作。它与软件测试不同，调试的任务是进一步诊断和改正程序中潜在的错误。

调试活动由两部分组成:

• 确定程序中可疑错误的确切性质和位置。
• 对程序(设计,编码)进行修改，排除这个错误。

调试的步骤：
执行一个测试用例 → 评估测试结果 → 如果发现实际结果与预期结果不一致，则这种不一致就是一个症状，它表明在软件中存在着隐藏的问题。

• 从错误的外部表现形式入手，确定程序中出错位置。
• 研究有关部分的程序，找出错误的内在原因。
• 修改设计和代码，以排除这个错误。
• 重复进行暴露了这个错误的原始测试或某些有关测试。

调试的方法：

调试的关键在于推断程序内部的错误位置及原因。

1. 蛮干法
   目前使用较多，但效率较低。不需要过多的思考，比较省脑筋。
   让计算机自己寻找错误的策略。
   在程序中到处写上WRITE语句。
2. 回溯法
   调试小程序
   做法：从发现症状的地方开始，人工沿程序的控制流往回追踪分析源程序代码，直到找出错误原因为止。
   一旦发现了错误，先分析错误征兆，确定最先发现“症状”的位置。然后，人工沿程序的控制流程，向回追踪源程序代码，直到找到错误根源或确定错误产生的范围。
3. 原因排除法
   • 归纳法
     从个别现象推断出一般性结论
     首先把和错误有关的数据组织起来进行分析，以便发现可能的错误原因。然后导出对错误原因的一个或多个假设，并且利用已有的数据来证明或排除这些假设。
     从一些线索（错误征兆）着手，通过分析它们之间的关系来找出错误。
     A.收集有关的数据
     列出所有已知的测试用例和程序执行结果。看哪些输入数据的运行结果是正确的，哪些输入数据的运行结果有错误。
     B.提出假设
     分析线索之间的关系，利用在线索结构中观察到的矛盾现象，设计一个或多个关于出错原因的假设。
     C.组织数据
     常以3W1H形式组织可用的数据:
     "What”列出一般现象;
     "Where”说明发现现象的地点;
     "When”列出现象发生时所有已知情况;
     "How”说明现象的范围和量级。
     D.证明假设
     把假设与原始线索或数据进行比较，若它能完全解释一切现象，则假设得到证明;否则，就认为假设不合理，或不完全，或是存在多个错误，以致只能消除部分错误。
   • 对分查找法
     如果已经知道每个变量在程序内若干个关键点的正确值，则可以用赋值语句或输入语句在程序中点附近“注入”这些变量的正确值，然后运行程序并检查所得到的输出。
     如果输出结果是正确的，则错误原因在程序的前半部分；
     反之，错误原因在程序的后半部分。
   • 演绎法
     从一般原理或前提出发，经过排除和精化的过程推导出结论。
     首先设想出所有的出错原因，然后试图用测试来排除每一个假设的原因。如果测试表明某个假设的原因可能是真的原因，则对数据进行细化以准确定位错误。