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

这篇关于自动化测试的文章，可能和你看到的大多数自动化的文章有所不同。我不是一位专职的自动化测试工程师，没有开发过自动化的工具或者框架，用的自动化的工具也不多，也没有做过开发，所以我讲不出那些现在很多人很看重的“很深”的东西。我也不想去讲某个流行的自动化的工具要怎么使用什么的，我觉得这些东西并不是我的，而且也是可以很容易获取的。

那么在自动化这个很大的领域来说，我是什么呢？ 我是自动化技术的使用者，要在团队中做自动化，还是脚本的编写者、管理者和运行者。 我想大多数测试朋友和我做的事情是一样的把。我想在这篇文章中，给大家分享一下我这些年实践自动化的经历，特别是那些不是那么成功的经历，希望能够给你带来一些思考和共鸣。

我的自动化历程

初次接触自动化测试

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

我是自动化测试的簇拥者。记得刚做测试那会，一听到“自动化测试”这个概念，就觉得好神奇，当时就把“手头的工作都自动化了”。我能把这些内容都自动化，不是我厉害，而是新员工手里的工作不多，又很简单，而且当时公司已经研发了一些自动化平台，我的这些自动化测试的原理就是捕捉到一个windows的窗口然后往里面发送字符串，连测试结果都还不能做到自动检查，还要自己去看日志或者截屏。尽管做得非常粗糙，这也极大的鼓励了我，我每天跑着这样的脚本乐此不疲，想象着下一步这些脚本会变得很智能。

接下来我就开始向公司的自动化测试前辈（本部门、外部门）学习，自己开始搞自动化。这时我又换了个产品，新的leader当时并不赞同做自动化（现在非常能够理解他当时为什么不赞成做自动化），我很沮丧，但我想公司已经有了现成的自动化测试的平台和工具了，我只要学会了用这个工具，自己就可以写脚本了，自动化测试不就做起来了嘛，不就是个工具吗，能有多难呢。于是我决定加班来学习脚本语言和学习使用工具。我的进展不错，但很快我就开始感到，自动化测试并不像我想象的那么美：

• 一个非常简单的功能，写好再调通，花费的时间并不少。别人5分钟就能做好的事情，我要花1个小时。

• 脚本执行时一旦发现问题，排查起来花费的时间也不少。一般来说跑出问题了，我会再反复跑几次，先确认是不是真的有问题，再加各种打印或者等待来运行脚本定位问题（别笑，当时真的是这样的）。

  我还记得当时我对这个问题，是这样安慰自己的，没事，自动化的优势是体现在反复执行上的。但是很快我就发现：

• 界面、环境稍微有点变化，脚本就不能用了。这点让我感到反复执行好像也不是那么好使，有点崩溃。
• 由于我们的产品经常会定制，版本的分支也很多，我发现如何把这些脚本管理起来，便于在不同的测试场景下测试也是个问题。

这两个问题让我有些崩溃，大家都说的自动化测试反复执行是强项，为什么到我这里就不灵了呢。

我开始意识到， 自动化测试不是靠一个工具，然后靠一腔热情加个班就可以完成的事情。 除了工具，如何设计函数，如何检查脚本的运行结果，如何做版本管理等等每一件事情的工作量都不小，需要有策略有规划，一步步的来完成。当然，如果你只是想写几个脚本玩玩除外。

第二次进行自动化测试

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

第一次的自动化测试就这样以失败告终了。但我也成长为了一名测试基层小leader，有了些可以“做主”的小权利。我认真总结了上次的经验，显然问题主要出在没有规划和设计自动化上，我想只要我做好了规划，加强设计，再做一次自动化一定行，于是我决定和我的小伙伴一起，再来做一次自动化。

当时我所在的公司的做事方式是做事情必须要有个目标，要写个承诺，年底还会拿这个承诺来考核你。所以我开始思考自动化测试的目标。我发现无论是公司内部还是公司外部，只要说到自动化，都是说定位于回归测试，好吧，既然大家都这样说，那一定有大家的道理，那我的自动化目标也是定位在回归测试自动化好了。另外既然是一个团队都来做自动化，肯定要从简单的地方开始入手，这样我们的自动化的目标就变成了从简单的回归测试开始自动化，完成100%的回归测试。

这个目标看起来似乎没有任何毛病，但具体执行起来的时候，在“简单的内容先自动化”的思想的指导下，我们做了很多测试边界的脚本。（什么叫测试边界值的脚本呢。比如一个接口的配置是允许输入（1，5），边界值就是0，1，5，6，边界值的脚本就是测试数据为0、1、5、6的脚本）。

