2、自动化测试实施的必要条件

　　（a）可控的需求与足够的支持

　　系统测试需求源自软件开发需求规格，项目中这种需求可能会偶尔或者经常发生变更，带来的是业务逻辑和UI的变更，测试需求随着一起变更；对于UI层的这种自动化测试来说是增加了一些自动化开发的耗费甚至是框架的变更。所以，如果这种变更是“经常”而不是“偶尔”的话，抛开系统开发不说，单就测试自动化的变更消耗就是很大的；而这种需求上的变更如果不可控制的话，自动化在项目中注定是要失败的。

　　其次是资源，除了上文提到的人力资源外还包含下面这些：自动化开发工具、稳定的自动化开发环境、系统测试环境、测试管理工具、文档服务器、多台PC或者虚拟机作为执行客户端以及网络、安全策略配置等一系列基础架构资源。有时候为了不影响单元测试、集成测试的进行，自动化开发要拿到一个基线版本放到自动化开发独有的环境中去，如果关联系统无法调通则多使用挡板程序进行测试开发。这些资源在做自动化调研的时候是应该考虑在内的，如果资源没有问题，自动化开发也就不会因此而受阻；如果勉强能够应付，只是某一两个非必需设备无法到位则可以通过其他手段委曲求全，也能“对付得过去”；但是如果关键的、必需的资源是不能缺少的，假如安全策略都是严格到无法调度调试、运行的话，那么作再多的努力也是白费的，因为无法模拟到真实的业务操作的（自动化）测试是不尽科学的。对于这些资源的使用和不能到位的风险在决定使用自动化的时候就应该提出来提早解决的，没有充足的资源却要求做相应的事情自然是不合理的，不能应了那句调侃的老话“又要马儿跑，又要马儿不吃草”。

　　（b）达到一定软件开发成熟度

　　提及软件开发成熟度，大家最常的会想起的就是CMMI评估标准，但是我们这里不讨论CMMI本身，只以CMMI为例讨论测试和测试自动化。大家可能想成熟度和自动化有啥关系呢？其实上文中描述的开发模式也与软件开发成熟度有一定表征关系，越利于质量控制和过程管理的模式一般成熟度级别越高。我们先来看一下CMMI的级别定义：

　　处于成熟度等级1的组织一般不具备稳定的开发环境。在这类组织中，项目的成功往往取决于个人的能力和拼搏精神，离开了具备同样能力和经验的人，就无法在下一个项目中获得同样的成功。处于成熟度等级1的软件组织在这种专门化的无序环境中常常也能生产出可以工作的产品，但是，往往伴随着的是项目超过预算和拖延进度。

　　不用多说，显然1这种成熟度级别是无法进行自动化测试的，因为如果无法保证稳定的开发环境，完全依赖某些人的个人能力，自动化测试是绝对无法持续进行的。

　　一个软件组织如果达到了成熟度等级2的各个过程方面的全部目标，就意味着该软件组织已经确保有关的过程在项目一级得到策划、被形成了文件、得到执行、受到监督和控制。在这一级上，项目要达到针对过程确定的诸如成本、进度和质量目标之类的具体目标。

　　成熟度2级看起来就已经具备了自动化开发、测试的条件，没有什么能够太过制约自动化测试平台的搭建，不过：

　　在第2级与第3级之间的一个重要差别在于标准、过程描述和规程的适用范围。在第2级成熟度等级上，标准、过程描述和规程可能只在过程的某个特定事例中使用，例如在某个具体项目上使用。在第3级上，项目用的标准、过程描述和规程是从组织过程财富剪裁得来，整个组织执行的过程是一致的，这些标准、过程描述和规程通过己定义过程在整个组织的各个项目使用。

　　这表明2、3级在流程规范是否是组织级的这一关键点上是不同的，2级的情况下可能某些项目或开发组能够遵循固定的规范和流程，但是其余的可能就仍然还是1级的水平，这些1级的系统开发依然不能使用自动化测试。所以并不是说一个公司通过了CMMI-2级评估就一定能够搭建出自动化平台，即使搭建了也只是“轻量级的”，无法在整个公司内部的开发过程中得到很好的应用。相应的，只有3级及以上的成熟度才可以进行大规模的自动化测试。

　　（c）明确定义测试框架的需求

　　这正同做项目计划一样，如果事先没有明确要做什么，就可能会带来毫无目的的或者冗余的工作。布鲁克斯在《人月神话》中提到对程序过分的修饰带来的“第二个系统”，其实自动化开发也有类似的情况。如果没有明确哪些需要做、哪些可以不必做，那么测试人员在做自动化开发的时候总会想着在既定的框架下增加一些额外的功能，而这些功能可能与系统的测试没有多大关系，虽然它们会使自动化看起来更加强大、更“完美”。笔者犯过这样的错误：定好了计划并且汇报给了领导，但是在开发过程中不断的涌现“奇思妙想”并且总是试图验证一下自己的想法是否正确，所以很多次在领导跟笔者要进度汇报的时候反倒落后于自己的计划、落后于其他同事。那么，这么多的“奇思妙想”不去试验和尝试又是一个浪费，我们该怎么处理呢？我们可以像系统集成一样，分一期、二期……先保证需要使用的基本内容一定要按时开发完成，再找“合适的时候”去考虑增强测试框架和自动化内容。