一、评审目的
一般来说，参加测试用例评审的人员包括对应项目的产品人员、设计人员、开发人员和测试人员。
图1-1 测试用例评审相关人员
测试用例评审会议的发起者一般是测试人员，既然我们是发起者，那我们发起这个会议的目的是什么呢？
首先，在测试用例设计过程中，我们可能会对某些需求点存在疑问或者不同意见，那我们就要找产品人员讨论和明确需求点。
其次，我们可能对产品的界面交互设计存在疑问或者优化建议，那我们就需要找设计人员和产品人员共同讨论和明确设计点。
再次，我们也可能对开发设计方案的理解上存在偏差，那我们就需要让各端开发人员协助把控测试用例的正确性和覆盖面。
最后，一个测试人员设计的用例是很难覆盖全需求及关联内容的，这时候就需要其他测试同事或者测试组长帮忙把关和补充，从而提高测试用例的覆盖面。
当然，除了明确测试用例疑问点和提高测试用例覆盖面的目的外，还有一个很重要的目的，就是要在团队中暴露出这些未明确的内容，推动各方人员对这些未确定内容的理解和风险处理方案达成一致，这也是测试左移的一种手段。
图1-2 测试用例评审目的概括
总结来说，如图1-2所示，测试用例评审的目的可以概括为三点：明确不确定因素，提高测试用例覆盖面和促进各方理解一致。
二、评审流程
当我们明确了测试用例评审的目的后，我们就可以从评审前、评审过程和评审后三个时间去思考如何更好地开展测试用例评审。
图2-1 测试用例评审流程
评审前，我们要新建项目工作群，将需要参会的人员拉进群。在测试用例的设计过程中，如果遇到疑问点，我们可以群里@ 对应负责人进行确认。如果还有未确认的点，我们可以标记下待会议上讨论。在完成了测试用例设计后，我们要提前把测试用例文档发群里，@ 相关人员查看测试用例并关注待确认点。在跟各方协商好测试用例评审时间后，我们就可以提前预约好会议室并发起会议邀请。
评审过程中，我们并不需要过每一条的测试用例，我们可以通过脑图的方式介绍测试用例的整体内容和思路。评审过程中，我们要重点评审测试用例中提前标记的疑问点和可能存在风险的内容。同时，如果评审过程中依然有部分内容无法明确，那我们就需要记录下来。
评审后，我们需要整理会议纪要并同步到工作群中。会议纪要内容需要包括本次会议中确认的结果以及需求相关的变动内容，并@ 全部人周知。如果还有遗留问题，我们需要@ 相关人进行跟进并确认答复时间。
总结来说，要让参会人员提前了解会议内容，带着问题或者问题的答案来参加测试用例评审会议。同时，我们要做到会议内容有记录，会议结果各方确认有记录，会议遗留问题跟踪有记录。
关于测试用例评审，还有哪些是我们可以改进的地方？欢迎大家一起补充。
