软件测试的艺术（二）
作者：互联网
代码检查、走查与评审
3.1代码检查与走查
代码检查、走查以及可用性测试是三种主要的人工测试方法。这些测试方法可以用在软件开发的任何阶段。
代码检查和走查都要求人们组成一个小组来阅读或直观检查特定的程序。无论采用哪种方法，参加者都需要完成一些准备工作。准备工作的高潮是在参加者会议上进行的所谓“头脑风暴会”。“头脑风暴会”的目标是找出错误来，但不必找出改正错误的方法。换句话说，是测试，而不是调试。
优点：
1.代码检查与走查是对过去桌面检查过程（在提交测试前由程序员阅读自己程序的过程）的改进。因为在实施过程中，除了软件编写者本人，还有其他人参与进来。
2.代码走查的另一个优点在于，一旦发现错误，通常就能在代码中对其进行精确定位，这就降低了调试的成本。另外，这个过程通常发现成批的错误，这样错误就可以一同得到修正。
缺点：
1.这些方法不能有效地查找出高层次的设计错误，例如在软件需求分析阶段的错误，
3.2代码检查
代码检查，是以组为单位阅读代码，它是一系列规程和错误检查技术的集合，
3.2.1代码检查小组
代码检查小组通常由四人组成：协调人、代码作者、程序设计人员和测试专家。
协调人：（1）为代码检查分发材料、安排进程；（2）在代码检查中起主导作用；（3）记录发现的所有错误；（4）确保所有错误随后得到改正。
3.2.2检查议程与注意事项
1.所有人员提前熟悉程序清单和设计规范。
2.检查时，由程序编码人员逐条讲解程序的逻辑结构，其他人可提问题、判断是否存在错误。
3.检查时，参考常见的编码错误列表分析程序。
4.代码检查会议时间不宜过长（90-120min），环境安静，避免外部干扰。
3.2.3对事不对人，和人有关的注意事项
代码检查的目的是发现程序中的错误，从而改进软件的质量。
程序员不可将代码检查视为对其人格的攻击、采取了防范的态度，那么检查过程就不会有效果。
3.2.4代码检查的衍生功效
除了发现错误这个主要作用之外，代码检查还有其他的衍生作用。
1.程序员通常会得到编程风格、算法选择和编程技术等方面的反馈信息。
2.其他参与者也可以通过接触程序员的错误和编程风格而同样受益匪浅。通常来说，这种类型的测试方法能够增强项目中团队的凝聚力，减少消极人际关系滋长的可能性，有利于打造高度合作、高效的以及信得过的开发模式。
3.3用于代码检查的错误列表
3.3.1数据引用错误
1.是否有引用的变量未赋值或未初始化？
2.对于所有的数组引用，是否每一个下标的值都在相应维规定的界限之内？
3.对于所有的数组引用，是否每一个下标的值都是整数？虽然在某些语言中这不是错误，但这样做是危险的。
4.对于所有的通过指针或引用变量的引用，当前引用的内存单元是否分配？（“虚调用”错误，编码中要保证每个使用指针的引用，引用的内存单元都存在。）
5.如果一个内存区域具有不同属性的别名，当通过别名进行引用时，内存区域中的数据值是否真正具有正确的属性？（实型A和整型B成为同一内存区域的别名，对A赋值后，引用变量B可能会出现此种错误）
6.变量值的类型或属性是否与编译器所预期的一致？（程序将记录读到内存中，并使用一个结构来引用它时，由于记录的物理表示与结构定义存在差异，这种情况下错误就可能发生。）
7.是否计算位串的地址？是否传递位串参数？（当内存分配的单元小于内存可寻址的单元大小时，是否存在直接或间接的寻址错误？如：在某些条件下，定长的位串不必以字节边界为起点，但是地址又总是指向字节边界的。）
8.基础的存储属性是否正确？（错误的例子：一个指向某个数据结构的C++指针，被赋值为另外的数据结构的地址。）
9.跨过程的结构定义是否匹配？（每个过程或子程序对该结构的定义是否都相同？）
10.索引或下标操作是否有“仅差一个”的错误？（边界值）
11.继承需要是否得到满足？
3.3.2运算错误
1.是否存在非算术变量间的运算？（避免不一致的数据类型的变量间运算。）
2.是否存在混合模式运算？（如：将浮点变量和整型变量做加法运算。尽量避免，存在时要保证转换规则正确。）
3.是否存在相同数据类型、不同字长变量间的运算？
4.目标变量的大小是否小于赋值大小？
5.中间结果是否上溢或下溢？
6.是否存在被0除？
7.是否存在二进制的不精确度？
8.变量的值是否超过了有意义的范围？
9.操作符的优先顺序是否被正确理解？
10.整数除法是否正确？
3.3.3数据声明错误
1.是否所有的变量都已声明？
2.默认的属性是否被正确理解？
3.数组和字符串的初始化是否正确？
4.变量是否赋予了正确的长度、类型和存储类？
5.初始化是否与存储类相一致？
6.是否有相似的变量名？
3.3.4比较错误
1.是否存在不同类型变量间的比较？
2.是否存在混合模式的比较运算？（不同长度的变量间的比较运算，应确保程序能正确理解转换规则。）
3.比较运算符是否正确？
4.布尔表达式是否正确？
5.比较运算是否与布尔表达式相混合？（比较运算符和布尔运算符是否错误的混在一起使用了？）
6.是否存在二进制小数的比较？（由于四舍五入，以及用二进制表示十进制数的近似度，这往往是错误的根源。）
7.操作符的优先顺序是否被正确理解？
8.编译器对布尔表达式的计算方式是否被正确理解？
3.3.5 控制流程错误
1.是否超出了多条分支路径？
2.是否每个循环都终止了？
3.是否每个程序都终止了？
4.是否存在由于入口条件不满足而跳过循环体？
5.可能的循环越界是否正确？
6.是否存在“仅差一个”的迭代错误（循环次数多一次或少一次）？
7.do/end语句是否匹配？
8.是否存在不能穷尽的判断？
9.输出信息中是否有文字或语法错误？
3.3.6输入/输出错误
1.文件属性是否正确？
2.open语句是否正确？
3.i/o语句是否符合格式规范？
4.缓冲大小与记录大小是否匹配？
5.文件在使用前是否打开？
6.文件在使用后是否关闭？
7.文件结束条件是否被正确处理？
8.是否处理了i/o错误？
3.3.7接口错误
1.形参数量是否等于实参的数量？
2.形参的属性是否与实参的属性相匹配？（如：数据类型和大小）
3.形参的量纲是否与实参的量纲相匹配？（如：形参以度为单位，而实参以弧度为单位。）
4.传递给被调用模块的实参个数是否等于其形参个数？
5.传递给被调用模块的实参属性是否与其形参属性匹配？
6.传递给被调用模块的实参量纲是否与其形参量纲匹配？
7.调用内部函数的实参的数量、属性、顺序是否正确？
8.如果某个模块或类有多个入口点，是否引用了与当前入口点无关的形参？（避免引用与当前入口点有关的形参）
9.是否改变了某个原本仅为输入值的形参？
10.全局变量的定义在模块间是否一致？
11.常数是否以实参形式传递过？（避免常数以实参形式传递）
3.3.8其他检查
1.在交叉引用列表中是否存在未引用过的变量？（如果编译器建立了一个标识符交叉引用列表，那么对该列表进行检查，查看是否有变量从未引用过，或仅被引用过一次。）
2.属性列表是否与预期的相一致？（检查变量的属性，确保没有赋予过不希望的默认属性值。）
3.是否存在“警告”或“提示”信息？（程序编译通过了，但存在“警告”或“提示”信息，检查处理“警告”或“提示”信息。）
4.是否对输入的合法性进行了检查？
5.是否遗漏了某个功能？
3.4代码走查
代码走查与代码检查很相似，都是以小组为单位进行代码阅读，是一系列规程和错误检查技术的集合。代码走查和代码检查大体相同，但是规程稍微有所不同，采用的错误检查技术也不一样。
相同点：开始的过程相同，参与者在走查会议的前几天得到材料，这样可以专心研究程序。
不同点：会议的规程不同，走查会议不仅阅读程序或使用错误检查列表，代码走查的参与者“使用了计算机”。被指定为测试人员的那个人会带着一些书面的测试用例（程序或模块具有代表性的输入集及预期的输出集）来参加会议。在会议期间，每个测试用例都在人们脑中进行推演。程序的状态记录在纸张或白板上以供监视。
3.5桌面检查
桌面检查是人工查找错误的一种古老方法。可视为由单人进行的代码检查或代码走查：由一个人阅读程序，对照错误列表检查程序，对程序推演测试数据。
缺点：效率低，原因一，它是一个完全没有约束的过程。原因二，缺少小组中的相互促进作用。
3.6同行评审
同行评审是一种依据程序整体质量、可维护性、可扩展性、易用性和清晰性对匿名程序进行评价的技术。该项技术的目的是为程序员提供自我评价的手段。
执行过程：一个程序员担任管理员，挑选6-20名相似背景的参与者（同为java程序员），每个参与者提供两段自己编写的程序（一段“最好的”，一段“最差的”），然后将所有程序随机发给每个参与者（每人4段程序，两段“最好”，两段“最差”，参与者未知），进行评阅打分。评审结束后每个程序员会收到一个匿名评价表。（自己的两段程序的评价表及自己评审的程序的评价与其他评审人对同一程序的评价情况。）
标签：艺术,错误,检查,是否,代码,引用,走查,软件测试 来源： https://blog.csdn.net/qq_35263791/article/details/122829767