软件过程基础_设计和代码评审

1、Chaoying Wu软件过程基础软件过程基础 Software Process foundation 第六讲：代码评审第六讲：代码评审lecture Six: code review北京航空航天大学软件工程研究所吴超英吴超英2为什么要进行软件审查（评审）为什么要进行软件审查（评审） Why do we need software inspection? 真正的聪明者并非“从来不犯错误”，而是决不再犯同样的错误。？or主题主题 评审类型 评审的原则 设计评审 评审检查单 缺陷预防 TSP质量准则 评审的注意事项PSP7：评审1 评审类型评审类型 审查（Inspection) 走查 (Walkt

2、hrough) 个人复查(Personal review)PSP7：评审5软件软件Inspection的历史的历史History of software inspection 最初开始于 IBM 的 Michael FaganFirst began in IBMs Michael Fagan 在70年代早期使用；在1976年发表论文 首先在IBM内部传授，然后向外部推广 首先应用于编码，然后扩展到需求和构架 包含了其他人的工作成果Contains other peoples work AT&T 的 Ebenau 和 Strauss Tom Gilb 和 Dorothy Graham 现

3、在的许多其他作者和培训员6一般的目的一般的目的 General objective 改进工作产品的质量 improve quality of product 标识和文档化缺陷和问题 identify and document the defects and problems 标识对一个工作产品所需要的改进 identify the need for product to be improved 验证工作产品与标准、产品规格说明及需求的一致性verify the consistency of product on the standard, product requirement specifi

4、cation and demand. 达到对工作产品的一致reach the consistency of the product 增加同行的产品知识increase product knowledge from peer 管理和正式控制一个项目任务的完成manage and formal control the accomplish of a project task为什么评审（复查）是有效的为什么评审（复查）是有效的 在测试的过程中，你必须 发现异常的行为 指出测试程序在做什么 发现问题在程序中的何处 找出哪个缺陷可能产生这样异常的行为 这些需要花费很多的时间 而在评审和审查时，你会 根据

5、你自己的逻辑 当你发现一个缺陷时，你知道自己在哪里 知道程序应该做什么，但是它没有这么做 知道为什么这是一个缺陷 更加清楚地知道如何进行正确的修正PSP7：评审2 PSP评审原则评审原则 PSP评审是根据一个已定义的流程来进行的，有指导方法、检查单和标准 PSP评审的目标是在第一次编译或测试之前发现每一个缺陷 为了达到这个目标，你应该 在编译和测试之前进行评审 使用编码标准 使用设计完成准则 度量并改进你的评审过程 使用定制的个人检查单PSP7：评审设计评审原则设计评审原则 除了进行代码评审之外，你还需要评审你的设计 这需要你 产生能够被评审的设计 遵循一个清晰的评审策略 阶段地评审设计 验证

6、逻辑正确的实施了需求的各项要求PSP7：评审可评审的设计可评审的设计 一个可评审的设计包括： 已定义的先后关系 准确的表述 一致和清晰的结构 这样就建议： 清晰的说明设计的目的和功能 有设计完成的准则 设计在逻辑方面是结构化的设计本身的话题本次课程不涉及PSP7：评审设计评审策略设计评审策略 产品设计的评审可以分为以下几个步骤： 建议的评审步骤包括： 1.根据需求进行评审，确保在设计中包括所有需要的功能 2.验证所有的程序结构和流程 3.检查逻辑构造是否正确 4.检查健壮性（ robustness ）、安全性（ safety ）和机密性（ security ） 5.检查功能、方法和程序调用，确

7、保都使用恰当 6.检查特殊变量、参数、类型和文件，确保都使用恰当 PSP7：评审12缺陷与质量缺陷与质量 Defect and quality 软件质量体现在许多方面，只有在排除了绝大部分程序缺陷后，才有可能考虑软件质量的其它目标。Software quality embodied in many aspects, Only in the exclusion of most bugs it can consider other goals of software quality. 即使是有经验的程序员，一般开发710行源程序就会引入一个缺陷。一般在编译和测试阶段能够发现和纠正大部分的缺陷，但还

