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

软件测试的艺术

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

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

相关资源：本草纲目下载李时珍本草纲目查询软件版v1.4_本草纲目pdf彩图版…