1.黑盒测试的概念

黑盒测试又称为数据驱动的测试或输入/输出驱动的测试。使用这种测试方法时，将程序视为一个黑盒子。测试目标与程序内部机制和结构完全无关，而是将重点集中放在发现程序不按其规范正确运行的环境条件。测试数据完全来源于软件规范。

2.设计测试用例

2.1.测试用例的定义

• 设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的预期结果。
• 如果程序在这种情况下不能正常运行，而且这种问题会重复发生，就代表软件测试员已经测出了软件有缺陷，这时候就必须把这个问题标识出来，并通知开发人员。开发人员接到通知后，将这个问题修改完成于下一个测试版本内。
• 软件测试员取得新的测试版本后，必须利用同一个用例来测试这个问题，确保该问题已经修改完成。

2.2.测试用例模板和包含的内容

模板通常使用Excel表格完成。测试用例应该包含以下内容：

• 标识符（测试编号规则TestCase_项目名称_模块名称_功能名称_0001）：由测试设计过程说明和测试程序说明引用的唯一标识符。
• 测试项（测试用例的测试目的，一般用一句话表明目的，例如：用浏览器打开百度首页）：描述被测试的详细特征、代码模块等，应该比测试设计说明中所列的特征更加具体。还要指出引用的产品说明书或者测试用例所依据的其他设计文档。
• 输入说明：该说明列举执行测试用例的所有输入内容或者条件。
• 输出说明：描述进行测试用例预期的结果。
• 环境要求：是指执行测试用例必要的硬件、软件、测试工具、人员等。
• 特殊要求：描述执行测试必须的特殊要求。
• 用例之间的依赖性：如果一个测试用例依赖于其他用例，或者受其他用例的影响，就应该在此注明。
• 测试步骤：用最朴实的语言，写出来软件的操作步骤，要尽量详细，例如：在用户名文本框输入信息。
• 测试数据：单独整合测试数据，必须和测试步骤中的数据保持一致。
• 预期结果：准确，对象的准确性，内容的准确性，原则上每一个操作，都要有一个结果，在重要的步骤之后，设定预期结果，例如：页面跳转到XXX，程序弹出对话框提示，一般和测试目的密切相关，测试目的决定了测试步骤和预期结果。
• 测试结果：要求在测试执行完成后添加，没有执行保持为空。测试结果只有成功或失败。
• 测试人：测试的执行人，可以和设计者相同，也可以不同。
• 备注：为了测试用例正常执行而做的特殊准备，例如：网络不好会有提示。

2.3.设计测试用例的作用

• 有效性：测试用例是测试人员测试过程中的重要参考依据。
• 可复用性：良好的测试用例具有重复使用的功能，使得测试过程事半功倍，提高测试效率。
• 易组织性：即使是小的项目，也可能有几千甚至更多的测试用例，测试用例可能在数月甚至几年的测试过程中被创建和使用
• 可评估性：从测试的项目管理角度来说，测试用例的通过率是检验代码质量的保证。
• 可管理性：测试用例也可以作为检验测试人员进度、工作量以及跟踪/管理测试人员的工作效率的标准。

2.4.测试用例编写注意事项

• 不要设计"穷举测试用例"
• 在详细测试用例与有效测试时间中找到平衡点
• 好的测试用例应该多关注"反向测试问题"
• 测试用例库应该不断更新和维护
• 测试用例可以复用，但要注意数据有效性与环境变化
• 多学习经验丰富的测试工程师所设计的测试用例
• 针对不同的需求类型和测试对象，灵活采用不同的测试用例设计方法

3.等价划分

对程序的穷举输入测试是无法实现的，因此，当测试某个程序时，我们被限制在从所有可能的输入中努力找出某个小的子集。这个子集必须是正确的，并且是可能发现最多错误的子集。
确定这个子集的一种方法，就是要意识到测试用例还应该具备另外两个特征：

1. 严格控制测试用例的增加，减少为达到"合理测试"的某些既定目标而必须设计的其他测试用例的数量
2. 覆盖了大部分其他可能的测试用例，也就是说，它会告诉我们，使用或不使用这个特定的输入集合，哪些错误会被发现，哪些会被漏掉。

