《软件测试的艺术》摘要（上）

软件测试的艺术

第一章 一次自评价测试
1、所谓软件测试，就是一个过程或者一系列过程，用来确认计算机代码完成了其应该完成的功能，不执行其不该有的操作。
2、软件应当是可预测且稳定的，不会给用户带来意外惊喜。

第二章 软件测试的心理学和经济学
1、测试是为了发现错误，而不是为了证明没有错误。测试一开始就已经假设了程序中隐藏了错误，然后开始测试，发现尽可能多的错误。
2、测试并不能发现所有错误。测试投入的目标在于通过有限的测试用例，最大限度地提高发现的问题的数量。
3、软件测试的原则
　　3.1 测试用例中一个必须部分是对预期输出或结果进行定义。
　　3.2 程序员应当避免测试自己编写的程序。
　　3.3 编写软件的组织不应当测试自己编写的软件。
　　3.4 应当彻底检查每个测试的执行结果。
　　3.5 测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应该根据无效和未预料的输入情况。
　　3.6 检查程序是否“未做其该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”。
　　3.7 应避免测试用例用后即弃，除非软件本身就是一个一次性的软件。
　　3.8 计划测试工作时不应默许假定不会发现错误。
　　3.9 程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比。
　　3.10 软件测试是一项极富创造性、极具智力挑战的工作。

第三章 代码检查、走查与评审
1、代码检查，即以组为单位阅读代码。它是一系列规程和错误检查技术的集合。对代码检查的大多数讨论都集中在规程、所要填写的表格等。
2、代码检查错误列表：
　　2.1 数据引用错误
　　　　a）是否有引用的变量未赋值或者初始化？
　　　　b）下标的值是否在范围之内？
　　　　c）是否存在非整数下标？
　　　　d）是否存在虚调用？
　　　　e）当使用别名时属性是否正确？
　　　　f）记录和结构的属性是否匹配？
　　　　g）是否计算位串的地址？是否传递位串参数？
　　　　h）基础的存储属性是否正确？
　　　　i）跨过程的结构定义是否匹配？
　　　　j）索引或下标操作是否有“仅差一个”的错误？
　　　　k）继承需求是否得到满足？
　　2.2 运算错误
　　　　a）是否存在非算术变量间的运算？
　　　　b）是否存在混合模式的运算？
　　　　c）是否存在不同字长变量间的运行？
　　　　d）目标变量的大小是否小于赋值大小？
　　　　e）中间结果是否上溢或下溢？
　　　　f）是否存在被0除？
　　　　g）是否存在二进制的不精确度？
　　　　h）变量的值是否超过了有意义的范围？
　　　　i）操作符的优先顺序是否被正确理解？
　　　　j）整数除法是否正确？
　　2.3 数据声明错误
　　　　a）是否所有的变量都已声明？
　　　　b）默认的属性是否被正确理解？
　　　　c）数组和字符串的初始化是否正确？
　　　　d）变量是否赋予了正确的长度、类型和存储类？
　　　　e）初始化是否与存储类一致？
　　　　f）是否有相似的变量名？
　　2.4 比较错误
　　　　a）是否存在不同类型变量之间的比较？
　　　　b）是否存在混合模式的比较运算？
　　　　c）比较运算符是否正确？
　　　　d）布尔表达式是否正确？
　　　　e）比较运算是否与布尔表达式相混合？
　　　　f）是否存在二进制小数的比较？
　　　　g）操作符的优先顺序是否被正确理解？
　　　　h）编译器对布尔表达式的计算方式是否被正确理解？
　　2.5 控制流错误
　　　　a）是否超出了多条分支路径？
　　　　b）是否每个循环都终止了？
　　　　c）是否每个程序都终止了？
　　　　d）是否存在由于入口条件不满足而跳过循环体？
　　　　e）可能的循环越界是否正确？
　　　　f）是否存在“仅差一个”的迭代错误？
　　　　g）DO/END语句是否匹配？
　　　　h）是否存在不能穷尽的判断？
　　　　i）输出信息中是否有文字或语法错误？
　　2.6 输入/输出错误
　　　　a）文件属性是否正确？
　　　　b）OPEN语句是否正确？
　　　　c）I/O语句是否符合格式规范？
　　　　d）缓冲大小与记录大小是否匹配？
　　　　e）文件在使用前是否打开？
　　　　f）文件在使用后是否关闭？
　　　　g）文件结束调试是否被正确处理？
　　　　i）是否处理了I/O错误？
　　2.7 接口错误
　　　　a）形参的数量是否等于实参的数量？
　　　　b）形参的属性是否与实参的属性相匹配？
　　　　c）形参的量纲是否与实参的量纲相匹配？
　　　　d）传递给被调用模块的实参个数是否等于其形参个数？
　　　　e）传递给被调用模块的实参属性是否与其形参属性匹配？
　　　　f）传递给被调用模块的实参量纲是否与其形参量纲匹配？
　　　　g）调用内部函数的实参的数量、属性、顺序是否正确？
　　　　h）是否引用了当前入口点无关的形参？
　　　　i）是否改变了某个原本仅为输入值的形参？
　　　　j）全局变量的定义在模块间是否一致？
　　　　k）常数是否以实参形式传递过？
　　2.8 其他检查
　　　　a）在交叉引用列表中是否存在为引用过的变量？
　　　　b）属性列表是否与预期的相一致？
　　　　c）是否存在“警告”或“提示”信息？
　　　　d）是否对输入的合法性进行了检查？
　　　　e）是否遗漏了某个功能？
3、代码走查与代码检查相似。过程大体相同，但是规程稍微不同，所采用的错误检查技术也不一样。
4、同行评审，是一种依据程序整体质量、可维护性、可扩展性、易用性和清晰性对匿名程序进行评价的技术。
5、上述手段其实都是人工测试的范畴。

