《软件测试的艺术》

利用错误列表进行错误检查

代码检查

（code inspections）

数据引用错误

1、是否有引用的变量未赋值或未初始化？	这是最常见的编程错误，在各种环境中引发。在每个引用数据项（如变量、数据元素、结构中的域）时，应试图非正式地“证明”该数据项在当前的位置具有确定的值。
2、小标的值是否在范围内？
3、是否存在非整数小标？
4、是否存在虚调用？
5、当使用别名时属性是否正确？
6、记录和结构的属性是否匹配？
7、是否计算位串的地址？是否传递位串参数？
8、基础的存储属性是否正确？
9、跨过程的结果定义是否匹配？
10、索引或小标操作是否有“仅差一个”的错误？
11、继承需求是否得到满足？

运算错误

1、是否存在非算数变量间的运算？
2、是否存在混合模式的运算？
3、是否存在不同字长变量间的运算？
4、目标变量的大小是否小于赋值大小？
5、中间结果是否上溢或者下溢？
6、是否存在被0除？
7、是否存在二进制的不精确度？
8、变量的值是否超过了有意义的范围？
9、操作符的优先顺序是够被正确理解？
10、整数除法是否正确？

数据声明错误

1、是否所有的变量都已声明？
2、默认的属性是否被正确理解？
3、数组和字符的初始化是够正确？
4、变量是否赋予了正确的长度，类型和存储类？
5、初始化是否与存储类相一致？
6、是否有相似的变量名？

比较错误

1、是否存在不同类型变量间的比较？
2、是否存在混合模式的比较运算？
3、比较运算符是否正确？
4、布尔表达式是否正确？
5、比较运算符是否与布尔表达式相混合？
6、是否存在二进制小数的比较？
7、运算符的优先顺序是够被正确理解？
8、编译器对布尔表达式的计算方式是否被正确理解？

控制流程错误

1、是否超出了多条分支路径？
2、是否每个循环都终止了？
3、是否每个程序都终止了？
4、是否存在由于入口条件不足而跳过循环体？
5、可能的循环越界是否正确？
6、是否存在“仅差一个”的迭代错误？
7、do/end语句是够匹配？
8、是否存在不能穷举的判断？
9、输出信息中是否有文字或语法错误？

输入/输出错误

1、文件的属性是否正确？
2、open语句是否正确？
3、I/O语句是否符合格式规范？
4、缓冲大小与记录大小是否匹配？
5、文件使用前是否打开？
6、文件在使用后是够关闭？
7、文件结束条件是否被正确处理？
8、是否处理了I/O错误？

接口错误

1、形参的数量是否等于实参的数量？
2、形参的量纲是否与实参的量纲相匹配？
3、传递给被调用模块的实参的个数是否等于其形参的个数？
4、传递给被调用模块的实参属性是否与其形参属性匹配？
5、传递给被调用模块的实参量纲是否与其形参量纲匹配？
6、调用内部函数的实参的数量、属性、顺序是否正确？
7、是否引用了与当前入口点无关的形参？
8、是否改变了某个原来仅为输入值的形参？
9、全局变量的定义在模块间是否一致？
10、常数是否以实参形式传递过？

 

 

 

小组代码走查

1、代码走查的概念：

以小组为单位进行代码阅读，是一系列规程和错误检查技术的集合。

2、代码走查的实施：

代码走查小组由三至五人组成，其中一个人扮演雷系代码检查过程中“协调人”的角色，一个人担任秘书（负责记录所有查出的错误）的角色，还有一个人担任测试人员。建议另外的参与者包括：（1）以为极富经验的程序员；（2）一位程序设计语言专家；（3）一位程序员新手（可以给出新颖，不带偏见的观点）；（4）最终将维护程序的人员；（5）一位来自其他不同项目的人员；（6）一位来自该软件编程小组的程序员。

3、代码走查的意义：

提出的建议应针对程序本身，而不是针对程序员。换句话说，软件中存在的错误不应该被视为编写程序人员自身的弱点。相反，这些错误应被看作是伴随着软件的艰难性所固有的。

 

桌面检查

(desk checking)

1、桌面检查可视为由单人进行代码检查或者代码走查：由一个人阅读程序，对照错误列表检查程序，对程序推演测试测试数据。

2、桌面检查胜过没有极限嘻哈，但其效果远远逊色于代码检查和代码走查。

 

同行评审

（peer rating）

1、同行评审的概念

同行评分是一种依据程序整体质量，可维护性、可扩展性、易用性和清晰性对匿名的程序进行技术评价的技术。改技术的目的是为程序员提供自我评价的手段。

2、实施过程：

选出一名程序员来担任这个评分过程的管理员，管理员又会挑选出大约2~20名参与者，保持匿名，这些参与者否应具有相似的背景要求每名参与者都挑选出两个由自己编写的程序以供评审。其中的一个程序应是参与者自认为能代表其自身能力的最好的作品，而了另一个则是参与者自认为质量较差的作品。

当所有程序都收集完毕后，就将这些程序随即分发给参与者。没名参与者拿到4个程序进行评审，其中的两个是“最好”的程序，另外两个则是相对“较差”的程序，单评审人自己并不知道。每名参与者没评审一个程序得花费30分钟，评审完后填写一张评价表。所有4个程序都评审完后，参与者对4个程序的相对质量进行分级。评价表要求评审人用从1~7的分值对诸如下面的问题进行回答：

1）程序是够易于理解？

2）高层次的设计是够可见且合理？

3）低层次的设计是否可见且合理？

4）修改此程序对评审者而言是否容易？

5）评审者是否会以编写出该程序而骄傲？

还要要求评审人给出总的评价和建议的改进意见。

评审结束后，参与者会收到自己的那两个程序的匿名评价爱表，此外还会收到一个带统计的总结，说明在所有的程序中其程序的整体和具体得分情况，以及他对其他程序的评价爱与其他评审人同意程序打分的比较分析情况。

3、评审目的：

让程序员对自身的编程技术进行自我评价。