在换了一家新工作之后，新公司的项目组也要开始做自动化了。这段时间做了一些基本的自动化工作，让我有些感触，也再次印证了我之前的一些观点。
我是自动化测试坚决的簇拥者。记得我刚做测试，第一次接触自动化测试，就觉得好神奇，当时就把手头的工作都自动化了--不过那时所谓的自动化，也就是写尽量写一些脚本来帮我操作被测对象，然后自己还要去检查测试结果对不对。尽管很low，但也给了初出茅庐的我巨大的成就感，此后我还养成个习惯，凡是遇到繁琐的测试任务，或是管理任务，我就思考能不能写几个脚本尽量自动化完成。
后来，在第一家公司，我就开始向各位自动化前辈（本部门，外部门）学习，并开始着手搞自动化，我自己包含热情的搞了至少有三大轮，但不避讳的说，全失败了。当然，最后我们团队的自动化还是做得不错的，但是在我同事，加上一个自动化团队的带领下搞出来的（这也是我很钦佩的牛人之一）。我们达到了"工厂化"的水平，能够支持所有的功能，回归，转测试，发布测试的工作。
这期间我也不断在总结我自动化失败的原因。从我们一听到自动化这个词开始，就觉得这项技术特别牛逼，不吝给它各种赞美之词，是提高测试效率的银弹。但是，自动化真的没有你想的那么好，自动化本身的投入也是巨大的。我第一次自动化失败的原因，就是没有意识到它的投入--自动化应该是一个团队的行为，领导需要给它留工时，团队成员也需要有一定的时间投入，靠员工加班，靠员工的激情是做不成自动化的（当然，写几个脚本还是可以，如果你认为几个脚本就是自动化了除外）
从意识到自动化需要高投入开始，我就开始思考效率和效益这个问题，也就是自动化的策略。我们是应该追求自动化率，还是该追求别的什么？这也是我第二次的失败经历：我没有想清楚自动化的目的，又要追求效率和收益，于是我追求自动化率，在这种情况下，必然是简单的内容先自动化，于是出现了大量的测边界值的脚本。这样的自动化率是上去了，但是效果呢？
那次自动化经历还暴露了别的问题，就是脚本的适应性问题，开发的参数，命令稍有变化，我需要改大量的脚本，当你率还不错的时候，真是一场灾难，有种自己挖坑自己跳的感觉。
有了这次弱爆了的失败经历，开始重视自动化的目标和策略：目前你定位自动化是回归测试，还是功能测试还是别的什么测试？然后优先开发这部分脚本，而不是管它三七二十一先做起来。另外，追求率是没有意义的，测得爽才是真的好。
还有一个经验就是，自动化也需要设计，也需要规范，需要框架。
有了这些教训，第三轮的自动化实践看起来就像样多了，也慢慢有了效果，但在运行过程中，我又发现了一个致命的问题：自动化脚本误判！跑出来的结果明明是pass，但实际上是失败的！omg！甚至还出了网上问题！
这段时间我也读了大量的测试书，记得之在一本当时很流行的测试书中也看到这样的问题，他们的解决方法是记录整个测试过程，但是这又引入新的问题，内容太多，分析不完。我对书中的做法表示怀疑，觉得这还算自动化么。
带着问题去思考和学习总是特别有效。公司中牛人很多，和前辈们讨论交流，发现原来这些问题，是可以通过写好自动化的检查函数来改善甚至避免的。这让我认识到自动化的难点不是让脚本模拟测试者的操作，能够运行起来，而是在check。很多人都喜欢把自动化测试比作"机器人"。自动化测试中模拟测试者的操作，是这个自动化机器人的"手"，而check就是机器人的"大脑"。check没有做好，自动化就不够可靠，做也是白做。有同学认为单元测试和接口测试不用太关心对check的设计，我认为这也是不正确的。Check的设计对UI和CLI自动化会比单元测试和接口测试更为重要一些，仅此而已。
自动化不是个人行为，要让一个团队每个人都能快速写好自动化，把check做到位，是自动化管理的难点。一个经验就是，针对业务特点来总结有哪些check类型，然后对这些类型来封装函数，让大家就可以根据用例的情况来用这些函数。
纪录测试过程也是需要的，对可能的测试结果分级，设计各种全局调试开关，做出分层级的测试结果报告。除了"成功"和"失败"的状态，还可以加入一个"怀疑"的状态，总结测试时的定位手段和思路，让脚步可以有针对性的抓取更多的定位信息，而不是一出现问题就只有重跑一遍脚本，这不仅提高了自动化测试的效率，还可以提升产品的可测试性水平。
把这些都做好后，自动化就变的舒服多了。后来我的实践还证明，做好check的设计还是提高UI和CLI自动化测试率的方法。自动化测试走上正轨后，我们又开始思考各种小改进，比如自动回填结果，自动生成脚本等等。
随着自动化测试进入正轨，团队也开始尝到自动化测试的甜头，自动化测试率也开始稳步上升。但这时又开始出现了新问题--我们发现自动化率到一定程度后，自动化率就很难上去了，就像减肥中遇到的平台期一样。另外还有个问题，就是和手工测试相比，自动化能够执行的用例比较少，但占用的资源量却很大，执行效率不高。
我们对当时团队的状况进行分析：自动化率上不去，是限于流程，是因为对新功能来说，无论是UI和CLI还是接口自动化，都无法做到项目一开始就自动化。开发对UI和CLI和接口确定的比较晚，而且修改还很随意。新功能在项目中，可以自动化的时间很短，最后到项目结束，新功能特别是UI和CLI的自动化，也只能做到一些基本功能的测试，只能满足冒烟要求。自动化测试主要还是针对稳定的老功能的回归测试。但在没有自动化的时候，我们并不会执行那么多老功能的回归测试。当时团队有些同学也对这种为什么要占用这么多资源，花这么多功夫进行这么大规模的回归测试提出了质疑，并提出应该想办法提高新功能测试的自动化率的诉求。
自动化测试占资源多的原因和我们的产品特点有关，我们的产品业务需要的部署比较复杂，有些用例需要控制多个设备来进行。我们当时还没有做到让脚本在不同的部署上跑，也无法在一个测试集中引入不同的测试部署环境。
... ...
查看全文内容，请点击下载：http://www.51testing.com/html/00/n-3712900.html
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