第四章 测试用例的设计
1、软件测试的关键：在所有可能的测试用例中，哪个子集最有可能发现最多的错误？
2、白盒测试，关注的是测试用例执行的程度或覆盖程序逻辑结构的程度。
　　2.1 语句覆盖：程序中的每个语句至少执行一次。
　　2.2 判定覆盖：要求测试用例，使得每个判断都至少有一个为真和为假的输出结果。
　　2.3 条件覆盖：要求测试用例，使得每个判断中的每个条件的所有可能的结果至少执行一次。
　　2.4 判定/条件覆盖准则：要求设计出充足的测试用例，将一个判断中的每个条件的所有可能的结构至少执行一次，将每个判断的所有可能的结果至少执行一次，将每个入口点都至少调用一次。
　　2.5 多重条件覆盖：要求编写足够多的测试用例，将每个判定中的所有可能的条件结果的组合，以及所有的入口点都至少执行一次。
3、黑盒测试，关注的是程序的输入和输出。
　　3.1 等价划分：将程序的输入范围进行划分，称为等价类。确定等价类是选取每一个输入条件，并将其划分为两个或更多的组。这些组通常分为两类：有效等价类和无效等价类。
　　　　前者表示对程序的有效输入，后者则是其他任何可能的输入条件。然后就是编写测试用例，尽可能多第覆盖有效等价类和无效等价类。
3.2 边界值分析：所谓边界，是指输入和输出等价类中那些恰好处于边界、或超出边界、或在边界以下的状态。
　　与等价划分的不同：
　　a）边界分析需要从等价类中选择一个或多个元素，以便等价类的每个边界都经过一次测试。等价划分只从等价类中选择一个元素。
　　b）边界分析关注输入和输出结果。等价划分关注输入条件。
3.3 因果图：是一种形式语言，类似于数字逻辑电路（与、或、非）。
　　将程序规格说明进行分解，确定规格说明中的因果关系。“因”是指一个明确的输入条件或输入条件的等价类，“果”是指一个输出条件或系统转换。
　　然后分析规格说明的语义内容，并将其转换为连接因果关系的布尔图（即因果图）。给图加上注解符号，说明由于语法或环境的限制而不能联系起来的因和果。
　　通过跟踪图中的状态变化情况，将因果图转换成一个有限项的判定表。表中的每一列代表一个测试用例，实现之。
3.4 错误猜测：这是一种下意识的行为，单凭直觉来列举可能犯的错误或错误易发情况，依次来编写测试用例。