原创作者：谢佳

背景说明：今天和以后讲的自动化主要是接口自动化，所以脚本也是拿接口自动化脚本做例子进行讲解，为什么不想涉及UI自动化呢，原因如下：

首先UI自动化本人做的伤透了心，所以再也不想去触摸了，用那句调侃的话来说：不做自动化是等死，做自动化是找死。我能想到的这里的找死，应该就是传说中的UI自动化吧。

让我试图猜猜大家为什么都是从UI 自动化开始的：大部分人是从点点点测试开始的，时间久了自然就有点想搞点新玩意摆脱纯人肉模式的束缚，而市场上很多UI自动化工具流行很多年，安装、配 置、录制、回放都非常简单易用，所以大多数人的自动化都是从它开始的。加上有些人对自动化确实有兴趣爱好，逐渐往里面探索，然后逐渐开发脚本，脚本积累的 就会越来越多了，到最后几乎所有时间不是让脚本执行产生价值了，而是全都被拿来维护自己的脚本了，领导吩咐上线前要让脚本来一遍回归的时候，总是遇到这个 那个问题，被自动化陷入了万劫不复的深渊。这句话是什么意思呢：就是说本来想解决UI自动化测试，所以自己开发了很多东西，不想开发这么多UI脚本和一大 串数据问题，最后时间几乎全部被拿来维护自己的这些脚本和数据本身了，你说尴尬不尴尬，原本想用自动化让自己得到部分解脱，不想最后给自己挖了个大坑。

就好比，你以前都是步行去远方，你发现效率太低了，想提高效率，然后你发明了一个不可靠的自行车，结果这个自行车每骑1 公里就得花1天时间去维修，最后人家步行的人已经到了目的地，你却还在半路上维修你的自行车，你说你的目标是伟大的理想也是很丰满的，想创造价值提高测试 效率嘛，最后不小心成了“犯贱”，搞的个破发明，让自己都不知道怎么死的。好好理解我说的自动化价值和意义，你们做过UI自动化的，是不是或多或少遇到这 样尴尬的事情。（说明下，当然也有些产品稳定的，而且UI自动化覆盖不多的，技术很成熟的，在UI自动化方面取得了一定的成效，但是我看到的并不多，大多 数是投入高于产出）

言归正传吧，很多人得意自己会使用工具了，甚至会写脚本了，就以为自己真能做自动化了。我见过这样的童鞋：

1、脚本写了一大串，执行下来，那报告好的不得了，全部通过，一个缺陷都没有，其实手工测试一大堆bug；

2、也见过有的同学写的脚本和真实的用例操作意图大相径庭，以为自己会了点技术就是会做自动化了；

3、还 有很多人写的脚本今天执行通过明天就执行失败，稳定性非常差，更不用说环境有点影响后，脚本一次性失败后全部结束完毕，原本指望他一大早出报告的，结果一 晚上闹了个乌龙；也见过很多人写脚本的时候为了处理异步方式的校验，加了很长的思考时间，结果是拿到了，但是浪费了很多时间，其实本来1分钟解决的问题，让他执行了10分钟才结束。

对于上述情况，我想说，你遇到过？如何让我们在设计脚本的时候考虑更多的因素，让脚本本身符合正常业务需求的情况下，跑的又快又好呢？

脚本设计要素图：

上面的脚本要素图，写的已经很详细了，我抽取重点做部分解释。

1、脚本正确性：做好自动化的前提是要充分理解用例的步骤和执行意图，用技术的手段去替代手工的执行过程，必须符合测试场景设计意图，而且要添加足够的检查点去做判断和校验。

2、脚本稳定性：为了使得脚本的稳定性更高，必须增强脚本的逻辑判断能力，让脚本本身的容错机制和自适应能力更强，这样才能保证脚本在正常的时候稳定执行，在异常的时候能自我恢复并且不影响后续自动化的执行。

3、脚本执行效率：对于接口自动化测试，执行速度都是很快的，一般不会存在这个问题，只是在某些动态时间等待时，需要结合脚本的健壮性，做智能的判断，不仅增强了脚本的稳定性，而且也节省了很多硬等待耗费的时间。

脚本用例组成图：

从上面我们可以看到，设计一个脚本，主要包括三部分：前置条件（执行前准备）、执行步骤、后置条件（执行后处理）。

前置条件：包括参数定义、数据准备、执行前数据的加密（如果有需要的话，比如登陆的部分信息）等。

执行步骤：如果是http协议，当然就包含了状态行、请求头、请求体相关的信息，这些信息可以通过抓包工具进行分析提取，也可以通过接口文档进行拼接。

后 置条件：对于获取的信息，如果有加密的情况，当然是得先解密了；然后对解密的信息中的部分重要字段进行检查，和期望值进行自动比对，来判断此次请求是否通 过的标志；对于报文中需要动态提取的数据，就得通过正则表达式等技术提取后保存到变量中，此变量作为后续接口的输入参数使用，使得有关联关系的接口能够形 成动态数据流转。

总结：当你看完了这篇后，你会不会想到拿着上面2张图，看看你的脚本设计是否有哪些地方的不足和遗漏，然后做一次完整的优化呢。