评审的内容有以下几个方面：
1) 用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
2) 优先极安排是否合理。
3) 是否覆盖测试需求上的所有功能点。
4) 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。
5) 是否已经删除了冗余的用例。
6) 是否从用户层面来设计用户使用场景和使用流程的测试用例。
7) 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。
其它几个关键认知：
- 测试用例是动态的，一旦测试环境、输入、输出发生了变化，测试用例都需要相应发生变化。所以复杂的测试用例不便于维护，而过于简单的用例不方便他人阅读也不利于历史追溯（比如有些必要条件没有记录，过一两个月后，再执行这条用例时或许就忘记了无法继续执行下去，如权限和角色组合测试的组合条件），所以应该不断完善用例设计方案，根据项目周期定期进行用例维护安排，大多数文档不是不想去维护而是不知道怎么维护，从而无从下手。测试度量值，测试覆盖表和测试通过或不通过的测试用例清单列表。
- 测试用例设计的重要性表现为：
1、测试用例量化了测试工作，为测试需求覆盖程度提供了依据，为判定测试执行程度提供了依据，也为测试工作量完成程度提供了依据，测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少
2、保障了软件测试质量执行的稳定性，和测试质量的全面性
3、了解其重要性才能再管理上做出决策，比如对工作时间安排、人员任务安排。
⒈指导测试的实施
⒉规划测试数据的准备
⒊编写测试脚本的"设计规格说明书"
⒋评估测试结果的度量基准
⒌分析缺陷的标准:通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。
- 对预期结果的验证，既要有对前端表象的验证，又要有对数据结果的验证
- 测试用例文档编写要素：测试目的、测试范围、定义术语、参考文档、概述等。具体测试用例内容将包括下列详细信息：版本号、模块名称、用例编号、用例名称、用例级别、预知条件、验证步骤、期望结果（含判断标准）、测试结果、测试时间、测试人员等。