第六章检查代码.pptVIP

第六章 检查代码 主讲人： 李巍 《软件质量保证与测试》 本章重点 静态白盒测试的好处 各种类型的静态白盒测试综述 编码规范和标准 如何从整体审查代码错处 * §6.1 静态白盒测试：检查设计和代码 静态白盒测试——检查代码，在不执行的条件下有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程，有时称为结构分析。 如果具有编程经验，即使只有一点点，就可以对软件的体系结构和代码进行测试。 白盒测试没有黑盒测试通用。 如果测试军队、金融、工业自动化、医药类软件，或者有幸在组织严格的开发模式下工作，在代码级别验证产品就是例行公事。 如果在测试软件的安全问题，需要白盒测试。 * §6.1 静态白盒测试：检查设计和代码 静态测试（人工测试）：不运行程序进行测试——即检查和审阅。 静态黑盒测试——检查产品说明书。 * §6.1 静态白盒测试：检查设计和代码 进行静态白盒测试的好处是尽早发现软件缺陷，以找出动态黑盒测试难以发现或隔离的软件缺陷。 进行静态白盒测试的另一个好处是为黑盒测试程序员设计和应用测试用例提供思路。 通过听审查评论，可以确定有问题或者容易产生软件缺陷的特征范围。 * §6.1 静态白盒测试：检查设计和代码 开发小组中，负责静态白盒测试的人员不是固定的。 在某些小组里面，程序员是组织和执行审查的人员。软件测试人员作为独立的观察者。 还有一些小组，软件测试人员是任务的执行人，编写代码的程序员和其他同事帮助审查。 * §6.1 静态白盒测试：检查设计和代码 静态白盒测试方法的正规性、精确性不如基于计算机测试 但并不妨碍测试取得成功，可以提高测试的功效 错误发现得越早，改正错误成本越低。 更容易定位以及发现由该错误引发的其他缺陷（如连锁错误或类似错误）降低调试成本 通常会有效地查找出30％－70％的逻辑设计和编码错误 * §6.1 静态白盒测试：检查设计和代码 静态白盒测试一般面临的情况是不能善始善终 现状：许多小组错误的认为静态白盒测试耗时太多，费用太高，没有产出。 人们认为程序员的任务就是编写代码，而任何破坏代码编写效率的事情都会减缓开发过程。 这些想法都不对，在后期发现软件缺陷的费用要昂贵很多。 还好这些情况正在改变。 * §6.2 正式审查 正式审查就是进行静态白盒测试的过程 正式审查的含义很广，从两个程序员之间的简单交谈，到软件设计和代码的详细、严格检查均属于此过程。 四个基本要素： 确定问题：审查的目的是找出软件的问题。找出错误、遗漏，对事不对人 。 遵守规则：设立并严格执行 准备：了解自己的责任和义务 编写报告：做出审查结果的书面总结 * §6.2 正式审查 正式审查要严格按照已经建立起来的过程执行。 太随意会让参与者感觉是在浪费时间。 正式审查可以在早期发现一些重大缺陷，一些小的缺陷可能留在后面的测试工作中。 * §6.2 正式审查 坚持正式审查还有一些间接效果： 交流：正式报告中没包含的信息得以交流。 例如，黑盒测试程序员洞察问题所在。 年轻程序员可以学习新技术。 管理员更加理解项目进度。 质量：程序员的代码经过逐个功能、逐个代码仔细复查，常常会使程序员变得更加仔细。 小组同志化：如果审查正确进行，就会建立软件测试员和程序员对双方技艺的相互尊重，并且更好地了解互相的工作及需求。 解决方案：在审查之外讨论解决方案也较有效。 * §6.2 正式审查 一般至少应有 4 人 一人负责协调：分发材料、安排进程、确保错误随后得到改正 被测试程序的编码人员 程序的设计人员 一名测试专家 * §6.2 正式审查 实施过程： 协调人在代码检查前几天分发程序清单和设计规范 编码人员讲述程序的逻辑结构，其他人员提问题并判断是否存在错误(对照常见的编码错误列表) 注意力集中在发现错误而非纠正错误上（非调试） 会议结束后，程序员会得到一份已发现错误的清单 * §6.2 正式审查 其他审查方式： 同事审查：伙伴审查（你看看我的，我看看你的）。 走查：将代码给其他小组。 检查：正式的审查。 * §6.3 编码标准和规范 有三个重要的原因要坚持标准或者规范： 可靠性：更加可靠和安全 可读性/维护性：代码更容易阅读、理解和维护 移植性：有助于在不同的硬件中运行 * §6.3 编码标准和规范 标准：必须遵守的规则 规范：建议的最佳做法 既有一些国际、国内通用的标准及规范，也有一些公司内部的规定。 虽然编程是艺术，但是标新立异未必是艺术 指望怪异着装体现自己艺术家气质的，往往是不入流的“艺术家”。 * §6.3 编码标准和规范 如何获取标准：通过公共机构 美国国家标准学会（ANSI）。 国际工程学会（IEC）。 国际标准化组织（ISO）。 信息技术标准国家委员会（NCITS）。 美国计算机协会（AC