关于自动化测试的一点感悟

最近的一年主要精力都放在自动化测试上了。前半年是手机客户端的自动化测试，主要是冒烟测试，一个平台大概200条用例的量，平均一个平台3个人力，在完成日常的系统测试之余，花了半年时间做起来的。接下来的半年是维护，比较大的问题是测试平台的支持不够及时，以及真机的损耗很大。而且客户端测试的一个短板在于测试覆盖度很小，冒烟测试，简单说就是最基本的功能测试，一般都是正常的用例，很少涉及异常的用例。对于一个仍然不断增加新功能的APP应用而言，大部分的工作还是要依靠测试人员手工完成。如果是一个很稳定的APP，类似QQ这种的，大量的客户端测试还是有相当客观的收益的。

 

后半年在研究后台自动化测试。几年前也做过一个Web项目的CGI接口测试，用Jmeter做的，http协议的，门槛是要学习Jmeter的使用，不算复杂，应用效果也是不错的，不仅可以用于日常测试，也可以用于线上监控。现在的这个APP是一款直播类应用，后台分为接入层和逻辑层，接入层是TCP协议，负责鉴权和转发，逻辑层是自定义的UDP协议，负责大部分的逻辑处理，且内容是二进制的。因此并不适合用Jmeter来做。这里选择自己写基于Python的测试脚本。Python有丰富的第三方库，对于收发包，组包和解包都能实现。而且还能自由得根据自己业务特点进行个性化定制。缺点是有一定的编程门槛，自研的框架没有成熟的框架那么简单好用。

 

说了这么多，本文并不是介绍自动化测试经验的。而是要给那些认为实施了自动化测试就能解决问题的测试人员提一个醒：

 

1、自动化测试非常的劳民伤财(本人的经验，基本需要半年以上时间才能看到成效)，是否要做自动化测试要考虑很多因素：产品的发展阶段，团队能力，ROI等。最最重要的是能否解决痛点问题。自动化测试本质上还是工具辅助测试，部分或全部得替代一种手工测试，其目的是让测试人员可以有更多时间去解决工具解决不了的问题。

建议：明确自动化测试的目标，增量得推进自动化测试。

 

2、后台测试一般会分为接入层的测试和逻辑层的测试。自动化测试实施在接入层，还是逻辑层，或者都需要，是测试人员需要考虑的问题。后台架构比较简单，且很少依赖第三方的产品，做接入层的自动化测试比较常见；对于后台架构比较复杂，有较多第三方依赖的产品，做逻辑层的自动化要更容易一些。原因和单元测试能够带给我们更多好处类似：

a、速度更快：使用一小部分代码就能运行起来的测试，比要调用多个组件甚至整个应用程序要快得多

b、有良好的可伸缩性：逻辑层的测试比较独立，能随着应用的规模线性伸缩，接入层的测试中，多个组件之间会有依赖关系，会遇到伸缩问题，导致测试用例的维护成本非线性增加。

c、逻辑层的测试用例，跟具体的代码块相关，可以让只针对变更代码进行测试变得很容易，更能为开发提供快速反馈

（ps: 单元测试的好处参考来源http://www.infoq.com/cn/articles/design-for-testability）

 

3、不要为了自动化而自动化。自动化测试有时候并不是最优的解决方案。

举个最近几天发生的例子：有一个线上运营的产品，商家会不定期进行一些更新（平均每月不到1次），由于更新时没有遵循规范，导致页面打开出问题。针对这个问题，PM提出这里应该增加监控措施，开发和运维讨论后觉得只能采用基于UI的自动化测试方案（因为需要登录态）。该产品的测试人员首先考虑的是这个解决方案自己有没有技术能力实现，以及有没有时间去做这件事。事情发展到这里，有问题么？ 有！想想UNPHAT原则(我的另一篇博客里有解释http://sharley.iteye.com/admin/blogs/2382789)：在彻底了解你的问题之前，不要急着去寻找解决方案。我提醒该测试人员进一步挖掘问题的根源，从而把思考问题的解决方案从监控结果转移到监控变更，因此有了候选方案，监控配置变更+人工检测页面，在频率极低的情况下，这不失为一个低成本的解决方案，更进一步的，可以增加智能化的自动检测，后者也要看ROI。前者虽然需要部分人工介入，但是人工成本基本可以忽略，最好让非测试人员去验证（只是看页面是否正常显示，没有任何逻辑，非测试人员也可以做得很好）。