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

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

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

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

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

1. 自动化的脚本要开发哪些内容，不应该在自动化开发的时候才来决定，而应该是事先就确定好了的。换句话说，测试用例是自动化的基础，有明确的测试用例才能保证自动化测试的内容符合预期目标。

2. 没有考虑项目进度会影响到自动化测试这个风险，也没有考虑自动化实现时会不会有什么问题或困难，就轻易承诺100%的自动化率，盲目追求自动化率，使得最后大家花精力开发出来的自动化脚本没有太大的作用。

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

我们在做自动化测试的时候，很容易只是盯着自动化，仅从自动化这个方面去思考，把自动化当成了一种很高级的测试，去设计自动化的框架，组织等，却忽

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