自动化测试脚本设计思想

阅读本文大约需要1.8分钟。

前言

之前看到过这么一个问题：如果一个月发布一个版本，在上线前都需要回归某功能，如果实现这个功能的自动化脚本只需要一天，那是否应该对这个功能实现自动化测试？这个问题没有绝对的答案，与实际项目的具体情况有很大的关系。我们心里对自动化测试应该有一个正确的概念：“自动化测试的根本目的是提高效率和降低成本。”

在实施自动化测试之前，我们需要进行如下思考：

首先，项目是否真的需要自动化测试，投入产出比如何？

其次，什么自动化方案更适合？

最后，如何实现自动化？

在实际项目中，很多同学过多地考虑第三个问题，也会做一些关于第二个问题的调研，但往往缺乏对第一个问题的思考。每个团队应该从自己项目的角度出发，慎重思考自动化测试的投入和收益，选择适合自己项目的方法，使投入产出比最大化。

想了解我们团队关于上面几个问题的思考可以参考另外一篇文章《终端自动化测试探索之路》。在已经确定自动化测试可以带来收益的情况下，接下来就是要选择测试方案，尽量让开发成本和维护成本降低一些。

下面是我们经过一年左右的实践后的一些思考。

基于Appium的UI自动化测试

要考虑被测应用主要变化的地方是哪里，是否真的适合做UI自动化测试。如果应用程序UI变化频率比较低，主要是下层逻辑变动，那么这样的应用是比较适合做UI自动化测试的。反之，如果UI变化大，那么UI自动化脚本维护成本就会很大，自动化测试的投入产出比就不会很高。因此我们经过一年左右的实践沉淀下来了一套基本稳定的自动化用例集，主要覆盖了应用的主流程等的一些UI变动不大的场景，基本可以达到比较高的投入产出比，这部分内容之前有单独写过一篇文章：《终端自动化测试探索之路》。

要考虑被测应用是什么类型的应用，因为不同类型的应用对自动化框架的选型有比较重要的影响，如果是游戏类的应用，那么可能很多的画面都是通过OpenGL直接渲染的，Appium无法找到OpenGL直接渲染出来的画面里的元素，这时候可以考虑通过图像识别的方式去做判断，比如像网易的Airtest框架就比较适合用来做游戏的UI自动化测试。

UI自动化测试的目标是什么，是否对测试的运行时间有要求。如果UI自动化的目标是快速地回归，要求在短时间内完成大量回归用例的运行的话，此时可能就不适合用UI自动化来做测试了，因为UI自动化测试运行同一条测试用例的时间一般情况都要比人工执行的时间要长，所以很难在短时间内运行大量的测试用例。但如果没有时间要求，比如每天晚上定时运行的BVT或者开发每次集成一个模块后的冒烟测试（平均3分钟左右，主要测主流程），则不用考虑时间效率。

由于是基于Appium的UI自动化测试，所以在语言的选择上就比较自由了。这时可以从部门内同学的能力考虑，选择学习成本和实施成本较低的语言，我们这里选择的是Python。

基于UIAutomator的竞品对比测试（性能测试）

跨进程有强大的兼容性，性能的数据采集可以通过接入第三方App进行，且不需要专门适配。这里我们是接入了网易的Emmagee，可以方便地采集目标应用的内存、CPU、流畅度等方面的数据。

测试方案确定下来后，就需要考虑如何实施了。有过自动化测试开发经验的同学应该都知道，自动化测试的脚本开发其实不难，但测试脚本的维护却是比较困难的。测试脚本设计的思想是尽量地提高测试脚本的可重用性和稳定性，降低脚本的维护成本，提高收益。