8、有许多缺陷仍然留在最终产品中。Generally, most defects can be found and correct in compile and test, but, there is still many defects in the final product. 首要的任务是要弄清引入的缺陷，并尽可能防止它们的引入。The primary task is to clarify the incoming defect, and as far as possible to prevent their introducing.13缺陷与缺陷与Bug Bugs （小虫子） “程序中仅剩

9、下几个Bugs”，你可能感到一阵轻松。 “程序中仅留有几个定时炸弹”，你还会同样有轻松的感觉吗？u定时炸弹定时炸弹or14无缺陷程序是一个巨大的挑战无缺陷程序是一个巨大的挑战 No defects program is a huge challenge 编写程序的软件工程师本人最适合查找和修复程序中的缺陷。The software engineer is the right person to find and repair the The software engineer is the right person to find and repair the defects in the p

10、rogram. defects in the program. 软件工程师应该承担所生产的软件的质量的责任。The engineer undertake the responsibility of the software quality.The engineer undertake the responsibility of the software quality. 如果你不朝着设计无缺陷程序的方向努力，你永远也不可能做到这一点。You will never do this if you dont attempt toward design no You will never do thi

11、s if you dont attempt toward design no defect program. defect program. 无缺陷无缺陷程序程序数据、有效的数据、有效的技术和技能技术和技能15个人评审过程的原则个人评审过程的原则 Personal review principle 在进入下个开发阶段之前，要评审所有个人的工作。You should review all the personal work before enter the next development stage. 把产品交付给别人之前，要尽量修复所有的缺陷。Try to repair all defect

12、s before deliver. 使用个人检查单并遵循结构化的评审过程。Using the personal checklist and follow the structured review process. 遵循合理的评审实践：在小的增量上进行评审，在纸上做评审，在精神状态好的时候评审。Follow the rational review practice: review in a small incremental, review on the paper, review when mental condition is good.16个人评审过程的原则个人评审过程的原则 Perso

13、nal review principle 度量评审时间、被评审产品的规模、以及发现和遗漏的缺陷类型及数目。Measure the review time, product scale, the found and the omissive defect number and type. 使用上述数据改进个人评审过程。Improve the review process using those data. 按易于评审的方式设计和实现产品。Design and implement the product follow the good review method. 根据评审的数据确定预防缺陷的方法

14、。Determine the defect prevention according to the review data.17错误、缺陷、运行错误、故障和问题错误、缺陷、运行错误、故障和问题 Error, defect, bug, failure and problem在图中，可以从程序员错误开始向下查找到问题，也可以从问题开始向上找到问题的根源缺陷缺陷DefectDefect工具或交付工具或交付打包问题打包问题程序员错误程序员错误其它其它OtherOtherLatentLatentBugBug潜在的潜在的重复重复DuplicateDuplicate运行错误运行错误BugBug硬件或其它硬件

15、或其它HardwareHardware，OtherOther故障故障FailureFailure操作错误操作错误OperatorOperatorErrorError，OtherOther问题问题ProblemProblem18错误数据错误数据 - 分析问题的过程分析问题的过程The error data-process of analysis the problem 软件错误度量问题要区分原因和结果The problem of software error measurement should distinguish the cause and effect. 是由故障引起 by failur

16、e 还是由运行错误引起by bug 还是由程序中的缺陷引起 or by defect 在开发和维护中，对软件运行错误进行跟踪，以找出导致它们的具体缺陷和错误。Tracking the software bug to find out the specific defect and the error. 测试和审查的基本区别 Fundamental distinction of test and review 测试是在操作中遇到问题并对其进行分析，以确定其原因Test is to analysis and ensure the reason of the problem in the proce

17、ssing. 审查是直接标识错误，由于判断减少、节约时间，在本质上比测试更有效Review is to identify the error directly and its more effective than test.19缺陷度量的分类缺陷度量的分类 1 Classification of defect measurement-1 软件缺陷以及标识它们的软件运行错误可以按下列方式分类： 严重程度: 指对用户操作环境的实际或预期的影响 症状: 在发现缺陷时观测到的系统行为 发现位置: 指缺陷被标识出来时所处的系统位置 发现时间: 指在软件生命周期中哪个阶段出现的 发现方式: 指发现缺陷时

