腾讯优测优分享 | 这样作测试用例评审更高效

腾讯优测是专业的移动云测试平台，提供多维度的自动化测试服务，让测试更简单！
最近的用例评审让我感觉颇深，如下是我对于测试用例评审的一些感觉，发出来供你们讨论学习。

听听你们对测试用例评审的吐槽？

“测试用例设计是测试的事情，为何评审要咱们参加？”
“测试用例已经不少了，不知道须要评审什么，我能提供什么？”
“用例评审太枯燥了，200个用例case用一条一条评吗？”
“这个是别人的开发的功能，跟我不要紧。”
相信以上几句话是评审时常听到的话，那么为何要进行测试用例评审？
这里从参与用例评审几个角色来（测试、开发、产品经理、项目经理）分析下进行用例评审的目的以及意义。

测试：

因为不一样测试同窗对于需求的理解和用例设计都不一样，为了提高用例的完整性、合理性、高效性，能够经过评审的方式，收敛不一样人以及不一样专业的意见，丰富测试用例。测试是无穷尽的，没有人能保证本身的设计用例覆盖彻底。

开发：

测试和开发对于需求理解未达成一致，经过评审与开发对需求进行double check，保证在测试前对需求理解的一致性，以避免执行测试过程当中产生争议和扯皮。
暴漏出开发在实现过程当中代码逻辑考虑不充分的地方，提早预警，避免逻辑处理考虑不充分致使的缺陷。
开发能够从实现层面评审用例，补充测试用例中，因为测试人员不了解实现过程致使的测试用例缺失的状况。

产品经理：

常常在测试用例设计的阶段，有些细节是没法从需求文档上得知的，须要频繁来和产品经理进行沟通；有些没有沟通到就存在理解不一致或者考虑不充分的地方。产品经理参与用例评审，他们能帮助你找出更多的问题，同时在评审的过程当中，你也能帮助产品经理发现一些他在产品设计过程当中考虑不充分的地方。好的测试用例会比需求文档要更具体。

项目经理：

经过用例评审不但能够评审测试用例是否足够覆盖全部需求逻辑，还能够经过评审的的手段来评估测试的工做量。若是100个用例能够用2我的1天进行，那么能够根据测试用例的数量能够安排测试的时间。固然不一样的用例执行的时间可能不一样，可是用例的多少确实某种程度上能够衡量人力消耗的成本。
因此项目经理在这个评审的过程当中，须要评审测试用例的覆盖度以及冗余性。

一、进行评审的时机

首先，咱们要说用例设计的时间，必定要在需求评审后就须要进行初步的用例设计，不管用例设计时通过多少深思熟虑，过一两天都会忘掉一部分当时的思路，因此先作好整理和记录。在参与开发的技术评审后，根据开发对需求的实现方式，进行修正和补充。
用例评审最好的时间是在开发中期阶段：
若是开发前期阶段发起用例评审，可能开发的技术评审还没开始，测试也没有足够的时间去整理测试设计的思路，致使用例质量不高。若是开发完毕阶段发起用例评审，在用例评审过程当中暴漏的问题极可能是产品经理和开发考虑不充分或者理解不一致形成的，问题暴漏较晚，会致使返工或者版本延期。

二、评审的流程

1. 测试人员肯定评审日期和参与评审人员

2. 评审前2天，测试用例发给全部评审人员

3. 评审人员记录测试用例问题

4. 评审会议，测试用例编写人员讲解用例，参与人员提出评审

5. 会议结束，修改用例，并邮件输出
   

三、评审的内容

一、描述是否清晰，是否存在二义性
二、内容是否完整,是否清楚包含输入条件和预期输出结果并没有争议点
三、是否覆盖了全部场景、逻辑分支、限制条件等
四、是否哪些需求不可测：没法准备环境、可测试性达不到等等缘由
五、是否考虑到测试用例的执行效率（冗余的用例）

四、最后啰嗦几句

在用例评审过程当中每每出现一个现象，参与评审用例的评审人员参与度不高，用例评审的效果较差。
一般，在用例评审中，测试人员不是先阐述本身的用例的设计思路，而是直接就说具体执行的案例。一般一个输入条件，不一样的场景、不一样的操做步骤，可能生成不少用例case;若是一条一条的评审确实很枯燥；并且不少用例case都是正常逻辑的，评审的意义不到。
当测试问：“还有什么须要补充的吗？”，估计开发也看得晕菜啦。若是测试人员能调整下，评审的时候先阐述设计的思路，能够经过流程图、用例图、时序图、状态图等辅助手段来帮助清晰用例设计的思路以及明确测试要点；开发在评审的过程当中也容易参与进来，增强互动性；而后在评审用例case，并以异常case为主，正常逻辑的用例case尽可能一语带过,提升用例评审的效率，相信这样评审人员参与度会提升。
文/ 腾讯 孙丽晶
__腾讯优测是专业的移动云测试平台，为应用、游戏、H5混合应用的研发团队提供产品质量检测与问题解决服务。不只在线上平台提供自动化兼容性测试、云手机远程租用与调试、漏洞分析、自动化测试工具Xtest等多种质量检测工具，更为VIP客户配备了专家团队提供定制化综合测试解决方案。