谈谈我在自动化测试中遇到的坑

目录

初次接触自动化测试：我发现仅靠工具和热情是做不好自动化测试的。

第二次进行自动化测试:没有做好自动化的准备，盲目追求自动化率。

第三次自动化测试：自动化脚本的误判。

第四次自动化测试:规模化自动化测试。

---

自动化测试不是单靠测试人员就可以搞定的。

自动化将繁琐工作自动化处理开始，能看到自动化测试的效果才是最重要的。

持续优化自动化测试的判断标准，让团队可以充分信任自动化测试结果。

自动化测试并不廉价，其实自动化测试很贵。

自动化测试的意义首先在于固化能力，其次才是提升效率。

我不是专职的自动化工具开发人员，和大多数测试者一样，我是自动化技术的使用者，带领一个小团队，自己利用公司已有自动化平台或开源工具，搭建自动化测试环境，编写自动化脚本、运行并管理它们。希望通过自动化提高测试效率，加速产品交付。希望我在自动化测试中的经历，特别是那些不成功的经历，能够引起大家的共鸣，带给大家一些思考和启发。

初次接触自动化测试：我发现仅靠工具和热情是做不好自动化测试的。

我是自动化测试的簇拥者。刚做测试时，一听到“自动化测试”，就觉得好神奇，心生向往。所以那时我就把手头的工作都自动化了，不是我有多厉害，而是因为当时我是新员工，工作内容非常简单，我做的自动化测试就是捕捉系统的窗口句柄然后往里面发送字符串，连测试结果都不能自动检查，还要自己去看日志或者截屏。尽管那时的自动化做得非常粗糙，但也极大地鼓励了我。我每天抱着这样的脚本，想象着这些脚本接下来一定会变得很强，于是我乐此不疲。

接下来我开始主动向公司的自动化测试前辈(本部门、外部门)学习。我满怀信心利用加班时间来学习脚本语言和工具的使用。但很快我就发现，自动化测试并不像我想象中那么美:

一个非常简单的功能，写好再调通，花费的时间并不少。很多时候手工测试5分钟就能做好的事情，调好脚本要花1个小时。

脚本执行时一旦发现问题，排查起来花费的时间也不少。

一旦脚本报错，我会再反复跑几次，先确认是不是真的有问题，再在脚本中加各种打印或者等待来定位问题。我感到有些不对劲，但我安慰自己:“没事，自动化的优势是体现在反复执行上的”。但是很快我就发现，只要被测系统的界面、环境稍微有点变化，脚本就不能用了，根本无法反复使用。

由于我们测试的产品定制多、版本分支也很多，我发现如何把这些脚本管理起来以便在不同的版本中运行也是个问题。这些问题让我有些沮丧--大家都说自动化测试可以提高效率，怎么到我这里就不灵了呢?

我开始意识到，自动化测试不是有了工具，有一腔热情，然后通过加班就可以完成的事情。这需要有基本的架构设计能力，能有手段和方法检查脚本的运行结果，并能有效管理这些脚本。每一件事情背后都工程方法，需要有策略有规划，一步步来完成。当然，如果你只想写几个脚本玩玩除外。

第二次进行自动化测试:没有做好自动化的准备，盲目追求自动化率。

慢慢地，我从新人成长为一名测试小组长，有了些可以“做主”的小权利。我认真总结了上次的经验，认为第一次自动化测试失败的问题，主要出在缺乏规划和设计上。既然找到了问题，我决定和我的小伙伴一起，再来做一次自动化。

既然是要做规划，第一步肯定是定目标。由于团队也是第一次做自动化，那从简单内容入手是比较靠谱的;另外回归测试中有大量重复测试工作，测试的内容也比较基础，很适合使用自动化。这样我们团队的自动化目标就变成了从简单的内容开始，将自动化脚本用于回归测试，达到100%自动化回归测试。

这个目标看起来没毛病，但实际执行起来却变了味。在“简单的内容先自动化”的思想下，大家心照不宣地做了很多非常简单的测试界面配置的边界值脚本。什么叫测试界面配置的边界值脚本呢?举个例子，比如一个接口的配置是允许输入(1，5)，边界值就是0、1、5和6，我们就写脚本去测试输入为0、1、5、6的系统对这个配置的处理。

由于我们希望把自动化脚本用于回归测试，这些测试配置的极简脚本就顺理成章地成为我们的回归测试用例集。

但这样的回归测试自动化，大家打心底都不认同，觉得这些脚本的测试内容执行起来没有任何意义，就是说出去好听而已(我们实现了100%回归自动化测试)。运行几次之后，大家就很自然地不想再继续了。

