大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。

Jetbrains全系列IDE使用 1年只要46元 售后保障 童叟无欺

1、黑盒测试概念

       黑盒测试法也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。

       黑盒测试主要发现以下类型的错误：

1. 基于规格说明的功能错误
2. 基于规格说明的构件或系统行为错误
3. 基于规格说明的性能错误
4. 面向用户的使用错误
5. 黑盒接口错误

2、黑盒测试特点

       “黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。

       黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。

       总体来说，黑盒测试有以下特点：

1. 对于更大的代码单元来说（子系统甚至系统级）比白盒测试效率要高；
2. 测试人员不需要了解软件的实现细节，包括特定的编程语言；
3. 从用户的视角进行测试，很容易被理解和接受；
4. 有助于暴露任何规格不一致或有歧义的问题；
5. 没有清洗和简明的规格，测试用例很难设计；
6. 不能控制内部执行路径，会有很多内部程序路径没有被测试到；
7. 不能直接针对特定的程序段，这些程序可能非常复杂（因此可能隐藏更多的问题）

3、黑盒测试方法

3.1、等价类划分法

       等价类划分法是把程序的输入域划分成若干部分（子集），然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。

3.1.1、等价类划分法的应用

       等价类划分法将程序所有可能的输入数据（有效的和无效的）划分成若干个等价类。然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类，测试用例由有效等价类和无效等价类的代表组成，从而保证测试用例具有完整性和代表性。利用这一方法设计测试用例可以不考虑程序的内部结构，以需求规格说明书为依据，选择适当的典型子集，认真分析和推敲说明书的各项需求，特别是功能需求，尽可能多地发现错误。等价类划分法是一种系统性的确定要输入的测试条件的方法。
       由于等价类是在需求规格说明书的基础上进行划分的，并且等价类划分不仅可以用来确定测试用例中的数据的输入输出的精确取值范围，也可以用来准备中间值、状态和与时间相关的数据以及接口参数等，所以等价类可以用在系统测试、集成测试和组件测试中，在有明确的条件和限制的情况下，利用等价类划分技术可以设计出完备的测试用例。

3.1.2、有效等价类划分

       有效等价类指对于程序规格说明来说，是合理的、有意义的输入数据构成的集合。利用有效等价类可以检验程序是否实现了规格说明预先规定的功能和性能。有效等价类可以是一个，也可以是多个，根据系统的输入域划分若干部分，然后从每个部分中选取少数有代表性数据当做数据测试的测试用例，等价类是输入域的集合。

3.1.3、无效等价类划分

       无效等价类和有效等价类相反，无效等价类是指对于软件规格说明而言，没有意义的、不合理的输入数据集合。利用无效等价类，可以找出程序异常说明情况，检查程序的功能和性能的实现是否有不符合规格说明要求的地方。

3.1.4、等价类划分的方法

       按区间划分:在输入条件规定的取值范围或值的个数的情况下，可以确定一个有效等价类和两个无效等价类。
      按数值划分:在规定了输入数据的一组值中（假定有n个值），并且程序要对每个输入值分别处理的情况下，可以确定n个有效等价类和一个无效等价类。
      按数值集合划分:在规定输入数据必须遵守的规则的情况下，可以确定一个有效等价类和若干个无效等价类。
      按限制条件或规划划分:在输入条件规定了输入值的集合或规定了“必须如何”的条件下，可以确定一个有效等价类和一个无效等价类。
      按处理方式划分:在确定已划分的等价类中各元素在程序处理中的方式不同的情况下，则应将该等价类进一步地划分为更小的等价类。

3.1.5、等价类划分的原则

    1、依据常用的原则划分等价类
    2、为每一个等价类规定唯一的编号
    3、设计一个新的测试用例，使其尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步，直到所有有效等价类都被覆盖为止。
    4、设计一个新的测试用例，使其覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等类都被覆盖为止。

3.1.6、等价类划分实例

