做了五年自动化平台开发，根据这几年的工作经历，个人把自动测试分为三个阶段：
   
    依赖工具阶段：
   
    在这个阶段，一般是刚起步阶段，公司开始想做自动化，开始在选择自动化工具阶段，是采用开源的，还是商用的或者自己自主开发呢。个人建议使用开源+二次开发。原因很简单一个是成本问题，开源意味着免费了，二是开源能拿到源码可以让它来适应自己的结构框架。采用商用的话，一个是成本问题，因为测试本身不是产品不能直接效益的。公司一般都希望把资金尽可能投在产品上。而是采用商用产品，可能要去适应它的框架。当然你如果你的需求是那种大众化需求，采用商用产品是一个比较好的选择。
   
    另外一种选择是自主开发然后把它开源。如果在市面没有找到合适的工具，这时候要采用自己开发了。但是为什么要开源呢。原因在于一旦开源之后，你的维护成本降低了，并且会大批具有相同需求人来不断改进它。但是如果你打算将来当作产品来卖，那另说了。但常见的做法是公司一般会把自主开发的helper工具开源。
   
    工具有了之后，公司开始招人，学习工具的使用，开始大规模自动化了。在这时候，依靠工具本身提供的功能，产品的自动化率很大突飞猛进的变化。基本上能很快做到了30%左右的覆盖率。
   
    走到这个时候，慢慢发现自动化脚本开发效率不高。这个时候开始对工具进行二次开发，开发一些针对自己产品的特定功能。例如实现针对产品原语开发。使开发效率从C语言时代跨越到matlab时代。
   
    另外在这个时候，脚本的量有一定的规模，这个时候会发现让这些脚本能够有效run起来是一个大问题。并且还不断集成新开发的脚本。这个时候开始对脚本开发了有一定的规范。例如要求case之间要求相互独立。每个case要自成一体。不能说一个case只能login，create动作，而没有delete，logout等等。
   
    等你把这开发效率和case集成的问题解决了，这时候产品的自动化覆盖率会有一个新突破，轻松能做70%以上。
   
    依赖人的阶段：
   
    等自动化覆盖率达到50%以上之后，慢慢从对工具的依赖转移到了对人的依赖。毕竟现在还做不到脚本的自动定位问题，自动提bug. 脚本fail了，只能说明出了问题，但到底是谁出错了（是脚本错了，还是软件一个真正的bug呢）。这个是还是需要人来定位了。走到这个阶段了，你的自动化的case应该已经上1000了吧。每次的SUCCESS的可能性不大。假设fail 10%，这已经是一个很好的值了。也是说一次要有100个左右的case需要人来查，定位问题，重现问题。如果产品发布高一些三天发布一个版本。基本上一周会200个case需要去查，定位。如果发布频率再高一些。要出现人机赛跑了。机器一晚上能run 1000个case没有问题。但让人去做100左右的case的问题定位，重现。是非常吃力了。这个时候自动化有效性取决于结果检查人员的效率。并且这个时候自动化开始招来结果检查人员的抱怨。并且这个时候还会出现一个现象。例如1000个case失败了80%，也是800个case.那800 失败的case终对应是1-2bug呢，还是对应100bug呢（不敢期望800 失败的case对应800个bug了）。 如果是前者，可能会引起人们对自动化有效性开始怀疑。进一步可能加剧测试与开发之间矛盾。因为80%的失败率意味着软件质量很差，但实际结果查下来，只是一两个小bug引起的。以后遇到问题，大家第一个问题那是不是脚本错了。一旦这个矛头出现了。测试与开发之间矛盾激化了。
   
    到了这个时候，测试效率瓶颈又回到人的身上。在这个时候，要开始对case本身结构进行重构了。例如抽出一些基本功能的case来做smoke test. 然后把case按照产品功能的逻辑性进行从上到下分层归类，哪些case先run，哪些case后run.  并且尽可能优化结果检查效率，例如建立失败后rerun的机制，对执行过程log日志进行分类优化等等，把结果结果检查效率给提上来。
 
这个阶段，对于case本身有效性要做review了，例如是不是有测试点重复的case.删除合并那些测试点重复的case.在这个时候大家想办法如何减少case的数量（这个时候理想标准是case加一个太多，减一个又太少）。
   
    等把这些都做完了，产品的自动化覆盖率基本达到85%以上了。后面15%怎么办呢，要从客户反馈问题中来提高了。但是能走到这一步的公司，自动化测试可以说是做的相当成功了。
   
    依赖架构的阶段：
   
    走过了前面两个阶段，大家可能自动化是不是做到头了。其实只是万里长征的第一步了。只要软件开发没有停止。测试不会停止。在这时候往往会两个方向：继续开发新的release，还是开发新的产品。
   
    先说继续开发的release. 新的release要开发新功能，可能要对老功能进行重构。一些接口或者逻辑变了，你的自动脚本自然也跟着改了。也是说软件有改动，你的脚本可能要跟着改。有可能接口改变对你来说是致命的伤害。并且有的时候，一个老的版本已经卖给出去了（假设为r1.0吧，现在开发为r2.0）。客户现场发现了bug.客户由于各种原因又不愿意升级到新版本r2.0. 这时候你的开发要出现分枝，并行开发了。对于手工测试来说，问题不大。但拿r2.0的脚本去测r1.0分枝恐怕不行吧。估计这时候，要么使现在脚本能够这个差异给吃掉了。要么使测试脚本也分枝。对于产品公司可以花人力去做并行开发，对于测试也花人力去并开维护脚本。这个有违当初做自动化初衷吧。软件开发怕是需求变更。自动化测试脚本质也是软件。只是一套软件去测另一软件。  如果一个构架好的软件，具有很强扩展性，容易应对变化。反之，这个软件慢慢会做不去了，给做死了。自动化测试也会遇到同样的问题。
   
    现在在说开发新产品。一般大家都会选择功能相似产品去开发，去重构以前的代码，以实现尽可能复用。同样测试脚本也一样，是不是能够复用呢。对于软件本身大家会花费大量的人力去框架结构设计与代码重构。对于测试脚本很少有人会花同样人力去这样做。并且走到时候，初做底层那批人也走的差不多，现在这个时候系统也可能变的非常庞大，重构成本非常大。如果原来的测试脚本不能方便移植复用到新的产品中。慢慢这个自动化测式也走到头了。要么要从头来过了。