第二章 识别测试模式和自动化准入

1.   产品、项目测试和运营测试

(1) 浅析三种测试模式的异同

大部分从业人士可能都知道产品开发的模式和具体流程，但可能并不是所有人都了解产品开发和开发完毕之后的运营维护的实际情况。笔者曾在一个国内知名IT外包公司工作，之后进入XXXX信息管理中心，也就是现在的XX科技，这两份工作经历让笔者有幸简单了解了一下软件测试的不同模式。笔者心目中的软件测试可以分为新产品开发项目测试、普通开发项目测试和运营测试（补丁需求版本）测试。本节简单阐述一下笔者心目中这三者的异同。

1.    新产品开发项目测试

(1) 整个项目立项，有些情况下测试也会单独立项，并且绝大多数有着较为完整的流程。如果软件开发成熟度较高，则测试管理相应也是比较规范和完善的，反之同理。

(2) 因适应新的市场或内部需求诞生或衍生一个或一组全新的系统。这些系统可能是经过深思熟虑而设计的，也可能是探索性的，但是无论对于开发还是测试和用户，它们都是从未操作过的。测试人员对系统的了解仅限于需求文档和页面原型，没有经验可参考。

(3) 有着较为充裕的时间跨度，能够运用较多的新技术和新思想。为了满足业务需求开发时可能会引进新的技术或平台架构，对应的测试人员如果经验不是非常丰富，那么需要学习的东西就比较多，甚至有时会出现系统上线之后“才刚刚有了那么点感觉”的意思。

(4) 一次性，项目发布之后，项目组大部分人将撤离，只留下极少的同事做后期维护工作。所以它在时间概念上是以一种一次性的模式存在的。

2.    一般项目开发测试

所谓一般的项目开发，主要是指：

Ø 技术、架构转平台项目，如某银行使用的核心对公交易管理系统从Terminal字符端升级到J2EE、某保险公司寿险业务系统的Forms转换到J2EE；

Ø 较大的系统变更项目，就是说系统变更所需要的人力、财力已经达到了立项标准的程度从而走了项目管理流程。

相比较上文新产品开发测试提到的几点：

(1)  项目管理流程大体一致，但是测试单独立项的可能性非常小；

(2)  系统中保留了业务逻辑理念，架构转平台时UI发生极大的变更，而同平台下的大规模改造则会沿用较多的现有模型。对于测试来说，最实惠的是有经验可借鉴，主要参照现有系统的逻辑作对比的变更测试，目的更为明确。

(3)  已有技能和经验在测试过程中起到不少作用，测试人员上手速度比较快。同时系统改造或者技术转平台将会对没有发生变动的模块产生大量的关联影响，可能大家比较认同的是：每一轮向Staging重要的发布都要经过全面的冒烟测试，即便关联影响在开发阶段得到了很好的控制，这种冒烟测试也是不多余的。

(4)  同项目开发测试，只不过多次改造、升级可能会连续进行，如每两、三年发生一次。

3.    运营测试

(1)  没有独立的项目过程，测试周期和测试时间跨度都比较短；

(2)  系统中绝大多数的规则和页面都没有发生变更，前台操作和后台的逻辑对于测试人员来说都是轻车熟路，不会有太多障碍，除非测试人员本身技能有问题；

(3)  变更的关联影响比较小，基本上能够通过SA、设计、编码和测试人员的共同评估就可以轻松得出变更范围和关联影响程度。事实上为了“保险起见”或者出于对这几方人员的不完全信任，让测试人员在发布前做一次全面的回归测试也是大多数公司和领导愿意去做的事情。

(4)  持续不断的，在系统运营中，为了满足新的业务需求或者解决已有生产缺陷，系统将持续不断的向生产发布补丁版本。区别在于周期是不固定的，有可能是每半个月、一个月发布一次版本，也可能是一个季度一次版本；可能也有版本管理不严格的公司，随时开发、测试完毕随时发布生产。

