移动端测试之自动化测试理论

​移动端自动化测试理论

自动化测试在很多年前就被提出并逐渐开始流行，selenium的出现拯救了很多为了大量回归测试而无奈增加测试人数的公司，有了自动化的回归测试可以大大缩减测试成本。到目前为止已经涌现了很多不管是web端还是app端的自动化测试框架，可以根据自己的需求进行选择甚至自己编写一个框架使用。

当我们提到自动化测试的时候往往大家脑海中涌现的是E2E的测试，但是这仅仅是自动化测试的其中一种形式，测试金字塔大家相比都听过相关的概念了。

​​

这张图是源自martin flower的博客中，他提到自动化测试的各部分比重应该像金字塔一样，单元测试是消耗最少、运行速度最快的；service层在中间，代表了接口测试、集成测试或者契约测试等；最上面是UI测试，也就是我们理解的E2E测试，这部分是执行最慢的且成本最高。因为越往上就越是接近黑盒测试，单元测试相当于白盒测试，主要是对代码逻辑的检验；到了UI层更多是模拟用户操作执行的，开发过程中免不了UI变更频繁这就会导致测试要经常进行维护，同时又因为测试框架本身不够稳定，也会造成用例的执行结果不可靠，误报或者错报bug，这些因素都是UI测试成本提高的重要原因。

那既然如此，是不是UI自动化越少越好呢？当然也不能这么武断，如果你有相关的经验的话你会发现，在以上这些不同类型的测试中，应该还有一条线是自信心，UI测试全部通过会增加对产品的信任。越往下则信心越不足，毕竟单元测试谁知道到底有没有覆盖完全代码的逻辑呢，也不知道核心功能是不是确实有单元测试覆盖，接口测试，单个接口调通了谁知道在客户端发出去是不是能正常处理和接收呢？所以正确的根据项目业务需求合理的设置各个层面的测试比例才能将收益最大化，最大程度发挥自动化测试的能力！

怎么衡量自动化测试的收益呢？这是一个很难有标准答案的问题，很多人认为你觉得好用，从中体验到了价值，那就可以尝试去做了。但是你就是觉得鸡肋，那就不用。如果非要找一个方法衡量价值的话，有个相对合理的解释是ROI模型，也就是投资回报比return of investment，大概是这样子一个表达式：

 当手工运行时间和频率高的时候，自动化测试的收益就越明显，特别是对于一个相对稳定的系统来说，这种收益价值就更为突出。当然自动化测试并不能完全取代手动测试，在实践中往往是采用两者相结合的方式，测试人员使用自动化测试工具提高测试效率释放自己用在回归测试的带宽，从而有更多的时间精力进行探索性测试，保障项目的质量。

UI自动化测试能够极大增加信心的同时，这也是一把双刃剑。作为测试人员不要盲目依赖自动化测试的结果，还是要结合实际情况采取测试方法。UI测试有天然的瓶颈，比如它无法完全模拟真实情况，比图一些屏幕手势操作或者视频播放这些功能。都很难进行自动化，即使有workaround的方法也会增加case的不稳定。同时UI由于app的响应渲染时间不确定可能无法每次都准确定位页面元素，导致用例失败，这些需要我们在搭建脚手架的时候采用一些其他方法等待或者进行错误重试。

为了减用例的维护成本，编写自动化测试用例的时候尽量采用PO和data driven的模式，同时推荐使用test id的方式编写组件，这样在元素发生改变的时候可以更好的维护。​