软件测试的艺术（测试工程师必备基本知识与概念）

一、黑盒测试与白盒测试：

等价类划分：

一、确定等价类

确定等价类是选取每一个输入条件（通常是规格说明中的一个句子或短语）并将其划分为两个或更多的组。可以使用图 4-3 中的表格来进行划分。注意，我们确定了两类等价类：有效等价类代表对程序的有效输入，而无效等价类代表的则是其他任何可能的输入条件（即不正确的输入值）。

二、生成测试用例

第二步是使用等价类来生成测试用例，其过程如下：

1. 为每个等价类设置一个不同的编号。

2. 编写新的测试用例，尽可能多地覆盖那些尚未被涵盖的有效等价类，直到所有的有效等价类都被测试用例所覆盖（包含进去）。

3. 编写新的用例，覆盖一个且仅一个尚未被覆盖的无效等价类，直到所有的无效等价类都被测试用例所覆盖。用单个测试用例覆盖无效等价类，是因为某些特定的输入错误检查可能会屏蔽或取代其他输入错误检查。举例来说，如果规格说明规定了“请输入书籍类型（硬皮、软皮或活页）及数量（l～999 )”，代表两个错误输入的测试用例“XYZ 0”，很可能不会执行对数量的检查，因为程序也许会提示 “XYZ 是未知的书籍类型”，就不检查输入的其余部分了。

边界值分析：

很难提供一份如何进行边界值分析的“详细说明’，因为这种方法需要一定程度的创造性，以及对问题采取一定程度的特殊处理办法（因此，就像测试的许多其他方面一样，这更多的是项智力工作，并非其他的什么）。然而，我们还是给读者提供一些通用指南：
1. 如果输入条件规定了一个输入值范围，那么应针对范围的边界设计测试用例，针对刚刚越界的情况设计无效输入测试用例。举例来说，如果输入值的有效范围是-1.0 至+l.0，那么应针对-1.0、1.0、-1.001 和1.001 的情况设计测试用例。

2. 如果输入条件规定了输入值的数量，那么应针对最小数量输入值、最大数量输入值，以及比最小数量少一个、比最大数量多一个的情况设计测试用例。举例来说，如果某个输入文件可容纳l~255 条记录，那么应根据0、l、255 和256条记录的情况设计测试用例。

3. 对每个输出条件应用指南 1。举例来说，如果某个程序按月计算FICA1的扣除额，且最小金额是$0.00，最大金额$1165.25，那么应该设计测试用例来测试扣除$0.00 和$1165.25 的情况。此外，还应观察是否可能设计出导致扣除金额为负数或超过$1165.25 的测试用例。注意，检查结果空间的边界很重要，因为输入范围的边界并不总是能代表输出范围的边界情况（例如，三角正弦函数sin的情况就如此）。同样，总是产生超过输出范围的结果也是不大可能的，但无论如何，应该考虑这种可能性。

4. 对每个输出条件应用指南 2。如果某个信息检索系统根据输入请求显示关联程度最高的信息摘要，而摘要的数量从未超过4 条，则应编写测试用例，使程序显示0 条、l 条和4 条摘要，还应设计测试用例，导致程序错误地显示5 条摘要。

5. 如果程序的输入或输出是一个有序序列（例如顺序的文件、线性列表或表格），则应特别注意该序列的第一个和最后一个元素。

6. 此外，发挥聪明才智找出其他的边界条件。

因果图分析：

生成测试用例时采用的过程如下：
1. 将规格说明分解为可执行的片段。这是必须的步骤，因为因果图不善于处理较大的规格说明。举例来说，当测试一个电子商务系统时，“可执行的片段”可能是指对挑选和确认购物车中的单件商品的规格说明。在测试一个Web 页面设计时，我们可能会测试一个单独的菜单树，甚至是一个不太复杂的导航序列。

2. 确定规格说明中的因果关系。所谓“因”，是指一个明确的输入条件或输入条件的等价类。所谓“果”，是指一个输出条件或系统转换（输入对程序或系统状态的延续影响）。举例来说，如果某个事务引起文件或数据库记录被修改，那么这种改变就是一个系统转换，而系统反馈的确认信息就是一个输出条件。通过逐字逐句地阅读规格说明，同时标识出描述“因”和“果”的文字或句子，就可以将“因”和“果”确定出来。因果关系一旦确定下来，每个“因”和“果”都被赋予一个惟一的编号。

3. 分析规格说明的语义内容，并将其转换为连接因果关系的布尔图。这就是所谓的因果图。

4. 给图加上注解符号，说明由于语法或环境的限制而不能联系起来的“因”和“果”。

5. 通过仔细地跟踪图中的状态变化情况，将因果图转换成一个有限项的判定表。表中的每一列代表一个测试用例。

6. 将判定表中的列转换成测试用例。

语句覆盖：

每条语句都执行到。

判断覆盖：

每个判断都有出现真和假。

条件覆盖：

每个条件都执行到。

条件/判定覆盖：

每个条件都有真假出现。

组合覆盖：

每个条件直接的组合都出现（显然，这种测试用例数很多）

二、模块测试与增量测试：

模块测试（或单元测试）是对程序中的单个子程序、子程序或过程进行测试的过程，也就是说，一开始并不是对整个程序进行测试，而是首先将注意力集中在对构成程序的较小模块的测试上面。

模块测试的目的是将模块的功能与定义模块的功能规格说明或接口规格说明进行比较。有自顶向下测试与自底向上测试。

什么是驱动模块和桩模块：

单元本身无法构成一个切实可运行的程序系统，所以我们需要为单元测试来开发桩模块和驱动模块，从而完成我们的单元测试目的，这是桩模块和驱动模块的作用。
驱动模块是用来模拟被测试模块的上一级模块，相当于被测模块的主程序。它接收数据，将相关数据传送给被测模块，启用被测模块，并打印出相应的结果。
桩模块（Stub）是指模拟被测试的模块所调用的模块，而不是软件产品的组成的部分。

增量测试--

1. 非增量测试所需的工作量要多一些。

2. 如果使用了增量测试，可以较早地发现模块中与不匹配接口、不正确假设相关的编程错误。

3. 因此如果使用了增量测试，调试会进行得容易一些。

4. 增量测试会将测试进行得更彻底。

5. 非增量测试所占用的机器时间显得少一些。

6. 模块测试阶段开始时，如果使用的是非增量测试，就会有更多的机会进行并行操作（也就是说，所有的模块可以同时测试）。