首先，要清楚是内部评审的定义，是测试组内部的评审，还是项目组内的评审。评审的定义不同，内容也会不同。
如果是测试组内部的评审，应该着重于：
1.测试用例本身的描述是否清晰 2.是否考虑到测试用例的执行效率，往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下。 3.是否针对需求文档，测试用例是否覆盖了所有的软件需求。 4.是否完全遵守了软件需求的规定，这并不一定的，因为即使在严格的评审，也会出现错误，应具体情况具体对待
1.需要评审的原因
测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。由于用力开发人员的设计经验和对需求理解的深度各不相同，所以用力的质量难免会有不同程度的差异。
2.进行评审的时机
一般会有两个时间点。第一，是在用例的初步设计完成之后进行评审_第二是在整个详细用例全部完成之后进
行二次评审。如果项目时间比较紧张，尽可能保证对用例设计进行评审，提前发现其中的不足之处。
3.参与评审人员
这里会分为多个级别进行评审。
1)部门评审，测试部门全体成员参与的评审。 2)公司评审，这里包括了项目经理、需求分析人员、开发人员和测试人员。 3)客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。
4.评审内容
评审的内容有以下几个方面
1)用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。 2)优先极安排是否合理。 3)是否覆盖测试需求上的所有功能点。 4)用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确_期待 结果是否有明显的验证方法。 5)是否已经删除了冗余的用例。 6)是否包含充分的反面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕 竟一个健壮的软件**。** 7)是否从用户层面来设计用户使用场景和使用流程的测试用例。 8)是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。
5.评审的方式
1)召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。 2)通用邮件与相关人员沟通 3)通用IM(办公通讯)工具直接与相关人员交流
方式只是手段，得到其它人员对于用例的反馈信息才是目的。
无论采用那种方式，都应该在沟通之前把用例设计的相关文档发送给对方进行前期的学习和了解，以节
省沟通成本。
6.评审结束标准
在评审活动中会收集到用例的反馈信息，在此基础上进行用例更新，直到通过评审。
测试用例的变更
测试用例并非一成不变。如果软件修改之后发生变化，或者需求发生变更，那么测试用例便不再满足当前版本
软件的测试需求，由此需要进行修改和变更操作。