我的自动化历程——从软件测试转到自动化测试的一些理解和感悟

Posted 2021-06-11 测试萌萌

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了我的自动化历程——从软件测试转到自动化测试的一些理解和感悟相关的知识，希望对你有一定的参考价值。

在换了一家新工作之后，新公司的项目组也要开始做自动化了。这段时间做了一些基本的自动化工作，让我有些感触，也再次印证了我之前的一些观点。

我是自动化测试坚决的簇拥者。 记得我刚做测试，第一次接触自动化测试，就觉得好神奇，当时就把手头的工作都自动化了–不过那时所谓的自动化，也就是写尽量写一些脚本来帮我操作被测对象，然后自己还要去检查测试结果对不对。尽管很low，但也给了初出茅庐的我巨大的成就感，此后我还养成个习惯，凡是遇到繁琐的测试任务，或是管理任务，我就思考能不能写几个脚本尽量自动化完成。

后来，在第一家公司，我就开始向各位自动化前辈（本部门，外部门）学习，并开始着手搞自动化，我自己包含热情的搞了至少有三大轮，但不避讳的说，全失败了。当然，最后我们团队的自动化还是做得不错的，但是在我同事，加上一个自动化团队的带领下搞出来的（这也是我很钦佩的牛人之一）。我们达到了"工厂化"的水平，能够支持所有的功能，回归，转测试，发布测试的工作。

这期间我也不断在总结我自动化失败的原因。从我们一听到自动化这个词开始，就觉得这项技术特别牛逼，不吝给它各种赞美之词，是提高测试效率的银弹。但是，自动化真的没有你想的那么好，自动化本身的投入也是巨大的。我第一次自动化失败的原因，就是没有意识到它的投入–自动化应该是一个团队的行为，领导需要给它留工时，团队成员也需要有一定的时间投入，靠员工加班，靠员工的激情是做不成自动化的（当然，写几个脚本还是可以，如果你认为几个脚本就是自动化了除外）

从意识到自动化需要高投入开始，我就开始思考效率和效益这个问题，也就是自动化的策略。我们是应该追求自动化率，还是该追求别的什么？这也是我第二次的失败经历：我没有想清楚自动化的目的，又要追求效率和收益，于是我追求自动化率，在这种情况下，必然是简单的内容先自动化，于是出现了大量的测边界值的脚本。这样的自动化率是上去了，但是效果呢？

那次自动化经历还暴露了别的问题，就是脚本的适应性问题，开发的参数，命令稍有变化，我需要改大量的脚本，当你率还不错的时候，真是一场灾难，有种自己挖坑自己跳的感觉。

有了这次弱爆了的失败经历，开始重视自动化的目标和策略：目前你定位自动化是回归测试，还是功能测试还是别的什么测试？然后优先开发这部分脚本，而不是管它三七二十一先做起来。另外，追求率是没有意义的，测得爽才是真的好。

在这里插入图片描述
还有一个经验就是，自动化也需要设计，也需要规范，需要框架。

有了这些教训，第三轮的自动化实践看起来就像样多了，也慢慢有了效果，但在运行过程中，我又发现了一个致命的问题：自动化脚本误判！跑出来的结果明明是pass，但实际上是失败的！omg！甚至还出了网上问题！

这段时间我也读了大量的测试书，记得之在一本当时很流行的测试书中也看到这样的问题，他们的解决方法是记录整个测试过程，但是这又引入新的问题，内容太多，分析不完。我对书中的做法表示怀疑，觉得这还算自动化么。

带着问题去思考和学习总是特别有效。公司中牛人很多，和前辈们讨论交流，发现原来这些问题，是可以通过写好自动化的检查函数来改善甚至避免的。这让我认识到自动化的难点不是让脚本模拟测试者的操作，能够运行起来，而是在check。很多人都喜欢把自动化测试比作"机器人"。自动化测试中模拟测试者的操作，是这个自动化机器人的"手"，而check就是机器人的"大脑"。check没有做好，自动化就不够可靠，做也是白做。有同学认为单元测试和接口测试不用太关心对check的设计，我认为这也是不正确的。Check的设计对UI和CLI自动化会比单元测试和接口测试更为重要一些，仅此而已。

