谈谈我在自动化测试中遇到的坑(2)

• 一个非常简单的功能，写好再调通，花费的时间并不少。别人5分钟就能做好的事情，我要花1个小时。
• 脚本执行时一旦发现问题，排查起来花费的时间也不少。一般来说跑出问题了，我会再反复跑几次，先确认是不是真的有问题，再加各种打印或者等待来运行脚本定位问题（别笑，当时真的是这样的）。 我还记得当时我对这个问题，是这样安慰自己的，没事，自动化的优势是体现在反复执行上的。但是很快我就发现：
• 界面、环境稍微有点变化，脚本就不能用了。这点让我感到反复执行好像也不是那么好使，有点崩溃。
• 由于我们的产品经常会定制，版本的分支也很多，我发现如何把这些脚本管理起来，便于在不同的测试场景下测试也是个问题。

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

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

第二次进行自动化测试

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

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

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

原文转自：http://gitbook.cn/books/58d23ddcfa7558521a30277a/index.html