第一个特征意味着，每个测试用例都必须体现尽可能多的不同的输入情况，以最大程度减少测试所需的全部用例的数量。
第二个特征意味着应该尽量将程序输入范围进行划分，将其划分为有限数量的等价类，这样就可以合理假设测试每个等价类的代表性数据等同于测试该类的其他任何数据。也就是说，如果等价类的某个测试用例发现了某个错误，该等价类的其他用例也应该能发现同样的错误。相反，如果测试用例没有发现错误，那么其他测试用例也不会发现错误。
这两种思想形成了称为等价划分的黑盒测试方法。第二种思想可以用来设计一个输入条件集合以供测试，而第一个思想可以随后用来设计涵盖这些状态的一个最小测试用例集。使用等价划分法设计测试用例主要有两个步骤：（1）确定等价类；（2）生成测试用例。

3.1.确定等价类

确定等价类是选取每一个输入条件（通常是规格说明中的一个句子或短语）并将其划分为两个或更多的组。可以用以下表格划分：

外部条件	有效等价类	无效等价类
…	…	…

有效等价类代表对程序的有效输入，无效等价类代表的则是其他任何可能的输入条件（不正确的输入值）。在给定了输入或外部条件之后，确定等价类大体上是一个启发式的过程。有以下一些原则：

1. 如果输入条件规定一个取值范围（数量可以是1到999），那么就应确定一个有效等价类（1≤数量≤999），以及两个无效等价类（数量＜1，数量＞999）。
2. 如果输入条件规定了取值的个数（汽车可登记一至六名车主），那么就应确定一个有效等价类和两个无效等价类（没有车主，或车主多于六个）。
3. 如果输入条件规定了一个输入值的集合，而且有理由认为程序会对每个值做不同处理（交通工具类型必须是公车、卡车、出租车、火车、摩托车），那么就应为每个输入值确定一个有效等价类和一个无效等价类（拖车）。
4. 如果存在输入条件规定了"必须是"的情况（标识符的第一个字符必须是字母），那么就应确定一个有效等价类（首字符是字母）和一个无效等价类（首字符不是字母）。

3.2.生成测试用例

1. 为每个等价类设置一个不同的编号。
2. 编写新的测试用例，尽可能多地覆盖那些尚未被涵盖地有效等价类，直到所有的有效等价类都被测试用例所覆盖（包含进去）。
3. 编写新的用例，覆盖一个且仅一个尚未被覆盖的无效等价类，直到所有的无效等价类都被测试用例所覆盖。

为什么用单个测试用例覆盖无效等价类，因为某些特定的输入错误检查可能会屏蔽或取代其他输入错误检查。比如，如果规格说明规定了"输入书籍类型（硬皮、软皮或活页）及数量（1-999）"，代表两个错误输入（书籍类型错误，数量错误）的测试用例"XYZ 0"，很可能不会执行对数量的检查，因为程序也会提示"XYZ是未知的书籍类型"，就不检查输入的其余部分了。

4.边界值分析

经验证明，考虑了边界条件的测试用例与其他没有考虑边界条件的测试用例相比，具有更高的测试回报率。所谓边界条件，是指输入和输出等价类中那些恰好处于边界、或超过边界、或在边界以下的状态。边界值分析方法与等价划分方法存在两方面的不同：

1. 与从等价类中挑选出来任意一个元素作为代表不同，边界值分析需要选择一个或多个元素，以便等价类的每个边界都经过一次测试。
2. 与仅仅关注输入条件（输入空间）不同，还需要考虑从结果空间（输出等价类）设计测试用例。

4.1.一些通用指南：

1. 如果输入条件规定了一个输入值范围，那么应针对范围的边界设计测试用例，针对刚刚越界的情况设计无效输入测试用例。比如，如果输入值的有效范围是-1.0至+1.0，那么应针对-1.0，1.0，-1.001和1.001来设计测试用例。
2. 如果输入条件规定了输入值的数量，那么应针对最小数量输入值、最大数量输入值，以及比最小数量少一个、比最大数量多一个的情况设计测试用例。比如，如果某个输入文件可容纳1-255条记录，那么应根据0、1、255、256条记录来设计测试用例。
3. 对每个输出条件应用指南1。比如，某个程序按月计算FICA的扣除额，且最小金额是0.00，最大金额是1165.25，那么应该设计测试用例来测试扣除0.00和1165.25的情况。同时还应该观察是否能设计出导致扣除金额为负数或超过1165.25的测试用例。
4. 对每个输出条件应用指南2。如果某个信息检索系统根据输入请求显示关联程度最高的信息摘要，而摘要的数量从未超过4条，则应编写测试用例，使程序显示0条、1条和4条摘要，还应该导致程序错误显示5条摘要。
5. 如果程序的输入或输出是一个有序序列（比如顺序的文件、线性列表或表格），则应特别注意该序列的第一个和最后一个元素。
6. 此外，发挥聪明才智找出其他的边界条件。