这里需要指出的是，在项目测试里面，只要是增量式移交模式，那么测试的工作内容也是增量的，除非每一阶段的代码完全独立、相互毫无关联。而事实上这是不可能的，也是违背目前开发设计理念的，因为很多好东西无法复用。为什么说增量式移交带来测试工作量递增呢？假设一个项目分三期移交，那么测试第二期移交的内容的同时就必须考虑第一移交内容受影响的可能性；在做第二期移交内容的完全测试的同时显然还要去做一期内容的测试，一旦发现问题就是反复好几次的移交……同理第三期移交将带来更加多的问题累积，传统的手工测试模式在同等的人力下很难支持这种移交模式。

(2) 对自动化测试的要求浅析

1.    新产品开发项目测试

前文提到新产品开发可能会引进全新的架构和技术平台，即将诞生的新系统对于测试人员来说也是完全陌生的，所以至少在首次移交测试环境之前，做自动化的分析调研难度都是非常大的。一般来说一个公司现有的自动化测试框架能否满足这种情况下的自动化开发也是个未知数。无论是否可以满足，参与该项目自动化构建的人至少应该包括一个对系统架构非常熟悉的人（无论是开发还是测试）、一个对业务需求十分了解的人、一个对测试整体过程和规范十分了解的人、一个自动化测试技术很好的人，当然测试经理和项目经理都能参与或许能给出一些较为有价值的、有大局观和前瞻性的建议。如果有一个同时熟悉环境架构、业务、自动化测试技术和测试规范的人，那么很幸运，让他来吃螃蟹吧。这个人在测试工具选取、框架设计修改上承担着很大的责任，这个时候丰富的经验和灵活的头脑将成为很重要的资本。在项目编码的初期，测试架构师就要能够有效论证已经选择的方案和方法是行得通的，并且做好技术风险的评估，找出自动化实现过程中可能遇到的类如安全性、兼容性、可移植性等等技术性问题。通常对系统架构熟悉或者决定系统架构的是EA，熟悉整体业务能预知UI设计细节的是SA和设计编码人员，熟悉自动化测试技术和测试流程规范的是资深测试工程师，所以完美的这么个兼各家之长的人是很难找到的。那么测试人员能做的是把大家聚到一起，对将要实现的目标和已有的资源做一个理性的分析，评估完毕给出分析报告，由测试经理和项目经理给出意见和建议，在不影响到项目成本和项目任务关键路径的情况下由测试经理给出最终的裁决：工具选取、人员、资源配备、进度schedule等等。

综上所述，新产品项目开发的自动化测试在项目前期要做很多的调研和探索分析，一般需要选取一个或几个典型案例场景做出Demo，论证其可行性。这样做的目的其实很简单：不让自动化成为项目的负担，让所有干系人明白自动化上的投入时值得的；让项目经理和测试经理放心、让参与自动化开发的同事树立信心。这一点无论对于什么模式下的测试都是十分重要的，但是在项目测试中显得尤为重要，因为这从根本上牵动着项目的铁三角：时间、成本、质量。如果投入的人力和资源没有给系统质量带来提高，或者中途反反复复，无疑是对项目的巨大打击。

2.    一般项目开发测试

相比之下，一般的系统开发项目倒因为自动化测试人员对现有技术平台和业务需求都是比较熟悉而变得稍微简单一些。

1)   对于系统改造和大规模的补丁需求立项来说，如果这个系统（群）从未进行过自动化测试，那么笔者个人认为最好不要为了这么个项目做过多的自动化投入，至少在项目周期内不要做。因为项目周期一般没有那么长，人力资源配备远不如新产品开发，这样的情况下进行自动化首先要考虑已经成熟应用是否也要同步完成。如果需要完成整个系统的自动化那么对项目进度的影响和测试资源的占用是比较大的；如果只完成现有项目测试内容，那么前文提到的每次向Staging的重要发布的回归测试可能不够全面，而且这样部分手工部分自动化执行对于测试分析和度量统计是一件较为麻烦的事情。

2)   同上一点，如果这个系统（群）已经进行过自动化测试，在现有成熟的框架下已经有足够多的测试用例，那么自动化就非常简单。所要做的是：

