序言：一般而言，刚开始自动化测试时，很多时候，很多人都不知道如何入手或者还有一部分人都信心满满，决心要建设出一份大的平台，可是事实在于自动化测试面临的问题一在于技术，二在于环境形势。每个公司有不同的需求、有不同的环境、不同的人员支持，所以做自动化测试所需要涉及的外界因素太多，就如黑天鹅效应中的说法，你所自认为的白天鹅中也许就隐藏着一只黑天鹅，它的出现会导致你的整体计划崩盘。所以，做自动化测试也一样，所依赖的东西太多，就能引起的整体变化太多，所以我觉得我们的基本策略就是：不断预测、不断总结，然后是拥抱变化

　　总结的从开始到一定阶段的建设自动化测试的策略如下（麻烦有不同想法或者别的策略的朋友帮忙补充）：

　　1、分析需求并且细化需求，自动化测试是急不来的事情，不能指望用他来解决所有问题，所以必须明确需求，将需求一步一步写下来，然后从简单到容易开始击破。

　　2、评估资源，围绕人力支持、部门测试流程情况以及产品业务来决定自动化测试要先从哪一步开始走，并哪一步为阶段。自动化测试必须最终与整体的测试流程相结合，才能发挥作用，否则只会越走越远。

　　3、从最小的需求开始入手，也许是一个工具或者是一个线性脚本。总之，先解决一点需求，然后从点到面。获得一个面后，将其授权，然后再做点，这样一步一步进行铺张，其实说白了，也是一个自动化测试信心和价值建立的问题。

　　4、记：简单。要将一个东西发扬出去，那么它必须简单，技术人员的思维有时候总是把东西做的很复杂，因为有时候会觉得很炫，但需要做好一个东西得到发扬的话，则需要将一个复杂的东西让人看起来很简单。一个工具或者一个框架，最好只有一个修改入口和一些API拓展机制。让测试人员用起来和拓展起来都很简单。

　　5、CBB：CBB在软件开发中俗称“软件模块共享”。而在自动化测试中也是一样，要建立自己的开发库，不仅提供给以后的测试开发使用，更是给测试人员使用，能够在其基础进行很快速的共享和拓展。

　　6、覆盖率分析：单纯的用例自动化很难突显自动化测试后，其到底覆盖了多少点，通过了哪些点，一个用例的拓展也不是很好拓展。因此需要划分为点的方式，即可以每个脚本对应一个测试点，每次测试，可以统计覆盖了多少个点，通过率如何，即产用产品—模块—测试点统计覆盖率的方法。

　　7、ROI分析：在自动化测试一定阶段后，做好自动化测试ROI分析，绝对不打没有目标性的仗，我们到底为了什么做自动化测试，很多人会说是为了保证质量，首先，大家都明白，自动化测试不是用来发现问题的，这个说法没有错，但是问题在于，好不容易做起来的自动化测试，结果没有好的ROI分析机制，乱做了一通，该做的测试用例没有自动化，不该做的做了一堆，结果导致自动化测试的开发和维护成本很高，收效成本很少，所以，到中期阶段，需要有一个ROI分析机制帮助评估自动化测试脚本的建设。

　　8、成熟度模型：现在业界有一些人已经提出了自己的自动化测试阶段，这些阶段在一定基础上是值得参考的，但是上面也说了，每个公司、每个部门的情况和需求是不一样的，其依赖的因素很多，所以在自动化测试发展过程中，可以从一个试点产品或者一个项目中不断分析抽象，建立一套自己的成熟度模型，然后进行推广。在每个阶段评估不同项目、不同产品的自动化测试成熟度。

　　总结：做自动化测试不是一件容易的事情，但也不是一件值得怀疑的事情，它有它的价值，正所谓存在即合理，也许我们做的是要找到正视它的价值，不浮夸它，也不贬低它，踏踏实实做它应该带来的效果。

版权声明：本文出自 散步的SUN 的51Testing软件测试博客：http://www.51testing.com/?382641

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。