以分析数值是否能构成三角形为例说明边界值分析的必要性。作为代表三角形的输入值，必须是大于0的整数，而且其中任意两个值和应大于第三个。如果定义了等价划分，可能会确定一个满足此条件的等价类，以及另一个两个输入之和不大于第三个的等价类。因此，3-4-5和1-2-4都是可能的用例。我们漏了一个可能的错误，如果程序中表达式写成了A+B>=C，而不是A+B>C，那么程序就会错误告诉我们1-2-3表示的是一个有效的不规则三角形。因此，边界值分析方法和等价划分之间的重要区别是：边界值分析考察正处于等价划分边界或在边界附近的状态。

5.因果图

边界值分析和等价划分的一个弱点是未对输入条件的组合进行分析。因果图有助于用一个系统的方法选择出高效的测试用例集。它还有一个额外的好处，就是可以指出规格说明的不完整性和不明确之处。
因果图是一种形式语言，用自然语言描述的规格说明可以转换为因果图。因果图实际上是一种数字逻辑电路（一个组合的逻辑网络），但没有使用标准的电子学符号，而是使用了稍微简单点的符号。

5.1.生成测试用例采用的过程：

1. 将规格说明分解为可执行的片段。这是必须的步骤，因为因果图不善于处理较大的规格说明。（因为原因和结果很多时，关系连线会很多导致可读性差，可以用于小功能的分析）
2. 确定规格说明中的因果关系。所谓"因"，是指一个明确的输入条件或输入条件的等价类。所谓"果"，是指一个输出条件或系统转换（输入对程序或系统状态的延续影响）。通过阅读规格说明，同时标识出描述"因"和"果"的文字或句子，就可以将"因""果"确定。一旦确定因果都被赋予一个唯一的编号。
3. 分析规格说明的语义内容，并将其转换为连接因果关系的布尔图。这就是因果图。
4. 给图加上注解符号，说明由于语法或环境的限制而不能联系起来的"因"和"果"。
5. 通过仔细跟踪图中的状态变化情况，将因果图转换成一个有限项的判定表。表中的每一列代表一个测试用例。
6. 将判定表中的列转换成测试用例。

5.2.基本的因果图符号

例子：第一列中的字符必须是"A"或"B"，第二列中的字符必须是一个数字。在这种情况下，对文件进行更新。如果第一个字符不正确，产生提示X12。如果第二个字符不是数字，产生提示X13。
画出因果图如下：

• “因”：1，第一列字符是A；2，第一列字符是B；3，第二列字符是一个数字。
• “果”：70，对文件做了更新；71，产生提示信息X12；72，产生提示信息X13。

尽管因果图表示了规格说明，但图中包含一个不可能的原因组合，即原因1和原因2不可能同时设置为1。在大多数程序中，由于语法或环境的原因，某些原因的组合是不可能存在的（一个字符不能同时为A和B）。所以我们要引入约束符建立约束关系。

• 约束E（Exclusive）表示其必须总为真，而a和b最多只有一个为1（不能同时为1）。
• 约束I（Include）表示其为真时，a，b，c中至少有一个应为1（a，b，c不能同时为0）。
• 约束O（Only）表示a，b中有且仅有一个必须为1。
• 约束R（Request）表示如果a为1，b也必须为1（a为1，b为0的情况不存在）
• 约束M（Mask）表示，结果a为0，b也强制为0。

回到上面的例子，原因1和原因2实际上是不可能同时成立的，而两者同时不成立是可能的。因此它们之间用约束E连接。

6.判定表法

6.1.什么是判定表

判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。有以下几个内容组成：

1. 条件桩（Condition Stub）：列出了问题的所有条件。通常认为列出的条件的次序无关紧要。
2. 动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
3. 条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能的情况下的真假值。
4. 动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。

判定表的应用场合：主要适用于多条件的内容组合与结果分析。
判定表的组成：由条件项、条件桩、动作项、动作桩组成。
判定表的使用条件：所有的条件桩在表中的位置和顺序相互不影响；所有的动作桩顺序不会因为条件顺序的变化产生不同

6.2.建立判定表的步骤

1. 确定规则的个数
   • 识别出操作条件（原因）和对应的动作（结果）
   • 分析条件的条件项（组合数量）：如果有n个条件，每个条件有成立和不成立两种情况，那么最后一共有2^n个数量
