测试人员如何组织用例评审

用例评审的内容

1.是否覆盖测试需求上的所有功能点，不违背产品原型和代码设计，用例设计的结构安排是否清晰合理，有利于高效覆盖需求

2.用例是否具有可执行性，前提条件、执行步骤和预期结果是否正确，有明确的验证方法。优先级安排是否合理

3.是否从用户层面来设计用户使用的场景和业务流程

4.是否包含充分的异常测试用例

5.是否简洁，不冗余，复用性强

用例评审过程

1.提前发出初稿和会议邀约，至少提前一天发出用例初稿，并确定参与用例评审人员，以便项目经理，产品和开发提前阅读用例，让会议更有效率的进行

2.先做简单的业务流程介绍，这个是在评审开始尤为重要的一个过程，刚开始评审，参与人员会比较蒙圈，产品和开发都不知道测试的思路，或者半途加入新的开发和测试，对需求和业务都不够熟悉，如何让评审快速进入状态，先做简单的需求业务流程介绍，说明白打算如何去做评审。

【举个栗子】一个项目有用户体系、电子账户、理财、生活模块，可以先由大到小的细分下去；可用事先画好的脑图，各种流程图，也可当场快速写上板书。

3.按模块进行，有些模块，业务性不是特别强的，可以简单说下有哪些模块，每个模块评审的时候，按测试项分类，UI、核心功能、基础功能、边界测试、兼容测试和异常测试等，预期结果类似的，主要讲清楚用例主题，让参与人员知道每条用例是做什么的。

4.按业务流程进行，业务流程性较强的需求，需要有业务场景和逻辑，按一定的顺序来，让参与人跟着你的思想，避免东一句西一句，

【举个栗子】一个理财活期产品的测试用例评审，购买和赎回，跑批时间段分日间和日终，工作日和周末四个场景，按不同场景分为不同的业务流程进行评审，有理有据，逻辑思路清晰。

5.按测试数据进行，涉及到计算逻辑、收益、报表等需求的，用例编写时会先规划好测试数据，尽管测试数据也是按不同的业务场景来设计的，但直接用测试数据来评审你的测试点，会更清晰，跟上你思路的开发和产品会对应上自己的产品设计和代码设计去评审你的测试点是否不合理或覆盖率不全的地方，从而有效的评审测试用例。

用例评审后的确认

为了节约时间成本，第一次评审尽量对用例设计全面考虑，提前发现其中的不足之处；但是第一次评审难免会要修修补补的地方，在评审时尽快的修复，不能在一两分钟修复的，记录下来，在会议结束后进行修改，如果改动不是很多的，可以发出邮件，标明修改部分，再最后确认最终版。如果需要进行二次评审，那么重新开始邀约会议做二次评审。

四、用例评审需要避免

1.测试点含糊用语，每个用例评审都应该确定最终版，稍有矛盾或疑惑的需求点，都应该确认下来，不能含糊不清。

2.杂乱无章的评审，有顺序有逻辑的进行评审是很重要的一点，如果臆想按照自己的思路评审，不顾他人感受，那么就等同于做无用功。这样的用例执行出来也会有一定的质量风险。

转于：https://zhuanlan.zhihu.com/p/24308453