测试用例本身的描述是否清晰，语言准确；是否存在二义性；

测试用例内容是否完整，是否清晰的包含输入和预期输出的结果；测试步骤是否清晰；

测试用例中使用的测试数据是否恰当，准确；

测试用例是否具有指导性，是否能灵活的指导软件测试工程师通过测试用例发现更多的缺陷，而不是限制他们的思维；

是否考虑到测试用例执行的效率。对于不断重复执行的步骤，是否保证了验证点相同；或者测试用例的设计是否存在冗余性等。这些都可能导致测试用例执行效率低下；

画出软件需求跟踪矩阵，验证测试用例是否完全覆盖了需求，验证测试用例的覆盖性；

测试用例是否完全遵守了软件需求的规定。这一点其实有一些难做到。考虑到时间/成本的关系，应该视具体情况而定。

需求文档是否清晰，描述是否准确，结果是否预期内

第一、如何对测试用例进行评审？

  测试用例本身的描述是否清晰，语言准确；是否存在二义性；

  测试用例内容是否完整，是否清晰的包含输入和预期输出的结果；测试步骤是否清晰；

  测试用例中使用的测试数据是否恰当，准确；

  测试用例是否具有指导性，是否能灵活的指导软件测试工程师通过测试用例发现更多的缺陷，而不是限制他们的思维；

  是否考虑到测试用例执行的效率。对于不断重复执行的步骤，是否保证了验证点相同；或者测试用例的设计是否存在冗余性等。这些都可能导致测试用例执行效率低下；

  画出软件需求跟踪矩阵，验证测试用例是否完全覆盖了需求，验证测试用例的覆盖性；

  测试用例是否完全遵守了软件需求的规定。这一点其实有一些难做到。考虑到时间/成本的关系，应该视具体情况而定。

第二、如何有效的对测试用例进行评审？ 关键是“有效”两个字。有效体现在哪里？

  1、评审之前，需要将即将评审的测试用例以及测试需求、测试分析的结果（测试点分析）等文档提前发送给相关的人员；最好能够让他们有时间提前阅读； 

  2、随时的问题沟通与反馈机制。评审之前做一些问题的沟通与反馈，以便于在测试用例评审会议上能够节省出来宝贵的时间；    3、评审会议的主持者，需要事前做好关于测试用例的疑问，问题点等记录，以便于在评审会上引导提问和解答； 

  4、评审期间做好详细的记录，需要对有关的疑问和问题及时进行澄清；  

  5、评审会议的主持者需要能够把控会议的进度，让参加评审的测试人员能够集中精力在测试用例上，而不要思维太发散而跑题；

  6、评审会议结束之后，及时提交审核评审记录；并且与参加会议的人员分享评审记录。

  测试用例的评审是一项在测试实施过程中，必不可少的工作环节，是一个重要的工作阶段；是一项非常严肃而且认真的事情。切不可因为测试时间紧张，就不认真进行，或者随便评审一下即可。

  要记住，如果测试用例产生了问题，未来用于修复的时间和成本，远远比对测试用例进行评审的时间和成本高的多。项目组会为此付出巨大的代价，来弥补这样一项错误。

　1.测试用例本身的描述是否清晰，是否存在二义性；
　　2.是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下；
　　3.是否针对需求跟踪矩阵，覆盖了所有的软件需求；
　　4.是否完全遵守了软件需求的规定。这并不一定的，因为即使再严格的评审，也会出现错误，应具体情况具体对待。

1.首先，测试人员提前准备好用例评审的资料，提前定好会议室发出会议邀约并附上用例评审资料

测试用例评审最好以Xmind脑图的形式进行，脑图可以清晰的展示用例的设计思路和关键信息，让参与评审的人员可以一目了然，能更快的捕获到用例设计者要表达的思想，降低阅读成本，提高会议效率。脑图需要包含全部用例的设计思路及测试功能点，并重点标注出有疑问的测试点。在评审前一天提前发出给相关与会人。

2.开始用例评审，会议组织者即测试人员做好会议记录，并标注清楚需要修改的用例内容

    用例评审很多人会走进一个误区，就是对着测试用例Excel列表，在会议上逐条逐字的念一遍，如此一次用例评审时间不到2个小时肯定结束不了，其实这种做法是很不科学的,不仅浪费时间还不能达到完善用例的目的。有研究表明成人的注意力高度集中只能维持约20分钟，如何把握住这20分钟让用例评审会议高效有收获？那就只能挑重点讲，对于已经明确的测试点也可一语带过，主要挑存疑需要三方共同确认的功能点讲，所以第一步在评审资料准备时要求在Xmind标注出存疑的测试点，就是在这个时候就派上用场的。

    另外，在评审过程中，如果对技术实现方案有疑问的也要提出来和开发确认，比如，哪些数据是从接口获取的，哪些数据是从其他页面的接口请求带过来的，哪些是前端写死的；哪些页面有必要实时刷新，哪些页面无需已进入就刷新。如果对于实现方式存在不合理之处可以提出可行的实现建议供开发开发参考。对于开发可能考虑遗漏的功能点或细节及时在会议上提醒，可从根源上遏制bug的出现，比如开发可能会忘记考虑防重点击的处理、一些特殊的异常逻辑处理等。

    评审过程中，测试人员要做好会议纪要，如果用例有需要补充或修改的地方快速在Xmind上标注清楚，便于会后进行整理补充测试用例。

3.用例评审会议后整理完善测试用例并再次同步

    用例评审会议后测试人员根据会议上各方建议进行测试用例的修改完善，再将整理补充后的用例同步给项目相关人员，是具体情况确定是否有必要进行二轮评审。若无其他问题则将用例整理后即可导入用例系统以供测试执行时使用。

作者：caisf
链接：https://www.jianshu.com/p/a50f75608ecd
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。