谈谈我在自动化测试中碰着的坑

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

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

自动化测试并未便宜，实在自动化测试很贵。

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

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

初次打仗自动化测试：我创造仅靠工具和激情亲切是做不好自动化测试的。

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

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

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

脚本实行时一旦创造问题，排查起来花费的韶光也不少。

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

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

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

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

逐步地，我重新人发展为一名测试小组长，有了些可以“做主”的小权利。
我负责总结了上次的履历，认为第一次自动化测试失落败的问题，紧张出在缺少方案和设计上。
既然找到了问题，我决定和我的小伙伴一起，再来做一次自动化。

既然是要做方案，第一步肯定是定目标。
由于团队也是第一次做自动化，那从大略内容入手是比较靠谱的;其余回归测试中有大量重复测试事情，测试的内容也比较根本，很适宜利用自动化。
这样我们团队的自动化目标就变成了从大略的内容开始，将自动化脚本用于回归测试，达到100%自动化回归测试。

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

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

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

这次经历让我对自动化测试有了新的思考--自动化测试要从办理繁琐事情入手而不是从大略事情入手，要让团队看到自动化测试切实的效果。
只有这样，自动化才能真正被团队接管，而不是变成劳民伤财的花架子。

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

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

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

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

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

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

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

逐步地，我们团队有了较多的脚本，但这些脚本都是基于用户接口设计的脚本，实行一个脚本须要做不少配置，我们的产品支配都很繁芜，有时候须要多个产品才能完成一个功能。
为了避免不同脚本之间配置滋扰，每实行一个脚本我们就要初始化一遍，以打消掉当前的配置，规复环境。
只管我们实现了并行化，但是自动化脚本的实行效率依然很低。
当自动化率到10%旁边的时候，团队好多同学都认为我们的自动化已经到头了，由于我们掩护这些脚本已经很难了，再连续下去，自动化测试的繁芜度会超过手工测试。
自动化测试进程再次进入僵局，徘徊不前。

这再次刺痛了我，我创造我做了这么久的自动化，并没有真正感想熏染到过自动化的便捷，相反它成为一个包袱，我不知道接下来该怎么走。

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

A:哀求开拓职员进行单元测试。

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

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

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

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

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

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

从自动化测试技能的角度来说，第三次和第四次并没有实质差异，差别在于流程中各个角色的合营办法，也便是工程方法。
我们须要全局看全体产品的状况，制订得当的自动化策略，以此来推动自动化测试发展。

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