测试的艺术：代码检查、走查与评审

软件开发人员通常不会考虑的一种测试形式-人工测试。

大多数人都以为，因为程序是为了供机器执行而编写的，那么也该由机器来对程序进行测试。这种想法是有问题的。人工测试方法在暴露错误方面是很有成效的。实际上，大多数的软件项目都应使用到一下的人工测试方法：

1. 利用错误列表进行代码检查

2. 小组代码走查

3. 桌面检查

4. 同行评审

 

代码检查：

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

一个代码检查小组通常由四人组成：

1. 协调人：以为称职的程序员
2. 该程序的编码人员
3. 该程序的设计人员
4. 测试专家

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

• 数据引用错误
  • 是否有引用的变量未赋值或未初始化
  • 下标的值是否在范围之内
  • 是否存在非整数下标
  • 是否存在虚调用
  • 当使用别名时属性是否正确
  • 记录和结构的属性是否匹配
  • 是否计算位串的地址，是否传递位串参数
  • 基础的存储属性是否正确
  • 跨过程的结构定义是否匹配
  • 索引或下标操作是否有“仅差一个”的错误
  • 继承需求是否得到满足
• 数据声明错误
  • 是否所有的变量都已声明
  • 默认的属性是否被正确理解？
  • 数组和字符串的初始化是否正确？
  • 变量是否赋予了正确的长度，类型和存储类
  • 初始化是否与存储类相一致？
  • 是否有相似的变量名？
• 运算错误
  • 是否存在非算术变量间的运算？
  • 是否存在混合摸式的运算？
  • 是否存在不同字长变量问的运算？
  • 目标变量的大小是否小于赋值大小？
  • 中间结果是否上溢或下溢？
  • 是否存住被0除？
  • 是否存在二进制的不精确度？
  • 变量的值是否超过了有意义的范围？
  • 操作符的优先顺序是否被正确理解？
  • 整数除法是否正确？
• 比较错误
  • 是否存在不同类型变量间的比较？
  • 是否存在混合模式的比较运算？
  • 比较运算符是否正确？
  • 布尔表达式是否正确？
  • 比较运算是是否与布尔表达式相混合？
  • 是否存在二进制小数的比较？
  • 操作符的优先顺序是否被正确理解？
  • 编译器对布尔表达武的计算方式是否被正确理解？
• 控制流程错误
  • 是否超出了多条分支路径？
  • 是否每个循环都终止了？
  • 是否每个程序都终止了？
  • 是否存在由于入口条件不满足而跳过循环体？
  • 肯能的循环越界是否正确？
  • 是否存在“仅差一个”的迭代错误？
  • DO/END语句是否匹配？
  • 是否存在不能穷尽的判断？
  • 输出信息中是否有文字或语法错误？
• 接口错误
  • 形参的数量是否等于实参的数量？
  • 形参的量纲是否与实参的量纲相匹配？
  • 传递给被调用模块的实参个数是否等于其形参个数？
  • 传递给被调用模块的实参属性是否与其形参属性匹配？
  • 传递给被调用模块的实参量纲是否与其形参量纲匹配？
  • 调用内部函数的实参的数量、属性，顺序是否正确？
  • 是否引用了与当前入口点无关的形参？
  • 是否改变了某个原本仅为输入值的形参？
  • 全局变量的定义在模块间是否一致？
  • 常数是否以实参形式传递过？
• 输入/输出错误
  • 文件的属性是否正确？
  • OPEN语句是否正确？
  • I/O语句是否符合格式规范
  • 缓冲大小与记录大小是否匹配？
  • 文件在使用前是否打开？
  • 文件在使用后是否关闭？
  • 文件结束条件是否被正确处理？
  • 是否处理了I/O错误？
• 其他检查
  • 在交叉引用列表中是否存在未引用过的变量？
  • 属性列表是否与预期的相一致？
  • 是否存在“警告”或“提示”信息？
  • 是否对输入的合法性进行了检查？
  • 是否遗漏了某个功能？

 

代码走查：

代码走查不同于仅阅读程序或使用错误检查列表，代码走查的参与者“使用了计算机”。被指定为测试人员的那个人会带着一些书面的测试用例来参加会议。在会议期间，每个测试用例都在人们脑中进行推演，也就是说，把测试数据沿程序的逻辑结构走一遍。程序的状态（如变量的值）记录在纸张或白板上以供监视。

这些测试用例必须结构简单，数量较少。因为人脑执行程序的速度比计算机执行程序的速度慢上若干量级。因此，这些测试用例本身并不起到关键的作用。它们的作用是提供了启动代码走查和质疑程序员逻辑思路及其设想的手段。在大多数的代码走查中，很多问题是在向程序员提问的过程中发现的，而不是由测试用例本身直接发现的。

 

桌面检查：

可以视为由单人进行的代码检查或代码走查。

 

同行评分：

同行评分是一种依据程序整体质量，可维护性、可扩展性、易用性和清晰性对匿名程序进行评价的技术。

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

 

转载于:https://www.cnblogs.com/LilianChen/p/4052399.html