如何编写高质量的测试用例?

如何编写高质量的测试用例 高质量的标准： 1、 覆盖到所有的业务逻辑（包括正常逻辑和异常逻辑） 2、 覆盖到所有的典型用户场景 3、 覆盖到所有的需求点 4、 测试目标明确，并且测试步骤能够最快的达到测试目的或者测试时间很短 5、 没有冗余的用例 6、 测试用例能够直接附带测试策略，该模块的策略指定人和用例执行人能够非常清楚

如何达到该目标： 一、基于逻辑的用例设计过程： A、用例编写过程：

1、优先完成业务逻辑图，需要在测试的角度上面去画逻辑图，包括数据流完整的输入和输出过程，并且自己能够理解为什么这样处理 2、根据自己的理解分析每个逻辑的处理是否完善，是否有没有覆盖到的地方，并提交缺陷预防bug 3、根据逻辑编写测试用例，保证每个逻辑都能够有对应的用例覆盖 4、编写逻辑用例的过程中思考如何去改进该用例的测试过程，比如：接口测试，自动化测试，脚本。并且，能够及时让研发提供对应的接口和调试方法 5、用例要按照10分钟原则，即保证10分钟内能够执行完成

B、用例评审过程：

1、先讲解整个业务逻辑图，需要保证评审人员对于整个业务逻辑图都非常清楚，并且能够理解为什么这样做 2、分析整个业务逻辑图是否有没有覆盖到的场景或者分支情况（采用头脑风暴的方式） 3、分析业务逻辑的异常处理情况（是否每个业务逻辑都有对异常情况进行处理，也采用头脑风暴的方式） 4、是否将逻辑的用例分类比较合理，让大家通过逻辑很容易就找到对应的用例 5、分析是否所有的逻辑都能够找到对应的用例（通过逻辑找到对应的用例）,包括前面没有考虑到的逻辑 6、分析用例是否有冗余，是否多个用例都是覆盖的同一个逻辑（包括测试步骤和检查点） 7、分析用例的测试方法是否有改进，是否能够直接通过代码静态走读、接口测试、自动化测试（包括编写脚本）、引入工具等等来进一步提高我们的测试效率

测试用例异常处理分析： 1、仅仅只能保证已有的逻辑没有问题，但是可能出现部分情况没有处理导致失效的情况，可以通过后面的场景用例和需求用例来补充覆盖 2、逻辑里面异常情况考虑不充分，导致测试用例也相对比较欠缺，可以通过对每个逻辑进行头脑风暴，分析是否有其他异常情况，并且评审时重点评审这块 3、研发的逻辑有可能本身就是错误的，但是如果顺着研发的逻辑去编写用例时会导致用例也有问题，达不到测试目的，所以需要从需求和设计的角度去提前分析逻辑是否有问题 4、过程中研发的逻辑可能变化比较快，这样会导致逻辑测试用例也要经常变化，所以需要保证研发的编码是与设计一致的，并且逻辑是尽量根据设计来进行的 另外，逻辑用例的设计可以在编码中后期进行，这样的改动会少点

http://blog.it985.com/16130.html