评审管理小结 - 附用例评审模板

1、评审概述

一般意义上的测试过程，是一个执行被测软件的过程。可是随着软件测试行业的技术理念随着时代愈来愈成熟，不执行被测系统的测试，即“静态测试”开始受到更多的重视。

评审就是静态测试的一种重要开展形式，也是“测试尽早介入”原则的最佳实践方式之一。

在项目中常见可能采用的评审类型有：

• 非正式评审（伙伴检查，交叉互查Cross Check）
• 走查（Walk-through）
• 技术评审（Technical Review）
• 审查（Inspection）
• 特别检查（Ad-hoc Review）
• 审计（Audit）
• 管理评审（Management Review）

从被评审的对象上来讲，需求评审，设计评审，用例评审等等，都是测试团队应该参与评审的对象。进一步说，项目全部阶段的产出，与测试工做开展相关，而且测试团队具有评审能力的，都应该积极参加。测试管理人员应该将评审视做测试活动的重要组成部分。

评审是一种经过阅读，分析和讨论发现问题的活动。与动态测试即一般意义上所言的测试执行相比，评审能够帮助团队从更上游的阶段施加检测，从而高效的发现和解决问题。从这个角度来讲，评审又是一种预防措施。好比，若是在需求评审阶段发现和解决了需求中的错误，那么则能够预防问题被带入到后续研发阶段，成本和投资回报上是一种很是有价值的活动。
评审的参与各方，能够划分为：

• 做者
• 评审员
• 协调者
• 主持人
• 记录者

其中评审员负责作出具体评审，协调者则负责协调各方意见。

2、评审过程

在具体总结评审的标准流程以前，先来讨论一下评审可能会出现的问题。

不少项目也会组织评审工做，可是每每得不到很是直观的效果，究其缘由问题可能会出如今如下方面：

• 问题1：没有足够的准备

临时召开的评审会议，与会者对于评审内容和对象没有充分的了解和准备。致使的结果是评审会议变成讨论会议，收效不佳甚至为零。

• 问题2：偏离评审目标

因为评审目不明确，可能达不到理想效果。好比，评审者可能对于文档格式等过于关注；又好比一个评审会议每每容易演变成技术讨论和决策会议，甚至是吐槽大会。

• 问题3：没有作好问题跟踪

评审发现了问题，却没有后续的过程去追踪和解决问题，致使评审失去意义。

• 问题4：评审没有被归入计划

评审未被归入计划中，致使的问题就是全部评审的展开都将须要占用额外的时间。这属于规划上的问题，一旦项目时间紧急的状况下，评审颇有可能就要为其余的任务让位。

• 问题5：评审参与度不足

也是常见的现象，评审的参与人员特别是开发人员，经常会以消极的态度看待评审，参与程度不高。

要避免这些问题的发生，那么一个正式评审过程，须要明肯定义如下阶段工做：

• 1.计划
• 2.启动
• 3.我的评审
• 4.评审会议
• 5.返工
• 6.问题跟踪

计划

正式的评审须要一整套过程的支持，因此须要提早作好计划。计划中须要明确的内容包括：评审采用的流程、评审的目标、时间场地安排、参与人员、角色分配等，对于更为正式的评审，可能还须要定义入口和出口准则（即开始、结束条件）。

启动

完善的评审过程应该包括启动阶段，这个阶段的意义在于作好被测对象（好比需求文档）的分发到位，并明确评审的目标，可能状况下主持者还要解答与会人员的疑问。

我的评审

正式会议开始以前，须要留给与会人员时间，先行评审文档，为评审会议作准备，而且标注和概括本身发现的可能缺陷、问题和建议；

评审会议

评审会议上由评审的组织者主持对全部被指出的问题、疑问进行讨论，讨论的重心应该落脚于问题的肯定以及影响程度的判断，而非问题的解决方案。问题的解决应该是会后的工做。

会议应该目标于得出问题清单，以及问题的责任人、级别等。

返工阶段

在评审会议中，咱们得出问题清单以及相关信息汇总，这远非评审的终结。既然知道了问题，那么接下来的工做必定是解决这些问题，这就是返工阶段的意义。责任人须要在预设的时间周期内，完成问题的解决、修复。

追踪阶段

最后咱们须要跟踪问题的修复，并肯定评审的工做已达结束标准。

若是对于被评对象具备比较多的疑虑，返工以后的二次甚至屡次评审也是有可能的。

最后附上用例评审模板一份，以供参考：
连接：https://pan.baidu.com/s/1gcDSli4thx9cwLbsijKqHw 提取码：2ri2