a)    在原有的框架体系下扩展自动化测试的内容，完成项目测试的自动化；

b)    在SA或者BA的协助下重新梳理已有场景、流程，整合原有的、新增的自动化测试案例或者场景，分析项目变更重点和关联影响重点，为项目测试组建一套完整的自动化测试集合，用于每次版本发布Staging的冒烟和回归测试。

3)   对于技术升级和架构转平台，如果项目经理和测试经理决定在项目中大规模进行自动化测试，无论之前的系统（群）是否已经完成自动化，整个自动化测试都要重头再来。同新产品开发项目测试的自动化类似，新架构、技术平台下的自动化分析、调研是必不可少的环节。之后的整个过程也是类似的，但是由于这种项目的周期可能不会有新产品开发那么长，资源也未必有那么充足，所以在论证自动化的可行性的时候一定要多关注在项目周期内的投入和产出是否协调的问题。

3.    运营测试

相比项目的两种测试模式，运营测试是铺开大规模的、系统化的全面自动化测试比较经济的一个模式，因为系统投入运营之后已经有了完善的文档和非常成熟稳定的界面，测试人员已经对系统业务流程和所采用的技术及其对应的测试技术非常熟悉了。显然项目阶段频繁的需求变更和界面改动在这个阶段内是比较少的，自动化开发和维护的成本非常低，并且应用于冒烟测试、回归测试的效果是立竿见影的。

1)   如果在项目测试阶段已经完成自动化开发，那么在系统运营的时候只需稍微整理现有的功能点、场景和流程分支，搭建用于每次发布的冒烟和回归测试集合即可。当然，补丁需求带来新的功能点和关联的变更也是需要自动化工程师进一步自动化开发和维护的，不过比起整个系统自动化测试的组建，这部分内容将不会消耗多少人力资源。

2)   还有一种情况是项目阶段某个（些）系统没有进行自动化功能测试或者没有进行完全的自动化测试。这种情况下的自动化开发需要了解如下几点：

a)    固定时间内，版本发布的周期和Staging环境的修复移交次数将直接作用于投入产出比例。版本发布越频繁冒烟、回归测试的次数自然也就越多，自动化测试带来的直接价值越大；Staging环境的修复移交次数越多，冒烟次数越多，用于每次移交版本的质量评估操作越简单。例如，版本部署窗口在17点，部署1小时内完成，18点半开始大规模的自动化运行，次日早上即可得出一份较完整的测试报告。

b)    反之，相同周期内版本发布的次数越少……那么从上一段的论述是不是可以得出这么一个结论呢：由于使用次数少自动化变得没有价值或者价值不大？事实上并不是这样的，看自动化的价值不仅仅是看投入和产出在开发时间和运行次数上的比例！在项目周期内这一点非常重要是因为它牵动着项目的各个方面，但是在项目之外除了单纯的考虑自动化开发和应用时间比例之外还要考虑管理成本和质量目标，后者往往被大家所忽略，这一点后文会继续分析。

c)    如果已经有了成熟的自动化测试体系框架，建议自动化工程师不要过多的参与运营测试阶段内的自动化开发。首先，一般测试人员对系统逻辑更加熟悉，对测试过程中使用自动化的需求更迫切。其次，让每个测试负责人都有机会学习一下自动化开发是一件好事，尤其是在有锻炼机会的情况下测试技术和测试理念的提升会很快。第三，无休止的开发和维护会把自动化测试工程师陷在某些系统中，虽然实践的机会比较多，但是或许有很多更重要、难度更大的自动化开发在等着他们，把他们的精力分散在长期的多系统的补丁测试开发和维护不利于人力的随时调度。第四，自动化测试工程师本身的职责应该偏向于测试框架的修补升级、自动化测试管理协助、新技术和疑难技术的研究和解答、自动化测试工具的开发，而不是单纯的做自动化测试的开发。

概括地看三种模式的测试自动化，我们先不妨下这么个结论：无论实在实验探索还是在成熟应用阶段，如果自动化不能为测试带来收益，甚至变成了负担，那么自动化还是不做的好。至于如何评估自动化到底是带来了收益还是带来了负担，我们再第三章将进一步讨论。

