1、软件评审技术,尽早发现错误、减少代价,主要内容,软件评审的目的 评审度量及其应用 评审：正式程度 非正式评审 正式技术评审 QESuite,软件评审的目的,评审的目标在于：尽早发现软件过程中的错误，防止错误传递、蔓延至后续活动，防止错误转化为缺陷。 设计活动引入的错误占软件过程中出现的所有错误的50%65%，技术评审能有效率的发现错误（60%90%）。,错误的传递、放大,示例：无评审,0,0,10,0%,概要设计,6,4 x 1.5,25,0%,详细设计,10 6,4,10,27 x 3,29,20%,编码/单元测试,96,0,0,50%,集成测试,96 96,37 10,27,示例：评审,0
2、,0,10,70%,概要设计,2,1 x 1.5,25,50%,详细设计,3 2,1,5,10 x 3,29,60%,编码/单元测试,27,0,0,50%,集成测试,27 27,15 5,10,0,评审度量及其应用,准备工作量Ep-实际评审会之前所需工作量； 评估工作量Ea-实际评审所花费的工作量 返工工作量Er-修改评审所发现错误的工作量 工作产品规模WPS-评审对象的规模 发现的主要错误数Errmajor-多于预期的改错工作量的错误数目 发现的次要错误数Errminor-少于预期的改错工作量的错误数目,分析度量数据,总评审工作量Ereview = Ep+Ea+Er 错误总数Errtot =
3、 Errmajor+Errminor 错误密度：评审的每单位工作产品发现的错误数Ed = Errtot / WPS错误密度数值的含义：较小（产品质量非常好或评审不够彻底）；较大（产品质量存在缺陷）,评审的成本效益,没有评审：评审成本为0，前期投入（立项至编码）相对较少；但含有较多的错误，后期工作量巨大，总体成本投入多 开展评审：前期增加了评审成本，但所开发的产品包含错误数较少，后期费用会大大降低；总体成本会有所下降。 总体成本的表现：资金投入、人力投入、时间投入等,工作量对比,应该进行项目评审,评审：正式程度,技术评审参考模型 评审人员角色 评审计划和筹备 评审任务、组织 修改、验证、跟踪 根
4、据项目具体情况，选择正式或非正式评审,非正式评审,非正式评审并没有严格的组织形式，一般也不需要将人员集合在一起评审，而是通过电子邮件甚至是网络聊天等多种形式进行评审。 由于缺乏准备、人员分工、评审任务安排、跟踪，存在较大的随机性，评审效率较低。,非正式评审形式,临时会议 即时通讯（eMail，聊天工具等） 结对编程（持续检查）,典型例子：结对编程。将本来可以交给一个人完成的任务分派给两个人去完成，显然浪费了一定的人力；但是产品的质量很大程度的提高，节省了总体成本。,正式技术评审（FTR）,严格按照计划筹备、人员分工、正式评审会议、跟踪等组织技术评审。 目标是: 发现软件的任何一种表示形式中的功
5、能、逻辑或实现上的错误； 验证评审中的软件是否满足其需求； 保证软件的表示符合预先指定的标准； 获得以统一的方式开发的软件； 使项目更易于管理。,评审角色,评审流程,桌上检查,由程序员在单元测试之前检查自己编写的程序，对照错误列表进行检查，对程序推演测试数据，并补充相关文档，目的是发现程序中的错误。,桌上检查的项目,检查变量的引用情况； 检查标号的引用； 检查子程序、宏定义和函数（接口一致性）； 常量检查； 标准检查； 风格检查； 比较控制流； 检查源代码与程序规格说明； 补充文档。,桌上检查编写的文档（非正式）,建立小型的数据字典； 描述主要的路径和异常的路径； 讨论程序的判断逻辑； 以功能
6、术语描述输入、输出； 描述已知的限制和假设； 描述接口和对接口的假设。,评审形式,Inspection,Walkthrouth（代码走查）,4Eyes,比较,评审会议,逐步检查源代码中有无逻辑错误，包括开发者自查和检查小组代码审查。人员包括： 组织者 程序员 其他程序员 测试小组,评审会议主要工作,会前评审小组熟悉源代码、设计说明书程序员阐述程序逻辑； 对照常见缺陷表检查程序设计缺陷； 汇总评审发现的问题，并提交。评审会议约束：评审会议由3人参加；提前准备（2小时）；会议时间不宜太长。,检查表,对照设计使用检查表，检查目标成果是否存在对应的缺陷。 应该根据项目的不同、评审活动的不同，使用不同的
7、评审检查表。评审检查表应该不断地完善。,代码评审检查表,评审报告,评审基本信息 缺陷识别 评审结论 缺陷修正、跟踪,评审报告,评审指导原则,评审工作产品，而不是评审开发人员。 制定并遵守日程表。 限制争论和辩驳。 要阐明问题，但是不要试图解决所有记录的问题。 做笔记。 限制参与者人数。 为每个将要评审的工作产品建立检查清单。 为FTR分配资源和时间。 对所有评审员进行有意义的培训。 评审以前所做的评审。,样本驱动评审,在理想情况下，每个软件工作产品都要经过正式技术评审。但在实际的软件项目中，由于资源有限和时间不足，评审常常被省略。 Thelin01提出了样本驱动评审过程，在这个过程中，要对所有
8、软件工作产品的样本进行审查，以决定哪些工作产品是最有错误倾向的，然后集中全部FTR资源，（根据抽样过程中收集的数据）只分配给那些可能具有错误倾向的工作产品。,样本驱动评审,为了提高效率，样本驱动评审过程必须对作为整个FTR的主要目标的那些工作产品进行量化。量化时一般采用以下步骤： 审查每个软件工作产品i的若干分之一，记做ai，记录在其中发现的缺陷数量fi。 用fi除以ai可得到在工作产品i中缺陷数量的粗略估算值。 按照缺陷数量粗略估算值的递减次序排列这些工作产品。 将现有的评审资源集中到那些具有最高缺陷数量估算值的工作产品上。,QESuite,QESuite软件测试过程管理工具是基于C/S结构
9、和B/S结构的面向软件产品的整个生命周期，实现对测试过程、测试对象和测试数据的有效管理，指导用户实施测试过程改进，满足了开发企业对于测试管理的需求，适用于各类软件企业对其软件测试过程进行有效的管理。,系统功能特点,软件测试过程全面管理 待测软件产品功能分类机制确保测试覆盖率 对测试用例与软件问题报告的数据库管理 测试用例执行与软件问题处理过程的全程跟踪 统一的测试用例与软件问题模板 实用的统计功能辅助管理决策 不同的运行环境随你选择：QESuite现有 Web版和Notes版两种运行版本,小结,本章主要目的实对软件技术评审有一个正确的认识 评审的目的； 评审度量 正式和非正式评审 评审形式（Inspection、Walkthrough）,评审误区,评审参与者不了解评审过程 评审人员评论开发人员，而不是产品（对事不对人） 评审没有被安排进入项目计划（会议时间2hr 评审会议变成了问题解决方案讨论会 评审人员事先对评审材料没有足够了解 评审人员关注于非实质性问题（如风格）尽早、经常地进行正式或非正式的评审,
