软件测试的艺术(读书笔记5)
下面开始本书第三部分的读书笔记部分
第三部分 软件测试中的人工测试方法
包括第3章 代码检查、走查与评审
第3章 代码检查、走查与评审
1、代码检查和代码走查
代码检查和代码走查是一种人工测试方法，这种测试技术在编码之后计算机测试之前使用，要求人们组成一个小组来阅读和检查程序，可以有效的在项目早期发现错误，并改正错误。代码检查和代码走查有以下的相同点：
- 三到四人的小组对程序进行审核
- 成员包括：代码作者、协调人、其他程序专家、测试专家
- 目标是发现错误而非改正错误
- 与使用计算机的测试互补
1.1 代码检查
代码检查是以组为单位阅读代码，有一系列的规程和错误检查技术。
1）代码检查小组
通常包括四个人：协调人、代码作者、其他程序设计人员、测试专家。
协调人职责：1.分发材料、安排进程；2.记录发现的错误；3.确保错误随后的改正。
代码作者职责：逐条讲解程序代码的逻辑结构。
其他程序设计人员：提问题，并判断程序是否存在错误。
测试专家：熟悉软件测试，并知道大部分的常见编码错误。
2）检查议程与注意事项
a) 代码评审之前：协调人将程序清单和设计规范分发给其他成员
b) 代码评审时：
1.编码人员对程序进行讲解；
2.其他程序人员提问题，并参考常见编码错误列表分析程序；
3.协调人确保会议高效进行；
c) 代码评审后：程序员会根据错误清单进行修改，如有必要，修改好后需要进行再次评审。
d) 评审会议地点和时间：会议地点应避免外部干扰，时间应在90-120分钟。
e) 代码检查时，应对事不对人：代码检查的目标是发现程序中的错误，从而改进软件质量。不应对程序员个人进行人身攻击。
f) 其他好处：程序员会得到编程风格、编程技术方面的反馈信息；同时其他参与者也能从代码作者那里获取编程方面的收获。
1.2 代码走查
代码走查同代码检查一样，也是以小组为单位进行代码阅读。不同点是使用的规程和错误检查技术。
下面主要说明不同点，其他可以参考代码检查
a) 代码走查时：
1.指定的测试人员会带一些书面的测试用例；
2.会议期间每个测试用例都会在人脑中进行推演（将测试数据沿程序逻辑走一遍）；
3.测试用例须结构简单，数量适中。
b) 参与人员（稍有不同）
协调人：类似代码检查
秘书：记录错误
测试人员：提供测试用例
程序员：代码作者
其他人员：有经验程序员、程序员新手、来自其他不同项目人、来自该软件编程小组的程序员
1.3 用于代码检查的错误列表
代码走查需要测试用例，代码检查需要一份检查代码的错误列表，以下包括一些错误列表的建议
a) 数据引用错误
| 数据引用错误 |
| 1.是否有引用的变量未赋值或未初始化 |
| 2.下标的值是否在范围之内 |
| 3.是否存在非整数下标 |
| 4.是否存在虚调用 |
| 5.当使用别名时属性是否正确 |
| 6.记录和结构的属性是否匹配 |
| 7.是否计算位串的地址？是否传递位串参数 |
| 8.基础的存储属性是否正确 |
| 9.跨过成的结构定义是否匹配 |
| 10.索引或下标是否有“仅差一个”的错误 |
| 11.继承需求是否得到满足 |
b) 数据声明错误
| 数据声明错误 |
| 1.是否所有的变量都已声明 |
| 2.默认的属性是否被正确理解 |
| 3.数组和字符串的初始化是否正确 |
| 4.变量是否赋予了正确的长度 |
| 5.初始化是否与存储类相一致 |
| 6.是否有相似的变量名 |
c) 运算错误
| 运算错误 |
| 1.是否存在非算术变量间的运算 |
| 2.是否存在混合模式的运算 |
| 3.是否存在不同字长变量间的运算 |
| 4.目标变量的大小是否小于赋值大小 |
| 5.中间结果是否上溢或下溢 |
| 6.是否存在被0除 |
| 7.是否存在二进制的不精确度 |
| 8.变量的值是否超过了有意义的范围 |
| 9.操作符的优选顺序是否被正确理解 |
| 10.整数除法是否正确 |
d) 比较错误
| 比较错误 |
| 1.是否存在不同类型变量间的比较 |
| 2.是否存在混合模式的运算比较 |
| 3.比较运算符是否正确 |
| 4.布尔表达式是否正确 |
| 5.比较运算是否与布尔表达式相混合 |
| 6.是否存在二进制小数的比较 |
| 7.操作符的优先顺序是否被正确理解 |
| 8.编译器对布尔表达式的计算方式是否被正确理解 |
e) 控制流程错误
| 控制流程错误 |
| 1.是否超出了多条分支路径 |
| 2.是否每个循环都终止了 |
| 3.是否每个程序都终止了 |
| 4.是否存在由于入口条件不满足而跳过循环体 |
| 5.可能的循环越界是否正确 |
| 6.是否存在“仅差一个”的迭代错误 |
| 7.DO/END语句是否匹配 |
| 8.是否存在不能穷尽的判断 |
| 9.输出信息中是否有文字或语法错误 |
f) 接口错误
| 接口错误 |
| 1.形参的数量是否等于实参的数量 |
| 2.形参的类型是否与实参的类型相匹配 |
| 3.传递给被调用模块的实参个数是否等于其形参个数 |
| 4.传递给被调用模块的实参属性是否与其形参属性匹配 |
| 5.调用内部函数的实参的数量、属性、顺序是否正确 |
| 6.是否引用了与当前入口点无关的形参 |
| 7.是否改变了某个原本仅为输入值的形参 |
| 8.全局变量的定义在模块间是否一致 |
| 9.常数是否以实参形式传递过 |
g) 输入/输出错误
| 输入/输出错误 |
| 1.文件的属性是否正确 |
| 2.OPEN语句是否正确 |
| 3.I/O语句是否符合格式规范 |
| 4.缓冲大小与记录大小是否匹配 |
| 5.文件在使用前是否打开 |
| 6.文件使用后是否关闭 |
| 7.文件结束条件是否被正确处理 |
| 8.是否处理了I/O错误 |
h) 其他检查错误
| 其他错误 |
| 1.在交叉引用列表中是否存在未引用过的变量 |
| 2.属性列表是否与预期相一致 |
| 3.是否存在“警告”或“提示”信息 |
| 4.是否对输入的合法性进行了检查 |
| 5.是否遗漏了某个功能 |
2、桌面检查
定义：由一个人阅读程序，对照错误列表检查程序，对程序推演测试数据。
由于桌面检查的低效性，桌面检查最好有其他程序员完成（两个程序员交换各自程序进行检查）
3、同行评审
目的：为程序员提供自我评价的手段。
步骤：
1）选择一位程序员担任评审过程的管理员；
2）管理员挑选6-20名参与者；
3）每名参与者挑出自己写的两个程序（一个好的，一个差的）；
4）将程序随机分发给每名参与者，参与者匿名评审其他人的代码；
5）每名参与者评审完一个程序后，须填写一张评价表，所有程序都评审完后，需要对程序整体质量进行分级；
6）评审结束后，参与者会收到程序的匿名评价表；