18、所执行的操作，如设计审查、实现、测试 引发位置: 用检查程序去标识其它程序的输出错误 引发时间: 指在软件生命周期中哪个阶段引入的 引发方式: 对改进软件过程来说，统计出导致缺陷的错误是最有用的。这些错误一般可以分为逻辑、数据定义、语法、界面等几类 修复地点: 安装修复后的程序时记录的变更位置 修复时间: 修复缺陷所花的时间。它有助于评估和改进软件的维护和增强过程 怎样修复：这里所关注的是怎样设计和应用变更的20PSP代代码码复复查查脚脚本本代码复查检查单代码复查检查单22缺陷记录日志缺陷记录日志 The log of defect 缺陷编号 Defect ID 每个缺陷单独描述 Every

19、defect has independent description 发现缺陷的日期 Date of found time 在修复缺陷后，登入缺陷类型 Login the defect type after defect repaired 引入缺陷的过程阶段。Process stage of bring in defect 在排除缺陷后登入过程阶段。这一般是指发现错误的阶段 Login the process stage after remove defect 缺陷修复时间，指开始修复到修复完成且检查无误所花的时间 Time of repair defect 修复缺陷指此缺陷是由于修复其它缺陷

20、而引入的 Repair defect means bring in because repair other defect 描述一个关于缺陷的简短说明 Cutline about defect 搞不清楚的缺陷类型，应该有一个特殊类型来说明。如：Unknown 或其他 Unknown defect type23缺陷记录日志示例缺陷记录日志示例 Example of defect log日日 期期编编 号号类类 型型引入阶段引入阶段排除阶段排除阶段修复时间修复时间修复缺陷修复缺陷10/28120编码编译1 min. 描述：漏掉了分号“；” 220编码编译1 min. 描述：漏掉了分号“；” 340

21、设计编译1 min. 描述：二元操作变量Rhs有类型错误，必须将整型转换为浮点型 440编码编译1 min. 描述：二元操作变量Rhs有类型错误，常量应为0.0，而不是0。 540编码编译1 min. 描述：二元操作变量Rhs有类型错误，必须将整型转换为浮点型。 640设计编译7 min. 描述：指数必须为整数。使用数学库计算Sqrt。整数计算不正确。 780编码测试14 min. 描述：答案不正确 880编码测试28 min. 描述：对负指数的循环没有终止，忘记减小循环变量。24统计缺陷个数统计缺陷个数 Statistic the defect number 按阶段统计缺陷：Statisti

22、cs defects according to the stage 当完成一个或部分产品的一个阶段后，就应该开始统计这个阶段的缺陷数。例如设计阶段结束后，就应该开始记录在设计中发现的缺陷。 Statistic the stage defect number when accomplish this stage. 在初期，把精力集中在统计编译和测试阶段发现的缺陷数。In the early days, concentrate on statistical the defects number found in the compilation and testing phase.25发现缺陷的步骤

23、发现缺陷的步骤 Procedure of defect be found 有多种发现程序中缺陷的方法，基本上，这些方法都包括几个步骤：Most method to find out defects include these stages:26管理缺陷的步骤管理缺陷的步骤Procedure of defect measurement了解缺陷Know the defects收集缺陷数据Collect defect data分析数据Analysis the data预防、发现和修复这些缺陷Prevent, find and repair these defects27发现和修复缺陷的方法发现和修复

24、缺陷的方法 Method of find and repair defects编译器 or compiler or 测试 or test or 用户反馈 or users feedback or 个人复查源程序 review source program personallyEfficient ?Efficient ?28发现和修复缺陷的方法发现和修复缺陷的方法 Method of find and repair defects 编译器：从几千个C+缺陷数据说明，大约有9.4%的语法错误通过编译器。Compiler: thousands of c + + defect data shows t

25、hat there are about 9.4 percent of grammar mistakes are from the compiler. 测试：测试的质量是由不同种类的测试用例覆盖所有程序功能的程度决定的。测试人员还要确定如果程序运行正确，测试的期望结果应该是什么样的?Test: test quality is determined by the degree of different kinds of test cases cover all program function.29发现和修复缺陷的方法发现和修复缺陷的方法 Method of find and repair def

