⾃动化测试遇到的难点_谈谈我在⾃动化测试中遇到的坑 这篇关于⾃动化测试的⽂章，可能和你看到的⼤多数⾃动化的⽂章有所不同。我不是⼀位专职的⾃动化测试⼯程师，没有开发过⾃动化的⼯具或者框架，⽤的⾃动化的⼯具也不多，也没有做过开发，所以我讲不出那些现在很多⼈很看重的“很深”的东西。我也不想去讲某个流⾏的⾃动化的⼯具要怎么使⽤什么的，我觉得这些东西并不是我的，⽽且也是可以很容易获取的。
那么在⾃动化这个很⼤的领域来说，我是什么呢？ 我是⾃动化技术的使⽤者，要在团队中做⾃动化，还是脚本的编写者、管理者和运⾏者。 我想⼤多数测试朋友和我做的事情是⼀样的把。我想在这篇⽂章中，给⼤家分享⼀下我这些年实践⾃动化的经历，特别是那些不是那么成功的经历，希望能够给你带来⼀些思考和共鸣。 我的⾃动化历程
初次接触⾃动化测试
初次接触⾃动化测试：我发现光靠⼯具和热情是做不好⾃动化测试的。
我是⾃动化测试的簇拥者。记得刚做测试那会，⼀听到“⾃动化测试”这个概念，就觉得好神奇，当时就把“⼿头的⼯作都⾃动化了”。我能把这些内容都⾃动化，不是我厉害，⽽是新员⼯⼿⾥的⼯作不多，⼜
很简单，⽽且当时公司已经研发了⼀些⾃动化平台，我的这些⾃动化测试的原理就是捕捉到⼀个windows的窗⼝然后往⾥⾯发送字符串，连测试结果都还不能做到⾃动检查，还要⾃⼰去看⽇志或者截屏。尽管做得⾮常粗糙，这也极⼤的⿎励了我，我每天跑着这样的脚本乐此不疲，想象着下⼀步这些脚本会变得很智能。
接下来我就开始向公司的⾃动化测试前辈(本部门、外部门)学习，⾃⼰开始搞⾃动化。这时我⼜换了个产品，新的leader当时并不赞同做⾃动化(现在⾮常能够理解他当时为什么不赞成做⾃动化)，我很沮丧，但我想公司已经有了现成的⾃动化测试的平台和⼯具了，我只要学会了⽤这个⼯具，⾃⼰就可以写脚本了，⾃动化测试不就做起来了嘛，不就是个⼯具吗，能有多难呢。于是我决定加班来学习脚本语⾔和学习使⽤⼯具。我的进展不错，但很快我就开始感到，⾃动化测试并不像我想象的那么美：
· ⼀个⾮常简单的功能，写好再调通，花费的时间并不少。别⼈5分钟就能做好的事情，我要花1个⼩时。
· 脚本执⾏时⼀旦发现问题，排查起来花费的时间也不少。⼀般来说跑出问题了，我会再反复跑⼏次，先确认是不是真的有问题，再加各种打印或者等待来运⾏脚本定位问题(别笑，当时真的是这样的)。 我还记得当时我对这个问题，是这样安慰⾃⼰的，没事，⾃动化的优势是体现在反复执⾏上的。但是很快我就发现：
·
界⾯、环境稍微有点变化，脚本就不能⽤了。这点让我感到反复执⾏好像也不是那么好使，有点崩溃。
· 由于我们的产品经常会定制，版本的分⽀也很多，我发现如何把这些脚本管理起来，便于在不同的测试场景下测试也是个问题。
这两个问题让我有些崩溃，⼤家都说的⾃动化测试反复执⾏是强项，为什么到我这⾥就不灵了呢。
阻尼系数我开始意识到， ⾃动化测试不是靠⼀个⼯具，然后靠⼀腔热情加个班就可以完成的事情。 除了⼯具，如何设计函数，如何检查脚本的运⾏结果，如何做版本管理等等每⼀件事情的⼯作量都不⼩，需要有策略有规划，⼀步步的来完成。当然，如果你只是想写⼏个脚本玩玩除外。
第⼆次进⾏⾃动化测试
第⼆次进⾏⾃动化测试：没有做好⾃动化的准备，盲⽬追求⾃动化率。
第⼀次的⾃动化测试就这样以失败告终了。但我也成长为了⼀名测试基层⼩leader，有了些可以“做主”的⼩权利。我认真总结了上次的经验，显然问题主要出在没有规划和设计⾃动化上，我想只要我做好了规划，加强设计，再做⼀次⾃动化⼀定⾏，于是我决定和我的⼩伙伴⼀起，再来做⼀次⾃动化。
当时我所在的公司的做事⽅式是做事情必须要有个⽬标，要写个承诺，年底还会拿这个承诺来考核你。所以我开始思考⾃动化测试的⽬标。我发现⽆论是公司内部还是公司外部，只要说到⾃动化，都是说定位于回归测试，好吧，既然⼤家都这样说，那⼀定有⼤家的道理，那我的⾃动化⽬标也是定位在回归测试⾃动化好了。另外既然是⼀个团队都来做⾃动化，肯定要从简单的地⽅开始⼊⼿，这样我们的⾃动化的⽬标就变成了从简单的回归测试开始⾃动化，完成100%的回归测试。
这个⽬标看起来似乎没有任何⽑病，但具体执⾏起来的时候，在“简单的内容先⾃动化”的思想的指导下，我们做了很多测试边界的脚本。(什么叫测试边界值的脚本呢。⽐如⼀个接⼝的配置是允许输⼊(1，5)，边界值就是0，1，5，6，边界值的脚本就是测试数据为0、1、5、6的脚本)。
由于我们的⽬标是要100%的回归测试，但我们当时并没有⼀个标准的回归测试⽤例集。那些简单的边界值脚本就⾃然⽽然的都成为了回归测试⽤例集。后来项⽬压⼒压下来，做⾃动化的时间变少了，为了达到⾃动化率的⽬标，我们甚⾄发展到把⼀个测试边界的脚本，拆成多个脚本(⽐如上⾯那个例⼦，测试数据为0、1、5、6，本来⼀个脚本就可以测试完，我们却偏要写4个脚本)，这样，我们“很聪明”的达到了⾃动化测试的⽬标。
但这样的⾃动化，我们⾃⼰都不不太想去运⾏，因为我们⾃⼰⼼⾥清楚，这样的脚本，运⾏不运⾏⼜有多⼤的意义呢。
n维欧式空间这次经历让我对⾃动化测试有了新的思考：
· ⾃动化的脚本要开发哪些内容，不应该在⾃动化开发的时候才来决定，⽽应该是事先就确定好了的。换句话说，测试⽤例是⾃动化的基础， 有明确的测试⽤例才能保证⾃动化测试的内容符合预期⽬标。
· 没有考虑项⽬进度会影响到⾃动化测试这个风险，也没有考虑⾃动化实现时会不会有什么问题或困难，就轻易承诺100%的⾃动化率，盲⽬追求⾃动化率，使得最后⼤家花精⼒开发出来的⾃动化脚本没有太⼤的作⽤。
归根到底，还是没有做好⾃动化的准备。
我们在做⾃动化测试的时候，很容易只是盯着⾃动化，仅从⾃动化这个⽅⾯去思考，把⾃动化当成了⼀种很⾼级的测试，去设计⾃动化的框架，组织等，却忽 视了⾃动化测试的本质——⾃动化测试就是⼀种测试执⾏的⽅式。我们在⼿⼯测试时要如何准备测试执⾏，⾃动化测试的时候也需要考虑 。
第三次⾃动化测试
第三次⾃动化测试：⾃动化脚本的误判。
第⼆次测试就这样也算是失败了(反正脚本⼏乎是都废了)。有了这两次的失败经验，俗话说事不过三，所以我准备再来⼀场。
这时团队的测试能⼒已经有了长⾜的提升，我们已经有了⼀些测试⽤例，为了做好⾃动化测试，我专门组织⼤家把需要⾃动化测试的⽤例筛选出来了。既然⽬标是回归测试，⽤例的筛选标准也很明确，就是那些基础的，需要⼿⼯反复执⾏的⽤例。
大民3307然后我⼜对这些⽤例逐个进⾏了分析，把当前的⾃动化测试技术暂时不能⽀持的⽤例也标记出来了，告诉⼤家不⽤担⼼，这些⽤例可以下⼀次再执⾏，我们就算是要追求100%的回归测试率，也是我们真正应该执⾏的，并且现在可以⾃动化测试的那些⽤例。
我还记得当时我们的⾃动化测试平台也升了次级了，平台也更稳定了，提供的功能也更多了，⼤家的⼲劲也很⾜，所谓天时地利⼈和，我对这次的⾃动化测试实践充满信⼼。
很快，脚本被⼀批批的开发出来了，之前不能⾃动化的测试的⽤例也随着⾃动化测试技术的突破⽽变得可以⾃动化了，⼀切都在向着好的⽅向发展。但很快我们就发现新的问题出现了，⾃动化脚本结果出现了误判！
什么叫⾃动化脚本的误判呢，就是⾃动化脚本在⾃动化平台上显⽰的结果和真实的结果不⼀致。⽐如
脚本A在⾃动测试报告中显⽰的结果为PASS，但实际的功能却有可能有问题。在⾃动化测试报告中显⽰的结果为失败，但实际可能却是受到环境的影响造成的，功能却没有问题。
徐渭传换句话说，我们⽆法相信⾃动化测试的结果。
这真是要把⼈折磨死的节奏啊。
我们想了很多办法，⽐如每⼀轮⾃动化测试，同⼀个脚本都反复执⾏⼏次(如执⾏5次)，然后设置⼀个脚本执⾏失败的“容错值”(⽐如设置容错值为2，即执⾏5次这个脚本，脚本失败只要不超过2次就都算通过，OMG这个想法也真是见招拆招，见洞补洞，丧⼼病狂啊)。想办法保存所有的测试执⾏记录，然后再⼿⼯再从测试记录⾥⾯去抽检⼀定⽐例的测试脚本的执⾏结果，看抽检的结果和脚本运⾏结果的差异，再以此来决定脚本出现误判的概率(OMG，我都服了我们⼩组的惊⼈的数学功底，但这真的是完全跑偏了好吗)…….
其实这些问题，归根到底就是脚本的check部分写得有问题 。
如果我们把⾃动化测试⽐作⼀个机器⼈。让⾃动化测试来模拟执⾏某个功能并不难，这就像是机器⼈的⼿⼀样。 难的是机器⼈的“脑⼦”，如何让⾃动化脚本来聪明的确认脚本的执⾏结果就变得⾮常重要，这才是⾃动化测试真正的难点 。
⾸先我们要梳理⾃动化check的使⽤规范，根据的业务的实际情况和使⽤的⾃动化⼯具来确定要怎样进⾏check才不会遗漏，来最⼤程度的保证⾃动化测试在结果检查上的准确性。
对high level的⾃动化测试来说(对low level的⾃动化测试，如接⼝、单元测试来说，这个问题并不明显)， ⽆论是UI界⾯的，还是CLI(命令⾏)的⽤户接⼝的，都隐含了⼀个情况，就是⾃动化测试只能check到预期有的东西，却不能check到预期外的东西 。
机电信息以下⾯这个web页⾯为例。假如我的⾃动化判定的是“秒杀”，但实际“秒杀”后⾯却多了⼀些别的东西，⽐如多了个“：)”。在⼿⼯测试下，我们很容易发现这个问题，但⾃动化测试却往往测不出这个问题。
CLI也是同样的道理。⽐如我想得到的是arp的回显。如果系统在给出了arp回显的同时，⼜打出了“this callback has not been registed”，⼿⼯测试很容易就发现了这个问题，⽽⾃动化却往往测不出：
第四次⾃动化测试
有了前三次的失败经验，第四次⾃动化测试顺畅多了。这时我们的⾃动化率也就是在10%的样⼦，但我们⼀共有接近1w个⽤例，所以脚本总数还⾏。团队⾥有的⼈觉得还是可以的，感到不管怎么样总是有了些东西，也有的⼩伙伴有些质疑，我⾃⼰是表⾯上表现得很⽀持，⼲劲很⾜，内⼼却总是觉得有些别扭。
其实对我的产品来说，基本功能部分的质量还是有保证的。在没有⾃动化测试的时候，即使是做回归测试，我们不会去测试那些很基础的⽤例，⽽会把⼏个功能组合起来做场景的回归测试，这样如果基本功能有问题，也可以第⼀时间发现。
⾃动化后，变成了先跑这些基础的回归测试⽤例，通过了，再去做场景回归。⽆论⾃动化测试的结果如何，都要投⼊⼀定的⼈⼒去运⾏维护⾃动化的环境，确认结果。虽然这时我们的⾃动化已经稳定多了，但⾃动化的乌龙事件还是⽐较多的。
我没有感受到⾃动化的便捷，相反，我感觉它成为了⼀个负担。
那时正是⾃动化测试在⾏业中被热捧的时期，⼀⽅⾯是外⾯的专家⽼师对⾃动化测试的各种赞美之情，另⼀⽅⾯我却觉得我那么努⼒，却⼀直没有达到应有的预期，我感到⼗分迷茫。
我想过是不是回归测试的⽤例写得不对，我试过将⼿⼯执⾏的场景⾃动化，但是这对high level的⾃动化来说特别不现实。此时我的⾃动化测试仿佛进⼊了⼀个僵局，我不知道现在我做的事情的意义在哪⾥，是该停下来还是继续⾛，还有关键是怎么⾛。
这段时间看了很多⾃动化测试的材料，看到这个著名的⾦字塔：
我感到有点释然了，我觉得这真是道出了⼀个⾃动化测试的真相：
· ⾃动化测试也需要分层
· UI的⾃动化(也就是high level)的⾃动化本来就做不⾼
这个模型虽然没有解决我的问题，但让我不再纠结。我想试试把⾃动化往下⾛，做接⼝的⾃动化或者单元测试。当时我们项⽬的情况是，单元测试开发在做，但我侧⾯了解到此时开发做单元测试做得很敷衍。没有做接⼝测试，我再⼀了解，我们的设计，就没有接⼝⼀说，接⼝的改动也⾮常随意，根本就没法做。
此时我们的项⽬也很紧张(其实⼯作了这么多年，这个⾏业好像就没有不紧张的项⽬)，产品开发和测试的压⼒都很⼤，都在拼命加班，很多同学都觉得现在做的所有事情都是符合公司要求的，也做顺了，结果看起来也还不错，也许之前⾃动化测试⼤家⼼⾥多多少少还是有些质疑的，所以⼤家都不太想再做接⼝的⾃动化或者再去改进UT的⾃动化，当然，也不知道这部分该怎么做。
在我感到⾃动测试可能就是在⾦⼦塔尖徘徊徘徊的时候，⼜发⽣了⼀件事情打破了我之前对⾃动化的认识。公司的⼤领导突然⾮常重视⾃动化，整体上加强了对⾃动化的投⼊，成⽴的专门的⾃动化⼩组。⼤领导直接拍了⼀个很⾼的⾃动化⽬标，⾃动率要达到30%，不到⼀个⽉⼜更新为要达到40%，然后要达到60%.....
这就意味着⾃动化测试不仅仅是做回归测试，还要做新功能的测试。要做新功能的测试，并且还要让脚本在新功能提交的时候就可以测试，就需要提前把脚本写好，⽽且界⾯、CLI都要尽量没有变化，当时我觉得是不可能做到的，觉得领导就是在那⾥拍脑袋瞎指挥。⽽且Martin 这样的⼤师都说了，⾃动化测试要做成⾦字塔的样⼦，我们去把⾦字塔的塔尖做⼤做平，真的有意义吗？
事实时，⾃动化测试组的leader在⽼板的⽀持下，真的做到了。在⽼板的⽀持下，他把流程改了，他把⾃动化测试明确的放在了流程中进⾏考虑。我们的产品是有CLI和UI的。以前CLI和UI是功能设计后期才输出，现在改为了在需求确定后就要输出相关的设计。对CLI要输出确定的界⾯回显。⽽且⼀旦评审通过，不允许随便修改。如果要修改，必须要通知⾃动化团队。⾃动化团队在CLI接⼝设计完成后，就会⽴即封装⾃动化的函数(我们内部叫AW，action word)，⾃动化团队基本能够在⽤例输出的时候就可以完成所有的AW封装。产品团队可以在⽤例设计完就投⼊脚本的编写。然后我们真的做到了⽤脚本来做新功能的接收测试，功能测试！
由于这个⾃动化团队是⼀个拉通了所有产品的资源部门，他们还尽量考虑了AW在不同产品的复⽤(在AW复⽤之前，我们的测试⽤例就已经复⽤了)，后来进化为了脚本的复⽤。⽐如A产品有“扫描”这个功能并且已经做了⾃动化了，B产品也准备做“扫描”这个功能，B产品不仅可以直接⽤A产品需求相同部分的⽤例，还可以直接⽤A产品的脚本！脚本让原本分散在不同产品不同版本中的测试⼈员，形成了⼀种合⼒，⼤⼤提升了测试效率。我感到这时的⾃动化，才是真正可以替代⼿⼯执⾏的⾃动化，我第
⼀次真真实实的感到了⾃动化测试的好处。
词频这段经历给我的触动是巨⼤的。
· 我感到⾃动化测试，不是测试单⽅⾯能够搞定的事情，需要开发的理解和配合，更需要领导的⽀持。
· ⾃动化测试的技术不是最重要的。我从感到⾃动化测试是种负担，到实实在在感到⾃动化的作⽤，我们的⾃动化测试平台，脚本语⾔，脚本的编写⽅式都没有变化。变的只是配合⽅式和做这件事情的时机，也就是⾃动化测试的策略。我们现在能够获得技术的途径太多了，是不是技术越⽜就可以做得越成功呢？显然不是这样的。做成⼀件事情的关键是能够审时度势，去解决当前问题。
· 如何看待权威：Martin讲的⾦字塔，是Martin基于他的视野提出来的，是有上下⽂的，忽视上下⽂⽆异于断章取义。
· ⾃动化测试除了脚本，还有很多上下游相关的⼯作，⽐如⽤例，⽐如需求。如果你的需求是乱的，⽤例是乱的，你觉得⾃动化会不乱吗？
⾄于⾃动化测试真的可以提⾼效率吗？我觉得不⾏。我觉得这是对⾃动化测试意义的最⼤的误解。那我们为什么⼜要做⾃动化测试？ ⾃动化测试最⼤的意义在于，对测试⼈员的能⼒的固化。脚本可以代
表测试⼈员的测试⽅法，通过脚本就把在原来在⼈⾝上的能⼒，固化为组织的资产。不同的团队及时没有懂这个功能的⼈，也可以通过脚本来分享这种能⼒，这才是⾃动化的意义。
后记
故事已经讲完了，⾮常感谢你可以⼀直看到现在。
现在我换了家公司。在新公司⾥，我实践着我的⾃动化理念。我花了两年的做⽤例基线，⽤例已经整得不错了。最近⼜开始重头做⾃动化，从⼯具，整合库，设计业务框架，设计关键字，设计脚本的管理规则开始。现在公司对⾃动化的关注还算不错，但依然没有多少资源。现在我的⾃动化做得很慢。是的，我真的宁愿做慢⼀点。
后来我在新公司⾥有幸作为评委，参加了⼀个测试优秀实践的评选会。当听到分享者讲他们加班加点做了2000个脚本，却只发现了2个问题时。我就问了个问题：“这些脚本的测试内容，没有⾃动化⼿⼯执⾏的时候，你们会做吗？”
分享者静默了⼏秒，说，不会。
然后我就没有再继续问了。还给了她们⽐较不错的分。
补充
对⾃动化测试，除了前⾯故事⾥的提到的⼀些理念，我还想我还想补充⼀些。
21/212>
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议