软件测试自动化的探索与管理（三）

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）明确定义测试框架的需求

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

　　如何定义适合当前项目或者系统自动化开发的框架内容呢？这需要自动化测试架构师根据系统特征、系统测试需求结合在一起进行分析，明确至少实现哪些内容，在时间和人力有限的情况下最多实现到什么程度等。将自动化测试框架所要达成的目标界定之后，才可以开始着手自动化测试框架本身的实际设计工作，伴随一些与测试脚本的同步开发，自动化测试框架将会随着自动化开发进程而日臻完备。

　　总之，自动化测试框架设计需求某种程度上比系统测试需求对自动化测试开发更重要，没有系统测试需求不知道开发的细节如何做，没有自动化测试框架需求或者自动化测试框架需求不明确就不知道到框架底要实现什么。知道需要实现哪些内容之后，我们尽量避免在项目中进行不必要的、多余的增强型功能设计和开发，以免影响项目进度，或者造成偏差。

　　3、小结：测试模式之拿来主义

　　概括地看一下这三种模式的测试自动化，我们可以发现它们本质上并没有什么区别，只是资源和时间限制会导致工作方式稍有所不同而已。而且我们可以用统一的项目管理手段来进行统筹，因为运营测试也好、新产品也罢都是可以被我视作项目处理。笔者分析这几种模式主要是想说明，自动化测试实现会受资源和时间进度的制约，所面临的境况有所不同，而且在指定的时间区间内带来的效益能否达到预期也会因此而不同。所谓细节决定成败，正是因为这些细微的差别，就决定了自动化测试在不同的场景下实施是否能够获得成功。因为在领导眼里这些模式看起来没有本质的区别，所以在不同的情况下，软件测试架构设计者支持或者自动化测试专家就必须因地制宜地向决策层领导传达这些细微差别能够带来什么风险或者效果，以避免自动化未开始实施就已经泥足深陷。

　　这三种模式的手工测试和自动化测试特点与各自的公司体制和流程制度都有一定关系。经常能在网上或者软件测试沙龙中听到不同的声音，大家对同一件事情同一个目标所做的事情也都不尽相同，所以分歧和异议不可避免。笔者也发现有很多同行、同事喜欢照搬别人的“先进经验”，比较信奉Microsoft、Google或者SAP的经验和理论，总喜欢讨论“别人这么做都怎么样了，我们这么做也应该会怎么样”之类的事情，基本把公司运营模式和流程制度的整体建设等因素抛在一边。例如，有人说Microsoft开发测试的比例是1：1甚至1：2应该是最合理的，是重视测试的真正体现；有人说Google在开发测试比例1：15的情况下能够完成自动化测试对敏捷开发的支持，说明人家的测试技术才真正是一流的；也有人说我们要引进Microsoft的测试理念、Google的测试技术，改一改我们的规范制度，也学习一下别人的敏捷开发、敏捷测试；还有人会经常抱怨：我们的开发测试比例多么的不协调，公司把整个开发过程中的压力都往测试周期内挪，还让我们做不简单、不务实的自动化……等等，诸如此类。其实这些言论大都是不客观的，因为大家在说这些话的时候没有差异化看待各自公司的特点，有些公司是做产品的，有些是做软件外包的，有的是做运营服务的，不能一概而论。虽然可能这些不同类型的公司所做的事情有交集，但是主体的公司运营模式已经决定了、区分了开发和测试形态的大体走向。笔者一个朋友这么给笔者描述他在花旗软件做外包测试：测试工具种类很多，爱用什么测试就用什么，给出测试报告就行……大家知道这样的公司或者部门可能一般是做软件（测试）外包服务或者咨询服务的，之所以有这么大的灵活性那是因为他们要面对不同客户的需求，那么别的类型的公司很明显不一定要满足这个特征——因为我们各自的客户需求是不一样的。

　　所谓实践出真知，“走有中国特色的社会主义道路”或许就是这么个理儿，既不能大跃进也不能全盘西化，而是要结合实际情况量身定做一套适合自己的衣服。同样自动化测试也是，可借鉴但万不可照搬别人的东西，要知道“拿来主义”背后还有着“深思熟虑”四个字，不思考、不调研的“拿来”是全无益处的，工具、框架、平台体系、管理模式……都这样。