软件测试自动化的探索与管理.docx

.软件测试自动化的探索与管理引言 辩证地看待“以人为本”若说起自动化测试， 可真是一千人有一千个说法，其实完全可以引用邓大爷的一句话来概括：不管是黑猫白猫，抓到老鼠就是好猫！无论是何种工具、何种框架或者体系，我们始终坚持 实用至上，能满足我们的测试需求才是王道。无论是商业工具还是开源工具，它们应该都有相同或相似的测试框架和流程、规范，所依赖的是一个较为完善的自动化 平台和体系。否则自动化测试只能依赖个别能力较强的测试专家去维持，而过于依赖个人能力对于组织来说则不具备稳定性和可靠性，对组织的可持续发展是个不小 的挑战。去年看新版三国的时候，还专门为此编了个顺口溜：人中吕布，三姓家奴；恩义持国，上将锦蜀！意思就是，一方面个人能力再强也可能有一天归入别人麾 下，只有靠着系统性的法则去维持系统的运转才有可能保证经久不衰；另一方面，能力发展要均衡，技术能力再强，意识理念如果落后或者停步不前的话，那就像吕 奉先一样有勇无谋，迟早要落得“身首异处”的下场。再看自动化测试，虽然我们不依赖某一两个人，但就对工具和测试手段的态度来说，笔者 始终坚信人毕竟还是制胜的决定性因素，不宣扬工具有多好或多不好。有人认为商业工具的对象与方法封装的很死，二次开发没有开源工具那么随心所欲；有人认为 开源工具使用起来编码难度更大、缺陷也多，只有少数的几个人能精通，很难在组织内推广。其实我们可以考虑一下：（1）有些人主张自动化只用来进行单元测试和集成测试，以追求更多的效益，那么请问我们平常需要做多少抛开页面的接口测试？而且这些接口测试难道不能、完全不能通过页面去测试么，例如开发接口模拟器？非敏捷的情况下大量需要UI自动化测试的现实可以被忽略么？ （2）有些人喜欢把不成功的自动化实现迁怒于测试工具，那么不妨让我们扪心自问：我们的工具使用起来效果不好问题在哪里？我们是否已经把这个自己觉得不 好用的工具用到极致了呢？我们的问题是否归咎于我们自己的测试设计质量不高呢？如果是测试设计的问题，那么既然VB用不好，JAVA就一定能用好么？ 当然，不同的工具各自有各自的优缺点，所支持的需求类型和功能侧重点也有所不同，但是，绝无必要因为商业工具用的失败就去追求开源，也不必因为开源工具 用得不方便就去追求商业工具，必须先弄清楚自己为什么用的不好，问题在哪里，如何改进！盲目的赶潮流倒是能积累很多经验，但同时也势必会给组织带来无谓的 资源浪费。所以，自动化测试不仅要坚持以人为本，还要看立足点落在什么角度上，所讨论的是什么问题，所以需要辩证地看待这个问题。笔者的观点是：以人为 本，但不以某一人或几人为本。笔者有四五年的Web（自动化）测试经验，主要使用的是Mercury系列商业测试工具，故而所谈论的一些内容主要都是以自己的经验认识为基础的。不过笔者相信做任何事情原理本质上是相通的，而且我们讨论的自动化测试的原理都是基于测试基础理论和项目管理基础理论。本文只讨论理念，不讨论技术，只希望通过本文的探讨可以整理一下自己长久以来在自动化测试上混乱的思路，也希望笔者的观点不要成为束缚大家思维的罪恶黑手或者任何人说教的依据，“抛砖引玉”可，“抛砖引砖”亦可，希望诸位读者不吝赐教。第一章 自动化测试模式差异化1、产品、项目测试和运营测试（a）三种测试模式的异同 大部分从业人士可能都知道产品开发的模式和具体流程，但可能并不是所有人都了解产品开发和开发完毕之后的运营维护的实际情况。笔者曾有幸在“神码融信” 先后经历过东亚银行、兴业银行和国家开发银行这三个项目的测试，有现场实施也有基地化开发；之后进入平安集团信息管理中心，也就是现在的平安科技，这两份工作经历让笔者有幸简单了解了一下软件测试的不同模式。笔者理解，软件测试从项目类型上可以分为新产品开发项目测试、普通开发项目测试和运营测试（补丁需求版本）测试。本节简单阐述一下笔者心目中这三者的异同。1）新产品开发项目测试 因适应新的市场或内部需求诞生或衍生一个或一组全新的系统。这些系统可能是经过深思熟虑而设计的，也可能是探索性的，但是无论对于开发还是测试和用户，它们都是从未操作过的。测试人员对系统的了解仅限于需求文档和页面原型，鲜有经验可供参考，像Windows 7和Office的一些新组件等。 有着较为充裕的时间跨度，能够运用较多的新技术和新思想。为了满足业务需求开发时可能会引进新的技术或平台架构，对应的测试人员如果经验不是非常丰富，那么需要学习的东西就比较多，甚至有时会出现系统上线之后“才刚刚有了那么点感觉”的意思。 一次性，项目发布之后，项目组大部分人将撤离，只留下部分同事做后期维护工作。所以它在时间概念上是以一种一次性的模式存在的。2）一般的开发项目测试所谓一般的项目开发，主要是指： 技术、架构转平台项目，如某银行使用的核心对公交易管理系统从字符终端（C/S）升级到J2EE的Web页面（B/S）、保险公司传统业务系统的Forms转换到J2EE； 较大的系统变更项目，就是说系统变更所需要的人力、财力已经达到了立项标准的程度从而走了项目管理流程。相比较上文新产品开发测试提到的几点： 系统中保留了业务逻辑理念，架构转平台时UI发生极大的变更，而同平台下的大规模改造则会沿用较多的现有模型。对于测试来说，最实惠的是有经验可借鉴，主要参照现有系统的逻辑作对比的变更测试，目的更为明确。 已有技能和经验在测试过程中起到不少作用，测试人员上手速度比较快。同时系统改造或者技术转平台将会对没有发生变动的模块产生大量的关联影响，可能大家比 较认同的是：每一轮向测试环境重要的发布都要经过全面的冒烟测试，即便关联影响在开发阶段得到了很好的控制，这种冒烟测试也不是多余的。 同项目开发测试，只不过多次改造、升级可能会连续进行，如每两、三年发生一次。3）运营维护性需求测试 系统中绝大多数的规则和页面都没有发生变更，前台操作和后台的逻辑对于测试人员来说都是轻车熟路，不会有太多障碍，除非测试人员本身技能有问题； 变更的关联影响比较小，基本上能够通过SA、设计、编码和测试人员的共同评估就可以轻松得出变更范围和关联影响程度。事实上为了“保险起见”或者出于对这几方人员的不完全信任，让测试人员在发布前做一次全面的回归测试也是大多数公司和领导愿意去做的事情。 持续不断的，在系统运营中，为了满足新的业务需求或者解决已有生产缺陷，系统将持续不断的向生产发布补丁版本。区别在于周期是不固定的，有可能是每半个 月、一个月发布一次版本，也可能是一个季度一次版本；可能也有版本管理不严格的公司，随时开发、测试完毕随时发布生产。这里需要指出的 是，在项目测试里面，只要是增量式移交模式，那么测试的工作内容也是增量的，除非每一阶段的代码完全独立、相互毫无关联。而事实上这是不可能的，也是违背 目前开发设计理念的，因为很多好东西无法复用。为什么说增量式移交带来测试工作量递增呢？假设一个项目分三期移交，那么测试第二期移交的内容的同时就必须 考虑第一移交内容受影响的可能性；在做第二期移交内容的完全测试的同时显然还要去做一期内容的测试，一旦发现问题就是反复好几次的移交同理第三期移交 将带来更加多的问题累积，传统的手工测试模式在同等的人力下很难支持这种移交模式。而在现代的先进开发模式里，敏捷开发占据了很大部分，恰巧敏捷开发基本都是增量式构建的，这就是对传统手工测试的最大挑战，之所以要在每日构建中引入自动化测试工具的使用，就是为了解决这种问题。（b）对自动化测试的要求1）新产品开发项目测试 前文提到新产品开发可能会引进全新的架构和技术平台，即将诞生的新系统对于测试人员来说也是完全陌生的，所以至少在首次移交测试环境之前，做自动化的分 析调研难度都是非常大的。一般来说一个公司现有的自动化测试框架能否满足这种情况下的自动化开发也是个未知数。无论是否可以满足，参与该项目自动化构建的 人至少应该包括一个对系统架构非常熟悉的人（无论是开发还是测试）、一个对业务需求十分了解的人、一个对测试整体过程和规范十分了解的人、一个自动化测试 技术很好的人，当然测试经理和项目经理都能参与或许能给出一些较为有价值的、有大局观和前瞻性的建议。如果有一个同时熟悉环境架构、业务、自动化测试技术 和测试规范的人，那么很幸运，让他来吃螃蟹吧。这个人在测试工具选取、框架设计修改上承担着很大的责任，这个时候丰富的经验和灵活的头脑将成为很重要的资 本。在项目编码的初期，测试设计专家就要能够有效论证已经选择的方案和方法是行得通的，并且做好技术风险的评估，找出自动化实现过程中可能遇到的类如安全 性、兼容性、可移植性等等技术性问题。通常对系统架构熟悉或者决定系统架构的是EA，熟悉整体业务能预知UI设计细节的是SA和设计编码人员，熟悉自动化 测试技术和测试流程规范的是资深测试工程师，所以完美的这么个兼各家之长的人是很难找到的。那么测试人员能做的是把大家聚到一起，对将要实现的目标和已有 的资源做一个理性的分析，评估完毕给出分析报告，由测试经理和项目经理给出意见和建议，在不影响到项目成本和项目任务关键路径的情况下由测试经理给出最终 的裁决：工具选取、人员、资源配备、进度计划等等。综上所述，新产品项目开发的自动化测试在项目前期要做很多的调研和探索分析，一般需要选取一个或几个典型案例场景做出范例，论证其可行性。这样做 的目的其实很简单：不让自动化成为项目的负担，让所有干系人明白自动化上的投入时值得的；让项目经理和测试经理放心、让参与自动化开发的同事树立信心。这 一点无论对于什么模式下的测试都是十分重要的，但是在项目测试中显得尤为重要，因为这从根本上牵动着项目的铁三角：时间、成本、质量。如果投入的人力和资 源没有给系统质量带来提高，或者中途反反复复，无疑是对项目的巨大打击。2）一般的开发项目测试相比之下，一般的系统开发项目倒因为自动化测试人员对现有技术平台和业务需求都是比较熟悉而变得稍微简单一些。 对于系统改造和大规模的补丁需求立项来说，如果这个系统（群）从未进行过自动化测试，那么笔者个人认为最好不要为了这么个项目做过多的自动化投入，至少在 项目周期内不要做。因为项目周期一般没有那么长，人力资源配备远不如新产品开发，这样的情况下进行自动化首先要考虑已经成熟应用是否也要同步完成。如果需 要完成整个系统的自动化那么对项目进度的影响和测试资源的占用是比较大的；如果只完成现有项目测试内容，那么前文提到的每次向测试环境的重要发布的回归测 试可能不够全面，而且这样部分手工部分自动化执行对于测试分析和度量统计是一件较为麻烦的事情。 同上一点，如果这个系统（群）已经进行过自动化测试，在现有成熟的框架下已经有足够多的测试用例，那么自动化就非常简单。所要做的是： 在原有的框架体系下扩展自动化测试的内容，完成项目测试的自动化； 在SA或者BA的协助下重新梳理已有场景、流程，整合原有的、新增的自动化测试案例或者场景，分析项目变更重点和关联影响重点，为项目测试组建一套完整的自动化测试集合，用于每次版本发布测试环境的冒烟和回归测试。 对于技术升级和架构转平台，如果项目经理和测试经理决定在项目中大规模进行自动化测试，无论之前的系统（群）是否已经完成自动化，整个自动化测试都要重头 再来。同新产品开发项目测试的自动化类似，新架构、技术平台下的自动化分析、调研是必不可少的环节。之后的整个过程也是类似的，但是由于这种项目的周期可 能不会有新产品开发那么长，资源也未必有那么充足，所以在论证自动化的可行性的时候一定要多关注在项目周期内的投入和产出是否协调的问题。3）运营维护性需求测试相比项目的两种测试模式，运营测试是铺开大规模的、系统化的全面自动化测试比较经济的一个模式，因为系统投入运营之后已经有了完善的文档和非常 成熟稳定的界面，测试人员已经对系统业务流程和所采用的技术及其对应的测试技术非常熟悉了。显然项目阶段频繁的需求变更和界面改动在这个阶段内是比较少 的，自动化开发和维护的成本非常低，并且应用于冒烟测试、回归测试的效果是立竿见影的。 如果在项目测试阶段已经完成自动化开发，那么在系统运营的时候只需稍微整理现有的功能点、场景和流程分支，搭建用于每次发布的冒烟和回归测试集合即可。当 然，补丁需求带来新的功能点和关联的变更也是需要自动化工程师进一步自动化开发和维护的，不过比起整个系统自动化测试的组建，这部分内容将不会消耗很多人 力资源。 还有一种情况是项目阶段某个（些）系统没有进行自动化功能测试或者没有进行完全的自动化测试。这种情况下的自动化开发需要了解如下几点： 固定时间内，版本发布的周期和测试环境的修复移交次数将直接作用于投入产出比例。版本发布越频繁冒烟、回归测试的次数自然也就越多，自动化测试带来的直接 价值越大；测试环境的修复移交次数越多，冒烟次数越多，用于每次移交版本的质量评估操作越简单。例如，版本部署窗口在17点，部署1小时内完成，18点半 开始大规模的自动化运行，次日早上即可得出一份较完整的测试报告。 反之，相同周期内版本发布的次数越少那么从上一段的论述是不是可以得出这么一个结论呢：由于使用次数少自动化变得没有价值或者价值不大？事实上并不是 这样的，看自动化的价值不仅仅是看投入和产出在开发时间和运行次数上的比例！在项目周期内这一点非常重要是因为它牵动着项目的各个方面，但是在项目之外除 了单纯的考虑自动化开发和应用时间比例之外还要考虑管理成本和质量目标，后者往往被大家所忽略，这一点后文会继续分析。如果已经有了成熟的自动化测试体系框架，建议自动化工程师不要过多的参与运营测试阶段内的自动化开发。首先，一般测试人员对系统逻辑更加熟悉， 对测试过程中使用自动化的需求更迫切。其次，让每个测试负责人都有机会学习一下自动化开发是一件好事，尤其是在有锻炼机会的情况下测试技术和测试理念的提 升会很快。第三，无休止的开发和维护会把自动化测试工程师陷在某些系统中，虽然实践的机会比较多，但是或许有很多更重要、难度更大的自动化开发在等着他 们，把他们的精力分散在长期的多系统的补丁测试开发和维护不利于人力的随时调度。第四，自动化测试工程师本身的职责应该偏向于测试框架的修补升级、自动化 测试管理协助、新技术和疑难技术的研究和解答、自动化测试工具的开发，而不是单纯的做自动化测试的开发。版权声明：本文出自 lyscser 的51Testing软件测试博客：/?68857原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。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的测试技术，改一改我们的规范制度，也学习一下别人的敏捷开发、敏捷测试；还有人会经常抱怨：我们的开发测试比例多么的不协调，公司把整个开 发过程中的压力都往测试周期内挪，还让我们做不简单、不务实的自动化等等，诸如此类。其实这些言论大都是不客观的，因为大家在说这些话的时候没有差异 化看待各自公司的特点，有些公司是做产品的，有些是做软件外包的，有的是做运营服务的，不能一概而论。虽然可能这些不同类型的公司所做的事情有交集，但是 主体的公司运营模式已经决定了、区分了开发和测试形态的大体走向。笔者一个朋友这么给笔者描述他在花旗软件做外包测试：测试工具种类很多，爱用什么测试就 用什么，给出测试报告就行大家知道这样的公司或者部门可能一般是做软件（测试）外包服务或者咨询服务的，之所以有这么大的灵活性那是因为他们要面对不 同客户的需求，那么别的类型的公司很明显不一定要满足这个特征因为我们各自的客户需求是不一样的。所谓实践出真知，“走有中国特色的社会主义道路”或许就是这么个理儿，既不能大跃进也不能全盘西化，而是要结合实际情况量身定做一套适合自己的 衣服。同样自动化测试也是，可借鉴但万不可照搬别人的东西，要知道“拿来主义”背后还有着“深思熟虑”四个字，不思考、不调研的“拿来”是全无益处的，工 具、框架、平台体系、管理模式都这样。第二章 自动化测试的常见问题1、自动化能满足我们什么自动化能做什么事情原本是个很古老的命题，基本所有人都知道，而且也有很多人对这一点进行过论述和论证。所以这里不再多说，只为讨论问题的完整性简单进行阐述，以便读者在阅读和思考或讨论的时候能更好的上下文衔接。（a）提高测试执行的速度毫无疑问，无论使用什么工具，自动化测试执行是使用机器部分代替人工执行的方式，10人日的测试执行工作量 可以由5个人花2天也可以2个人花5天完成。自动化如果实现了80%，那么使用2个人1天可以完成剩下的20%手工测试；用一台PC Server组装10套虚拟系统，10套虚拟系统0.8甚至0.5天就可以完成所有这些自动化的测试执行。不考虑自动化开发的投入，还是2个人，1天就能 完成所有的测试执行，所以说自动化测试提升执行速度的本意是使用同等的执行人力可以结合自动化在最短时间内完成测试执行，而并非说自动化的操作速度比人工 快。对于不同层面的自动化测试来说，有些执行速度是远远高过手工测试的执行速度的，但是有些却并不是这样。例如，应用JUNIT的单元测试和SELENIUM的UI测试的执行速度是比手工测试执行要快很多，绝大多数性能测试工具也是如此；然而在某些UI测试或者系统操作大部分时间消耗在后台数据库操作的时候，自动化测试工具并不会显得比手工测试快，而且手工测试还能利用时间的交叉实现并行，但是自动化工具却并不会自动化实现这些。（b）避免机械式重复工作 虽然测试有像正交覆盖这样被证明了是科学的裁剪方法，但是，一方面，这些裁剪方法并不是所有的地方都能使用，另一方面，即便都能用测试执行的工作量还是 非常大的。无论是多有耐心的测试人员，在长期的测试执行中也会感觉疲惫和乏味，当然有些自制力比较强的同事还是能坚持下来的。自动化测试的好处就在于能替 代人去做一些反反复复的工作，可以不眠不休不厌倦；这样可以解放出一部分测试执行人员，让他们向更需要他们的地方成长、发挥。特别是对 于像我们这样做运营测试的同事来说，可能会有几年只负责测试某一个或几个系统的补丁需求的情况。自动化让大家可以腾出手来做更多的分析工作，一定程度上也 能通过提高测试分析设计的投入来提升测试的质量；同时也能让测试人员减少一些乏味的感觉，日新月异的自动化技术和不断产生的问题与系统测试结合也让大家更有解决问题的欲望，在繁琐的测试工作中更容易收获一些乐趣和成就感。（c）避免手工易犯的错误虽然测试人员普遍比较耐心细致，但是偶尔的错漏总是难免的，笔者参照自己平时的工作总结了了一下，对于笔者来说主要有以下几种导致错误的因素： 正确率总会有极限，就是说测试执行的时候可以细心一万次，也总会有那么几次是不小心就忘了一些什么东西，导致测试结果偏差； 注意力被其他事物所分散，尤其在并行任务较多的时候很容易发生考虑不周全或者忽视了一些比较隐蔽的问题； 不够耐心细致，上节说到反反复复的测试，或者受心情影响，使得测试人员产生懈怠的状况，这样测试出来的结果很难保证就是没有问题的； 思维定势，长期的工作习惯和对某些系统较为熟悉的时候容易产生问题，按照自己的经验去判定一个测试结果的正确性；而实际上一些隐藏的问题在这种情况下较容易被忽视。当然，手工容易发生错误的情况肯定不止笔者说的这几种情况，大家可以自己参照一下自己平时的经验，看看都会遇到一些什么样的场景。这些列举的问 题如果出现在测试分析和设计的时候自动化是很难替我们避免的，即使有严格的评审机制也不能保证就可以完全避免，所以这里主要是指测试执行的时候。（d）应对高频的构建测试持续集成和敏捷开发这两个概念大家应该都不陌生，它们对测试的要求基本是一致的：快速、可靠、简单！因为在这种模式下，版本移交的频度很高，如 果使用传统的手动测试，可能一个版本只测试到三分之一或者更多一些，下一个版本就已经移交到这套测试环境来了，所以要求测试必须很快，显然在同等人力的情 况下，我们在第一点“提高测试执行的速度”中描述的自动化测试的优点是可以选择的上佳手段。可靠，道理同上文所述一致，自动化测试忠实于每一处输入和检查 点，能够逐一列举不符合需求的地方，不会因为人为的变通而隐藏擅自修改带来的问题。简单，是指在构建体系中的测试环节工作要易于操作、易于分析，虽然自动 化本身的实现可能不见得非常简单，但是一旦在持续不断的构建中引入自动化测试的利用，那么测试工作不仅仅快速可靠，而且测试的结果分析和构建的分析也将大 大受益。我们可以在开始这次发布之初一键点击，由构建平台实现代码的归并、打包、移交、自动部署、启动冒烟测试和性能关注点的测试、运行结果分析和构建分 析等工作。这个理念提出来已经有年头了，虽然能够实现“一键”的公司屈指可数，但是可实现“两键”、“十键”的公司却不在少数，当然或多或少存在一些人工 干预的情况。归根结底，如果测试和编码能够无缝结合在一起，构建的速度和频度就可以很大提高，这就意味着软件开发生产力的提升。有一些尝试自动构建平台建设 的公司可能最大的感慨就是：把自动化测试纳入版本构建流程中去实在太不像想象中的那么简单了！后文我们再讨论如何使用自动化测试支持敏捷开发，很显然，自 动化测试对于敏捷开发来说是多么的重要。请注意，这里说的自动化测试并非特指QTP这种基于UI的验证测试，而是包含从单元测试、集成测试到系统功能与性能的所有被自动化实现的测试手 段。事实上，在敏捷测试中，像QTP这种基于UI的自动化测试只是其中的一部分，真正大部分用于驱动开发的测试代码是放在对组件、服务这些底层的代码模块 的测试上面的。单靠QTP或者Selenium这种工具是完全无法支持真正意义上的敏捷开发的。2、避开自动化测试的误区 自动化测试有很长一段时间里被无限妖魔化，说它好的人很多，但是说它不好的人也大有人在，其实这些说法都是基于一种或几种测试工具的使用经验上的：成功 的经验都是相近的，不成功的教训都各不相同。既然失败的原因有很多，那么避免失败的关注点就不会很少，笔者经验、精力有限，简单谈一下自己的看法，同时也 建议大家多到网上搜罗一些关于自动化建设的硕士论文看看，虽然有一点书生气，但是理论导向性基本都是正确的，并且是对我们很有启发效果的。（a）充分信任自动化测试 自动化虽然已经有了二三十年的发展历史，但是很多同事潜意识里还是更愿意相信手工测试的真实可靠性。他们其中一部分认为自动化测试是不错的方法和思想， 但是相比来说机器永远代替不了人的大脑，不够灵活、不懂得变通；另外一部分从根本上就不信任自动化测试所做的测试执行，认为执行结果不可靠，根本无法节约 成本，而且反而会降低测试质量对自动化测试到底怎么看还是受站在什么角度想问题、考虑问题是否全面等因素的影响。这些不看好自动化 的想法很可能是来自没有自动化实践经历的凭空想象或者是有过失败的自动化经历；他们这种失败的经历中自动化测试没有选取合适的应用范围、方法不得当所占比 重非常大，并且他们在失败之后没有进一步思考，没有总结出这些导致失败的诱因。比如，认为不够灵活的往往是因为要求太高而技术实现又达不到预期；为什么想 要变通呢？想必是因为需求没有达到足够细致的程度，测试设计太模糊从而导致执行实际结果很容易产生一定的偏差：如果测试分析、设计上下了足够的功夫，那么 所谓的变通是完全不必要的。自动化测试脚本或者工具为什么要替代人的头脑呢？换个角度思考一下，被测系统是否达到了替代人脑的功能呢？当然没有！自动化测 试只是在对被测系统进行操作，每一处验证点的检查都是针对系统的设计和实现进行的，从根本上说，如果被测系统无法替代人脑的存在，自动化测试也没有这个必 要去考虑所谓的“替代人脑”的问题。另一方面，大家可能也会这样的忧虑：我们的测试脚本运行通过就一定能够保证系统没有缺陷么？一次构 建上运行通过之后还可能再同样的构建上发现新的问题么？其实这种担忧不是没有道理的，说明大家注重的还是测试本身，没有偏离测试主题，不过大家这种担心的 情况是可以通过一些手段去避免的。因为测试检查点如果在测试设计的时候被明确并且在测试脚本开发的时候被认真实现的话，自动化将比人的手工测试更加忠于我 们既定的判断规则，所以对自动化测试的可信度我们是没有必要去怀疑的，当然它所依赖的前提是测试设计和自动化脚本开发的正确性。对自动化测试作用的彻底信任是自动化测试开始的必要条件，抱着半信半疑的态度去尝试只会带来很多的困扰。犹犹豫豫地总是怀疑自动化测试是否值得很可能就会导致人力投入、其他设备资源支持上的问题，认识上的误差尤其是管理者的误解会给自动化的策略和发展带来很大的障碍。不要把自动化作为一种资本或者实力的体现，从项目管理的角度来说，它只是在测试过程中实现测试周期调控和测试质量把控的手段而已，而在整个测试过程中是起到辅助手工测试的作用还是主导着测试主要是看自动化使用的水平和程度。（b）理解自动化开发模式前面也谈到开发模式略有不同，测试自动化开发也随着不一样，一般说来自动化开发有下面几种模式，我们来看下他们各自的特点。 超前式，在项目设计编码的同时就开始了自动化脚本开发，依赖系统开发过程中的高度复用；是一种比较先进的自动化设计开发模式，能够在系统移交初期就完成自动化开发，并且得到很好的应用，但是极少有公司能达到这种水平。 尾随式，在系统开发环境紧随编码进度去做自动化的开发，需要投入人力较多，开发进度稍滞后与系统编码进度，但是总体来说测试开发、调试完成之后还是能够得到较好的应用。 基线式，在SIT或者FAT完成之后的某个较为稳定的版本上进行自动化脚本、程序的开发。开发的时候需要有一套独立的自动化开发环境（也可以是测试环境），界面比较稳定；但是在后期需要同步更新的地方较多，测试运行基本只能够应用在ST的冒烟测试和回归测试。这几种只是几种相比其它方 式较为正常、普遍的模式，在第一、第二种模式里，比较容易出现的问题是没有满足相应的条件又去使用对应的自动化开发方法；比如在第二种方式里人力投入较 少，那么自动化开发进度可能严重滞后，并不能达到预期的效果，这在第一章已有阐述。基线式最常见的问题是在测试过程中不断的更新项目版本，在不断更新的项 目版本上进行不断地进行自动化更新。从表面上看这种操作没有什么问题，可实际上系统开发过程中有缺陷修复带来的反反复复，UI变动也存在A-B-C-A的 过程。由于测试脚本开发较晚，这种测试运行基本只能够应用在ST的冒烟测试和回归测试，中途的更新并不能带来什么实际的好处，不断地随项目版本的变更去进 行自动化的更新反而会消耗更多的时间和人力。我们经常听到的是：“这个系统不适合做自动化测试”这种说法，究其原因，却是因为变更（需求）太多导致的。同 时这种不适合做自动化的抱怨也是一种误解，只要调整对应的自动化开发策略，问题还是能够得到一定程度上的缓解的。那有些同事可能说“刚 经过SIT或者FAT的版本和经过ST的版本有着天壤之别，后期的更新可能跟重新开发消耗一样的时间和人力，那最初的自动化开发不是一种浪费吗？！”很简 单，拿出需求规格来看看，为什么有这么多的变更呢？这些变更如果没有对应的流程记录，那毫无疑问项目经理或者你的直接主管要为这么多的人力浪费买单；如果 有已经明确知会的变更，那么请记得在自动化开发过程中要跟踪每次变更，同步更新测试需求和自动化开发需求。软件开发成熟度评估标准中有一项是对需求管理的指标，上文之所以强调软件开发成熟度对自动化的影响，其中一部分原因就在这个地方了。另一方面，要相信技术还是可以解决相当一部的变更带来的问题的，完善的体系和框架能够让自动化开发尽可能少的受不必要的变更的影响。（c）明确测试角色资源组合理的自动化设计过程会给自动化开发带来很高的效率和可维护性，能够节约大量的自动化成本，而没有组织的自动化经常会出现反复开发、维护成本高、运行不稳定、扩展性不够好的问题。笔者根据自己的经验总结，自动化开发过程中应该有如下几种角色：1）测试负责人/测试经理统筹整个系统的测试管理，负责测试进度和测试出口、入口的掌控，对整个系统的测试时间、质量和人力负责，属于统筹管理角色。对于自动化测试来 说，测试负责人要制定自动化测试的计划、协调自动化测试所需要的各方面资源，为测试自动化的实现提供基础设施的保障并且对自动化开发进度进行监督。2）框架设计者/架构师负责自动化测试工具选型、测试框架的搭建，为自动化测试过程中遇到的各种问题提供技术支持并且进行总结，提供技术培训，对测试框架以及测试工具 的缺陷进行修复。一般情况下他们还对测试环境要有一定管理权限，让自动化测试使用的开发、测试环境稳定运行以保证自动化测试的进度和测试结果的可靠性。3）测试用例设计人员负责手工测试用例、场景的设计，规划测试流程和测试数据的使用。测试用例设计要求描述足够细致清晰，操作内容和预期结果可衡量，不可模棱两可。 一般情况下，如果自动化测试开发在手动测试成功执行过之后才开始并且手动测试设计和自动化测试开发角色不是同一个人的话，这样的要求对自动化开发的意义就 是很大的。因为手动测试设计的足够详细，自动化实现人员才能读得懂，否则开发过程中的沟通成本将非常大。此外，自动化开发人员应该和手动测试设计人员一起 对被测业务流程的规划做一个review，用这种手段尽可能的节省自动化开发的工作量并且兼容到尽可能多的测试场景覆盖。尽管有些情况下这两个角色是同一 个人，我们也有必要弄清楚核心所在：在当前的软件开发技术水平上，（手动）测试设计才是测试的核心，而自动化只是一个手段而已。4）测试脚本开发人员脚本编写人员，也就是被大家称作自动化测试工程师的人，负责脚本编写。这个角色需要有一定的编码基础，有良好的理解力和沟通能力，依据测试设计 人员提供的思路并且参照框架设计和相关的规范完成自动化的测试程序开发。测试脚本开发的规范笔者此处不提，只强调一点：对手动测试用例中的每个操作步骤的 预期结果的check都要实现，想必大家经常发现有某个脚本总是运行通过但事实上对应的功能存在缺陷的情况吧，这就是自动化测试开发质量不高所导致的。所 以对自动化测试脚本开发人员来说，更重要的素质是能够按照测试用例设计去实现每一个步骤的自动化操作和结果检查的能力，而并非测试框架开发的能力，想必这 一点在诸位心里不见得能够得到认同吧；不要紧，总有一天大家都会认同我的。5）测试平台管理人员负责测试框架、平台的管理和维护，对测试执行平台和框架的稳定运行负责，并且有些情况下还负责自动化测试资源的调配和测试任务优先级的评估。因 为这个角色对测试运行软硬件环境比较熟悉，所以他应该在测试设计和自动化开发的时候提供与环境信息相关的意见，并且在测试程序交付使用的时候进行检查，以 保证不会因为测试脚本的非法操作破坏测试平台和框架的稳定性。（d）不为自动化而自动化无论是项目测试还是运营测试中，自动化测试的目的是测试而不是自动化，自动化测试应该是先进的测试手段，是提高测试质量、测试速度的手段，而并不是单纯为了技术研究而做的事情。在这一点上犯形式主义错误的人和事屡见不鲜，笔者总结有以下三种情况： 主观上崇拜技术，只是为了要证明自己有做自动化测试的实力，进行自动化的出发点错误。把自动化测试技术作为第一要义，不注重测试的需求内容，盲目追求测试 自动化实现的华丽程度，但事实上没有给系统测试做太多的贡献。费时费力并不可怕，可怕的是费时费力之后却没有得到应该得的东西；你可以鼓吹自己的自动化平 台、技术多先进，但是却没有资格对别人说自己的自动化能来带什么样的收益。例如有很多人在有QC和QTP的情况下，喜欢舍近求远，放弃QC的预留接口和它 与QTP之间非常好的兼容性，另起炉灶去开发难度较大的测试框架。这样技术投入上消耗了更多的资源，但是效果却并不一定有已有的东西好。 偏离测试主旨，长期运作但是没有实际产出物。试想一下，每天成千上万的测试脚本反复运行，但是从未见有发现任何缺陷或者从来就没有对“每日回归”发现的缺 陷进行统计分析，这是一种什么概念？我们缺失了一个重要的环节：对当前版本上运行结果的分析。其实高频度的运行涵盖两个方面，一是冒烟测试，这是版本每次 发布测试环境之后的运行，另一个是回归测试，也就是版本定版之前的运行。那么有可能哪个版本移交过来之后就没有缺陷么？当然几乎没有！既然有缺陷，那么自 动化运行失败而置缺陷不理，一味追求测试脚本的修复、更新又是所谓何来呢？那只能理解为你只求把自动化的运行用在回归测试上，但事实上回归测试的时候版本 基本已经稳定，一般自动化运行是很难发现什么问题的。最终自动化测试成了回归测试时增加测试人员信心的手段，目的只是为了证明没有缺陷，而不是争取发现缺 陷，这也就从根本上偏离了测试的主旨。如果能形成每次运行之后的报告分析机制，那么种情况或许能够得到改善，缺陷提交是自动化做的，缺陷关闭是版本移交生 产必须做的，这样卡住过程的首尾，自动化测试方能起到它该起的作用。 剥离手工测试和自动化测试，没有立足系统测试本身，有些人潜意识里可能认为自动化技术含量比较高，手工测试技术含量低。由于这种“高低”之分，或许是为了 管理方便，很多公司把负责自动化测试开发的同事和手工测试的同事从行政上划分开来，组成自动化测试组或者自动化测试技术支持组。据笔者观察，专职负责自动 化的同事在自动化开发时候容易产生自我意识，按照自己对系统操作逻辑的理解去编写测试脚本，而不是严格按照系统测试用例的操作步骤去实现。这样容易导致没 有准确的操作异常处理甚至操作本身就是错误的，在运行发生错误需要开发协助的时候很耗费沟通时间。如何避免这样的情况呢？自动化脚本评审！评审不单包含编 码规范性和框架使用的合法性检查，还要检查对业务操作和容错性、健壮性的实现程度。参与评审的除了框架设计者和自动化测试负责人之外还必须要有SA/BA 和系统测试用例设计人员甚至被测系统编码人员，由他们对脚本的内容做检查的重要性要比框架设计者和自动化测试负责人所做检查的重要性大的多。（e）不过分地追求覆盖率本章开头举了个25和52的例子，这个例子里，如果能实现100%的自动化测试，那么测试执行周期就会更短，看起来更能体现自动化测试的优 越性。不过自动化覆盖程度也是要和自动化开发的投入挂钩的，覆盖率越接近100%，需要的投入也就越多，并且有些自动化模式下这种投入产出不以线性关系呈 现。为了论述简单，我们不妨先定义几个概念： 自动化覆盖率：自动化运行场景数除以所有测试场景数，而并非自动化测试开发完成的案例数除以总案例数； 自动化完成率：自动化测试脚本个数除以所有测试案例个数； 狭义的自动化收益：是指自动化测试运行总次数乘以每次运行的总时间减去测试开发投入的总时间，这也是经常被大家所津津乐道的“自动化效益”。首先，在业务场景覆盖方面，对于简单的录制、回放来说，本身运行的稳定性已经很难保证，加上脚本的复用程度非常低，所以要达到较高的覆盖率是要 投入非常多的自动化开发人力的，所以自动化覆盖率本身就很难达到一个较高的水平。而无论是数据驱动还是关键字驱动，自动化场景的覆盖率都比较依赖测试数据 的覆