携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第46天，点击查看活动详情
用例评审就是测试人员邀请产品经理、开发人员和项目经理等人一起评审测试用例是否编写正确，有
无遗漏等行为。
一般测试用例评审的过程如下：首先是测试人员邀请产品经理、开发人员和项目经理在约定的时间和
地点（找个会议室）一起坐下来开会过用例。一般是发邮件提前一到两天邀请，群邀请也可以。然后就是
在会议室投放用例并且由测试人员主讲自己写了哪些测试用例，由产品经理、开发人员评审是否存在错误
的用例和遗漏的用例，如果存在则记录下来。
有时候也会出现测试人员想到的测试场景（用例）是开发人员没有想到的，那么就意味着开发人员事
先没有想到要实现这个场景，可以帮助开发人员提前去补充这个场景。有时候需求也没有想到要对某个场
景测试，那也可以帮助产品经理完善需求规则。在写用例的时候，如果测试人员觉得应该验证某个场景，
而需求又没有提到这个场景，那么我们可以写出对应的用例并标记一下，到评审的时候主动提出来是否有
这个场景。此时就可以帮助到产品经理了。【这是给开发和产品经验帮助】
评审会议结束后，测试人员应该对评审时的错误进行修复。
接口测试和 UI 测试这两块其实是有一部分是重叠的，UI 测试是通过前端写的界面，来调用接口，而
接口测试是直接调接口。所以排除前端的处理的逻辑和调用的正确性，在理论上接口测试是可以覆盖所有
的 UI 测试的业务逻辑。但实际过程中，如果只是在接口层覆盖所有的业务流，在 UI 上只测试前端的逻辑，
最终的结果可能会是忽视很多原有的功能点，导致了 UI 测试的不充分。所以存在多人分工且时间充分的
时候可以尝试接口去做业务流的全覆盖，否则不要轻易尝试。
