如何写好测试用例

写好测试用例的技巧：1、确定一个标准的模板；2、测试用例标题是一个完整易懂的句子；3、用条件而不是参数来描述测试用例标题；4、如果一个用例中包含有多个参数，用例中应该是每个参数的取值等。确定标准模板是写好测试用例的前提。

一、写好测试用例的技巧

1、确定一个标准的模板

一般包含以下几项：用例编号、所属模块、用例标题、优先级、适用阶段、前置条件、测试数据、操作步骤、预期结果、执行结果和备注。

2、测试用例标题是一个完整易懂的句子

能够清晰表达测试用例的测试目的和关键测试要素，只有当测试用例标题是一个完整的句子时，读者才能完整地了解这个测试用例的意图。用例标题要求一句话简单描述（在/当。。。时候/之后/页面，主语+谓语+宾语）。

3、用条件而不是参数来描述测试用例标题

如果你有对比就会发现，使用条件来作为测试用例标题，和使用参数相比，前者更能突出设计这个测试用例的目标，也易于读者理解测试用例的设计意图，也更易于维护。可见，在描述测试用例标题时，更适合用条件，而不是参数。参数更适合在测试用例模板中的测试数据部分体现，不要把它们罗列在测试用例标题中。

4、如果一个用例中包含有多个参数，用例中应该是每个参数的取值

我们在写测试用例的时候，应该对涉及的每个参数给出确定的值。

5、不要在测试用例中引用别的测试用例

引用测试用例会给后期用例的修改、维护和移植带来麻烦。我们会在测试用例中引用另外一个测试用例，在很大程度上是因为用例在执行中存在先后关系，即测试用例2一定会在测试用例1之后执行。这时我们可以考虑这样来编写测试用例：把测试用例1和测试用例2合并成一个大的测试用例。可以把测试用例1的主要内容放到测试用例2的预置条件中。

6、避免测试用例中包含过多的用户接口细节

用例执行者应该是专业人士，测试用例不必写得面面俱到。

7、明确测试步骤和预期结果的对应关系

一个测试用例通常会包含好几个测试步骤和多个预期结果。有时候不同的测试步骤可能会有相同的预期结果，为了描述简便，很多测试用例作者会省略相同的预期结果。另外，也不是所有的测试步骤都有预期结果，一般是重要、关键的测试步骤才会有预期结果。这时我们可以在测试用例中，增加简单的标记来明确测试步骤和预期结果之间的对应关系，让测试执行人员一目了然。

8、避免在测试步骤中使用笼统的词

我们在描述测试步骤时，需要尽量避免那些笼统的表述方式，如“反复”、“长时间”、“大量”等。因为这样描述，不同的测试执行者的理解会有所不同。比如“反复”，有人会认为执行两次就是反复了，有人可能会认为要执行至少10次，这样就会造成测试执行上的差异，很可能会达不到测试的效果。

二、编写测试用例的注意点

每一条测试用例都必须包含输入，操作和输出。
每一条测试用例都要覆盖业务流或者业务场景的某一条分支。包含正常场景和异常场景。要满足MCM E原则、即相互独立，完全穷尽原则。所以完整的测试用例一定包含所有业务流分支。所谓有效等价类和无效等价类统统包含。但不可重复.
每一条测试用例的校验点要清晰明确。尤其涉及数据的，展示数据从哪里来，到哪里去都要一清二楚。有基础的可以画一画数据流图。非常有益于大家学习业务。
每一条测试用例执行结果是否会影响数据库。数据库是否增加字段，字段类型，对应页面展示。都要非常清楚。
跳出开发思维或者测试思维。真正地实际用需求实现一个具体业务场景，要真实有意义的业务场景。用测试用例去承载真实业务场景。看看结果怎么样。实际体验一下自己产品的易用性。构造测试数据也尽量贴近客户数据量大小。
涉及数据的，基本增删改查操作都要写用例验证。
测试用例校验点和测试场景同样重要。明确要验证的测试校验点。类似于写好自动化脚本里的断言。没有断言的脚本不是好脚本。同理，没有校验点的测试用例不是好用例。写好测试校验点非常重要。界面UI、操作结果等等都要写出来。

延伸阅读

什么是好的测试用例

测试覆盖面全：覆盖面全，是最最重要的一点，只有全面的覆盖，才能找到非常多的问题，只有更全面的测试，才能更好的保障产品的质量，当然穷尽测试是不可能的，所有全面也是相对的。
测试用例精简：精简的case，是为了减少重复的工作，减少人工成本和时间成功，通过TC设计策略了解和对于需求的充分了解，达到精简测试用例。
步骤清晰：步骤清晰，主要是为了方便其他公司去执行你的TC。
目的明确：冗长的步骤前，用几个字概括你的测试目的，方便阅读。
易于维护：分为三种类型：易于他人维护修改；易于系统升级维护修改；易于挑选不同纬度，不同优先级，不同功能的测试用例。结构清晰、优先级明确、描写清晰的测试用例更容易维护。