本文为"software testing"一书的读书笔记

静态白盒测试：检查设计和代码

formal review

这个过程有4个方面要做：

• 找到问题（错误的地方或者漏掉的地方）
• 遵守规则（遵守架构规则和代码规范）
• 要有所准备（不打无准备之战）
• 写报告（有助于后期维护）

完成这个过程有助于：

• 团队成员之间的交流
• 项目的质量
• 增进团队成员之间的友谊(camaraderie)
• 可能会找到一些难题的解决方案

peer review

这是一种非正式的过程，通过是一个程序员设计和写的代码被其它几个程序员 和测试师来检查，小团队里面的成员会互相检查代码。

walkthrough

不知道怎么翻译，主要是某个程序员把自己的代码展示给一个检查小组， 这个小组需要写下评论和问题。一个小组里面最好是要有一个高级程序员。 这个程序员需要一个函数一个函数或者一行代码一行代码地解释给这个小组的人 听，小组的人来提问，最后这个程序员需要写一个报告，说明找到的问题以及 以后要怎么解决。

inspection

这是一个最正式的过程，分为很多种角色。一种是presenter或者reader，他不是 写代码的程序员，他是被迫来阅读那个程序员写的代码，写下来他的理解，然后在 inspection meeting上展示他的理解。剩下的人称为inspector，专门通过不同的 角度（用户，测试题，客户）来检查代码。在inspector中，有部分的人称为moderator 或者recorder, 负责准备检查报告，说明问题出现在哪里。

编码标准和规范

好的代码需要满足下面的几点：

• 可靠
• 可读/可维护
• 可移植

一些常见的代码错误

虽然这些是靠编程经验的积累来理解的，但是知道比不知道要好。

数据引用错误

• 引用一个未初始化的变量
• 数组下标不是整数或者数组下标越界
• 数组下标差了一个位置（比如一些编程语言下标从0开始）
• 一些可以用常量代替的地方却用了变量（比如数组长度）
• 变量被赋了不同类型的值
• 引用的指针没有分配内存

数据定义错误

• 变量没有定义正确的长度和类型
• 很多变量有类似的名字（会让看代码的人混淆）
• 有一些变量从未被使用或者只使用了一次

计算错误

• 左边的变量存不下右边的计算结果
• 溢出在计算的中间过程产生
• 除0错误
• 整数除法中丢失了精度
• 计算结果背离了有意义的范围（比如不在0%-100%之间）
• 运算符优先级错误

比较错误

• 比较两个浮点数，可能会存在精度问题

控制流错误

• 有死循环
• 分支语句永远不会被执行
• 循环中计数器差了一个位置，出现了"off by one"错误

函数参数错误

• 实参和形参类型不对，顺序不对
• 函数修改了一个参数，但是这个参数本来是不能被修改的
• 本来可以使用传递参数的方法解决问题却使用了全局变量

输入输出错误

• 输入输出没有特定格式，但是没有实现
• 没有判断文件或设备打不开的情况
• 没有检查用户输入的正确性，语法错误和拼写错误

其他错误

• 没有考虑软件需要多国语言支持
• 没有考虑软件需要移植到其他CPU或平台
• 没有考虑兼容性（比如说不同的显卡声卡等）
• 软件编译过程没有产生一些提示信息。