26、ects 发行仍然含有缺陷的产品，等待用户发现和反馈缺陷信息。但事实证明，这是花费的。 Release the product with defects and wait for users to find and feedback the information. 个人复查源程序清单最有效的发现和修复缺陷的方法。虽然这种方法似乎很难彻底清除程序中的缺陷，但事实证明，这是最快而且最有效的。 Review source program list personally is the most effective method to find and repair defects.30代码复查代码复

27、查Code Review 代码复查 code review 代码复查最好是在源程序编码完成后并且在编译和测试之前进行。这个时候程序员还能记住他打算做什么，也知道如何修复任何问题。 It would be best to do the code review after source program encoding and before compile and test. 在代码复查时看到的是问题本身而不是征兆。We will see the question itself not the sign in code review.314 代码复查检查单代码复查检查单 The Code Revi

28、ew Checklist 当你自己的检查单根据你自己的缺陷经验进行定制后，你的评审才能发挥最大的效果Your reviews will be most effective when your personal checklist is customized to your own defect experience. 使用你自己的数据来选择检查单中的项目Use your own data to select the checklist items. 收集和分析复查中的数据Gather and analyze data on the reviews. 根据经验对检查单进行调整Adjust the

29、 checklist with experience. 根据打印的清单进行复查，而不是屏幕Do the reviews on a printed listing, not on the screen. 检查单定义了复查的步骤和建议的执行这些步骤地顺序The checklist defines the review steps and the suggested order for performing them. 一次复查一个检查单项目Review for one checklist item at a time 在完成时核对每个项目Check off each item as you com

30、plete it.32设计检查单设计检查单 Design checklist 目的：为了确保复查提供了最大的效益，检查单应该将重点放在To ensure that your reviews provide the most benefit, your checklists should focus on defects that 带给你最大麻烦的缺陷上面give you the most trouble 提供最大的杠杆作用provide the most leverage 排列图帮助你建立优先级，分布可以按下面分类分布A Pareto distribution will help you to

31、 establish priorities. Create distributions for 不同类缺陷的发生次数 defect frequency by category 不同类缺陷的带来的成本defect cost by category 33PSP 缺陷类型标准缺陷类型标准 Standard of PSP defect type34分析缺陷分析缺陷-Pareto图示例图示例 Pareto graph example35什么是最常见的缺陷？什么是最常见的缺陷？Whats the most common defect?Pareto分析标识了数据处理，而根本原因分析标识了数据定义36按优先级

32、排列缺陷按优先级排列缺陷 arrangement defects according to priority强调以优先级观察缺陷数37学习建立检查单学习建立检查单 Learn to build checklist为优先级最高的缺陷类型设计检查 Devise checks for the highest priority defect types. 检查你的缺陷日志来识别具体的缺陷，你可以通过产生和设计检查来发现他们 Examine your defect logs to identify the specific defects that you make and devise checks

33、to find them. 设计检查单时应该明确的强调你产生的缺陷 Checks should be devised to specifically address the defects that you make. 例如，在声明的结束你常常忘记分号，那么为这种缺陷设计一个检查单项 For example, if you often forget to include semicolons at the end of a statement, then devise a checklist item for this defect. 虽然太多的细节可能是繁琐的，但是当每一个检查项都有一个小的

34、，容易测试的范围时，可以快速和准确的检查，评审一般来说更有效的 While too much detail can be overwhelming, reviews are generally more efficient when each checklist item has a small, easily tested scope that can be quickly and accurately checked.38组织检查单组织检查单 Organization the checklistn 当选择类别时考虑一下几个方面 When selecting categories consi

35、der the following. 将相同的项合并为一个类别 Merge similar items into one category. 将类别排序以支持你的评审策略和过程 Order categories to support your review strategy and process.39建立个人或项目组检查单建立个人或项目组检查单Establishing personal or team checklist 根据在软件开发过程中每个阶段发现的缺陷类型和数目制作一个表。 列出对于带有大多数缺陷的那些少数缺陷类型：要检查缺陷记录日志，看看是什么问题引起了这些缺陷。 列出对于那些导致