自动化不是个人行为，要让一个团队每个人都能快速写好自动化，把check做到位，是自动化管理的难点。一个经验就是，针对业务特点来总结有哪些check类型，然后对这些类型来封装函数，让大家就可以根据用例的情况来用这些函数。

记录测试过程也是需要的，对可能的测试结果分级，设计各种全局调试开关，做出分层级的测试结果报告。除了"成功"和"失败"的状态，还可以加入一个"怀疑"的状态，总结测试时的定位手段和思路，让脚步可以有针对性的抓取更多的定位信息，而不是一出现问题就只有重跑一遍脚本，这不仅提高了自动化测试的效率，还可以提升产品的可测试性水平。

把这些都做好后，自动化就变的舒服多了。后来我的实践还证明，做好check的设计还是提高UI和CLI自动化测试率的方法。自动化测试走上正轨后，我们又开始思考各种小改进，比如自动回填结果，自动生成脚本等等。

在这里插入图片描述
随着自动化测试进入正轨，团队也开始尝到自动化测试的甜头，自动化测试率也开始稳步上升。但这时又开始出现了新问题–我们发现自动化率到一定程度后，自动化率就很难上去了，就像减肥中遇到的平台期一样。另外还有个问题，就是和手工测试相比，自动化能够执行的用例比较少，但占用的资源量却很大，执行效率不高。

我们对当时团队的状况进行分析：自动化率上不去，是限于流程，是因为对新功能来说，无论是UI和CLI还是接口自动化，都无法做到项目一开始就自动化。开发对UI和CLI和接口确定的比较晚，而且修改还很随意。新功能在项目中，可以自动化的时间很短，最后到项目结束，新功能特别是UI和CLI的自动化，也只能做到一些基本功能的测试，只能满足冒烟要求。自动化测试主要还是针对稳定的老功能的回归测试。但在没有自动化的时候，我们并不会执行那么多老功能的回归测试。当时团队有些同学也对这种为什么要占用这么多资源，花这么多功夫进行这么大规模的回归测试提出了质疑，并提出应该想办法提高新功能测试的自动化率的诉求。

自动化测试占资源多的原因和我们的产品特点有关，我们的产品业务需要的部署比较复杂，有些用例需要控制多个设备来进行。我们当时还没有做到让脚本在不同的部署上跑，也无法在一个测试集中引入不同的测试部署环境。

这时领导的巨大能力就体现出来了。对第一个问题，在领导的支持下，我们修改了研发流程改了，要求项目先设计出 CLI 和 web，先确定出 CLI 的回响和 web 的显示，严格评审后就开始自动化，在项目中不得随便修改自动化，就算要修改也需要通知测试团队这大大增加了自动化的可编写时间，让自动化可以做新功能的测试了，自动化变得更实用了。为了更好的自动化，我们对测试用例的设计也做了调整，使其更适合自动化。

第二个问题，我们引入测试床的技术，在一个床上可以包容多套部署。此后自动化开始工厂化运作，有专门的环境，可以 7*24 小时不间断跑。我们也像产品开发一样来自动化脚本，用 svn 来管理脚本，评审脚本，不断重构和优化自动化框架和脚本，自动化也运作的越来越好了。

这段经历让我认识到，自动化其实不是测试的单方面能搞定的事情，需要领导支持，还有开发的理解和配合。自动化的框架确实非常重要，但是一个牛逼的框架，不是因为技术有多新多牛，而是能够切实的解决问题。

看完这篇内容后，相信以下两件事，也会对你的个人提升有所帮助：

1、点赞，让更多人能看到这篇文章，同时你的认可也会鼓励我创作更多优质内容。

2、让自己变得更强：想一想，如果你想在测试这个行业一直做下去，你的经验和功能测试技术是远远不够的，你需要进阶，你需要一直丰富你的技术栈！还等什么！