假设要输入一个日期，日期限定在1990年1月~2049年12月，并规定日期由6位数字字符组成，前4位表示年，后2位表示月。现用等价类划分法设计测试用例，来测试程序的”日期检查功能”。
1)划分等价类并编号,下表等价类划分的结果

2)设计测试用例，以便覆盖所有的有效等价类在表中列出了3个有效等价类，编号分别为①、⑤、⑧，设计的测试用例如下：

3)为每一个无效等价类设计一个测试用例，设计结果如下：

3.2、边界值分析法

3.2.1、概念

       边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

3.2.2、边界值分析法应用

       根据大量的测试统计数据，很多错误是发生在输入或输出范围的边界上，而不是发生在输入/输出范围的中间区域。因此针对各种边界情况设计测试用例，可以查出更多的错误。
       使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

3.2.3、边界值分析法与等价值划分法的区别

       边界值分析使用与等价类划分法相同的划分，只是边界值分析假定错误更多地存在于划分的边界上，因此在等价类的边界上以及两侧的情况设计测试用例。
       边界值分析法与等价类分析法的区别：
       1、边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。
       2、边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。入条件，还要考虑输出空间产生的测试情况。

3.2.4、边界值分析

       通常情况下，软件测试所包含的边界检验有几种类型：数字、字符、位置、重量、大小、速度、方位、尺寸、空间等。相应地，以上类型的边界值应该在：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、  最短/最长、 空/满等情况下。利用边界值作为测试数据.

3.2.5、内部边界值

       在多数情况下，边界值条件是基于应用程序的功能设计而需要考虑的因素，可以从软件的规格说明或常识中得到，也是最终用户可以很容易发现问题的。然而，在测试用例设计过程中，某些边界值条件是不需要呈现给用户的，或者说用户是很难注意到的，但同时确实属于检验范畴内的边界条件，称为内部边界值条件或子边界值条件。
       内部边界值条件主要有下面几种：
      1、数值的边界值检验：计算机是基于二进制进行工作的，因此，软件的任何数值运算都有一定的范围限制。

      2、字符的边界值检验：在计算机软件中，字符也是很重要的表示元素，其中ASCII和Unicode是常见的编码方式。如下列出了一些常用字符对应的ASCII码值。

      3、其它边界值检验：在不同的行业应用领域，依据硬件和软件的标准不同而具有各自特定的边界值。如下列出部分手机相关的边界值：

3.2.6、边界值分析原则

       1、如果输入条件规定了值的范围，则应取刚达到这个范围的边界值，以及刚刚超越这个范围边界的值作为测试输入数据。
      2、如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少1，比最大个数多1的数作为测试数据。
      3、根据规格中每个输出条件，使用原则1，如果输出条件规定了值的范围，则应取刚达到这个范围的边界值，以及刚刚超越这个范围边界的值作为测试输入数据。
      4、根据规格中每个输出条件，使用原则2，如果输出条件规定了值的个数，则用最大个数、最小个数，比最小个数少1，比最大个数多1的数作为测试数据。
      5、如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。
      6、分析规格说明，找出其他可能的边界条件。

3.3、错误推测法

3.3.1、概念

       错误推测法是指：在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。
       错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例.
       总之，就是进行错误的操作。

3.3.2、错误推测法的应用

1.     例如, 输入数据和输出数据为0的情况；输入表格为空格或输入表格只有一行。 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。
2.     例如，前面例子中成绩报告的程序，采用错误推测法还可补充设计一些测试用例：
        1)     程序是否把空格作为回答
       2)     在回答记录中混有标准答案记录
       3)     除了标题记录外，还有一些的记录最后一个字符即不是2也不是3
       4)     有两个学生的学号相同
       5)     试题数是负数
3.     例如，测试一个对线性表（比如数组）进行排序的程序，可推测列出以下几项需要特别测试的情况：
       1)    输入的线性表为空表；
       2)    表中只含有一个元素；
       3)    输入表中所有元素已排好序；
       4)    输入表已按逆序排好；
       5)    输入表中部分或全部元素相同。
