软件测试的艺术(第3版)第03章 代码检查、走查与评审讲解.pptx

3.1 代码检查 3.2 用于代码检查的错误列表 3.3 代码走查 3.4 桌面检查 第3章 代码检查、走查与评审 静态测试（人工测试） 不运行程序进行测试，即检查和审阅 静态黑盒测试——检查产品说明书 静态白盒测试——检查代码，在不执行的条件下有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程，有时称为结构分析。 动态测试（基于计算机的测试） 运行和使用软件以发现错误，即通常意义上的测试 第3章 代码检查、走查与评审—静态测试和动态测试 人工测试方法的正规性、精确性不如基于计算机测试，但并不妨碍测试取得成功，相反可以提高测试的功效和可靠性 错误发现得越早，改正错误成本越低，正确改正错误可能性越大 程序员在开始基于计算机的测试时要经历一个心理上的转变，改正早期发现的错误比改正后期计算机执行发现的错误时失误更少 更容易定位以及发现由该错误引发的其他缺陷（如连锁错误或类似错误）降低调试成本 通常会有效地查找出30％－70％的逻辑设计和编码错误 第3章 代码检查、走查与评审—人工测试 人工测试的主要方法 代码检查 代码走查 可用性测试 第3章 代码检查、走查与评审—人工测试 负责静态测试的人员不是固定的。在某些小组中，程序员就是组织和审查的人员，软件测试员被要求作为独立的观察者。还有一些小组，软件测试员是该任务的执行人，要求编写代码的程序员和其他同时帮助审查。采用何种方式取决于开发小组的自身状况。 3.1 代码检查 静态白盒测试一般面临的情况是不能善始善终，因为小组会认为太好使，费用太高，没有产出。 原因是人们认为程序员的任务就是编写代码，而任何破坏代码编写效率的事情都会减缓开发过程。 3.1 代码检查 四个基本要素 确定问题 遵守规则 准备 编写报告 3.1 代码检查 实施过程 协调人在代码检查前几天分发程序清单和设计规范 编码人员讲述程序的逻辑结构，其他人员提问题并判断是否存在错误(对照历来常见的编码错误列表) 注意力集中在发现错误而非纠正错误上（非调试） 会议结束后，程序员会得到一份已发现错误的清单 3.1 代码检查 人员组成（4人） 一人负责协调：分发材料、安排进程、确保错误随后得到改正 被测试程序的编码人员 程序的设计人员和一名测试专家 代码检查的其他作用 程序员会得到编程风格、算法选择及编程技术等方面的反馈信息其他参与者也可以同样受益 3.1 代码检查 1.数据引用错误 变量使用前是否赋值或初始化？ 容易引起变量使用错误，特别是对于指针或引用变量。 在java中要求变量在使用前必须初始化。 数组下标的范围和类型 是否存在下标越界错误，下表类型是否为整型。 通过指针引用的内存单元是否存在（虚调用）？ 如在函数返回局部变量的指针或引用时会产生虚调用错误。 被引用的变量或内存的属性是否与编译器预期的一致？ 如A类型的指针或引用是否指向的是非A类型对象。 3.2 用于代码检查的错误列表 2.数据声明错误 是否所有变量都已声明？ 绝大多数编程语言要求变量先定义后使用，可保证变量使用的安全性。 默认的属性（默认值）是否正确？ 变量的初始化是否正确？变量的初始化是否与其存储空间的类型一致？ 是否每个变量都有正确的长度、类型和存储类别？ 是否存在相似名称的变量？ 3.2 用于代码检查的错误列表 3.运算错误 是否存在非算术变量之间的运算？ 是否存在混合模式的运算？（ int与float类型） 是否存在不同字长变量之间的运算？（int与long类型） 目标变量大小是否小于所赋值的大小？（精度损失或越界错误） 中间结果是否上溢或下溢？ 是否存在除0错误？ 操作符的优先顺序是否正确？ 整数除法是否正确？（精度问题，如2*(i/2)==i） 3.2 用于代码检查的错误列表 int x = 1; int y = 2; float z = 0; z = x/y; System.out.println (z = z); OUTPUT: z = 0 3.2 用于代码检查的错误列表 4.比较错误 是否有不同类型数据的比较运算？（如日期与数字） 是否有混合模式或不同长度数据的比较运算？ 比较运算符是否正确？（如至多、至少，不小于） 布尔表达式（与、或、非）是否正确？ 比较运算符是否与布尔表达式相混合？（如2i10对吗？） 是否存在浮点数的比较？ 优先顺序是否正确？（例如if((a==2) (b==2) || (c==3)） 布尔表达式的计算方式（例如 if((x==0 (y/x)z)） 3.2 用于代码检查的错误列表 5.控制流程错误 是否所有循环都能终止？（循环结束条件是否能满足以及递归的终止条件是否能满足。） 是否存在由于入口条件不满足而跳过循环体？（do…while循环） 是否存在仅差一个的循环错误？（如