由于我们的目标是要100%的回归测试，但我们当时并没有一个标准的回归测试用例集。那些简单的边界值脚本就自然而然的都成为了回归测试用例集。后来项目压力压下来，做自动化的时间变少了，为了达到自动化率的目标，我们甚至发展到把一个测试边界的脚本，拆成多个脚本（比如上面那个例子，测试数据为0、1、5、6，本来一个脚本就可以测试完，我们却偏要写4个脚本），这样，我们“很聪明”的达到了自动化测试的目标。

但这样的自动化，我们自己都不不太想去运行，因为我们自己心里清楚，这样的脚本，运行不运行又有多大的意义呢。

这次经历让我对自动化测试有了新的思考：

• 自动化的脚本要开发哪些内容，不应该在自动化开发的时候才来决定，而应该是事先就确定好了的。换句话说，测试用例是自动化的基础，

  有明确的测试用例才能保证自动化测试的内容符合预期目标。

• 没有考虑项目进度会影响到自动化测试这个风险，也没有考虑自动化实现时会不会有什么问题或困难，就轻易承诺100%的自动化率，

  盲目追求自动化率，使得最后大家花精力开发出来的自动化脚本没有太大的作用。

归根到底，还是没有做好自动化的准备。

我们在做自动化测试的时候，很容易只是盯着自动化，仅从自动化这个方面去思考，把自动化当成了一种很高级的测试，去设计自动化的框架，组织等，却忽 视了自动化测试的本质——自动化测试就是一种测试执行的方式。我们在手工测试时要如何准备测试执行，自动化测试的时候也需要考虑 。

第三次自动化测试

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

第二次测试就这样也算是失败了（反正脚本几乎是都废了）。有了这两次的失败经验，俗话说事不过三，所以我准备再来一场。

这时团队的测试能力已经有了长足的提升，我们已经有了一些测试用例，为了做好自动化测试，我专门组织大家把需要自动化测试的用例筛选出来了。既然目标是回归测试，用例的筛选标准也很明确，就是那些基础的，需要手工反复执行的用例。

然后我又对这些用例逐个进行了分析，把当前的自动化测试技术暂时不能支持的用例也标记出来了，告诉大家不用担心，这些用例可以下一次再执行，我们就算是要追求100%的回归测试率，也是我们真正应该执行的，并且现在可以自动化测试的那些用例。

我还记得当时我们的自动化测试平台也升了次级了，平台也更稳定了，提供的功能也更多了，大家的干劲也很足，所谓天时地利人和，我对这次的自动化测试实践充满信心。

很快，脚本被一批批的开发出来了，之前不能自动化的测试的用例也随着自动化测试技术的突破而变得可以自动化了，一切都在向着好的方向发展。但很快我们就发现新的问题出现了，自动化脚本结果出现了误判！

什么叫自动化脚本的误判呢，就是自动化脚本在自动化平台上显示的结果和真实的结果不一致。比如脚本A在自动测试报告中显示的结果为PASS，但实际的功能却有可能有问题。在自动化测试报告中显示的结果为失败，但实际可能却是受到环境的影响造成的，功能却没有问题。

换句话说，我们无法相信自动化测试的结果。

这真是要把人折磨死的节奏啊。

我们想了很多办法，比如每一轮自动化测试，同一个脚本都反复执行几次（如执行5次），然后设置一个脚本执行失败的“容错值”（比如设置容错值为2，即执行5次这个脚本，脚本失败只要不超过2次就都算通过，OMG这个想法也真是见招拆招，见洞补洞，丧心病狂啊）。想办法保存所有的测试执行记录，然后再手工再从测试记录里面去抽检一定比例的测试脚本的执行结果，看抽检的结果和脚本运行结果的差异，再以此来决定脚本出现误判的概率（OMG，我都服了我们小组的惊人的数学功底，但这真的是完全跑偏了好吗）…….

其实这些问题，归根到底就是脚本的check部分写得有问题 。

如果我们把自动化测试比作一个机器人。让自动化测试来模拟执行某个功能并不难，这就像是机器人的手一样。 难的是机器人的“脑子”，如何让自动化脚本来聪明的确认脚本的执行结果就变得非常重要，这才是自动化测试真正的难点 。

希望以上内容对你有所帮助！软件测试是IT相关行业中最容易入门的学科~不需要开发人员烧脑的逻辑思维、不需要运维人员24小时的随时待命，需要的是细心认真的态度和IT相关知识点广度的了解，每个测试人员从入行到成为专业大牛的成长路线可划分为：软件测试、自动化测试、测试开发工程师 3个阶段。

如果你不想再体验一次自学时找不到资料，没人解答问题，坚持几天便放弃的感受的话，可以加我们的软件测试交流：313782132，里面有各种软件测试资料和技术交流。