4.     例如，测试手机终端的通话功能，可以设计各种通话失败的情况来补充测试用例：
       1)    无SIM 卡插入时进行呼出（非紧急呼叫）
       2)    插入已欠费SIM卡进行呼出
       3)    射频器件损坏或无信号区域插入有效SIM卡呼出
       4)    网络正常，插入有效SIM卡，呼出无效号码（如1、888、333333、不输入任何号码等）
       5)    网络正常，插入有效SIM卡，使用“快速拨号”功能呼出设置无效号码的数字

3.3.3、网上常见的用例参考

3.4、因果图

3.4.1、概念

       等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。
      如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）

3.4.2、因果图涉及的概念

1、因果图的介绍

      1)    4种符号分别表示了规格说明中向4种因果关系。
      2)    因果图中使用了简单的逻辑符号，以直线联接左右结点。左结点表示输入状态（或称原因），右结点表示输出状态（或称结果）。
      3)    C1表示原因，通常置于图的左部；e1表示结果，通常在图的右部。C1和e1均可取值0或1，0表示某状态不出现，1表示某状态出现

2、因果图的关系

• 恒等：若c1是1，则e1也是1；否则e1为0。
• 非：若c1是1，则e1是0；否则e1是1。
• 或：若c1或c2或c3是1，则e1是1；否则e1为0。“或”可有任意个输入。
• 与：若c1和c2都是1，则e1为1；否则e1为0。“与”也可有任意个输入。

3、因果图的约束

       输入状态相互之间还可能存在某些依赖关系，称为约束。例如, 某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。
（1）、输入条件的约束有以下4类：

• E约束（互斥）：a和b中至多有一个可能为1，即a和b不能同时为1。
• I约束（包含）：a、b和c中至少有一个必须是1，即 a、b 和c不能同时为0。
• O约束（唯一）；a和b必须有一个，且仅有1个为1。
• R约束（要求）：a是1时，b必须是1，即不可能a是1时b是0。
• M约束（屏蔽）：表示若a是1是，b必须为0，既不可出现a=1且b=1的情况。

（2）、输出条件约束类型
       输出条件的约束只有M约束（强制）：若结果a是1，则结果b强制为0。

3.4.3、因果图的应用

       因果图在软件测试用例设计过程中，用于描述被测对象输入与输入、输入与输出之间的约束关系。因果图的绘制过程，可以理解为用例设计者针对因果关系业务的建 模过程。根据需求规格，绘制因果图，然后得到一个盘点表进行用例设计，通常理解因果图为判定表的前置过程，当被测对象因果关系较为简单时，可以直接使用判 定表设计用例，如若不然可使用因果图与判定表结合的方法设计用例。

3.4.4、因果图测试用例设计方法

1)   分割功能说明书
       分析需求规格说明书，将输入条件分成若干组，然后分别对每个组使用因果图，这样可以减少输入条件组合的数目。
2）识别“原因”和“结果”，并加以编号。
       “原因”是指输入条件或输入条件的等价类；“结果”是指输出条件或系统变换，如更新主文件就是一种系统变换。
       每个原因和结果都对应与因果图中的一个结点，当原因或结果成立（或出现）时，相应的节点的值记为1，否则记为0.
3）根据功能说明中规定的原因和结果之间的关系画出因果图。
       因果图的基本符号如下图所示：

       图中左边的结点表示原因，右边的结点表示结果。原因和结果之间的关系有恒等、非、或、与，其含义如下。
       在画因果图时，原因在左，结果在右，由上向下排列，并根据功能说明中规定的原因和结果之间的关系，用上述符号连接起来，必要时，可在因果图中加入一些中间结点。
4）根据功能说明在因果图中加上约束。
       因果图中表示约束条件的符号如下所示：

5）根据因果图画出判定表
       列出满足约束条件的所有原因组合，写出各种原因组合下的结果，必要时可在判定表中加上中间点，如下表所示：

6）根据判定表设计测试用例
       为上面判定表的每一列设计一个测试用例。

