软件测试的艺术概要-上

软件测试的艺术

一、测试心理学

1. 心理学

为了发现软件错误而执行程序的过程，从而提高软件的可靠性和质量

2. 经济学

1. 穷尽所有测试场景或者可能出现的输入时不可能的
2. 穷尽控制流的所有路径是不可能的

3. 测试原则

1. 测试用例需要对预期的输出结果进行定义
2. 程序员/编写程序的组织应当避免对自己的程序进行测试
3. 应当测试检查每个测试的执行结果
4. 测试用例应当包含无效和未预料到的输入情况
5. 除了检查程序是否未做其“应当做的”之外也要检查程序是否做了“不应该做的”。
6. 测试用例应当具有普适性；应当避免测试用例用后即弃
7. 计划测试工作时应当假设会出现错误
8. 已经发现错误的部分，再次发现错误的情况可能性更高
9. 软件测试需要证明软件存在错误，是需要有创造力的

二、代码审查

1. 代码审查安排及原则

错误发现得越早，改正的成本越低，改正错误的可能性越大
代码审查议程：

1. 成立审查小组；（一位经验丰富的程序员、一位程序设计专家、一位程序员新手、一位最终维护程序的人、一位来自该编程小组的程序员）
2. 由程序编码人员逐句讲述程序逻辑结构
3. 参见 常见的编码错误列表分析程序
   代码检查的目标：发现程序中的错误，改进代码质量
   代码检查的衍生功效：程序员得到编程风格、算法选择等方面的反馈信息

2. 代码审查错误列表

1. 数据引用错误
   1.1 引用的变量是否赋值或者初始化
   1.2 对于引用数组，下标值是否在范围内/下标值是否为整数/是否存在仅差一个错误
   1.3 继承的需求是否能得到满足
2. 运算错误
   2.1 是否存在非算术变量间的运算
   2.2 是否存在混合算术类型的运算，运算是否符合要求
   2.3目标变量的字长会小于赋值变量的大小吗
   2.4 中间结果是否存在上溢或者下溢
   2.5 是否存在被除数可能为0的情况
   2.6 变量的值是否超过了有意义的表示范围
   2.7 操作符的优先顺序是否被正确理解
   2.8 除法结果赋值是否会出现失精
3. 数据声明错误
   3.1是否所有变量已经被声明
   3.2 变量的默认属性是否被程序和逻辑接受
   3.3 数组和字符串的初始化是否正确
   3.4 变量是否赋予了正确的长度、类型
   3.5 是否存在相似的变量名
4. 比较错误
   4.1 是否存在不同类型变量间的比较
   4.2 是否存在不同算术类型数据间的比较
   4.3 比较运算符和布尔表达式是否正确
   4.4 操作符的优先顺序是否符合程序要求
5. 输入输出错误
   5.1 文件属性是否正确
   5.2 是否每个文件都有open和close语句
   5.3 是否处理了打开错误和i/o错误
   5.4 打印语句是否符合规范
6. 控制流程错误
   6.1 分支是否包含了所有情况
   6.2 所有循环、模块是否都终止了
   6.3 循环是否存在越界的情况
   6.4 在不进入循环体的情况是否优先处理了
   6.5 是否出现死循环
   6.6 输出信息是否符合规范
7. 接口错误
   7.1 传参是否正确
   7.2 调用内部函数的数量、属性和顺序是否正确
   7.3 是否引入了无关参数，调用的实参是否初始化
   7.4 常数是否被当做实参使用
   7.5 是否存在改变形参值的操作
   7.6 是否存在两个变量由于调用某个方法导致一个变量改变引起其他变量跟着改变的情况
   7.7 全局变量的使用过程中是否符合逻辑
8. 其他错误
   8.1 是否存在内存泄漏和内存溢出的情况
   8.2 功能是否全部实现
   8.3 输入的合法性检查是否做了
   8.4 警告信息是否可以容忍

三、测试用例设计

1. 黑盒测试

1. 等价划分
   原则：

   1. 严格控制测试用例增加，每个测试用例覆盖尽可能多的输入
   2. 确保用例覆盖大部分其他可能的测试用例。，精良将程序输入范围进行划分，将其划分为有限数量的等价类

   1.1 确定等价类
   确定有效等价类和无效等价类
   1.2 生成测试用例
   为每个等价类进行标号；编写测试用例尽可能多的覆盖有效等价类；编写测试用例覆盖一个且仅一个无效等价类。

2. 边界值分析

3. 因果图
   3.1 将规格说明书分解成可执行的片段
   3.2 确定规格说明中的因果关系
   3.3 分析规格说明的语义，将其转换为连接因果关系的布尔图
   3.4 给图加上注解符号
   3.5 根据图中的状态变化情况，将因果图转换成有限项的判定表

   1. 选择一个果为1的所有因
   2. 在判定表中所有因的组合生成一列
   3. 对弈所有因的组合中判断其他其他过 状态组成一列
   4. 当回溯到一个结果因为1的or节点时，不要讲该or节点一个以上的输入值置为1
   5. 当会所经过因为0的and节点时，仅有一种所有输入皆为0的情况，所有为1的情况都要列出来，如果多个，无需将一个输入为0，其他输入中有一个或者更多为1的所有情况列出来
      3.6 将判定表中的列转换成测试用例

2. 白盒测试

测试准则：

1. 每个判断的所有结果都执行一遍
2. 将所有 程序的入口都至少调用一次
3. 将所有条件的组合都执行一次

分类：

1. 语句覆盖：每一条语句都执行一遍
2. 判定覆盖：每一个判断的真假都执行一次
3. 条件覆盖：每一个条件的可能结果的执行一次
4. 判定/条件覆盖：每个判断的所有结果都执行一次、每一个判断中的每一个条件真假都执行一次、每个入口点都调用一次
5. 多重条件覆盖：每个判定中条件结果的可能组合，以及所有的入口点都至少调用一次

3. 错误猜测

根据经验测试：
测试输入/输出为空；
测试输入相同/测试只包含一个条目；
测试为负数情况；
测试输入输出相同情况。

4. 测试策略

1. 如果规格说明书包含输入条件组合的情况，优先使用因果图分析法
2. 任何情况下都需要使用边界值分析
3. 应为输入和输出确定有效等价类和无效等价类
4. 使用错误猜测技术增加更多的测试用例
5. 针对测试用例检查程序的逻辑结构