(3) 测试模式之外看拿来主义

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

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

2.   自动化测试与软件系统开发

(1) 明确且严格遵循框架需求

咱们前文提到，在不同的情况下，自动化的作用和地位会有所不同，基于这个前提，我们还需要弄清楚测试自动化在每一个独立的系统测试中应该起到什么样的作用，或者说要明确自动化应该达到什么效果。请注意，这不是说自动化要投入多少、产出多少或者能带来什么效益，而是说该系统使用自动化做测试要做到什么样一个程度。例如，笔者有一个系统测试任务，经过调研知道了这个系统的测试可以使用自动化的方式来进行，那么测试自动化的作用点应该包含哪些是需要明确的，如每次测试执行的报告是否自动化生成、是否要发送给相关领导和同事、测试结果的多维分析度量是否也要一并执行、是否在执行失败的时候自动提交缺陷到缺陷管理系统中等事宜都需要明确。

这正同做项目计划一样，如果事先没有明确要做什么，就可能会带来毫无目的的或者冗余的工作。IBM360之父Brooks在《人月神话》中提到对程序过分的修饰带来的“第二个系统”，其实自动化开发也有类似的情况。如果没有明确哪些需要做、哪些可以不必做，那么测试人员在做自动化开发的时候总会想着在既定的框架下增加一些额外的功能，而这些功能可能与系统的测试没有多大关系，虽然它们会使自动化看起来更加强大、更具有兼容性和可移植性。笔者犯过这样的错误：定好了计划并且汇报给了领导，但是在开发过程中不断的涌现“奇思妙想”并且总是试图验证一下自己的想法是否正确，所以很多次在领导跟笔者要进度汇报的时候反倒落后于自己的计划、落后于其他同事。后来想想，在公司现有的体系下去做这么一件事情，可以不用太多的考虑“如果以后公司做了什么变动会导致笔者这儿要怎么办？”的问题；有前瞻性是好事，但是最好不要过分“杞人忧天”，因为公司在做“什么变动”的时候会让大家都去厘清关联影响的。但是那么多“奇思妙想”不用又是一个浪费！我们可以像系统开发一样，分一期、二期……先保证需要使用的基本内容一定要按时开发完成，再找“合适的时候”去考虑增强测试框架和自动化内容。

总之，如果项目经理或者测试经理让你“先做做看”，那你就直接告诉他：不行，只有在需求明确的情况下才去做自动化测试的开发。请记得这一点：自动化测试需求某种程度上比系统测试需求对自动化测试开发更重要，没有系统测试需求不知道开发的细节如何做，没有自动化需求或者自动化需求不明确就不知道到底要做什么。

(2) 与软件开发成熟度的关系

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

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

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

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

(3) 足够的资源和可控的需求

第一章、第一节的第1、第2小节曾简单提到一些自动化测试的投入和需求问题。

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

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

这里要提出一个有趣的现象：有些人做事是高速集中型，有些人做事是按部就班型。按部就班的人是一件一件的完成每件事情，虽然可能优先级是准确的但是很少并行操作；而高速集中型是把几件事情同时进行的，可能在A机器编写测试案例AA，同时在B机器调试脚本BB，隔几秒跑到C机器上去调度测试集CC。要知道的是AA、BB、CC是不能同时在一台机器上操作的，那么如果这种高速集中的自动化开发人员需要多台机器或者虚拟机器那么请考虑给他，否则这种人的工作效率很可能还不如按部就班的人，因为他们注意力集中……不能被打断，而多任务的优先级的实时变化让他们很难适应。举个形象的例子：分别给两个人性质相同的10件事情，他们各自都有自己所需要的资源，从10点钟到17点钟不停的工作，全部完成了还不是很累的是按部就班的人，而从11点到16点就可以完成但是非常疲惫需要休息1个小时的人是集中型的人。                                                        作者 不懂管理的围观群众yijiubasi@163.Com