3.4.5、实例

      饮料自动售货机允许投入5角和1元的硬币，用户可通过“橙汁”和“啤酒”按钮选择饮料，售货机中无零钱找时提示灯亮。当用户投入5角硬币并押下“橙汁”或“啤酒”按钮后，售货机送出相应的饮料。当用户投入1元硬币并押下“橙汁”或“啤酒”按钮后，如果售货机有零钱找，则送出相应的饮料，并退还5角硬币；如果售货机没有零钱找，则饮料不送出，并且退还1元硬币。
       （1）、分析规格说明，列出原因和结果
根据规格说明，反映原因的输入条件有：投入1元硬币，投入5角硬币，押下“橙汁”按钮，押下“啤酒”按钮。反映结果的输出条件有：退还1元硬币，退还5角硬币，送出“橙汁”饮料，送出“啤酒”饮料。由于“售货机有零钱找”是在投入1元硬币时判断是否能找零钱的依据，所以也可把它看作是一个输入条件，即原因。与之对应的结果是售货机指示灯亮（或暗）。
       因此，本例的原因和结果如下：
原因：
1——售货机有零钱找
2——投入1元硬币
3——投入5角硬币
4——押下橙汁按钮
5——.押下啤酒按钮

结果：
21——售货机〖零钱找完〗灯亮    
22——退还1元硬币
23——退还5角硬币              
24——送出橙汁饮料
25——送出啤酒饮料
（2）、所有原因节点列在左边，结果结点列在右边，画出因果图，如下图所示：

其中中间结点的含义如下：
结点11表示投入1元硬币且押下饮料按钮。
结点12表示押下“橙汁”或“啤酒”按钮。
结点13表示应找5角硬币且售货机有零钱找。
结点14表示钱已付清。
（3）、在因果图中加上约束条件
由于原因2和3不能同时发生，原因4和5也不能同时发生，所以需加约束条件E，如上图。
（4）、根据因果图画出判定表
根据因果图画出判定表如下：

其中阴影部分表示不可能出现的原因条件组合，此外当原因2,3,4,5均为0时，表示既没有投硬币也没有押按钮，此时表示售货机处于无人使用状态，因此也不必为他们设计测试用例。
（5）、为判定表的每个有意义的列设计一个测试用例。

3.5、判定表/决策表驱动法

3.5.1、判定表驱动法概念

       判定表是黑盒测试的方法之一，判定表是把作为条件的所有输入的各种组合值以及对应输出值都罗列出来而形成的表格。它能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。
       因此，利用判定表能够设计出完整的测试用例集合。在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。

3.5.2、判定表的组成

1)    条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
2)    动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
3)    条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。
4)    动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。
5)    规则：  任何一个条件组合的特定取值及其要执行的相应操作。在判定表中贯穿条件项和动作项的一列就是一条规则。

3.5.3、优点缺点

优点：它能把复杂的问题按各种可能的情况一一列举出来，简明而易于理解，也可避免遗漏。
缺点：不能表达重复执行的动作，例如循环结构。

3.5.4、适用条件

B. Beizer 指出了适合使用判定表设计测试用例的条件：

• 规格说明以判定表形式给出,或很容易转换成判定表。
• 条件的排列顺序不会也不影响执行哪些操作。
• 规则的排列顺序不会也不影响执行哪些操作。
• 每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则。
• 如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要。

B. Beizer提出这5个必要条件的目的是为了使操作的执行完全依赖于条件的组合。其实对于某些不满足这几条的判定表，同样可以借以设计测试用例，只不过尚需增加其它的测试用例罢了。

3.5.5、判定表的建立步骤

• 确定规则的个数.假如有n个条件。每个条件有两个取值（0,1）,故有 clip_image006种规则。
• 列出所有的条件桩和动作桩。
• 填入条件项。
• 填入动作项。得到初始判定表。
• 简化判定表（合并相似规则（相同动作））,如下表所示，左侧的两列均可以合并为右侧一列

3.5.6、判定表建立实例