2. 列出所有的条件桩和动作桩
   • 填入条件项
   • 填入动作项，指定初始判定表
3. 简化，合并相似规则或相同动作

6.3.判定表使用的实例

1. 需求：订购单的检查

   • 如果金额超过500元，又未过期，则发出批准单和提货单
   • 如果金额超过500元，但由过期了，则不发批准单
   • 如果金额低于500元，则不论是否过期都发出批准单和提货单，在过期的情况下还需要发出通知单

2. 分析条件和动作

   条件1	条件2	动作
   金额>500	未过期	发出批准单和提货单
   金额>500	过期	不发批准单
   金额≤500	未过期	发出批准单和提货单
   金额≤500	过期	发出批准单和提货单，通知单

3. 写入条件桩、动作桩、条件项、动作项
   

4. 对判定表进行简化和优化（对其中不合理的内容进行取舍）
   不管金额高低，只要未过期，就会发批准单和通知单。
   

5. 将判定表中的每一列（条件项和对应的动作项）作为测试用例的数据和操作以及对应的预期结果

6.4.适合使用判定表设计测试用例的条件

1. 规格说明以判定表的形式给出，或很容易转换成判定表
2. 条件的排列顺序不影响执行哪些操作
3. 规则的排列顺序不影响执行哪些操作
4. 当某一个规则的条件已经满足，并确定要执行的操作后，不必检验别的规则
5. 如果某一规则要执行多个操作，这些操作的执行顺序无关紧要

6.5.测试用例的设计方法：没有哪一种方式是单独使用的

1. 所有的软件，都是因为某种操作才会导致一定的结果，考虑使用因果图
2. 所有的软件都有文本框，考虑使用等价类、边界值

7.正交实验法

7.1.原理介绍

1. 日本统计学家提出，使用的工具（正交表），统计和分析实验数据，从大量实验中找到合适的实验数据组合。（原本用于工业生产的数据组合与实验室的数据挑选）。大量实验组合中，挑选出一部分具有代表性的点，进行试验，分析数据。
2. 基本思想：在一项实验中，把影响实验结果的量称为实验因素（因子），简称因素。在实验过程中，每一个因素可以处于不同的状态或状况，把因素所处的状态或状况，称为因素的水平，简称水平。每列中不同数字出现的次数相等。这一特点表明每个因素的每个水平与其他因素的每个水平参与实验的概率是完全相同的，能有效地比较实验结果并找出最优的实验条件。在任意2列其横向组成的数字对中，每种数字对出现的次数相等。这个特点保证了实验点均衡地分散在因素与水平的完全组合之中。
3. 一般的正交表记为

$$L_n(m^k)$$

• m是水平数，k是因素数，n是需要进行实验的行数
• 行数：正交表中的行的个数，即试验的次数，也是通过正交实验法设计的测试用例的个数
• 因素数：正交表中列的个数，即要测试的功能点。
• 水平数：任何单个因素能够取得的值的最大个数，即要测试功能点的输入值

4. 正交表种类（各列水平数均相同的正交表，混合水平正交表）
5. 正交表特征（整齐可比，均衡分散）
6. 例如：字体的显示效果，字体、字号、颜色称为因素。字体选择时，可以选择宋体、楷体、微软雅黑称为水平。字号选择时，称为水平。颜色选择时，称为水平。
7. 数学原理
   • 线性代数
   • 统计学和概率论
   • 数理统计

7.2.实现步骤

1. 确定因素：这里因素是指软件运行结果有影响的软件
   • 确定因素的取值范围或集合
   • 因素的取值范围是指软件输入的取值范围或集合以及可用的硬件资源
   • 例如：文本框、按钮等需求中提及或者没有提及的因素
2. 确定每个因素的水平
   • 根据因素的取值范围或集合，采用等价类、边界值分析以及其他软件测试技术，在每个因素的取值范围或集合内挑选出有效等价类、无效等价类、正好等于、刚刚大于或刚刚小于边界值等有代表性的测试值
   • 例如：需求中说明和未说明的概要分析
3. 选择正交表
   • 根据确定的因素和水平，选择适合的正交表
   • 如果没有合适的正交表可用或需要的测试用例太多，要对因素和水平调整
   • 只有特定的因素和水平的组合才有对应的正交表，所以在现实中用到的时候，找最贴近的正交表（正交表的因素和水平一般大于实际的因素和水平）

7.4.相关软件

正交实验助手

8.功能图法

8.1.原理介绍

