软件质量保证与测试检查代码
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
9
§6.2 正式审查
正式审查要严格按照已经建立起来的过程执行。Hale Waihona Puke Baidu
• 太随意会让参与者感觉是在浪费时间。
正式审查可以在早期发现一些重大缺陷，一些小 的缺陷可能留在后面的测试工作中。
10
§6.2 正式审查
坚持正式审查还有一些间接效果：
• 交流：正式报告中没包含的信息得以交流。
• 例如，黑盒测试程序员洞察问题所在。 • 年轻程序员可以学习新技术。 • 管理员更加理解项目进度。
15
§6.3 编码标准和规范
标准：必须遵守的规则 规范：建议的最佳做法 既有一些国际、国内通用的标准及规范，也有一
些公司内部的规定。 虽然编程是艺术，但是标新立异未必是艺术 指望怪异着装体现自己艺术家气质的，往往是不
入流的“艺术家”。
16
§6.3 编码标准和规范
如何获取标准：通过公共机构
静态测试（人工测试）：不运行程序进行测试— —即检查和审阅。
静态黑盒测试——检查产品说明书。
4
§6.1 静态白盒测试：检查设计和代码
进行静态白盒测试的好处是尽早发现软件缺陷， 以找出动态黑盒测试难以发现或隔离的软件缺陷 。
进行静态白盒测试的另一个好处是为黑盒测试程 序员设计和应用测试用例提供思路。
• 美国国家标准学会（ANSI）。 • 国际工程学会（IEC）。 • 国际标准化组织（ISO）。 • 信息技术标准国家委员会（NCITS）。 • 美国计算机协会（ACM）。 • 电子电气工程学会（IEEE）。
17
§6.4 通用代码审查清单
应该审查哪些内容？
18
§6.4.1 数据引用错误
变量使用前是否赋值或初始化？ 数据类型是否匹配？ 数组下标的范围和类型：遗漏、越界等 通过指针引用的内存单元是否存在（虚调用）？
？ 是否存在相似名称的变量？
20
§6.4.3 计算错误
是否存在非算术变量之间的运算？ 是否存在混合模式的运算？（ int与float类型） 是否存在不同字长变量之间的运算？ 目标变量长度是否小于所赋值的大小？（精度损
失或越界错误） 中间结果是否上溢或下溢？ 是否存在除0错误？ 操作符的优先顺序是否正确？ 整数除法是否正确？（精度问题）
7
§6.1 静态白盒测试：检查设计和代码
静态白盒测试一般面临的情况是不能善始善终 现状：许多小组错误的认为静态白盒测试耗时太
多，费用太高，没有产出。 人们认为程序员的任务就是编写代码，而任何破
坏代码编写效率的事情都会减缓开发过程。 这些想法都不对，在后期发现软件缺陷的费用要
昂贵很多。 还好这些情况正在改变。
8
§6.2 正式审查
正式审查就是进行静态白盒测试的过程
• 正式审查的含义很广，从两个程序员之间的简单交谈， 到软件设计和代码的详细、严格检查均属于此过程。
四个基本要素：
• 确定问题：审查的目的是找出软件的问题。找出错误、 遗漏，对事不对人 。
• 遵守规则：设立并严格执行 • 准备：了解自己的责任和义务 • 编写报告：做出审查结果的书面总结
息？ 程序或模块是否对输入的合法性进行了检查？ 程序是否遗漏了某个功能？
26
本章小结
检查代码——静态白盒测试——被证实是早期发 现软件缺陷最有效的方法。
这是一项需要大量准备工作才能有成效的任务。 许多研究表明，花费时间在静态白盒测试上面与
得到的好处相比是值得的。 静态白盒测试正在收到重视，在某些开发过程中，
13
§6.2 正式审查
其他审查方式：
• 同事审查：伙伴审查（你看看我的，我看看你的）。 • 走查：将代码给其他小组。 • 检查：正式的审查。
14
§6.3 编码标准和规范
有三个重要的原因要坚持标准或者规范：
• 可靠性：更加可靠和安全 • 可读性/维护性：代码更容易阅读、理解和维护 • 移植性：有助于在不同的硬件中运行
随后得到改正 被测试程序的编码人员 程序的设计人员 一名测试专家
12
§6.2 正式审查
实施过程：
• 协调人在代码检查前几天分发程序清单和设计规范 • 编码人员讲述程序的逻辑结构，其他人员提问题并判断
是否存在错误(对照常见的编码错误列表) • 注意力集中在发现错误而非纠正错误上（非调试） • 会议结束后，程序员会得到一份已发现错误的清单
形参和实参的数量是否相等？ 形参的属性是否与实参的属性相匹配？ 形参的属性是否与实参的顺序相匹配？ 形参的单位是否和实参匹配？（属逻辑错误） 是否改变了某个仅作为输入值的形参？ 全局变量的定义是否一致？
24
§6.4.7 输入/输出错误
文件属性是否正确？
打开文件的语句是否正确？
缓冲区、内存大小是否足够来保留程序将读取的 文件？
文件在使用前是否打开？
文件在使用后是否关闭了？
文件结束条件是否本正确处理？
是否处理了IO错误？
打印或输出的文本信息中是否存在拼写或语法错 误？即输出结果正确性。
25
§6.4.8 其他检查
是否存在未引用过的变量？ 每个变量的属性和赋予的默认值是否一致？ 编译通过的程序是否存在“警告”或“提示”信
• 如函数返回局部变量的指针会产生虚调用错误。
被引用的变量或内存的属性是否与预期的一致？
• 如A类型的指针或引用指向的是非A类型对象。
19
§6.4.2 数据声明错误
是否所有变量都已声明？ 默认的属性（默认值）是否正确？ 变量的初始化是否正确？变量的初始化是否与其
存储空间的类型一致？ 是否每个变量都有正确的长度、类型和存储类别
• 质量：程序员的代码经过逐个功能、逐个代码仔细复查 ，常常会使程序员变得更加仔细。
• 小组同志化：如果审查正确进行，就会建立软件测试员 和程序员对双方技艺的相互尊重，并且更好地了解互相 的工作及需求。
• 解决方案：在审查之外讨论解决方案也较有效。
11
§6.2 正式审查
一般至少应有 4 人 一人负责协调：分发材料、安排进程、确保错误
21
§6.4.4 比较错误
是否有不同类型数据的比较运算？ 是否有混合模式或不同长度数据的比较运算？ 比较运算符是否正确？ 布尔表达式（与、或、非）是否正确？ 比较运算符是否与布尔表达式相混合？ 是否存在浮点数的比较？ 优先顺序是否正确？
22
§6.4.5 控制流程错误
是否所有循环都能终止？（循环结束条件是否能 满足，递归的终止条件是否能满足。）
《软件质量保证与测试》
第六章 检查代码
xxx
1
本章重点
静态白盒测试的好处 各种类型的静态白盒测试综述 编码规范和标准 如何从整体审查代码错处
2
§6.1 静态白盒测试：检查设计和代码
静态白盒测试——检查代码，在不执行的条件下 有条理地仔细审查软件设计、体系结构和代码， 从而找出软件缺陷的过程，有时称为结构分析。
如果具有编程经验，即使只有一点点，就可以对 软件的体系结构和代码进行测试。
白盒测试没有黑盒测试通用。
如果测试军队、金融、工业自动化、医药类软件 ，或者有幸在组织严格的开发模式下工作，在代 码级别验证产品就是例行公事。
如果在测试软件的安全问题，需要白盒测试。
3
§6.1 静态白盒测试：检查设计和代码
字母必须采用大写的形式，那么这是标准还是规范呢？ 6. 你会采用本章的代码审查清单作为项目小组验证代码的
标准吗？ 7. 缓冲区溢出错误作为一个常见的安全问题属于哪一级错
误？是由什么原因引起的？
29
30
6
§6.1 静态白盒测试：检查设计和代码
静态白盒测试方法的正规性、精确性不如基于计 算机测试
但并不妨碍测试取得成功，可以提高测试的功效 错误发现得越早，改正错误成本越低。
• 更容易定位以及发现由该错误引发的其他缺陷（如连锁 错误或类似错误）降低调试成本
• 通常会有效地查找出30％－70％的逻辑设计和编码错误
• 通过听审查评论，可以确定有问题或者容易产生软件缺 陷的特征范围。
5
§6.1 静态白盒测试：检查设计和代码
开发小组中，负责静态白盒测试的人员不是固定 的。
• 在某些小组里面，程序员是组织和执行审查的人员。软 件测试人员作为独立的观察者。
• 还有一些小组，软件测试人员是任务的执行人，编写代 码的程序员和其他同事帮助审查。
是否存在由于入口条件不满足而跳过循环体？（ do-while循环）
是否存在仅差一个的循环错误？
• 如for ( int i=0; i<=10; i++) {}
程序结构中括号是否匹配、if,else是否匹配、 do,while是否匹配、try,catch是否匹配等。
23
§6.4.6 子程序参数错误
没有静态白盒测试，项目就无法得到可靠的软件。
27
28
作业
请回答以下问题：
1. 说出白盒测试的几个好处？ 2. 判断题：静态白盒测试可以找出遗漏之处和问题。 3. 正式审查由哪些关键要素组成？ 4. 除了更正式之外，检验与其他审查类型有什么重大差别？ 5. 如果要求程序员在命名变量时只能使用8个字符并且首
§6.2 正式审查
正式审查要严格按照已经建立起来的过程执行。Hale Waihona Puke Baidu
• 太随意会让参与者感觉是在浪费时间。
正式审查可以在早期发现一些重大缺陷，一些小 的缺陷可能留在后面的测试工作中。
10
§6.2 正式审查
坚持正式审查还有一些间接效果：
• 交流：正式报告中没包含的信息得以交流。
• 例如，黑盒测试程序员洞察问题所在。 • 年轻程序员可以学习新技术。 • 管理员更加理解项目进度。
15
§6.3 编码标准和规范
标准：必须遵守的规则 规范：建议的最佳做法 既有一些国际、国内通用的标准及规范，也有一
些公司内部的规定。 虽然编程是艺术，但是标新立异未必是艺术 指望怪异着装体现自己艺术家气质的，往往是不
入流的“艺术家”。
16
§6.3 编码标准和规范
如何获取标准：通过公共机构
静态测试（人工测试）：不运行程序进行测试— —即检查和审阅。
静态黑盒测试——检查产品说明书。
4
§6.1 静态白盒测试：检查设计和代码
进行静态白盒测试的好处是尽早发现软件缺陷， 以找出动态黑盒测试难以发现或隔离的软件缺陷 。
进行静态白盒测试的另一个好处是为黑盒测试程 序员设计和应用测试用例提供思路。
• 美国国家标准学会（ANSI）。 • 国际工程学会（IEC）。 • 国际标准化组织（ISO）。 • 信息技术标准国家委员会（NCITS）。 • 美国计算机协会（ACM）。 • 电子电气工程学会（IEEE）。
17
§6.4 通用代码审查清单
应该审查哪些内容？
18
§6.4.1 数据引用错误
变量使用前是否赋值或初始化？ 数据类型是否匹配？ 数组下标的范围和类型：遗漏、越界等 通过指针引用的内存单元是否存在（虚调用）？
？ 是否存在相似名称的变量？
20
§6.4.3 计算错误
是否存在非算术变量之间的运算？ 是否存在混合模式的运算？（ int与float类型） 是否存在不同字长变量之间的运算？ 目标变量长度是否小于所赋值的大小？（精度损
失或越界错误） 中间结果是否上溢或下溢？ 是否存在除0错误？ 操作符的优先顺序是否正确？ 整数除法是否正确？（精度问题）
7
§6.1 静态白盒测试：检查设计和代码
静态白盒测试一般面临的情况是不能善始善终 现状：许多小组错误的认为静态白盒测试耗时太
多，费用太高，没有产出。 人们认为程序员的任务就是编写代码，而任何破
坏代码编写效率的事情都会减缓开发过程。 这些想法都不对，在后期发现软件缺陷的费用要
昂贵很多。 还好这些情况正在改变。
8
§6.2 正式审查
正式审查就是进行静态白盒测试的过程
• 正式审查的含义很广，从两个程序员之间的简单交谈， 到软件设计和代码的详细、严格检查均属于此过程。
四个基本要素：
• 确定问题：审查的目的是找出软件的问题。找出错误、 遗漏，对事不对人 。
• 遵守规则：设立并严格执行 • 准备：了解自己的责任和义务 • 编写报告：做出审查结果的书面总结
息？ 程序或模块是否对输入的合法性进行了检查？ 程序是否遗漏了某个功能？
26
本章小结
检查代码——静态白盒测试——被证实是早期发 现软件缺陷最有效的方法。
这是一项需要大量准备工作才能有成效的任务。 许多研究表明，花费时间在静态白盒测试上面与
得到的好处相比是值得的。 静态白盒测试正在收到重视，在某些开发过程中，
13
§6.2 正式审查
其他审查方式：
• 同事审查：伙伴审查（你看看我的，我看看你的）。 • 走查：将代码给其他小组。 • 检查：正式的审查。
14
§6.3 编码标准和规范
有三个重要的原因要坚持标准或者规范：
• 可靠性：更加可靠和安全 • 可读性/维护性：代码更容易阅读、理解和维护 • 移植性：有助于在不同的硬件中运行
随后得到改正 被测试程序的编码人员 程序的设计人员 一名测试专家
12
§6.2 正式审查
实施过程：
• 协调人在代码检查前几天分发程序清单和设计规范 • 编码人员讲述程序的逻辑结构，其他人员提问题并判断
是否存在错误(对照常见的编码错误列表) • 注意力集中在发现错误而非纠正错误上（非调试） • 会议结束后，程序员会得到一份已发现错误的清单
形参和实参的数量是否相等？ 形参的属性是否与实参的属性相匹配？ 形参的属性是否与实参的顺序相匹配？ 形参的单位是否和实参匹配？（属逻辑错误） 是否改变了某个仅作为输入值的形参？ 全局变量的定义是否一致？
24
§6.4.7 输入/输出错误
文件属性是否正确？
打开文件的语句是否正确？
缓冲区、内存大小是否足够来保留程序将读取的 文件？
文件在使用前是否打开？
文件在使用后是否关闭了？
文件结束条件是否本正确处理？
是否处理了IO错误？
打印或输出的文本信息中是否存在拼写或语法错 误？即输出结果正确性。
25
§6.4.8 其他检查
是否存在未引用过的变量？ 每个变量的属性和赋予的默认值是否一致？ 编译通过的程序是否存在“警告”或“提示”信
• 如函数返回局部变量的指针会产生虚调用错误。
被引用的变量或内存的属性是否与预期的一致？
• 如A类型的指针或引用指向的是非A类型对象。
19
§6.4.2 数据声明错误
是否所有变量都已声明？ 默认的属性（默认值）是否正确？ 变量的初始化是否正确？变量的初始化是否与其
存储空间的类型一致？ 是否每个变量都有正确的长度、类型和存储类别
• 质量：程序员的代码经过逐个功能、逐个代码仔细复查 ，常常会使程序员变得更加仔细。
• 小组同志化：如果审查正确进行，就会建立软件测试员 和程序员对双方技艺的相互尊重，并且更好地了解互相 的工作及需求。
• 解决方案：在审查之外讨论解决方案也较有效。
11
§6.2 正式审查
一般至少应有 4 人 一人负责协调：分发材料、安排进程、确保错误
21
§6.4.4 比较错误
是否有不同类型数据的比较运算？ 是否有混合模式或不同长度数据的比较运算？ 比较运算符是否正确？ 布尔表达式（与、或、非）是否正确？ 比较运算符是否与布尔表达式相混合？ 是否存在浮点数的比较？ 优先顺序是否正确？
22
§6.4.5 控制流程错误
是否所有循环都能终止？（循环结束条件是否能 满足，递归的终止条件是否能满足。）
《软件质量保证与测试》
第六章 检查代码
xxx
1
本章重点
静态白盒测试的好处 各种类型的静态白盒测试综述 编码规范和标准 如何从整体审查代码错处
2
§6.1 静态白盒测试：检查设计和代码
静态白盒测试——检查代码，在不执行的条件下 有条理地仔细审查软件设计、体系结构和代码， 从而找出软件缺陷的过程，有时称为结构分析。
如果具有编程经验，即使只有一点点，就可以对 软件的体系结构和代码进行测试。
白盒测试没有黑盒测试通用。
如果测试军队、金融、工业自动化、医药类软件 ，或者有幸在组织严格的开发模式下工作，在代 码级别验证产品就是例行公事。
如果在测试软件的安全问题，需要白盒测试。
3
§6.1 静态白盒测试：检查设计和代码
字母必须采用大写的形式，那么这是标准还是规范呢？ 6. 你会采用本章的代码审查清单作为项目小组验证代码的
标准吗？ 7. 缓冲区溢出错误作为一个常见的安全问题属于哪一级错
误？是由什么原因引起的？
29
30
6
§6.1 静态白盒测试：检查设计和代码
静态白盒测试方法的正规性、精确性不如基于计 算机测试
但并不妨碍测试取得成功，可以提高测试的功效 错误发现得越早，改正错误成本越低。
• 更容易定位以及发现由该错误引发的其他缺陷（如连锁 错误或类似错误）降低调试成本
• 通常会有效地查找出30％－70％的逻辑设计和编码错误
• 通过听审查评论，可以确定有问题或者容易产生软件缺 陷的特征范围。
5
§6.1 静态白盒测试：检查设计和代码
开发小组中，负责静态白盒测试的人员不是固定 的。
• 在某些小组里面，程序员是组织和执行审查的人员。软 件测试人员作为独立的观察者。
• 还有一些小组，软件测试人员是任务的执行人，编写代 码的程序员和其他同事帮助审查。
是否存在由于入口条件不满足而跳过循环体？（ do-while循环）
是否存在仅差一个的循环错误？
• 如for ( int i=0; i<=10; i++) {}
程序结构中括号是否匹配、if,else是否匹配、 do,while是否匹配、try,catch是否匹配等。
23
§6.4.6 子程序参数错误
没有静态白盒测试，项目就无法得到可靠的软件。
27
28
作业
请回答以下问题：
1. 说出白盒测试的几个好处？ 2. 判断题：静态白盒测试可以找出遗漏之处和问题。 3. 正式审查由哪些关键要素组成？ 4. 除了更正式之外，检验与其他审查类型有什么重大差别？ 5. 如果要求程序员在命名变量时只能使用8个字符并且首