给出三个任意正数a、b、c判断其能否构成三角形及三角形按边分类的类型
1、 确定规则的个数，先定义条件个数，如下：
三角形按照边分为：等腰三角形、等边三角形、一般三角形
根据分析，确定条件如下：
a<b+c、b<a+c、c<a+b、a=b、b=c、c=a，故规则的个数有2的6次方64个
2、初始判定表

上述判定表已经是合并相同规则后的表格，经过简化后（去除不可能条件）得到最终判定表如下：

根据上述判定表，得到用例如下：

3.6、状态迁移法

3.6.1、状态迁移法概念

       许多需求用状态机的方式来描述，状态机的测试主要关注在测试状态转移的正确性上面。对于一个有限状态机，通过测试验证其在给定的条件内是否能够产生需要的状态变化，有没有不可达的状态和非法的状态。可能不可能产生非法的状态转移等。对于被测系统，若我们可以抽象出它的若干个状态，以及这些状态之间的切换条件和切换路径，那么就可以从状态迁移路径覆盖的角度来设计用例对该系统进行测试。状态迁移法的目标是设计足够的用例达到对系统状态的覆盖、状态-条件组合的覆盖以及状态迁移路径的覆盖。
       状态迁移法的思想是提供将多个状态的转换串联起来进行测试的思路。该方法适合测试各种状态的转换，而且这些状态转换的测试在实践中是易遗漏的。例如像手机、MP3等，都可以使用状态迁移法对使用状态的迁移（即用户使用场景的转换）进行测试。

3.6.2、使用状态迁移法的条件

       被测系统的功能依赖于数据的状态，像常见的工作流系统（OA），对于这类软件状态迁移法就在合适不过了。
       1、针对有限状态机的测试方法
       2、给一个触发条件
       3、常应用于WEb页面转换、自动化测试、通信协议测试等

3.6.3、状态迁移图法设计用例步骤

1、分析需求规格说明书，找出状态和触发条件（分析状态条件之间有哪些关系）
2、画出状态迁移图（设定一个初始状态、初始状态是相对而言的，状态用圆圈表示，条件用带有箭头的线段表示）3、通过状态图画出状态–事件表（四列，上一状态，条件，下一状态，表现的行为动作信息）
4、从状态转换树推导出测试路径
5、根据测试路径编写合法测试用例
6、编写非法测试用例

3.6.4、具体实例

       打印机初始处于就绪的状态下，可以接收打印的任务，进入打印状态，开始打印；在打印的过程中，如果打印机出现故障，打印机将处于故障状态，等待修复故障；故障修复后，打印机恢复打印状态，继续打印原来的文档；在打印过程中，如果纸张用完，打印机将暂停打印，处于缺纸状态，当放入印纸后，打印机会自动检测，恢复打印状态，继续开始打印；打印任务完成，打印机恢复就绪状态
       步骤：
      1、分析需求片段，找出所有状态以及状态之间的跳转条件
      状态：就绪，打印，故障，缺纸
      跳转条件：打印指令，出现故障，故障修复，缺纸 ，放入纸张，打印完毕
      2、设定初始状态，画出状态迁移图。

       3、生成状态时间表

       4、生成状态转换树

5、从状态树推导出测试路径：
             就绪—打印—缺纸—打印
             就绪—打印—故障—打印
             就绪—打印—就绪
6、根据测试路径编写测试用例
7、添加非法的测试用例
       比如直接就绪状态—-故障状态或者 就绪—-缺纸等

3.6.5、总结

       状态迁移法实际测试了被测系统各种状态的转换，这些状态转换的测试在实际工作中是容易遗漏的，只要能够将这些状态的转换测试到，是否采用状态迁移法并不重要，因为状态迁移法只是提供了一种将多个状态的转换串联起来进行测试的思路（思维模式）。
       实际工作中，在业务流程中都涉及到了复杂的业务场景（即业务状态的迁移）。而这些业务场景在需求规格中往往不能够完全阐述清楚，容易出现遗漏。所以当被测系统的业务场景复杂时，在工程中应用这种针对状态迁移测试的思路完成对复杂业务场景的测试有时是很有必要的。