1. 功能图又叫状态迁徙图
2. 来源：在遇到有事务流或由于某种条件成立导致状态改变的软件时，如何进行测试用例的设计就比较麻烦
3. 目标：设计足够多的测试用例达到对系统状态的覆盖、状态-条件组合的覆盖以及状态迁移路径的覆盖

8.2.实现步骤

1. 列出所有可能的输入事件，以input-N的方式命名（N为1，2，3，4等）
2. 把软件的打开的初始状态，定义为"空闲"状态
3. 在"空闲"状态上加所有可能的输入（只加一次）
4. 为上一步产生的所有新状态，分别加所有可能的输入（只加一次）
5. 循环执行上一步
6. 直到再没有新状态产生，列出所有的状态，生成状态表
7. 组合任意可能的状态组合，写出相应的测试用例

8.3.QQ登录界面为例

1. 识别出可以进行的操作

   • input1：输入账号
   • input2：输入密码
   • input3：点击登录
   • input4：点击关闭按钮

2. 定义QQ登录界面为空闲状态

3. 给空闲状态加操作（第一轮分析后产生新的状态）
   

4. 产生了新的状态，针对新的状态进行分析
   

5. 得到了新的状态，继续进行分析
   

6. 将状态变化过程进行列表化，准备测试用例
   

A列：从QQ登录界面，直接点击关闭按钮，QQ退出
B列：从QQ登录界面，先输入QQ号（状态变为QQ已输入），在输入密码（状态变为QQ号，密码输入），点击登录，状态就变为QQ主界面

9.场景法

9.1.场景法基本原理

场景法图示如下：

1. 现在软件几乎都是用事件触发来控制流程的。测试时，可以生动地描述出事件触发时的情景，有利于设计测试用例，同时使用测试用例更容易理解和执行。
2. 基本流：软件功能按照正确的事件流实现的一条正确流程。通常一个业务仅存在一个基本流，且基本流仅有一个起点和一个终点。
3. 备选流：除了基本流之外的各支流，包含多种不同的情况
4. 注意：场景中必须有基本流；场景中必须有内容从用例的开始，到用例的结束
5. 场景列表
   • 场景1：基本流
   • 场景2：基本流 备选流1
   • 场景3：基本流 备选流1 备选流2
   • 场景4：基本流 备选流3
   • 场景5：基本流 备选流4

9.2.场景法设计用例的步骤

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

场景法适用于解决业务流程清晰的系统或功能

9.3.场景法设计实例

银行卡在ATM机取钱
基本流：插卡-输入密码-出钱-取卡
备选流：卡片不是银行卡；卡片不是银联卡；密码输错一次；密码输错两次，第三次输入正确；密码输入错误三次，冻结账号或吞卡；选择存款服务；选择查询服务；选择转账服务；选择修改密码服务；选择取款金额；选择其他金额；账户金额；ATM机没钱；账户取款金额达到取款机当日取款上限；账户取款金额达到账户当日取款上限；取款机掉线了；取款机停电了
设计测试用例（假定ATM只能识别银联卡）：

1. 插卡（Master卡）
2. 换卡（银联卡），进行插卡
3. 输入密码（第一次输入错误）
4. 再次输入密码（第二次输入错误）
5. 第三次输入密码（输入正确）
6. 选择服务-取款
7. 选择取出金额-500
8. 等待出钞
9. 取卡

10.其他用例设计方法

1. 测试大纲法
   • 一种着眼于需求的方法
   • 为列出各种测试条件，将需求转换为大纲的形式（思维导图/树形结构）
   • 无需用例设计，一般从根节点开始，到叶节点为止
   • 一般用于快速的测试和过程记录，用例一般进行后补
2. 探索性测试法
   • 基于测试人员经验与直觉的测试方法
   • 是对测试用例设计的有效补充
   • 探索性测试也必须生成测试用例
3. 猴子测试（随意性测试）
   • 一种没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试
   • 缺点：测试往往不太真实；不能达到一定的覆盖率；许多测试都是冗余的；需要使用同样的随机数才能重建测试

11.用例设计方法综合选择

1. 首先进行等价类划分
2. 在任何情况下都必须使用边界值分析法
3. 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表法
4. 对于参数配置类的软件，要用正交实验法选择较少的组合方式达到最佳效果
5. 状态迁徙图也是很好的测试用例设计方法，可以通过不同时期条件的有效性设计不同的测试数据
6. 对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程
7. 可以用错误推测法追加一些测试用例
8. 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例