由于格式的限制，这里给一个列表。
    1. 是否涵盖了需求文档上的每个功能点
    2. 是否涵盖了需求文档上的每条业务规则说明
    3. 是否覆盖了输入条件的各种有意义组合 0
    4. 是否覆盖了业务操作的基本路径和异常路径
    5. 是否考虑了重要表单字段的数据合法性检查
    6. 是否考虑了其他的测试类型（对某个功能很重要，但未在需求文档中提及的，如安全测试、周期性测试和故障恢复等方面）
    7. 是否考虑了对其他模块/功能的影响
    8. 是否使用了项目组的标准用例模板
    9. 用例是否覆盖了测试设计中定义的所有场景
    10.用例编号是否统一、规范
    11.用例名称是否简洁、明了
    12.目的字段是否准确地描述了对应场景的测试输入的特征（不同数据，操作，配置等）
    13.前提条件字段的条目是否充分、准确，操作上是否不依赖于同组之外的其他用例
    14.对应的需求编号字段是否填写正确
    15.用例粒度、预估出的执行时间是否适当
    16.同组用例中，仅数据不同的，是否实现了测试步骤的重用
    17.某个功能点的第一个用例是否是基本流的
    18.操作步骤的描述，是否清晰、易懂
    19.操作步骤是否充分和必要，并具有可操作性
    20.测试用例的检查点是否明确、充分和可操作
    21.单个用例步骤或检查点中是否不再存在分支
    22.测试数据的特征描述是否准确，有条件的情况下，是否给出了一个当前环境下的可用参考值
    23.文字、语法是否准确；布局、格式是否统一
    测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
    测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
    不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。