• 到今天为止做api自动化已经有一段时间了，所以总结一下这段时间对于自动化的认识，以及在设计程序的过程中怎样增加用例的健壮性

• 对自动化认识的误区

• 自动化先行：

1.我认为自动化先行不是不可行只是没有必要，毕竟所谓的自动化，也只是用代码测黑盒，并不能从根源发现问题；
2.既然是测黑盒，那单纯从测试接口来说，还是人工稍微快些且灵活性更强一点；
3.人工测试与开发同学联调符合业务需求，符合逻辑以后，开始测试接口的健壮性，可以参考另一篇文章接口用例设计
4.经过以上步骤的接口，才是一个基本稳定，具备可持续监测价值的接口，这时候我们再引进自动化接口测试，可以使开发修改其它bug时，对该接口的影响尽早被发现；

• 数据驱动：

  数据驱动：通过excel/xml传入各种参数值

  • 1.在自动化模型选型的时候我也思考过这种问题，是否应该才用数据驱动的方式；
  • 2.我的自动化思想是：自动化检测，自动化回归；我不认为用数据驱动的方式进行自动化测试有任何优点，查看大量资料基本千篇一律，通过excel或者xml编写用例，理由也是异口同声的为了方便测试同学进行接口测试，我感觉很不可思议，如果是单纯的功能测试接口，那比你自己写的代码更加强壮的工具太多了，就目前来说我还没有找到能让我转变驱动方式的想法；
  • 3.现在我的用例都是通过unittest进行管理，通过配置文件进行用例的配置；

• 用例设计

  • 1.总是想将用例覆盖度尽量扩大：这样做的后果是可怕的，就是可怕的维护成本，不多说，自己体会；另外也没啥必要；
  • 2.用例中写静态数据：这样做当时很开心，但是真正跑起来的时候，会发现问题越来越多，单从测试环境来说，你用到的某个数据，就不一定会被哪个好队友删掉，这时候用例必然失败；

• 3.用例中做好环境配置：比如上一条中说到的，也会有特殊情况，就是当前需要的数据根本没有对应结款产生数据，而我们又不能去查库（线上的我是查不了），这时候就要跟亲爱的队友打好招呼，找一个稳妥的数据，做好环境判断，在用例中分情况处理；

• 4.关于用例的设计也是基于自动化思想而来，首先是自动化检测，那如果实现这个，我只需要知道当前接口status是否符合预期即可，通过则说明接口正常，失败则说明接口异常

• 5.其次是自动化回归，要达到这点就有一些难度了，像现在的公司主要做 To B的业务,所以一般的接口都要处理登录依赖,另外，还要在用例的配置上符合业务逻辑，通过上一个接口产生的新数据作为下一个接口的源数据；然后校验接口字段，这种依情况处理吧；

• 用例的健壮性

• 维护的东西多了以后，越来越感觉，用例的健壮性是有多重要；

• 这里说的健壮性主要有2点：

• 1.用例覆盖度
  这个体会颇深，写的是覆盖的太多，那你维护的成本就会越高；覆盖的太少，又怕会因为覆盖不全会遗留什么为题；我的方法是：覆盖度不能太高且一定要覆盖致命性问题；根据这种思想去编写用例，会少很多维护成本，而且即使遗留一些问题又不会产生大的影响；而且能加入自动化行列的接口是已经通过严格的功能测试的；

• 2.用例包含的情况
  还是上边说的情况，设计用例的时候，不能跑通本地环境就万事大吉了，还需要适配各种环境，类似数据的选择，状态码的统一，分情况验证问题的机制等等；

@雨--- 2016-09-26 19:05:08