36、重要问题的缺陷：在代码复查阶段要采取措施发现他们。 如果检查表在发现某些类型的缺陷时无效，那么尽量修改检查表以便它能更好地找出这些缺陷，然后再试一次。 如果某项单独的检查不能充分地发现问题,那么用另外的检查项来完成同样的检查工作,替换掉不满意的检查项。 开发完每个新程序后，用同样的方法简要检查一下缺陷数据和检查表并标识出有用的更改和增加部分。 建议想一想哪些步骤可以在以后预防这些缺陷。例如可以更新编码标准或在设计过程中增加一个步骤。40更新检查表更新检查表 Update the checklist 最好在收集20个以上的缺陷后再更新检查表。Its better to update the ch

37、ecklist when collecting more than 20 defects. 定期更新检查表。要定期复查缺陷数据，删除那些不能找到问题的表项。可以把删除的表项放在一个杂类中，为复查其它的表项作参考。Update checklist regularly. Review defect data regularly and delete the table item that cannot find the problem. 设计出适合自己的检查表，定期对它进行检查以保证检查表更有效。Design a suitable checklist and check it regularly

38、to make sure the effectiveness. 只要你在代码复查中还遗漏缺陷，就要不断寻找改进检查表的方法 。As long as there still exists defects, you should find the method to improve the checklist constantly.扩扩展展缺缺陷陷类类型型标标准准42编码标准编码标准 Coding standard 编码的格式和风格-编码标准。The format and style of coded-coding standard 预防缺陷-编码标准还有助于预防缺陷。例如，可以在编码标准中列出那

39、些应该避免使用的方法，像go-to语句、函数多出口、或使用递归算法。有些实践经验也很有用，如在循环入口前或在声名时初始化变量。Defect prevention-coding standard is also contribute to the defect prevention. 规范命名-不良的命名习惯可能是缺陷的一个主要来源。使用那些与变量含义有关的字符作名字，每个名字应有明显的区别以免混淆 。Naming standard-ill-structured naming habit maybe one main source of defect.43评审原则评审原则 Review Prin

40、ciples PSP复查是根据一个已定义的流程来进行的，有指导方法、检查单和标准PSP reviews follow a defined process with guidelines, checklists, and standards. PSP复查的目标是在第一次编译或测试之前发现每一个缺陷The PSP review goal is to find every defect before the first compile or test. 为了达到这个目标，你应该To address this goal, you should 在编译和测试之前进行复查review before com

41、piling or testing 使用编码标准use coding standards 使用设计完成准则use design completeness criteria 度量并改进你的评审过程measure and improve your review process 使用定制的个人检查单use a customized personal checklist44需要需要评审评审的工作产品的工作产品 The product needed review项目建议书和市场需求 Proposal for project and market demand用户需求user requirement技术需

42、求technology requirement系统构架system framework概要设计和详细设计 General design and detailed design软件模块 software module测试计划，测试构件，测试结果 test plan, test construction, test results产品开发计划 Product development plan质量保证计划 quality assurance plan配置管理计划 configuration management plan用户文档 user documentation设施和安装计划 facility

43、and install plan45遵照明确的遵照明确的评审评审策略策略 Follow the explicit review strategy 在评审多个小程序时可能也会遇到问题。 例如，当评审有几个方法的类时，假设这个类有一个控制方法和三个应用方法。如果每个方法大约有50-70行源代码，可能会考虑根据检查单整个类只评审一次。 为了确定这是否是一种合理的策略，再次看一下表9.3（见第175页）并描述出应该如何评审。 确认代码是否覆盖了所有的设计，评审每个方法以确保所有需要的函数都被包含。 检查includes，检查每个方法以确保对每个库函数正确的输入了includes。 检查初始化问题，走查

44、所有方法的逻辑。如果采用这种方式评审，就会在方法之间跳来跳去。检查一个方法时，会建立一个语境，而转到另一个方法时这个语境就会丢失。切换内容会花费时间，导致错误，而且大部分情况下还会导致评审效率低下。 当程序比较复杂时，需要把每部分作为独立的单元进行评审。然后再逐项完成全部检查单。有助于确定哪种方法最有效的度量: 每小时发现的缺陷数（defects/Hr.) 每小时LOC(LOC/Hr.) 收益（缺陷发现百分比） 对几个程序或程序的几个部分尝试一种策略，而对其它程序尝试其它的策略, 分析以上数据。46返工分析图表返工分析图表 Rework analysis charts 050100150200

