开篇先来说说，什么是测试用例评审？测试用例评审是通过测试人员组织用例评审会议，邀约项目相关人员，主要包括产品，开发及测试三方，对测试人员设计的测试用例的可执行性和全面性进行评估，同时消除各方对需求文档理解的偏差达到对需求理解的一致。
测试用例评审是测试流程中极为关键的一环，用例评审何为如此重要？首先，通过测试用例的评审不仅可以消除产品、开发、测试三方对需求文档理解的偏差，还可以保证测试内部人员，即测试执行者和测试用例设计者在测试质量保障方面保持一致性；其次，通过测试用例评审，产品和开发可以通过对用例合理性和全面性进行评估，指出用例设计不合理或遗漏之处，以便更好的完善测试用例，提高测试用例的质量。再者，如果囿于各种限制条件导致开发无法展开技术评审会议，那么在用例评审也可以和开发沟通确认实现方式，关注不同实现方式的测试点，以实现全面测试；最后，常言道，测试人员是项目的前灯，是一个探路的角色，所谓良医治未病，那么测试人员就应该在项目前期多挖掘潜在的坑，并提醒开发注意，慎防掉坑，同时也降低了bug出现的概率，减少开发测试成本。
说了这么多，那么测试用例评审该如何评审呢？个人认为可以从以下几个步骤来组织实行测试用例的评审工作。
1.首先，测试人员提前准备好用例评审的资料，提前定好会议室发出会议邀约并附上用例评审资料
测试用例评审最好以Xmind脑图的形式进行，脑图可以清晰的展示用例的设计思路和关键信息，让参与评审的人员可以一目了然，能更快的捕获到用例设计者要表达的思想，降低阅读成本，提高会议效率。脑图需要包含全部用例的设计思路及测试功能点，并重点标注出有疑问的测试点。在评审前一天提前发出给相关与会人。
2.开始用例评审，会议组织者即测试人员做好会议记录，并标注清楚需要修改的用例内容
用例评审很多人会走进一个误区，就是对着测试用例Excel列表，在会议上逐条逐字的念一遍，如此一次用例评审时间不到2个小时肯定结束不了，其实这种做法是很不科学的,不仅浪费时间还不能达到完善用例的目的。有研究表明成人的注意力高度集中只能维持约20分钟，如何把握住这20分钟让用例评审会议高效有收获？那就只能挑重点讲，对于已经明确的测试点也可一语带过，主要挑存疑需要三方共同确认的功能点讲，所以第一步在评审资料准备时要求在Xmind标注出存疑的测试点，就是在这个时候就派上用场的。
另外，在评审过程中，如果对技术实现方案有疑问的也要提出来和开发确认，比如，哪些数据是从接口获取的，哪些数据是从其他页面的接口请求带过来的，哪些是前端写死的；哪些页面有必要实时刷新，哪些页面无需已进入就刷新。如果对于实现方式存在不合理之处可以提出可行的实现建议供开发开发参考。对于开发可能考虑遗漏的功能点或细节及时在会议上提醒，可从根源上遏制bug的出现，比如开发可能会忘记考虑防重点击的处理、一些特殊的异常逻辑处理等。
评审过程中，测试人员要做好会议纪要，如果用例有需要补充或修改的地方快速在Xmind上标注清楚，便于会后进行整理补充测试用例。
3.用例评审会议后整理完善测试用例并再次同步
用例评审会议后测试人员根据会议上各方建议进行测试用例的修改完善，再将整理补充后的用例同步给项目相关人员，是具体情况确定是否有必要进行二轮评审。若无其他问题则将用例整理后即可导入用例系统以供测试执行时使用。