这次经历让我对自动化测试有了新的思考--自动化测试要从解决烦琐工作入手而不是从简单工作入手，要让团队看到自动化测试切实的效果。只有这样，自动化才能真正被团队接受，而不是变成劳民伤财的花架子。

第三次自动化测试：自动化脚本的误判。

认真总结第二次自动化测试的经验教训后，我们准备再发起一次自动化测试实践活动。为了保证自动化测试的有效性，我专门组织大家，从手工测试中选出那些需要反复执行的测试用例，作为自动化测试用例，然后从当前自动化测试技术的角度，对这些测试用例是否具备自动化的条件仔细梳理了一遍。我们对自动化测试平台底层技术也进行了讨论，做了一些优化，还讨论制定了团队的自动化开发规程，讨论了脚本的组织和管理形式。领导也开始更加关心自动化测试，大家的激情都被重新点燃，干劲十足。

很快，脚本被一批批地开发出来了，那些之前讨论的暂时不能自动化的测试用例，随着大家自动化能力的提升，也可以自动化了。就当一切都在向着好的方向发展的时候，新的问题又出现了:自动化脚本出现了误判!换句话说，我们无法相信自动化测试的结果，自动化脚本运行结果是失败的测试用例，可能仅是自动化环境的问题;自动化脚本运行结果是通过的测试用例，实际功能却可能有问题。

我们想了很多办法去解决问题，比如每一轮自动化测试，同一个脚本都反复执行几次(如执行5次)，然后设置一个脚本执行失败的容错值(比如设置容错值为2，即执行5次这个脚本，脚本失败只要不超过2次就算通过):想办法保存所有的测试执行记录，然后再手工抽验测试记录，确认是否有脚本判断漏掉的异常。

其实这些问题，归根到底还是脚本的检查部分，或者说断言写得有问题。

让自动化脚本按照测试者的意愿执行测试操作其实并不难，难的是让自动化脚本可以像测试者那样检查预期。比如，对预期内的结果，自动化脚本要保证效率，要避免误判，除此之外，还要注意捕捉预期外的各种异常。

第四次自动化测试:规模化自动化测试。

慢慢地，我们团队有了较多的脚本，但这些脚本都是基于用户接口设计的脚本，执行一个脚本需要做不少配置，我们的产品部署都很复杂，有时候需要多个产品才能完成一个功能。为了避免不同脚本之间配置干扰，每执行一个脚本我们就要初始化一遍，以清除掉当前的配置，恢复环境。尽管我们实现了并行化，但是自动化脚本的执行效率依然很低。当自动化率到10%左右的时候，团队好多同学都认为我们的自动化已经到头了，因为我们维护这些脚本已经很难了，再继续下去，自动化测试的复杂度会超过手工测试。自动化测试进程再次进入僵局，徘徊不前。

这再次刺痛了我，我发现我做了这么久的自动化，并没有真正感受到过自动化的便捷，相反它成为一个负担，我不知道接下来该怎么走。

这时又出现一个转机，公司的高层开始非常重视自动化，成立专门的自动化测试小组。高层领导直接定了一个很高的自动化目标，自动化率要达到80%。我们觉得这是不可能完成的任务。但是自动化测试小组的负责人却在领导的支持下，做了一系列的改革：

A:要求开发人员进行单元测试。

B:增加接口自动化测试。

对用户层面的自动化测试，在需求确定后，就要求开发人员确定用户层面的输入输出，且一经确定不能随意修改，然后自动化测试团队开始封装关键字。我们可以在测试用例设计完成后直接使用封装好的关键字编写测试脚本。这样我们真的做到了可以用自动化来做新功能的测试。

对那些自动化中的困难点，例如前面提到的每个脚本要恢复配置，自动化测试团队基于此给产品开发团队提交了自动化可测试性需求。我们通过脚本执行起来费时费力的操作，产品开发团队通过内部设计很容易就搞好了。

由于这个自动化测试团队是一个拉通了所有产品的资源部门，他们还将脚本按照场景做成了测试套，供不同产品团队在有类似需求时选用，大大加强了脚本的复用率，促进了自动化测试规模化发展，也让我第一次切实感到了自动化测试的威力。

这次自动化的经历给了我很大的启发。我感到自动化测试，并不是测试人员单方面能够搞定的事情，要想做好自动化，需要领导的支持，需要产品、架构、开发等全流程的支持。

自动化建设同样需要分层，可分为单元测试和接口测试，这样用户层面的测试就可以减少，版本质量也会更好，自动化测试的效率会更高。

从自动化测试技术的角度来说，第三次和第四次并没有本质区别，差别在于流程中各个角色的配合方式，也就是工程方法。我们需要全局看整个产品的状况，制定合适的自动化策略，以此来推动自动化测试发展。

-----转自于《测试架构师修炼之道》