3.7、正交实验法

3.7.1、正交实验法概念

       利用因果图来设计测试用例时，作为输入条件的原因与输出结果之间的因果关系，有时很难从软件需求规格说明中得到往往因果关系非常庞大，以至于据此因果图而得到的测试用例数目多的惊人，给软件测试带来沉重的负担，为了有效地，合理地减少测试的工时与费用，可利用正交试验设计方法进行测试用例的设计。
       研究多因素多水平的一种设计方法。它是根据正交性从全面试验中挑选出部分有代表性的点进行试验，这些有代表性的点具备了“均匀分散，齐整可比”的特点，正交试验设计是一种基于正交表的、高效率、快速、经济的试验。
       正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。
      例如，要考察正常值、错误值和边界值对某软件界面的影响。每个因素设置3个水平进行试验。A因素是正常值，设 A 1、A 2 、A 3  3个水平；B因素是错误值，设B1 、B 2 、B 3  3 个水平；C 因素为边界值，设C 1、C 2 、C 3  3个水平。这是一个3 因素 3 水平的试验，各因素的水平之间全部可能组合有27(即3^3)种。
       全面试验:可以分析各因素的效应，交互作用，也可选出最优水平组合。但全面试验包含的水平组合数较多，工作量大，在有些情况下无法完成。
      若试验的主要目的是寻求最优水平组合 ，则可利用正交表来设计安排试验。正交试验设计的基本特点是:用部分试验来代替全面试验，通过对部分试验结果的分析，了解全面试验的情况。正因为正交试验是用部分试验来代替全面试验的 ，它不可能像全面试验那样对各因素效应、交互作用一一分析；当交互作用存在时，有可能出现交互作用的混杂。虽然正交试验设计有上述不足，但它能通过部分试验找到最优水平组合，因而很受实际工作者青睐。
      如对于上述 3 因素 3 水平试验 ，若不考虑交互作用，可利用正交表L9(33) 安排，它表示需作9次实验，最多可观察3个因素，每个因素均为3水平，试验方案仅包含9个水平组合，就能反映试验方案包含27个水平组合的全面试验的情况，找出最佳的生产条件。
       这种方法的优点是试验次数少,效果好,方法简单,使用方便，效率高。

3.7.2、正交实验法步骤

      (1)  确定因素
       这里的因素是指对软件运行结果有影响的软件
      (2)  确定因素的取值范围或集合(该步是为步骤3做准备的)
      因素的取值范围是指软件输入的取值范围或集合以及可用的硬件资源。
      (3)  确定每个因素的水平
      根据因素的取值范围或集合 ,采用等价类划分、边界值分析以及其他软件测试技术,在每个因素的取值范围或集合内挑选出有效等价类、无效等价类、正好等于、刚刚大于或刚刚小于边界值等有代表性的测试值。
      (4)  选择正交表
      根据确定的因素和水平 ,选择适合的正交表。
      如果没有合适的正交表可用或需要的测试用例个数太多 ,要对因素和水平进行调整。
      (5)  测试结果分析
      加上你认为可疑且没有在表中出现的组合。

3.7.3、正交表

      将正交试验选择的水平组合，列成表格，称为正交表。
      正交表的构成：
      (1)、行数(Runs)：正交表中的行的个数，即试验的次数，也是通过正交实验法设计的测试用例的个数
      (2)、因素数(Factors)：正交表中列的个数，即要测试的功能点。
      (3)、水平数(Levels)：任何单个因素能够取得的值的最大个数，即要测试功能点的输入值
      (4)、L行数(水平数因素数)，
      正交表具有以下两个特点，即正交性。正交表必须满足这两个特点，有一条不满足，就不是正交表。
      1）每列中不同数字出现的次数相等。这一特点表明每个因素的每个水平与其它因素的每个水平参与试验的几率是完全相同的，从而保证了在各个水平中最大限度地排除了其它因素水平的干扰，能有效地比较试验结果并找出最优的试验条件。
      2）在任意2列其横向组成的数字对中，每种数字对出现的次数相等。这个特点保证了试验点均匀地分散在因素与水平的完全组合之中，因此具有很强的代表性。

