1）保持简单但不要太简单;使其复杂，但不要太复杂

这种说法似乎是一个悖论。但是，我们保证事实并非如此。保持TC的所有步骤原子性和精确性。提及具有正确顺序的步骤，并正确映射到预期结果。测试用例应该是不言自明的，易于理解。这就是我们要让它变得简单的意思。

现在，使其变得复杂意味着使其与测试计划和其他TC集成。在需要时，请参阅其他TC，相关工件，GUI等。但是，以平衡的方式做到这一点。不要让测试人员在一堆文档中来回移动以完成单个测试场景。

甚至不要让测试人员紧凑地记录这些TC。在编写TC时，请始终记住，您或其他人必须修改和更新这些内容。

2）记录测试用例后，作为测试人员查看一次

永远不要以为一旦你写了测试场景的最后一个TC，工作就完成了。首先回顾所有TC一次，但不要以TC作家或测试计划员的心态。以测试人员的头脑查看所有TC。理性思考并尝试干运行您的TC。

评估所有步骤，看看您是否以可理解的方式清楚地提到了这些步骤，并且预期结果与这些步骤一致。

确保TC中指定的测试数据不仅对实际测试人员是可行的，而且也是根据实时环境。确保 TC 之间没有依赖关系冲突，并验证对其他 TC/工件/GUI 的所有引用是否准确。否则，测试人员可能会遇到很大的麻烦。

3）绑定以及简化测试人员

不要将测试数据留给测试人员。为他们提供一系列输入，特别是在要执行计算或应用程序的行为取决于输入的情况下。您可以让他们决定测试数据项值，但绝不能让他们自由选择测试数据项本身。

因为，有意或无意地，他们可能会一次又一次地使用相同的测试数据，并且在TC的执行过程中可能会忽略一些重要的测试数据。

通过根据测试类别和应用程序的相关区域组织TC，使测试人员放心。显然，指示并提及哪些TC是相互依赖的和/或批处理的。同样，明确指出哪些TC是独立和隔离的，以便测试人员可以相应地管理其整体活动。

现在，您可能有兴趣阅读有关边界值分析的信息，这是一种用于黑盒测试的测试用例设计策略。点击这里了解更多有关它的信息。

4）成为贡献者

切勿按原样接受 FS 或设计文档。您的工作不仅仅是通过 FS 并确定测试方案。作为QA资源，如果您认为应用程序中可以改进某些内容，请立即为业务做出贡献并提出建议。

也建议开发人员，特别是在TC驱动的开发环境中。建议下拉列表，日历控件，选择列表，组单选按钮，更有意义的消息，警告，提示，与可用性相关的改进等。

作为一名QA，不要只是测试，而是要有所作为！

5）永远不要忘记最终用户

最重要的利益相关者是“最终用户”，他们最终将使用该应用程序。所以，在TC写作的任何阶段，永远不要忘记他。事实上，在整个SDLC的任何阶段都不应忽略最终用户。然而，到目前为止，我们的重点只是与这个话题有关。

因此，在识别测试场景时，永远不要忽视那些主要由用户使用的情况，或者即使它们不太常用，也是业务关键的案例。让自己站在最终用户的角度，然后遍历所有TC并判断执行所有记录的TC的实际价值。