45、250300350400RequirementsDesignImplementationIntegration/TestQualification0.00%20.00%40.00%60.00%80.00%100.00%120.00%Rework HrsCum Percent47评审（复查）和检查评审（复查）和检查 Reviews and Inspections 检查的主要焦点应该是发现你忽视的问题The principal focus of inspections should be to find problems that you have missed. 当程序中有很多简单的缺陷，检查者

46、就会受到很多干扰而往往忽视更多的重要的问题When programs have many simple defects, inspectors are distracted and often miss more important problems. 评审（复查）代码首先要Reviewing the code first 提供一个达到检查标准的产品来进行检查provides a quality product for the inspection 表现出对检查者时间的尊重shows respect for the inspectors time 进行更高质量的检查produces highe

47、r-quality inspections 产生更高质量的产品produces higher-quality products485 缺陷预防缺陷预防 Defect Prevention 缺陷预防是很重要的，原因是：Defect prevention is important because 发现缺陷总是很昂贵的it is always expensive to find defects 如果缺陷可以被预防，你就可以避免发现和修复这些缺陷的成本if the defects can be prevented, you can avoid the costs of finding and fixi

48、ng them 缺陷预防分析成本发生一次，可以使每个项目获益defect prevention analysis costs are incurred once, but the savings apply to every project 缺陷预防应该遵循一个有序的策略和一个已定义的流程Defect prevention should follow an orderly strategy and a defined process. 对于PSP而言，缺陷预防活动包括收集缺陷数据，改进设计方法和原型建造For the PSP, defect prevention actions include

49、 gathering defect data, improving design methods, and prototyping.49缺陷预防策略缺陷预防策略 -1 Defect Prevention Strategy -1 对于下列最经常出现缺陷的类型设定优先级Set priorities for the defect types that are most 在最终测试或使用时发现的那些缺陷found in the end 最常出现的那些缺陷frequently found 最难或花费最昂贵才能找到和修复的那些缺陷troublesome 可以快速识别出预防行动的那些缺陷easily pre

50、vented 最扰乱你的那些缺陷annoying 缺陷预防过程包括下列步骤The defect-prevention process has the following steps. 遵照一个已建立的时间表Follow an established schedule. 选择一个或两个缺陷类型进行初始活动Select one or two defect types for initial action. 度量缺陷预防的效果Measure the effectiveness of defect prevention. 进行调整并持续进行缺陷预防活动Make adjustments and cont

51、inue.50缺陷预防策略缺陷预防策略-2 Defect Prevention Strategy -2 最初要考虑在集成和系统测试中最经常发现的缺陷的类型When setting initial priorities, consider the defect types found most frequently in integration and system test. 使用PSP数据选择一个或两个缺陷类型来进行初始的活动Use PSP data to pick one or two defect types for initial action. 努力的尝试，建立清晰的预防活动Dont

52、 just try harder; establish explicit prevention actions. 结合过程脚本、检查单和表格Incorporate these actions into your process scripts, checklists, and forms.51分析原因分析原因 鱼骨图示例鱼骨图示例 Cause analysis-fishbone diagram example 名称/类型忘记声明不知道需要声明不理解他人误导拼写错误缺陷52TSP侧重于开发项目的组织与协调，并通过采集必要的数据，使项目组在进入集成和系统测试之前，就能够通过“模块质量剖面图”分析模

53、块的质量。根据这些数据，开发人员就可在集成和系统测试之前就能够确定哪个模块中可能潜伏的错误。该模块质量剖面图是根据这五条准则计算出来的。6 TSP质量准则质量准则 TSP quality criterion 软件设计时间不小于软件实现时间Design time should not less than the implementation time of software. 设计评审（复查）时间至少应占一半的设计时间More than a half design time should be the time of design review. 代码评审（复查）时间至少应占一半的代码编制时间M

54、ore than a half code time should be the time of code review. 在编译阶段发现的缺陷不应超过 10 个/KLOCThe defect found in the compile stage should less than 10/KLOC. 在测试阶段发现的缺陷不应超过 5 个/KLOC。The defect found in the test stage should less than 5/KLOC.53过程质量指数（过程质量指数（PQI）Process quality index 设计/编码时间=设计时间/编码时间，范围是0.01.0 设计评审（复查）时间=2*设计评审（复查）时间/设计时间，范围是0.0