3.7.4、如何选择正交表

–考虑因素（变量）的个数
 –考虑因素水平（变量的取值）的个数
 –考虑正交表的行数
 –取行数最少的一个

3.7.5、正交表实验法应用实例

      例如：淘宝搜索宝贝，条件有宝贝评价（好评、中评、差评），所在地（江、浙、沪），价格范围（100以下，100~199之间，199以上），包邮（包邮、不包邮），假设这个需求是针对富二代的，那么利用正交试验法对此需求进行分析.
步骤：
       1、划分需求子片段
      2、找出因子和因子状态
      因子:                           
      评价
      所在地
      价格范围
      包邮

      状态:
      好评、中评、差评
      江、浙、沪
      100以下，100~199之间，199以上
      包邮、不包邮

      3、构造因子状态表

      4、根据因子状态表，进行加权筛选，生成因素分析表
            根据分析：
            针对评价方面，很少有人搜索差评的，所以差评的取值可以去掉；（删除评价因子中的一个状态）
            针对富二代的，所以价格方面考虑的会比较少，所以价格可以去掉；（删除一个因子）

      5、利用正交表构造测试数据集
            各因子的状态数不统一，利用逻辑命令作出布尔图,所在地可以将某两个取值取或的关系，合成一个值。

找最接近的阶数相应的正交表，3因子 2状态，根据正交表构造测试数据集

把A、B、C换成对应的数据，B1是江浙两个取值

6、利用正交表每行数据构造测试用例。

3.7.6、常用正交表

3.8、场景法

3.8.1、场景法概念

       现在的软件几乎都是用事件触发来控制流程的。像GUI软件、游戏等。事件触发时的情景形成了场景，而同一事件不同的触发顺序和处理结果就形成了事件流。这种在软件设计方面的思想可以引入到软件测试中，可以生动地描绘出事件触发时的情景，有利于设计测试用例，同时使测试用例更容易理解和执行。
      在测试一个软件的时候，在场景法中，测试流程是软件功能按照正确的事件流实现的一条正确流程，那么我们把这个称为该软件的基本流；而凡是出现故障或缺陷的过程，就用备选流加以标注，这样的话，备选流就可以是从基本流来的，或是由备选流中引出的。所以在进行图示的时候，就会发现每个事件流的颜色是不同的。
      基本流就是按照正确的事件流来实现的流程。备选流就是出现故障或缺陷的过程。场景就是若干事件流首尾拼接构成一个测试场景。来看一个场景图：

3.8.2、用例设计步骤

1、根据说明，描述出程序的基本流及各项备选流
2、根据基本流和各项备选流生成不同的场景
3、对每一个场景生成相应的测试用例
4、对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值

3.8.3、场景法案例一

       我们都在当当网或china-pub华章网上书店都订购过书籍，整个订购过程为：用户登录到网站后，进行书籍的选择，当选好自己心仪的书籍后进行订购，这时把所需图书放进购物车，等进行结帐的时候，用户需要登录自己注册的帐号，登录成功后，进行结帐并生成订单，整个购物过程结束。
       那么我们通过以上的描述，从中确定哪是基本流，哪些是备选流：

根据基本流和备选流来确定场景：

       对于每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。

      本例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。通过从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。例如，在下面的矩阵中，V（有效）用于表明这个条件必须是 VALID（有效的）才可执行基本流，而 I（无效）用于表明这种条件下将激活所需备选流。下表中使用的“n/a”（不适用）表明这个条件不适用于测试用例。

       我们看到以上表中，是把每个场景成立的条件进行了分析，基本上已经明确了测试用例的数量，现在只要把真实数据填充上，那么整个测试用例就完成了。

3.8.4、场景法案例二

       例子：分析ATM取款机的场景流程，并设计测试用例和测试数据　　

根据基本流和备选流来确定场景：