用例评审最佳实践

　　在软件测试活动中测试用例扮演着十分重要的作用。关于怎么写好测试用例，测试用例包含的八大要素，黑盒测试用例八种设计方法等相关介绍有很多，但本篇关于测试用例的评审的精准总结，绝对不容错过！
　　测试用例评审作为测试用例设计过程中必要步骤，可以指数级提升测试用例的质量。为什么这么说呢？下面我们就聊一聊测试用例评审活动。
　　我们借用5W1H的模型，让各位看官能够更清晰了解测试用例评审活动。
　　图片
　　WHY
　　测试用例评审的目的
　　首先谈谈Why，也就是测试用例评审的目的，简单的总结一下：
　　1. 提高测试用例覆盖率：在评审过程中，项目组中各个角色看待问题的角度不完全一致，所以可以根据各个角色提出的意见和建议，再次考虑测试方法扩充测试用例的全面性，保证测试 用例的覆盖率，从而保证产品质量。
　　2. 保证测试用例的有效性：在评审过程中向项目组各个角色阐述测试人员对需求的理解，保证测试用例是得到各个角色认可的有效的用例，减少在测试过程中引起的冲突和争议。
　　3. 提前发现问题：在评审过程中,测试人员以及项目组其他成员会对需求进行再一次的确认，可以提前发现需求问题，需求实现问题等，避免在转入测试阶段后再发现，减低修改成本。
　　图片
　　WHO
　　测试用例评审相关人员
　　接下来是Who，测试用例评审相关的人员。既然是测试活动中的一环，那测试用例评审的主导人（发起人）肯定是测试人员；其他的参与人员：产品经理，对应需求开发人员，对应需求的其他测试人员，项目运营人员，需求的业务方，需求关联的项目组其他成员都是必不可少的。至于为什么加上对应需求？是为了精确人员，减少测试用例评审带来的成本消耗。
　　图片
　　HOW
　　测试用例评审的形式
　　我们继续看How，测试用例评审的形式。一般测试用例会采用三种形式：
　　a.召开评审会议，与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。
　　b. 通过邮件与相关人员沟通确认。
　　c. 通过IM等交流工具与相关人员进行确认。
　　选取方式的时候一般遵循以下原则：
　　a. 正常迭代用例进行会议评审。
　　b. 紧急需求可选择使用非会议方式评审。
　　c. 少量优化类需求可选择非会议方式评审。
　　d. 方式只是手段，得到项目各个角色对于用例的反馈才是目的。
　　e. 无论采取哪种评审方式，在用例评审前1-2天需要把设计好的测试用例给到项目各个相关角色。
　　图片
　　WHEN
　　测试用例评审的时间节点
　　用例评审应该在什么时间点进行（When）？两个时间节点：在用例初步设计完成后进行评审；在用例评审完成并更新后进行确认。
　　图片
　　WHAT
　　测试用例评审的内容
　　用例评审评审的内容(What）：
　　a.用例是否覆盖需求需要包含的测试点。
　　b.用例优先级安排是否合理。
　　c.用例是否具有很好的可执行性。
　　d.用例是否包含了必要的异常场景（测试用例应当包含百分之二十的正向用例和百分之八十的异常用例）。
　　e.用例是否从用户角度设计场景和使用流程
　　以上就是中通科技测试团队用例评审活动的大体步骤和内容。
　　图片
　　但是理论和实践之间总是存在着巨大的鸿沟：很多产品线，总是有或大或小的缺陷遗漏到了线上。线上故障分析的时候，有部分比例的线上故障能追根溯源到用例评审环节。用例评审环节本可以发现这些问题的，但总是有各种原因，放过了。 中通科技测试团队在这方面做了一些探索：我们成立了一个跨团队用例评审专家团。
　　提前拿到各个团队的用例评审时间。
　　交叉安排不同的测试专家去旁听用例评审活动。
　　测试专家提前拿到需要评审的用例和需求。
　　现场专家不发表观点，只记录整个过程。
　　过程记录事前设计好了模板。
　　模板内容非常全面 有参与人员，开发产品的投入度，提问的次数等等。
　　阶段性分析反馈数据，找到共性问题。
　　通过这种实际参与的方式去发现用例评审存在的痛点，总结下来大致存在以下几个痛点。
　　用例评审效率低
　　评审是在做需求讨论，而不是在进行用例评审
　　单次会议时长太长无法进行有效的评审和意见收集
　　用例评审参与度低
　　参与人员不按时参加
　　与会成员不关注用例情况
　　多数开发都带着电脑来参加，一直在低头看自己电脑
　　用例内容不规范
　　用例照搬PRD
　　场景类用例缺失
　　反向异常，并发，安全，兼容性用例缺失
　　讲解过程没有重点，按顺序念
　　图片
　　GUIDE
　　踩坑改进指南
　　针对以上存在的痛点，中通科技测试团队总结经验教训，整理出了一份踩坑改进指南，具体如下：
　　用例评审会议节奏控制：
　　评审需要控制时间,尽量控制在0.5小时之内，不要超过1小时，提升评审效率可以参以下几点：
　　对于特别重要的需求，并且需求很多，可以分多次评审，一次一个专题。
　　根据需求的内容和大小采取多种用例评审方式结合的方式进行。
　　用例评审前，存在需求不明确的，会议之前多沟通，测试人员多找产品确认，并要求产品及时给与回复并更新好文档。
　　评审时技术实现跟需求有争议的，2分钟之内没有结论的，及时中断，记录下来，会议后再进行讨论并更新文档。
　　评审前，测试人员将用例给到项目组各个成员。冒烟用例、疑问用例，高亮不同色系区别出来，要求开发，产品评审前阅读确认测试用例，带着疑问参与用例评审。
　　只详细评审冒烟用例+有疑问的用例，这个疑问包括但不限于：测试人员在需求文档之外扩展的场景，测试人员怀疑开发人员容易遗忘的场景，测试人员认为容易存在问题的用例。
　　测试人员互相帮忙，一个主讲测试用例，另一个记录改动点。提高评审效率。
　　用例评审开始前，先简单一两句话阐述下这个需求的重点。
　　评审时，测试人员讲场景时，主要讲用例的检查点是什么，不需要描述步骤。
　　提高参会人员的参与度：
　　参加用例评审会议时，除了主评审测试人员，产品和开发不要带电脑。
　　测试人员在过检查点时，主动与产品及开发互动，经常提问，经常确认。
　　对于参与度一直不高的团队，评审时可以邀请开发负责人或者业务线负责人。
　　评审后持续跟进：
　　第一时间整理测试用例，把修正的内容重新整理补全。
　　会上未确定的内容，会后继续跟进，直到确定结果。
　　没有任何有疑问的地方了，再做个简单的用例评审会议总结（如修正了哪些功能点，补全了哪些？哪些模块功能有变动？哪些功能推迟到下一期做？等）。
　　更新后的用例及时同步到项目组各个角色