有段时间没静下心来写点什么了，一直在忙着架构项目的自动化框架。许多人都认为自动化等同于自动化测试，为什么说自动化就一定只能用于测试的呢？个人并不认同这个理念，自动化旨在把重复有规律的劳动用机器运行的程序来代替，人可以把更多的精力放在探索性的工作中。不管是测试、开发还是文档、设计，都可以思考如何把自动化带入到自身的工作中。
当然鉴于目前带领的是测试团队，我们也一直在思考着什么样的自动化才是最适合我们这个项目的。其实在业界有着各种各样先进的理念和测试经验，很容易在书籍、博客、新闻、互联网上看到它们，例如：Cucumber, BDD, TDD, 自动化MVC等等。这都是前人在已有的项目中总结出来的，值得尊重和参考，但不值得盲从！因为项目的个性和差异性往往很大，理论归理论，如果没办法结合项目本身的特点来制定进化或者改版的理论，盲从经验教条的话，即使看起来很美好，实际执行起来也一定会付出惨痛的代价。
那么我们是怎么做的呢？首先回顾以往没有自动化框架的时候，大家在做什么？我脑海中的画面是：学习产品的功能和业务知识 -> 设计Test Case -> 制定Test Plan -> 安排人员和机器按照Test Plan进行测试 -> 最后给出Test Report。往复如此...... 那么当有了自动化之后呢？我见过一些项目组的状况是：分离一两个成员出来，撰写自动化脚本，其他人继续保持原有的方式进行，最终可能形成自动化在跑，人也在做，Case在设计，自动化脚本在实现，自动化在出report，人也在写Report。其实这两套流程并行看似合理，实则有许多重复和冗余的部分在里面，比如人设计了Test
Case，懂自动化脚本的人需要把Test Steps实现成自动化脚本。而自动化出了report之后，人还需要进一步去分析这份report里各个细节的真实性，甚至再重现许多次最终定位出真正的Bug。另外，Test Plan依然需要人来维护(从创建->填充内容->更新->到发布)，各个方面的结果也要靠人来汇总，最终的report还是由人来撰写。说白了，自动化所起的作用就是：一个不休不眠的机器，人可以休息，它不用，继续按照里程运行它那一套测试。
老实说，这本身没错，但是否能做得更好呢？我的想法是：能否让自动化框架“理解”人所设计的Test Case和撰写的Test Plan，直接跳过自动化脚本这一步，直接运行人给出的Test Case和Test Plan。然后把人执行Test Plan并给出最终Report的过程完全由自动化框架来做，人只需要发出命令，review最后的结果，并持续的设计新的Test Case就可以了。
有了这个想法之后，我们的自动化框架直接就朝这个方向来努力，这样人可以完全不改变以往的流程和习惯，全员还是规范的设计Test Case和撰写Test Plan，只不过写出来的Case和Plan可以自己运行并出Report。