通常意义上的测试过程，是一个执行被测软件的过程。
但是随着软件测试行业的技术理念随着时代越来越成熟，不执行被测系统的测试，即“静态测试”开始受到更多的重视。
评审就是静态测试的一种重要开展形式，也是“测试尽早介入”原则的最佳实践方式之一。
在项目中常见可能采用的评审类型有：
◆ 非正式评审（伙伴检查，交叉互查Cross Check）
◆ 走查（Walk-through）
◆ 技术评审（Technical Review）
◆ 审查（Inspection）
◆ 特别检查（Ad-hoc Review）
◆ 审计（Audit）
◆ 管理评审（Management Review）
从被评审的对象上来说，需求评审，设计评审，用例评审等等，都是测试团队应该参与评审的对象。
进一步说，项目所有阶段的产出，与测试工作开展相关，并且测试团队具备评审能力的，都应该积极参加。
测试管理人员应该将评审视作测试活动的重要组成部分。
评审是一种通过阅读，分析和讨论发现问题的活动。
与动态测试即通常意义上所言的测试执行相比，评审可以帮助团队从更上游的阶段施加检测，从而高效的发现和解决问题。
从这个角度来说，评审又是一种预防措施。
比如，如果在需求评审阶段发现和解决了需求中的错误，那么则可以预防问题被带入到后续研发阶段，成本和投资回报上是一种非常有价值的活动。
评审的参与各方，可以划分为：
◆ 作者
◆ 评审员
◆ 协调者
◆ 主持人
◆ 记录者
其中评审员负责做出具体评审，协调者则负责协调各方意见。
在具体总结评审的标准流程之前，先来讨论一下评审可能会出现的问题。
很多项目也会组织评审工作，但是往往得不到非常直观的效果，究其原因问题可能会出现在以下方面：
问题1：没有足够的准备
临时召开的评审会议，与会者对于评审内容和对象没有充分的了解和准备。导致的结果是评审会议变成讨论会议，收效不佳甚至为零。
问题2：偏离评审目标
由于评审目不明确，可能达不到理想效果。比如，评审者可能对于文档格式等过于关注；又比如一个评审会议往往容易演变成技术讨论和决策会议，甚至是吐槽大会。
问题3：没有做好问题跟踪
评审发现了问题，却没有后续的过程去追踪和解决问题，导致评审失去意义。
问题4：评审没有被纳入计划
评审未被纳入计划中，导致的问题就是所有评审的展开都将需要占用额外的时间。这属于规划上的问题，一旦项目时间紧急的情况下，评审很有可能就要为其他的任务让位。
问题5：评审参与度不足
也是常见的现象，评审的参与人员特别是开发人员，常常会以消极的态度看待评审，参与程度不高。
要避免这些问题的发生，那么一个正式评审过程，需要明确定义以下阶段工作：
◆ 计划
◆ 启动
◆ 个人评审
◆ 评审会议
◆ 返工
◆ 问题跟踪
计划：
正式的评审需要一整套过程的支持，所以需要提前做好计划。
计划中需要明确的内容包括：评审采用的流程、评审的目标、时间场地安排、参与人员、角色分配等，对于更为正式的评审，可能还需要定义入口和出口准则（即开始、结束条件）。
启动：
完善的评审过程应该包括启动阶段，这个阶段的意义在于做好被测对象（比如需求文档）的分发到位，并明确评审的目标，可能情况下主持者还要解答与会人员的疑问。
个人评审：
正式会议开始之前，需要留给与会人员时间，先行评审文档，为评审会议做准备，并且标注和归纳自己发现的可能缺陷、问题和建议。
评审会议：
评审会议上由评审的组织者主持对所有被指出的问题、疑问进行讨论，讨论的重心应该落脚于问题的确定以及影响程度的判断，而非问题的解决方案。问题的解决应该是会后的工作。
会议应该目标于得出问题清单，以及问题的责任人、级别等。
返工阶段：
在评审会议中，我们得出问题清单以及相关信息汇总，这远非评审的终结。既然知道了问题，那么接下来的工作一定是解决这些问题，这就是返工阶段的意义。
责任人需要在预设的时间周期内，完成问题的解决、修复。
追踪阶段：
最后我们需要跟踪问题的修复，并确定评审的工作已达结束标准。
如果对于被评对象具有比较多的疑虑，返工之后的二次甚至多次评审也是有可能的。
今天的小分享就到这了，有问题可以+群：927360521 领取100G软件测试学习视频，暗号：，群内有各大城市软件测试招聘（北上广深比较多）消息，每周1至周5群都会有免费公开课，笔试面试题分享哒！