《软件测试的艺术》读书笔记（三）

3.3 用于代码检查的错误列表

常见错误对照表，容易出现的问题：过于注重代风格码而不是代码错误、过于模糊不够具体。

 

 

 

 

 

 

 

 

 

 

 

3.3.1 数据引用错误

3.3.2 数据声明错误

3.3.3 运算错误

3.3.4 比较错误

3.3.5 控制流程错误

3.3.6 接口错误

3.3.7 输入/输出错误

3.3.8 其他检查

就像产品经理会有一个清单，在需求和原型完成后对照查看是否有常见的遗漏和错误，代码检查的这些常见错误也涵盖了方方面面。

虽然其中有些专有名词看不太明白，但看得明白的部分确实是一些不太容易发现又确实遇到过的 bug，原来这些问题在代码检查阶段就应该发现。

在实际工作中，时常因为例如接口返回顺序到底应该由产品来规定，还是程序员应该自己决定而无法明确区分权责。

目前的情况就是，对于一些和时间相关的顺序，经过多次纠错，程序员同事已经知道默认使用倒序排序，已经算是从“反常问题”变成了“常规问题”。

但对于一些不那么明显的列表，还是会存在使用莫名其妙的排序方法的问题，例对随机 ID 进行首字母排序，导致从表象来看完全摸不着头脑。

3.4 代码走查(Walkthroughs)

代码走查小组由三至五人组成，其中一人负责协调，一人负责记录所有查出的错误除，一人负责测试。

小组成员组成，除了负责编写项目的程序员外，还可以从以下人员中挑选两到三人：

(1)一位极富经验的程序员

(2)一位程序设计语言专家

(3)一位程序员新手（可以给出新颖，不带偏见的观点）

(4)最终将维护程序的人员

(5)一位来自其他不同项目的人员

(6)一位来自该软件编程小组的程序员

 

不同于仅阅读程序或使用错误检查列表，代码走查的参与者“使用了计算机”。被指定为测试人员的那个人会带着一些书面的测试用例（程序或模块具有代表性的输入集及预期的输出集）来参加会议。

与代码检查不同的是，走查有了测试人员的参与，加入了对程序的使用。

在大多数的代码走查中，很多问题是在向程序员提问的过程中发现的，而不是由测试用例本身直接发现的。

走查所有的测试用例并不是完整的，而是只包含一些主要的、典型的部分。

代码走查的目的并不是通过走查找到所有的错误（这是软件测试的目的），而是提供了对程序员的逻辑思路和设计思想质疑的机会。

就像产品需求评审一样，是人们坐在一起对程序的逻辑和需求进行评审的机会。

目的都是尽早发现逻辑错误，以免浪费开发成本，造成更大的损失。

3.5 桌面检查(Desk Checking)

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

桌面检查胜过没有检查，但其效果远远逊色于代码检查和代码走查。

3.6 同行评分(Peer Ratings)

• 程序是否易于理解？
• 高层次的设计是否可见且合理？
• 低层次的设计是否可见且合理？
• 修改此程序对评审者而言是否容易？
• 评审者是否会以编写出该程序而骄傲？

该过程适用于企业开发和课堂教学环境

通过第三方评价帮助程序员发现自身编程能力的不足。

3.7 小结

大多数的软件项目都应使用到以下的人工测试方法：
• 利用错误列表进行代码检查。
• 小组代码走查。
• 桌面检查。
• 同行评审。