走出自动化软件测试的乌托邦
TIB自动化测试工作室成员 刘毅 倾力作品《走出自动化软件测试的乌托邦》
完整PDF版本下载地址：
目录
目录... 2
第一章 引言... 2
第二章 识别测试模式和自动化准入... 4
1. 产品、项目测试和运营测试... 4
(1) 浅析三种测试模式的异同... 4
(2) 对自动化测试的要求浅析... 5
(3) 测试模式之外看拿来主义... 7
2. 自动化测试与软件系统开发... 8
(1) 明确且严格遵循框架需求... 8
(2) 与软件开发成熟度的关系... 9
(3) 足够的资源和可控的需求... 10
第三章 自动化测试目的和常见问题... 11
1. 自动化能满足我们什么... 11
(1) 提高测试执行的速度... 11
(2) 避免机械式重复工作... 11
(3) 避免手工易犯的错误... 11
(4) 自动化最根本的目标... 12
2. 避开自动化测试的误区... 12
(1) 必须信任自动化测试... 12
(2) 了解测试开发的模式... 13
(3) 莫为自动化而自动化... 13
(4) 不要过分追求覆盖率... 15
第四章 自动化测试管理和成效分析... 17
1. 如何理解自动化测试框架... 17
2. 测试自动化框架元素管理... 18
(1) 测试规范管理... 18
(2) 测试资源管理... 19
(3) 测试调度管理... 20
(4) 测试对象管理... 22
(5) 测试组件管理... 23
(6) 测试数据管理... 23
(7) 公共函数管理... 26
(8) 异常恢复管理... 27
(9) 统计分析管理... 31
3. 自动化测试成本收益分析... 32
(1) 真正的成本降低来自何处... 32
(2) 影响成本收益的关键因素... 34
附录：笔者的牢骚和现世报... 38
第一章 引言
若论起自动化测试来，可真是一千人有一千个说法，分歧争议多多，而剪刀石头布在这并不能解决任何问题。举例来说，对于“商业主义”和“开源主义”之争，则可以引用邓大爷的一句话来概括：不管是黑猫白猫，抓到老鼠就是好猫！在这个问题上，大部分的分歧都是因为想把自己的价值观和经验强加给别人，或许他们根本就没有仔细考察过别人的需求，没有弄明白别人为什么坚持不使用自己推崇的工具，泛泛空谈而已！无论是商业工具还是开源工具，自动化测试都应该有着完整的体系流程，可以细化研究，却不可因测试工具不同而在管理上区别对待。就像整数包含正数、负数，也包含质数、合数，但是在做加减运算的时候却不需要也不能够去做这么多维度的划分。类似的道理，无论是商业工具还是开源工具，它们应该都有相同或相似的测试框架和流程、规范，否则自动化测试只能依赖较强的个人能力去维持，而过于依赖个人能力对于组织来说则不具备稳定性和可靠性，对持续发展是不利的。最近看新版三国，不如捎带编个顺口溜：人中吕布，仅三姓家奴；恩义持国，得上将锦蜀！
就对工具和测试手段的态度来说，笔者始终坚信人才是制胜的决定性因素，不要轻言任何工具有多好或多不好。有人认为商业工具的对象与方法封装的很死，二次开发没有开源工具那么随心所欲；有人认为开源工具使用起来编码难度更大、缺陷也多，只有少数的几个人能精通，很难在组织内推广。其实我们可以考虑一下：
（1） 有些人主张自动化只用来进行单元测试和集成测试，以追求更多的效益，那么请问我们平常需要做多少抛开页面的接口测试？而且这些接口测试难道不能、完全不能通过页面去测试么（如开发接口模拟器）？大量UI需要（自动化）测试的现实可以被忽略么？
（2） 有些人喜欢把不成功的自动化实现迁怒于测试工具，请问你的工具使用起来效果不好问题在哪里？你们是否已经把这个你觉得不好用的工具用到极致了呢？你的问题是否只是脚本写的不好而已呢？如果是这样，那么A语言用不好，莫非B语言就更容易么？
总之，不要因为商业工具用的失败就去追求开源，也不要因为开源工具用得不方便就去追求商业工具，必须先弄清楚自己为什么用的不好，问题在哪里，如何改进！盲目的赶潮流倒是能积累很多经验，但同时也势必会给组织带来无谓的资源浪费。当然，如果已经在一种工具和平台下达到了较成熟的测试水平，那么再引进一些其他的工具技术来丰富一下自己的测试也是可取的。
笔者只有四年的Web（自动化）测试经验，主要使用的是Mercury系列商业测试工具，故而所谈论的一些内容主要都是以自己的经验认识为基础的。不过笔者相信做任何事情原理本质上是相通的，而且我们讨论的自动化测试的原理都是基于测试基础理论和项目管理基础理论。笔者不敢标榜自己“精通”或“谙熟”自动化测试，只是觉得有想法就要适时总结，与大家探讨、分享。笔者本文只讨论理念，不讨论技术，只希望通过本文的探讨可以整理一下自己长久以来在自动化测试上混乱的思路，也希望笔者的观点不要成为束缚大家思维的罪恶黑手或者任何人说教的依据，“抛砖引玉”可，“抛砖引砖”亦可，希望诸位读者不吝赐教。
为了不让读者为了这么又臭又长的文档浪费精力，笔者简述一下本文的核心思想：一是弄清楚自己需要什么样的自动化再去做自动化，二是如何避开在做自动化的时候因误解而带来的阻力，三是自动化应该通过科学的管理来解决技术（包括框架）和人才储备的问题，四是自动化的成本效益可以站在更高一些的层次上来看。
第二章 识别测试模式和自动化准入
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的组织一般不具备稳定的开发环境。在这类组织中，项目的成功往往取决于个人的能力和拼搏精神，离开了具备同样能力和经验的人，就无法在下一个项目中获得同样的成功。处于成熟度等级1的软件组织在这种专门化的无序环境中常常也能生产出可以工作的产品，但是，往往伴随着的是项目超过预算和拖延进度。
不用多说，显然1这种成熟度级别是无法进行自动化测试的，因为如果无法保证稳定的开发环境，完全依赖某些人的个人能力，自动化测试是绝对无法持续进行的。
一个软件组织如果达到了成熟度等级2的各个过程方面的全部目标，就意味着该软件组织已经确保有关的过程在项目一级得到策划、被形成了文件、得到执行、受到监督和控制。在这一级上，项目要达到针对过程确定的诸如成本、进度和质量目标之类的具体目标。
成熟度2级看起来就已经具备了自动化开发、测试的条件，没有什么能够太过制约自动化测试平台的搭建，不过：
在第2级与第3级之间的一个重要差别在于标准、过程描述和规程的适用范围。在第2级成熟度等级上，标准、过程描述和规程可能只在过程的某个特定事例中使用，例如在某个具体项目上使用。在第3级上，项目用的标准、过程描述和规程是从组织过程财富剪裁得来，整个组织执行的过程是一致的，这些标准、过程描述和规程通过己定义过程在整个组织的各个项目使用。
这表明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个小时的人是集中型的人。
第三章 自动化测试目的和常见问题
1. 自动化能满足我们什么
自动化能做什么事情原本是个很古老的命题，基本所有人都知道，而且也有很多人对这一点进行过论述和论证。所以这里不再多说，只为讨论问题的完整性简单进行阐述，以便读者在阅读和思考或讨论的时候能更好的上下文衔接。
(1) 提高测试执行的速度
毫无疑问，无论使用什么工具，自动化测试执行是使用机器部分代替人工执行的方式，10人日的测试执行工作量可以由5个人花2天也可以2个人花5天完成。自动化如果实现了80%，那么使用2个人1天可以完成剩下的20%手工测试；用一台PC Server组装10套虚拟系统，10套虚拟系统0.8甚至0.5天就可以完成所有这些自动化的测试执行。不考虑自动化开发的投入，还是2个人，1天就能完成所有的测试执行，所以说自动化测试提升执行速度真正的意思是使用同等的执行人力可以结合自动化在最短时间内完成测试执行，而并非说自动化的操作速度比人工快。
(2) 避免机械式重复工作
虽然测试有像正交覆盖这样被证明了是科学的裁剪方法，但是一方面这些裁剪方法并不是所有的地方都能使用，再者即便都能用测试执行的工作量还是非常大的。无论是多有耐心的测试人员，在长期的测试执行中也会感觉疲惫和乏味，当然有些自制力比较强的同事还是能坚持下来的。自动化测试的好处就在于能替代人去做一些反反复复的工作，可以不眠不休不厌倦；这样可以解放出一部分测试执行人员，让他们向更需要他们的地方成长、发挥。
特别是对于像我们这样做运营测试的同事来说，可能会有几年只负责测试某一个或几个系统的补丁需求的情况。自动化让大家可以腾出手来做更多的分析工作，一定程度上也能通过提高测试分析设计的投入来提升测试的质量；同时也能让测试人员减少一些乏味的感觉，日新月异的自动化技术和不断产生的问题与系统测试结合也让大家更有解决问题的欲望，在繁琐的测试工作中更容易收获一些乐趣和成就感。
(3) 避免手工易犯的错误
虽然测试人员普遍比较耐心细致，但是偶尔的错漏总是难免的，笔者参照自己平时的工作总结了了一下，对于笔者来说主要有以下几种导致错误的因素：
1、 正确率总会有极限，就是说测试执行的时候可以细心一万次，也总会有那么几次是不小心就忘了一些什么东西，导致测试结果偏差；
2、 注意力被其他事物所分散，尤其在并行任务较多的时候很容易发生考虑不周全或者忽视了一些比较隐蔽的问题；
3、 不够耐心细致，上节说到反反复复的测试，或者受心情影响，使得测试人员产生懈怠的状况，这样测试出来的结果很难保证就是没有问题的；
4、 思维定势，长期的工作习惯和对某些系统较为熟悉的时候容易产生问题，按照自己的经验去判定一个测试结果的正确性；而实际上一些隐藏的问题在这种情况下较容易被忽视。
当然，手工容易发生错误的情况肯定不止笔者说的这几种情况，大家可以自己参照一下自己平时的经验，看看都会遇到一些什么样的场景。这些列举的问题如果出现在测试分析和设计的时候自动化是很难替我们避免的，即使有严格的评审机制也不能保证就可以完全避免，所以这里主要是指测试执行的时候。
(4) 自动化最根本的目标
上文分别说了自动化的三个最为明显的好处，还有一些其他的好处我们就不继续讨论了。虽然自动化测试有这么多好处，但是我们自己到底需要自动化做什么呢？其实还是经典的三个要素：成本、时间、质量；质量不用多说大家也理解，就是避免一些人工容易犯的错误。至于时间，因为执行速度可以得到提高，所以某些测试的周期可以得到控制，比较成功的实践甚至可以大幅缩短测试周期。而成本，这里很笼统的说“成本”二字而并非人力成本或者时间成本，因为好多人把自动化的这点作用理解为节省人力、节省时间，对于测试来说，成本不仅仅是测试人力和测试时间这两点。如果把测试与项目与部门、公司的整体利益孤立开来或许可以这么说，但是测试并不能随意与这些因素割离，因为联系是普遍的，请见第三章第3节阐述。
2. 避开自动化测试的误区
(1) 必须信任自动化测试
自动化虽然已经经历了10来年的发展历史，但是很多同事潜意识里还是更愿意相信手工测试的真实可靠性。他们其中一部分认为自动化测试是不错的方法和思想，但是相比来说机器永远代替不了人的大脑，不够灵活、不懂得变通；另外一部分从根本上就不信任自动化测试所做的测试执行，认为执行结果不可靠，根本无法节约成本，而且反而会降低测试质量……
对自动化测试到底怎么看还是受站在什么角度想问题、考虑问题是否全面等因素的影响。这些不看好自动化的想法很可能是来自没有自动化实践经历的凭空想象或者是有过失败的自动化经历；他们这种失败的经历中自动化测试没有选取合适的应用范围、方法不得当所占比重非常大，并且他们在失败之后没有进一步思考，没有总结出这些导致失败的诱因。比如，认为不够灵活的往往是因为要求太高而技术实现又达不到预期；为什么想要变通呢？想必是因为需求没有达到足够细致的程度，测试设计太模糊从而导致执行实际结果很容易产生一定的偏差：如果测试分析、设计上下了足够的功夫，那么所谓的变通是完全不必要的。自动化测试脚本或者工具为什么要替代人的头脑呢？换个角度思考一下，被测系统是否达到了替代人脑的功能呢？当然没有！自动化测试只是在对被测系统进行操作，每一处验证点的检查都是针对系统的设计和实现进行的，从根本上说，如果被测系统无法替代人脑的存在，自动化测试也没有这个必要去考虑这个问题。无法节约成本的看法是因为不懂得自动化的成本效益如何分析，一味的单从自动化开发投入时间和运行时长作比较；认为自动化会降低测试质量的看法则是由于不懂自动化测试理论、不懂测试理论导致的。
对自动化测试作用的彻底信任是自动化测试开始的必要条件，抱着半信半疑的态度去尝试只会带来很多的困扰。犹犹豫豫地总是怀疑自动化测试是否值得很可能就会导致人力投入、其他设备资源支持上的问题，认识上的误差——尤其是管理者的误解会给自动化的策略和发展带来很大的障碍。不要把自动化作为一种资本或者实力的体现，从项目管理的角度来说，它只是在测试过程中实现测试周期调控和测试质量把控的手段而已，而在整个测试过程中是起到辅助手工测试的作用还是主导着测试主要是看自动化使用的水平和程度。
(2) 了解测试开发的模式
前面也谈到开发模式略有不同，测试自动化开发也随着不一样，一般说来自动化开发有下面几种模式，我们来看下他们各自的特点。
1、 超前式，在项目设计编码的同时就开始了自动化脚本开发，依赖系统开发过程中的高度复用；是一种比较先进的自动化设计开发模式，能够在系统移交初期就完成自动化开发，并且得到很好的应用，但是极少有公司能达到这种水平。
2、 尾随式，在系统开发环境紧随编码进度去做自动化的开发，需要投入人力较多，开发进度稍滞后与系统编码进度，但是总体来说测试开发、调试完成之后还是能够得到较好的应用。
3、 基线式，在SIT或者FAT完成之后的某个较为稳定的版本上进行自动化脚本、程序的开发。开发的时候需要有一套独立的自动化开发环境（也可以是Staging环境），界面比较稳定；但是在后期需要同步更新的地方较多，测试运行基本只能够应用在ST的冒烟测试和回归测试。
这几种只是几种相比其它方式较为正常、普遍的模式，也有一些不为笔者所了解的方法，如果大家能够补充一下就更好了。
在第一、第二种模式里，比较容易出现的问题是没有满足相应的条件又去使用对应的自动化开发方法；比如在第二种方式里人力投入较少，那么自动化开发进度可能严重滞后，并不能达到预期的效果，这在第一章已有阐述。基线式最常见的问题是在测试过程中不断的更新项目版本，在不断更新的项目版本上进行不断地进行自动化更新。乍一看这种操作没有什么问题，可实际上系统开发过程中有缺陷修复带来的反反复复，UI变动也存在A-B-C-A的过程。由于测试脚本开发较晚，这种测试运行基本只能够应用在ST的冒烟测试和回归测试，中途的更新并不能带来什么实际的好处，不断地随项目版本的变更去进行自动化的更新反而会消耗更多的时间和人力。我们经常听到的是：“这个系统不适合做自动化测试”这种说法，究其原因，却是因为变更（需求）太多导致的。同时这种不适合做自动化的抱怨也是一种误解，只要调整对应的自动化开发策略，问题还是能够得到一定程度上的缓解的。
那有些同事可能说“刚经过SIT或者FAT的版本和经过ST的版本有着天壤之别，后期的更新可能跟重新开发消耗一样的时间和人力，那最初的自动化开发不是一种浪费吗？！”很简单，拿出需求规格来看看，为什么有这么多的变更呢？这些变更如果没有对应的流程记录，那毫无疑问项目经理或者你的直接主管要为这么多的人力浪费买单；如果有已经明确知会的变更，那么请记得在自动化开发过程中要跟踪每次变更，同步更新测试需求和自动化开发需求。软件开发成熟度评估标准中有一项是对需求管理的指标，上文之所以强调软件开发成熟度对自动化的影响，其中一部分原因就在这个地方了。
(3) 莫为自动化而自动化
无论是项目测试还是运营测试中，自动化测试的目的是测试而不是自动化，自动化测试应该是先进的测试手段，是提高测试质量、测试速度的手段，而并不是单纯为了技术研究而做的事情。在这一点上犯形式主义错误的人和事屡见不鲜，笔者总结有以下三种情况：
1、 主观上崇拜技术，只是为了要证明自己有做自动化测试的实力，进行自动化的出发点错误。把自动化测试技术作为第一要义，不注重测试的需求内容，盲目追求测试自动化实现的华丽程度，但事实上没有给系统测试做太多的贡献。费时费力并不可怕，可怕的是费时费力之后却没有得到应该得的东西；你可以鼓吹自己的自动化平台、技术多先进，但是却没有资格对别人说自己的自动化能来带什么样的收益。例如有很多人在有QC和QTP的情况下，喜欢舍近求远，放弃QC的预留接口和它与QTP之间非常好的兼容性，另起炉灶去开发难度较大的测试框架。这样技术投入上消耗了更多的资源，但是效果却并不一定有已有的东西好。
2、 偏离测试主旨，长期运作但是没有实际产出物。试想一下，每天上万的测试脚本反复运行，但是从未见有发现任何缺陷或者从来就没有对“每日回归”发现的缺陷进行统计分析，这是一种什么概念。按理说能进行每日回归并且我们这种几近无甄选的“每日回归”是非常强大的，即便是大家津津乐道的持续集成中的高频度构建也是能支持的；但是我们这里缺失了一个重要的环节：对当前版本上运行结果的分析。其实高频度的运行涵盖两个方面，一是冒烟测试，这是版本每次发布Staging之后的运行，另一个是回归测试，也就是版本定版之前的运行。那么有可能哪个版本移交过来之后就没有缺陷么？当然几乎没有！既然有缺陷，那么自动化运行失败而置缺陷不理，一味追求测试脚本的修复、更新又是所谓何来呢？那只能理解为你只求把自动化的运行用在回归测试上，但事实上回归测试的时候版本基本已经稳定，一般自动化运行是很难发现什么问题的。最终自动化测试成了回归测试时增加测试人员信心的手段，目的只是为了证明没有缺陷，而不是争取发现缺陷，这也就从根本上偏离了测试的主旨。如果能形成每次运行之后的报告分析机制，那么种情况或许能够得到改善，缺陷提交是自动化运行失败必须要做的，缺陷关闭是版本移交生产必须做的，这样卡住过程的首尾，自动化测试方能起到它该起的作用。
3、 剥离手工和自动化，没有立足系统测试本身，有些人潜意识里可能认为自动化技术含量比较高，手工测试技术含量低。由于这种“高低”之分，抑或是为了管理方便，很多公司把负责自动化测试开发的同事和手工测试的同事从行政上划分开来，组成自动化测试组或者测试技术支持组。据笔者观察，专职负责自动化的同事在自动化开发时候容易产生自我意识，按照自己对系统操作逻辑的理解去编写测试脚本，而不是严格按照系统测试用例的操作步骤去实现。这样容易导致没有准确的操作异常处理甚至操作本身就是错误的，在运行发生错误需要开发协助的时候很耗费沟通时间。对于这样的情况：
a) 首先，自动化脚本要经过严格的评审，不单包含编码规范性和框架使用的合法性检查，还要检查对业务操作和容错性、健壮性的实现程度。参与评审的除了有测试架构师、框架设计者和自动化测试负责人之外还必须要有SA和系统测试用例设计人员甚至业务系统设计、编码人员，由他们对脚本的内容做检查的重要性要比框架设计者和自动化测试负责人所做检查的重要性大的多。
b) 其次，笔者个人不建议把懂得或者擅长自动化测试开发的人都统一放到一个分组中再去支持每个系统、项目的自动化开发；如果需要组建测试架构、技术支持组，选择一两个或少数几个自动化测试技术较好、大局意识较强的同事加入就可以了，其他的能够参与自动化开发的同事还是归属各自的行政分组或者项目组。
c) 最后，不建议给自动化开发的人冠以“自动化测试工程师”的头衔，笔者觉得非常有必要扭转一下“自动化至上”的风气。要让大家明白，自动化测试技术只是测试技术中必备的一种，而不是能够凌驾于测试基础理论和丰富的测试经验之上的东西；同时要有相应的考核指标，对参与自动化测试的同事有一个客观的评价，对他们的技术水平和贡献度进行评定。
(4) 不要过分追求覆盖率
本章开头举了个2×5和5×2的例子，这个例子里，如果能实现100%的自动化测试，那么测试执行周期就会更短，看起来更能体现自动化测试的优越性。不过自动化覆盖程度也是要和自动化开发的投入挂钩的，下面这个图是笔者根据自己的经历、感受描绘的，这里不讨论其科学性，意思很简单：覆盖率越接近100%，需要的投入也就越多，并且不以线性关系呈现。不过这不是针对所有的系统，比如查询、报表类的系统就是很接近直线的一种趋势。
为了论述简单，我们姑且认为人力、技术投入和自动覆盖率的下图这种关系是正确的，持否定态度的请稍安勿躁。如果有些同事认为曲线走势有少许偏差那么请忽略之，这无伤大雅；如果认为是直线或者开口朝下的右半抛物线那只能说明咱们的经历实在相差太远，您就姑妄听之、看之。另外，我们不妨先定义几个概念：
- 自动化覆盖率：自动化运行场景数除以所有测试场景数，而并非自动化测试开发完成的案例数除以总案例数；
- 自动化完成率：自动化测试脚本个数除以所有测试案例个数；
- 狭义的自动化收益：是指自动化测试运行总次数乘以每次运行的总时间减去测试开发投入的总时间，这也是经常被大家所津津乐道的“自动化效益”。
（图一） 人力、技术投入与自动化覆盖率之间的关系
首先，在业务场景方面，对于简单的录制、回放来说，本身运行的稳定性已经很难保证，加上脚本的复用程度非常低，所以要达到较高的覆盖率是要投入非常多的自动化开发人力的，所以自动化覆盖率本身就很难达到一个较高的水平。对于数据驱动和关键字驱动层次的自动化来说，自动化场景的覆盖率比较依赖测试数据的覆盖率。在业务操作和数据分离之后，流程、场景的组合相比较低层次的录制、回放更加灵活；测试数据准备的足够全的情况下，业务场景的组合将足够丰富，带来的覆盖率更高。第一个矛盾在于对框架设计的要求很高，单个脚本设计平均耗时较多。第二个矛盾在于虽然系统测试提供多少数据就会有对应数量的场景、流程，然而系统测试中并非所有数据都能支持复用或支持数据状态回退操作，所以自动化测试数据准备本身就比较消耗时间。例如保全系统中的保单犹豫期内退保项目的每日回归就需要每天有源源不断的新承保的保单数据产生才能支持该保全项目的自动化测试运行，而新保单承保取决于新契约系统投保功能正常、新契约系统自动化测试运行正常，中间有任何环节出问题则保全系统该项目的自动化测试数据将无法获取得到。这种因实时性要求较高而储备不多的数据准备在手工测试时一般都有一定的缓冲时间；但是自动化却是无法等待的，所以有些时候未必实现了自动化就能一直应用于自动化测试执行，有时候权衡过后，即便是已经自动化的也还是要手工测试的。如果时常受这种数据问题的困扰，那么在受困扰的时候放弃这部分的自动化运行也是可以考虑的，当然牺牲一定的覆盖率，也赢得了灵活性。
其次，在技术难度方面，我们一般不提倡把不是非要在一开始就必须解决的问题放到自动化开发的最初阶段来解决，这样很可能会因为技术卡壳影响开发进度甚至打击测试人员的信心。于是，实现上技术难度偏大的模块和功能很可能会被推后开发，开发计划制定的时候一般也会尽量这么安排，否则计划频频变更可能会难以避免。从而在自动化开发后期，技术攻关几乎成了测试开发人员的主要话题——当然，并不是每个项目都能碰到技术问题。那么在稳定的自动化开发投入持续到遇到技术瓶颈的时候，我们何不考虑一下重新评估这些没有实现自动化的模块、功能是否必须实现自动化呢？如果现有的自动化测试脚本加上手工测试用例执行的总周期能够满足版本发布测试的频度和时效要求的话，那么从项目测试角度笔者建议不要再继续开发，避免消耗更多资源；从运营维护的角度考虑可以暂缓——待系统稳定之后再考虑去解决这些问题。
最后，结合以上两点分析，从理论上推断不难得出下图中自动化收益和自动化覆盖率之间的关系。也就是说自动化覆盖率的提升带来了人力投入的非线性增长，人力投入的非线性增长也带来了自动化收益上的非线性下降，所以自动化覆盖率的线性增长就间接带来了自动化收益上的非线性降低。至于到底是如何的一种非线性关系，各位还是从图中理解吧，笔者那点数学知识早就还给老师了。
（图二） 狭义自动化收益与自动化覆盖率之间的关系
第四章 自动化测试管理和成效分析
自动化不是纯技术问题，也不能孤立的存在，先进的自动化测试依赖先进的测试管理，同时由于自动化也有它自身的特殊性，所以要在现有的测试管理的基础上搭建一套自动化测试管理的平台。自动化管理平台要包含自动化的指标定义和管理、自动化规范制度管理、自动化资源设施管理和自动化的测试框架管理。这些管理工作做好了自动化测试能得到很大的实惠，下文说得这些内容对于已经做得比较好的公司来说看起来比较小儿科，但是笔者知道也有很多公司在这一方面并没有做得很好。其实这些管理工作做到什么程度也能从一定程度上反映一个公司整体的管理水平。
1. 如何理解自动化测试框架
到底什么是自动化测试框架？笔者问了无数人，包括我们自己公司的同事和很多网络上的同仁，每个人都有一套自己的说法；现在流行百家争鸣，但是还没有鸣出个所以然很多人注意力又跑到敏捷测试身上了，什么是自动化测试框架对笔者来说就成了一个悬案。为了写这一节笔者上网查资料查了很久，但是现在，大家怎么理解自动化测试框架笔者已不再关注，毕竟自己所看到的、别人想要表达和别人已经表达出来的很可能就都不是一码事，满足自己的需求才是最重要的，每个人都应该有自己的理解。
- 自动化测试管理框架，偏向于自动化测试的全局架构理论，把自动化测试的各个环节、要素的说明和规范文档化，测试管理结构文件实例化，在没有背离“主旋律”的前提下，自动化可以按照规范要求任意发挥，只要满足测试需求即可。这种框架本身也带有一些基于本公司业务特点和使用需求的其他功能，例如测试运行调度、邮件服务的使用、文件服务的使用和报表分析等等。这种框架在管理上下了较多的功夫，有了成型的架构之后就可以不依赖任何一个技术核心人物，大大降低了技术储备的难度和人员离职带来的风险。缺点是在这种理论指导下若没有相应的商业工具支持，框架开发或二次开发比较费时费力。
- 自动化测试开发框架，典型的代表就是被很多人推崇的QuickTest Pro的自动化测试框架SAFFRON。这种框架的作用就是简化自动化脚本编写，分离业务、脚本操作和数据，自定义封装一些常用的操作，使自动化脚本在业务系统发生变更时更容易维护、开发速度更快。这种框架立意于直接达到关键字驱动的效果，但是如何能与整个测试部门或公司的管理有效的整合在一起却很是问题；对测试管理工作起不了很大的决策支持的作用，很单纯的应用于自动化开发这个动作本身，这种框架笔者觉得有一个更贴切的名字可以给它：自动化测试脚本开发辅助框架。笔者个人理解，关键字驱动和数据驱动的最大区别在于描述性语言的使用上，描述性编程的优势是大幅减少了脚本对页面对象稳定性的依赖。像SAFFRON这种框架的好处也就在于即便页面控件的属性发生了一些变化，在它下面开发的脚本也能继续运行，除非出现逻辑上的不一致。而事实上对于我们的系统来说，上页面元素的变化对我们来说也是一个系统监控点：是什么样的需求让编码人员去做这样的变动呢？带着这个疑问系统测试会做得更细致，如果忽略了这些微小的变更，测试缺陷遗留的风险将有可能会提高。所以两种编程方式各自有着自己的优缺点，从自动化测试脚本维护工作量和脚本灵活性的角度笔者更愿意使用描述性语言，但是从系统测试的可信度和是否足够细致的角度上去考虑，笔者更愿意使用傻瓜式的对象库。
一种是理论化的管理型，它所依赖的基础理论能放之四海而皆准；一种是实际化的开发应用型，能随时在绝大部分项目或系统中应用，加速自动化测试开发。太实则不能通用、无法给测试管理来带更多的便利，太虚则无法落地，让自动化测试工作缺少切合实际的指引，所以我们的理想是理论结合实际：综合一下各自的特征，把两种框架实例化地整合在一起，扬长避短，从而满足我们自身的需求。
反过来仔细考察一下上面描述的两种具有代表性的典型自动化测试框架，我们会发现概念型的框架完全可以把实用型的框架包容在内。因为理论性很强、大局意识和管理支持体现得较多的这种框架除测试规范之外并没有对自动化测试做太多的限制，所以它的包容性很强；而像类似于SAFFRON的这种测试脚本开发框架目的很单纯，就是要在自动化测试技术水平上达到一个较高的层次，他们并没有大的冲突，并且在本质追求上都是一致的：让自动化测试更加快捷方便。我们可以考虑把小的框架封装起来，作为大框架的一个组件来使用，这样并不影响他们各自的长处发挥，并且能够很好的消除各自的弱点。同时很明显，以大框架的包容性是不仅仅只能容纳一个小框架的，那么如果有很多类似的测试开发的好的框架，那么可以进行一定的改造，都纳入到这个大集体中来。这样不同的测试人员的不同编码偏好都能得到照顾，就像在Windows下做一个小游戏到底是用C++去实现还是用JAVA去实现是一样的道理。需要指出的是，不同的测试脚本开发优化型的框架有着不同的特点，对脚本编写人员的技能、测试工具、测试开发环境等因素的要求不一样，引进的时候我们或许会发现它本身存在与整体框架规范冲突的地方，这就是为什么要裁剪或者修改其一部分功能的原因。
百花争鸣是没有问题的，尤其是对一种新事物的探究……众口一词未必是好事，异议多、冲突多说明大家的经历多、需求多，如果从众多的经历和需求中找出共性，稍加提炼，那么或许很快大家的需求就会得到满足。希望所有的人能够从系统测试的实际出发，尽量把视野放宽，不要盲目相信或者排斥他人的观点，多思考，或许你能找到一个真正属于你自己的框架，并且能分享给大家。
2. 测试自动化框架元素管理
自动化测试框架不仅仅是自动化测试技术的体现，它更多的体现为自动化测试管理的文件实例化，我们下面看看我们基于QC+QTP的自动化测试管理框架都包含哪些要素。
(1) 测试规范管理
自动化测试和手工测试是一体的，都要服务于系统测试；既然系统测试有对应的测试规范和流程，自动化同样也是需要规范管理的。我们先看一下没有规范的自动化有什么不妥：
1、 没有规范无法统一监控，较难管理。由于测试人员技术层次不同、工作习惯不同，大家喜欢以自己喜爱的工作方式去开展工作；如果没有统一的规范约束，就容易产生混乱的局面，如大家开发的自动化测试脚本习惯不同、规范性不一致就会导致开发完的脚本很难集中维护，测试自动化实现的深度不同等等因素导致测试质量也很难在过程上得到统一控制等等。
2、 自动化相关的规范能够指引自动化测试工作的方向，明确工作重心，没有它，参与自动化测试的同事可能会偏离这个大方向，做出一些与大局利益不吻合的事情。例如某君在开发自动化脚本的时候为了自己负责的模块脚本编写方便简单，做私自修改框架、不做代码注释、擅自修改测试报告数据等等危害自动化测试科学性与合理性的事情。
3、 重复工作导致资源浪费。没有规范制度指引的情况下，团队的协作很难达到严密合理、彼此之间资源共享、成果复用的效果；反之，这种情况能得到大幅改善，从而能避免测试开发的重复，避免资源浪费。例如A设计自动化测试脚本不喜欢在已有的测试案例上进行，乐于在自己建立的目录下重新保存一个测试脚本，而B在自动化无法运行被迫做手工测试的时候习惯于使用已有目录下的测试案例。那么假设他们的主管现在需要知道他们测试的这个功能点是否被包含在每次冒烟测试的集合里面、是否自动化实现该功能的测试，看到两个目录下的不同的东西不免产生困惑。结果呢？要么A把脚本移植到已有案例上，要么B去把手工测试描述和信息移植到自动化脚本上，总之还是浪费了时间：主管的和他们自己的。
4、 在没有规范的情况下，测试主管对参与自动化测试的同事的考核工作很容易发生争议。由于大家各司其职，如果没有规范的约束，考核中少了对职业技能的考察，单凭KPI的考核是难做到合理二字的，因为系统的复杂程度、关联影响度甚至“政治因素”等都会影响到考核的监控指标。把规范的执行力度和执行规范的效果加入到考核内容中已经成为所有主管的共识，如果没有这部分内容考核就是不完整的了，自动化测试也是。
自动化测试没有自动化测试规范的坏处当然不止这几点，大家可以把坏处往死里想……如果没有对应的规范，那么CMMI也就不可能达到“已定义级”，没有达到这个标准自动化也就是不能轻易开始的，所以从根本上说这就是矛盾的。当然，规范也不是一成不变的，随着自动化测试水平的进步和公司发展的进程，在适当的时候更新规范也是必需的。文档作为框架实例下一个单独的文件目录存在，可以在共享、FTP服务上，也可以存在测试管理工具中。框架下的文档包含测试总体规范、自动化测试流程规范、自动化测试开发规范、框架中每个模块或要素的说明、自动化测试疑难百科和框架下自动化开发应用技能的培训教材等等。这些文档由熟悉自动化的测试架构师和自动化测试相关主管授权或亲自更新，对框架文档的版本管理要严格，最好每次更新都有一个审批流程，并且每一个更新前的版本都做一次备份，以方便将来的回溯查询。
(2) 测试资源管理
前文提到自动化测试资源包含自动化开发和执行工具、自动化开发环境、系统测试环境、测试管理工具、文档服务器、以PC或者虚拟机为载体的执行客户端以及合理的网络、安全策略配置等一系列基础架构资源。这些资源一般与系统测试环境的方方面面存在关联，由熟悉自动化测试的测试架构师负责统一维护与管理。
首先，统一维护的好处是测试架构师可以对自动化运行所依赖的大环境进行改善，降低自动化开发的难度。例如自动化测试运行客户端上文件下载保存时需设置“下载完毕之后是否关闭对话框”，假设50个自动化开发人员有10个在开发的时候由于习惯问题没有注意到这个对话框的存在，那么将会有大量的脚本因脚本自身的场景判断失误而运行失败。这时候如果每个脚本编写者都去修改一下自己的脚本那就太浪费时间了，测试架构师可以直接在执行客户端改一下注册表，这简单易操作得多，会节省很多时间。其次，在资源的使用和协调上必须有一个负责人，如A项目分组有为期3个月的每天一次的自动化运行需求，B项目分组有长期的每次版本移交部署之后立即开始的自动化运行需求，那么如何按照优先级分配资源使用是需要解决的。尤其是在许可证、PC或虚拟机数量等非常有限的情况下处理好这些资源的使用顺序显得更加重要。
对这些自动化测试资源设备的管理办法、规定以及资源本身需要纳入自动化测试整体框架中，资源管理的文档要纳入文档管理，通常这部分的文档应该包含如：资源采购与配置明细清单、资源的使用与配置方法说明、资源申请与归还流程说明等；资源本身可以由环境工程师或测试架构师负责进行管理与分配。资源实际上就是资产，资源管理也就是资产管理，很多公司都有一套自己的资产管理规范，自动化测试框架中可以直接饮用这部分规范，简单而直接。测试管理包含对资源设备的管理是管理更加全面的一种体现，尤其在组织级的规范管理中更应该体现这一点。
(3) 测试调度管理
QTP自动化测试的运行调度方式有很多种，总体来说主要还是以QC提供的Open API使用的最为广泛，下面简单罗列一下几种常见的方式：
- 最为经典的就是QC自带的任务控制工具，使用起来快捷方便，并且QC本身就包含对邮件服务的配置、使用，同时也有着比QTP场景恢复更为宏观有效的异常处理机制，有着灵活的参数配置功能；只是定制并行执行计划比较不方便，由于无法预知每个流程运行的结束时间从而导致后一个流程开始的时间无法确定。这种调度主要使用在多人监管的情况下，多人使用多台机器登录，同时使用QC调度测试任务，否则在批量设置任务的时候比较不方便，容易造成执行冲突或者时间浪费。
- 众所周知，QC给用户留了很多开放的接口，那么还有一种思路就是基于QC预留的Open API重新开发控制工具，结合EXCEL或者数据库表的执行队列统计控制。引入对QC接口的调用，获取QC中指定测试脚本、测试集实例，配置一定的参数去执行，测试结果依然保存在QC中，测试报告依旧可以通过QC的报表系统出具。这种模式的调度控制的好处是可以轻易的批量设置任务，控制执行的先后顺序，通过主机状态的判断就可以判断上一个流程是否运行完毕；能够根据项目和系统的特点定制周期性的工作计划，依据版本部署时间窗口设置定期自动测试执行；同时这样做也保留了QC测试集本身的异常处理机制和灵活的参数配置功能。不同的设计者可以使用各自擅长的语言去开发控制端的图形界面以取得更方便的操作，开发出来的程序可以是CS结构也可以是BS结构。下图（三）是其中的一些简单VBS代码示例，为截图方便已经删除了注释和空行以及对邮件通知等功能的使用，这个示例既不具备BS特性也不具备CS特性，只是一个VBS文件和一个EXCEL文件，这里主要是给大家简单示范一下程序实现的基本原理（其中OpenText是笔者自定义的一个简单加、解密函数、GetCellValue是通用VBS的EXCEL文件读取函数）。目前我们使用的方法是把这个自己用Java开发的自动化运行控制管理系统嵌入到测试报表管理平台中去，把自动化测试管理作为测试管理的一部分，同时也更加方便了自动化测试指标数据的采集。回想起来，我们的这个控制程序也经历了从QC自身到VBS到VB客户端到JSP页面这三个阶段，每一次程序的升级都为整个测试部门的大规模冒烟测试、回归测试调度和统计节省了很多的时间。
图（三）部分基于QC API调度的代码示例
- 最后一种是完全脱离QC，使用VBS或者其他程序直接控制脚本运行，把测试结果统一写入指定的数据库或者EXCEL中去。这是广泛应用于那些没有正式采购QC工具但是使用着QTP进行自动化测试的公司的一种常见的方法，这种做法在工具采购上比较节省，开发出来的程序轻巧灵便，但是管理起来较为复杂、费力。首先对脚本编写要求较高，对测试流程串连的支持不够灵活；其次程序可能不具备通用性，每个系统或者项目需要自己重新开发或者复制代码进行修改，管理起来不是很方便；最后是对测试结果的分析比较费力，如果没有成型的报表系统与之匹配的话，单就分析EXCEL或者数据库表的执行结果记录来说就是一件非常费时费力的事情，要知道重新开发测试分析报表管理平台要达到类似QC这种商业工具的成熟程度是要消耗很大气力的。
(4) 测试对象管理
前文提到，如果在QTP的自动化测试脚本中全部使用描述性编程，那么测试脚本基本可以完全脱离对象库的使用，但是笔者的观点是：如果要放弃对象库的使用而全部采取描述性编程，那么QTP本身基于关键字的脚本录制、编写的优点将消失殆尽，进而也就没有使用QTP的必要了。笔者咨询了几位经验比较丰富的老QTPer，大家一致认为对象库和描述性编程在Web自动化测试脚本开发中的使用比例应该是根据系统特点在7:3到9:1之间。所以，既然使用QTP，那么免不了就要面对它的对象管理问题，描述性编程的确好，不过也不能完全迷信，QTP捕捉的对象的属性要比我们自己描述性编程描述的完整，而且只要配置好对象捕捉的参数，基于对象库的脚本编写还是比较方便快捷的。对象库的管理分为两个层次：
第一层是测试脚本自身的对象库管理，包括对象的收集方法、对象的层次与命名规则、对象的复用粒度等等，笔者要先明确一个思想：对象的妥善管理与复用，能节省很多隐形的自动化投入的时间。例如，同一个页面在不同功能中被多次引用，那么这个页面的对象就应该是公用的，如果某个引用的地方因为需要独立修改而采用复制的方式，那么对象库也要同步分离。QTP对象库的整理可能比较繁琐，有些人可能觉得整理一个被5个脚本调用的公用库所花的时间比重新录制5个脚本所花的时间还多，不值得去做！其实这种想法是不对的，这是完全无视脚本维护成本的做法，说严重点这种做法无异于饮鸩止渴。且不说整理对象库是对象复用的前提，即便不考虑对象库的复用，整理它也是非常有必要的。我们在长期的项目或者系统维护中使用的测试脚本通常会因为脚本自身的原因运行失败，修复一个脚本的耗时可比重新开发1个甚至2个、3个所用的时间，究其原因，绝大部分原因是因为对象库的使用和维护不力，这也是很多经验丰富、技术高超的自动化脚本编写人员更乐意抛弃对象库去使用描述性编程的原因。笔者仔细分析了所在部门很多人编写脚本的特点和“非业务逻辑变更导致运行受阻”的运行成功率，发现对象库层次不清晰、对象命名凌乱的脚本常常运行失败，尤其在脚本数量庞大的时候，脚本修复的时间花费的非常多，一旦修复操作被其他工作延迟，累积的“债务”就会越来越多。面临测试报告中一堆红色的告警，测试人员通常有深深的负罪感，但是短时间内几十、上百个脚本的修复工作也让他们感到绝望，迫不得已只好选择手工执行；久而久之，测试人员面临的问题就是测试脚本的重新开发，这是一个恶性循环。这种严重的重复开发、人力浪费大部分原因来自于对象库，但是这决不是抱怨对象库存在的理由！只要在脚本设计的时候在这方面多投入一些时间，这些问题是完全可以避免的，就是说：也许在前期牺牲一些脚本开发的速度能赢来后期维护的轻松。在自动化测试脚本编写规范里明确指明这一点并且严格执行是目前已知最简单有效的方法，同理，将这部分规范纳入文档管理中的自动化设计开发规范也是必须的。
第二层是框架下的对象库管理，在框架对应的目录下，可以有很多子系统或项目的子目录，每个子系统目录下可以直接存放或者分类存放QTP的对象库文件。测试脚本中单独引用这些对象库而并不把它们合在一起保存，这样就从一个很简单的层次上实现了对象和操作的分离，为脚本设计的关键字驱动打下良好的基础。当然，我们并不需要追求全部脚本与对象的分离，客观地说，可复用对象库有必要和脚本操作分开，不可复用的对象是没必要这么操作的。对于着力追求关键字驱动层次的自动化测试的框架设计，这一步路却是迟早要走的；至于是否有必要去做看似没有必要的整齐划一，IBM360之父Brooks曾经在《人月神话》中兰斯教堂的例子告诉我们：有时候牺牲一些个性来获取组织级的共性是有必要的。
(5) 测试组件管理
什么是组件？上节提到测试脚本的对象可以和业务操作分离，对象可以凭借自动化测试脚本的对象库文件实例化，而操作呢？在自动化测试脚本中可以是VBS文件或者MTS文件或者无论是否自动化测试的用例、用例的步骤，在使用了BPT模块的QC版本里则表现为Business Component，这也正是我们这个基于QC+QTP的自动化测试框架下的业务组件的最好注解。HP声称QC9.5及以后的版本结合QTP就可以很轻松的做到自动化测试的关键字驱动，想必其中的很大一部分原因就在于这个模块的存在了。当然，笔者认为，未必没有BPT这个模块就无法实现关键字驱动，业务组件既然可以体现为测试用例或者测试案例的步骤，那么如果测试用例的粒度足够细，测试用例本身也可以成为替代BPT中Business Component的一种实例。
无论是以什么形式体现，从自动化测试脚本中独立出来的业务组件却是实现自动化测试关键字驱动的第一大要素，因为关键字驱动相比数据驱动来说最突出的一点就是业务组件（足够细致的操作）的独立存在。笔者这里举出BPT的Business Component的用意并非替HP做广告，只是想借助大家都比较熟悉的QC来让大家感知一下组件到底有什么特征。那么组件的特点包含哪些呢？
- 组件是在业务系统中很单一的操作，甚至一般都是没有独立业务意义的，例如一个Button或者Link的Click操作；
- 由于操作粒度非常细小，所以它们的可复用性极高，一般在一个业务系统中可以被普遍引用或调用；
- 业务组件可以依赖商业工具中成型的模块如QC-BPT，也可以使用测试工具开发，以SAFFRON为例，它所封装的Web的一些常用的简单对象的操作可能为大家所熟知。
通过组件的含义和特性，我们知道，一个框架中并非一定有操作组件这个部分的存在；它的作用是提升自动化测试的“成熟度”，用于提升测试开发速度、降低维护成本消耗。根据大家对关键字驱动的一致认识，组件和对象、数据分离是必不可少的，所以，如果要做关键字驱动的自动化测试，操作组件的独立管理是必由之路。
(6) 测试数据管理
测试数据不仅仅是自动化测试的一个重要元素，也是所有类型的测试所共有的一个基本元素，离开测试数据的测试基本上就丧失了它的可靠性与意义。对于自动化测试来说，首先我们需要明确一点：绝大多数脚本与数据共生的自动化测试用例都是不够灵活的，每次更换数据进行测试都要对测试脚本进行修改，这是不方便的、低效的。分离开的测试脚本与测试数据之间体现为一种应用程序和配置文件的关系，数据分离意味着维护成本的降低和灵活性、可移植性的增加。通常自动化测试脚本所使用的测试数据以下面几种方式存在：
1、 文件配置：TXT、XML、HTML等形式的测试执行基础配置，主要用于框架下所使用的各个元素的所在路径引用、管理和运行模式控制。
2、 文件存储：TXT和EXCEL等文件数据，其中TXT多用于复杂的一次性参数传递和基础配置管理，例如相对路径配置等；EXCEL等文件多用于实际的测试数据保存，系统页面上每一个需要参数化的可编辑域和特定的需记录输出值的区域都可以对应文件中规定好的一个字段，保存一条或多条测试数据。
3、 数据源存储：EXCEL、ACCESS和一些商用的数据库（Oracle、SQL Server、DB2、Sybase、Informix等），通过测试工具所支持的对数据源操作的接口进行测试数据的读取和回写。
4、 测试执行管理工具上的参数配置：如QC测试实验室中可配置的测试集案例配置，这种参数可预先定义好也可以在运行时从外部文件导入进行变更。
读者可能会问，为啥EXCEL能够同时存在于文件存储和数据源存储两种方式中呢？其实很简单，操作模式不同：文件存储读写的时候都是通过文件操作的相关函数进行单元格数值的逐个读取和修改，而是用数据源模式则是通过ODBC等方式对数据进行操作，这种模式下一般是采用基于数据库操作的语句或命令进行操作，二者原理不同。
那么这四种方式孰优孰劣呢？笔者的答案是基本没有优劣之分：主要视被测需求、流程特点、测试框架复杂度以及测试资源使用情况而定。至于要如何区分使用这些方式，笔者认为没有整齐划一约束的必要，因为这么一个大的框架下所支持的业务流程可能形形色色，有些只需要1、2两种，有些需要1、2、3，有些只需要2、3，也有的1、2、3、4都需要使用，组合起来情况还是比较多的，太过约束会导致不灵活，反而不便于管理。
笔者通常使用的是XML + EXCEL + Oracle + QC测试集参数，XML用于被测系统的登陆地址URL配置（用于多套测试环境之间的切换）、测试数据库TNS配置（用于分布式数据库之间的切换或多套测试环境之间的切换）、测试数据文件引用和自定义的测试结果保存路径配置、测试用户权限和角色配置等；EXCEL用于保存可复用测试数据；Oracle用于获取不可复用的或实时性要求较高的测试数据；QC测试集参数用于配置同一可复用测试脚本在不同流程里参数引用来源，如发起保全初审脚本在增加被保险人流程中读加人的数据文件（或所在路径），在减少被保险人流程中读减人的数据文件（或所在路径）。
对于系统测试来说，测试数据分为可复用的测试数据和不可复用的测试数据，对于自动化测试运行来说可能最棘手的事情就是如何保障测试数据不可复用的自动化测试程序的稳定运行问题了。笔者对此有一点点小心得，愿与大家分享一下，为了便于理解，我们根据使用情况对测试数据种类做更细致的划分，分别看看不同类型的数据在高频的自动化测试执行过程中如何使用与管理：
1、 可“永久”复用的测试数据，其实没有所谓的永久概念，因为一旦切换测试环境，这个概念就不成立了，这里主要是指查询操作使用的数据和一些与业务逻辑没有关联（系统程序没有进行判断和控制）的数据，如身高、体重、籍贯等等。因为与业务逻辑关联性不大，很多同事很喜欢把这些数据写死在测试程序里面，或者写在静态的DataTable里面，从脚本开发效率的角度考虑无可厚非，但是如果测试环境切换了或者某一天业务逻辑扩展到与这些数据所代表的要素有关联了呢？与其逐个修改测试程序还不如去改配置文件，既简单明了又易于操作，不容易发生错误。
2、 可使用有限次数的测试数据，比如团险保单减少被保险人操作，有效分单数量是优先的，那么这个保单所能支持的操作数据也是有限的，简单地看这种数据是需要定期更新的。也可以考虑与其他操作流程结合在一起运行，让能 “有限”使用的测试数据变成可“无限”使用的数据，比如先进行增加被保险人操作，再进行减少被保险人操作，就是说利用被测系统中的可互逆的操作让测试数据增加可使用的次数。除了客观上有使用次数限制的情况之外，还有一种是测试执行失败之后留下的“脏数据”，如团险保单拆分操作，发起初审之后如果保全处理失败，就可能导致这笔数据下次运行的时候因为保全任务互斥的控制而无法继续使用，而只有在整个流程完全运行成功之后才能令下一次的运行不受干扰。对于这种情况一般是需要重新更换测试数据（保单、分单）去做测试的，也可以针对每一种限制测试数据使用的运行失败做数据清理，本例中就可以在运行失败之后或者能够确定下次运行无法正常进行的时候调用保全申请撤件功能去撤销未完成的流程，也可以通过后台的数据修改去回滚、删除运行失败的数据。对数据清理的说明，下面第8节异常恢复管理中将继续讨论。
3、 一次性使用的测试数据，例如保单状态修改，从缴费有效变成缴清，再如保单犹豫期退保操作，这些操作不可能再次使用同一笔数据。让很多同事在自动化测试执行中最头疼的可能就是这种测试的数据准备工作了，因为只能使用一次，每次运行之前都要准备新的数据，工作量不可谓不大，而且如果数据本身比较复杂或者稀少，这个数据准备工作就更让人怀疑这些功能用自动化的方式来测试是否价值了。那么对于这种一次性的测试数据，我们用什么方法去争取一劳永逸的效果呢？
a) 如果数据存量较多，则考虑直接链接数据库查询满足测试需求的数据，注意，满足测试需求或许不是简单的一两个SQL语句能决定的，需要仔细了解系统业务、设计逻辑，争取让测试数据是绝对可用的。
b) 如果数据较少，运行存在数据不足使用的潜在隐患的话，可以考虑该业务功能的互逆操作，从系统中寻找现成的具有数据对称性的功能，如果有这种功能的存在，那么两个功能串联在一起测试运行，能够起到操作回退的作用。
c) 如果业务系统中不存在互逆的功能，考虑后台数据的回归和删除，例如保单状态修改，系统中不支持保全回退。考虑在测试数据库中建立一个JOB，对操作进行回滚，修改和删除所有影响到该笔数据下次继续运行的数据库记录，根据测试执行的频率决定JOB对应的运行频率，保证每次测试运行之前运行一次Rollback测试数据的JOB。
d) 不断生成新的可用的测试数据，增加可用数据量。寻找数据最初的来源，例如我们说的这两个操作所需要的数据，他们都可以由新契约承保生成测试数据，如果契约承保系统功能正常、自动化能够正常运行，那么我们将会不断得到新的数据，从而避免数据量过少又不可复用的尴尬。只不过这种方式对关联系统功能和自动化测试程序运行的稳定性依赖性较高，很难保证。
笔者个人建议：无论是什么类型的数据，使用什么样的方法，只要相同的数据能够长时间反复使用，那么将这写数据使用数据文件存储，映射到测试程序上去。存储数据的载体文件如EXCEL，统一保存在测试框架下指定的目录中，降低测试运行对人工测试数据准备的要求，最好能保证在首次运行成功之后还能够运行30次以上。对于不可复用的数据或者实时性要求很高的数据，则从被测系统数据库从获取，而对于完全不可复用也不可状态回退的测试数据，如第二章结尾所述，是否要进行自动化测试是值得商榷的。
数据分离是同行们普遍的共识，笔者这里不再继续讨论它的好或不好，基于数据分离的自动化数据驱动中存在的一些数据使用问题，总是有解决或者变通解决的方案，希望大家也能分享一下自己的方案。
(7) 公共函数管理
公共函数是指自动化测试程序开发的时候能够被大部分编码人员引用的公共的类、函数、过程，这些公共函数是所有自动化测试框架必备内容。公共函数包括两大类，一种是测试程序里常用的类如文件系统处理、数据库处理、字符串格式转换处理、数学计算处理、系统进程处理等操作。这些公共操作的使用能够加快自动化测试的程序开发，实现一些测试工具之外的程序支持以满足测试模拟实现和测试结果校验的需要，是传统意义上的共有程序。另外一种是在测试工具自身函数基础上再次封装的处理操作，典型的代表就是前文提到的SAFRRON框架，它就是在QTP自带的类和方法上封装了一套新的操作，以VBS文件形式加载到QTP中去的。有时候为了解决一些特殊问题或者工具缺陷也需要重新封装一些函数，例如一个EXCEL页数操作10个以上就很有可能在Import Sheet操作的时候发生未知错误，为了解决这个问题我们就可以在Import Sheet函数的基础上封装出一个新的函数去处理它，代码示例如下图。
图（四） 为解决EXCEL与QTP兼容性问题而封装的参数表导入过程
函数保存不仅仅可以使用VBS格式，也可以使用QFL和TXT格式保存，依据需要在测试脚本程序中引用。如上文所述，这些函数可以根据操作类别进行文件分割保存为文件系统操作、数据库操作、字符串操作、数学计算操作、系统操作和测试开发框架等类别，将函数载体文件保存在测试框架下指定的公有目录中。另外，每个子系统也可以有该子系统独自使用的函数库，以实现更加个性一些的功能支持，它们可以被保存在函数库下子系统的目录中。
图（五） 框架下函数库目录结构
公共函数文件一定要进行严格的权限控制，不能随意更改！即便是有权限的人修改也要经过所有系统自动化测试开发负责人评审同意，如函数内容变更、参数变化等，可能对现有已经开发的测试程序有着非常大的影响。如果必须修改而又不能兼顾已有的引用，那么最好在原文件中新增一个函数以满足新的需求，只不过我们要尽量避免这种情况的发生，否则函数文件会越来越大，不利于维护管理。
(8) 异常恢复管理
提到异常恢复，大家自然而然会想起QTP的场景恢复这个功能来，事实上场景恢复只是异常恢复的一个方面。QTP的场景恢复是QTP自身的功能，他所能支持的异常恢复是比较有局限性的，下面我们简单讨论一下几种常见的异常恢复处理方法。
1、 QTP的场景恢复，它能够发生异常的时候进行错误页面的清理，在一些特定的错误下做特定的处理，甚至能够重启操作系统。笔者理解，QTP的场景恢复是一个轮询任务，能够时刻关注测试运行是否发生异常，它的好处就是不用在每一个可能发生异常的步骤都去人工的写一个判断，测试脚本程序的开发比较简单；另一方面，场景恢复的用作是忽略或者处理掉一些非预期的异常，以便于下一操作步骤的继续进行，追求在一次测试执行中覆盖到更多的内容。
2、 QC的运行恢复，位于QC测试实验室（Test Library）中，它能够针对测试流程中的每个可能运行失败的脚本程序做比较宏观的清理操作，对于运行环境不稳定所造成的运行失败、无逻辑先后关系的流程前置功能运行失败导致的后续测试运行无法继续，做很好的恢复操作。我们可以通过QC中的设置（参见图六）使因别的运行失败而受阻导致失败的操作重新运行，并且可以在运行之前选择一个清理测试，通常笔者会选择重新登陆作为清理的主要手段，当然，在登陆操作中不会忘记先执行清理应用进程的操作。
图（六） Quality Center中的运行失败清理功能
3、 除以上两种运行恢复机制外，还有一种恢复机制是针对运行失败产生的数据异常进行恢复清理的，它不是对当次测试运行实时产生作用的，只是对测试运行失败之后再一次运行所进行的处理。通常，由于运行失败之后产生了“脏数据”，再次运行很容易因为数据问题而出错，那么对运行失败之后产生的“脏数据”进行恢复清理是很有必要的，与上文提及的实现数据复用的方法类似，清理可分为前台和后台：
- 前台的清理操作，利用被测系统本身的功能，对运行失败的流程进行做类似流程撤销的操作，这种方法能使用的范围不大，仅限于有撤销功能的业务系统和操作。
- 后台的清理操作，使用数据库函数、过程，回退或删除已经运行失败的记录，以保证下一次运行可能成功。例如，使用上文中的QC场景恢复，在再次运行之前就需要调用一下测试流程实例运行失败之后的清理操作（参见图六）。
除此之外还有一些其他的恢复机制，比如开发插件程序等，对QTP运行的异常也可以进行处理，这里不再赘述。笔者个人认为，尽管QC+QTP这套工具在运行场景的恢复处理上比较有优越性，但是我们还是要尽量避免使用这些功能，因为使用这种功能无外乎三种情况：第一，测试环境因素导致的运行失败；第二，测试脚本程序逻辑、对象、数据本身存在问题；第三，被测程序功能存在问题。对于第一种情况，例如网络异常、执行客户端的资源紧张或者应用系统服务本身有问题导致的运行失败，我们需要着力解决环境的稳定性问题。如果环境出现问题，运行恢复使用的再好也是没有意义的，除非有一套能够实时修复测试环境的机制。对于第二、第三种情况，笔者认为有两种流程结构（但愿换个维度去划分不会让大家思维混乱）：
1、 执行流中的业务操作之间是相互独立的，如一系列的查询或设置操作，假设由于第1个查询出现了程序异常，页面上出现了未预期的Dialog或Module Window，那么如果不做处理，后续的查询操作都可能因此运行失败，那么我们可以选择使用QTP的场景恢复也可以选择QC的运行恢复来保证其他功能的运行。但是我们需要注意，场景恢复默认只是给测试结果中添加一个告警，而从整体的报告里观察出来的结果只有成功、失败两种，如果不够细致，那么很多人会因为告警的测试结果太多而忽略它，从而忽略了测试脚本程序逻辑、对象、数据问题甚至是被测程序功能的缺陷。
2、 执行流程中的操作有逻辑先后关系或者是有数据依赖关系，那么场景恢复在整个测试流程中的作用就好比是VBS运行时catch exception使用的on error resume next，如果是为了获取错误码，用起来则是无可厚非，如果后续的对象是来自于已经发生异常的声明或构造中，那么运行下去就没有意义了！试想一下，前一个步骤运行失败了，后续的业务流程能够成功么？追求更多的测试覆盖只能带来更多运行失败的测试结果，消耗测试、编码人员更多定位问题的精力，所以笔者认为QTP的场景恢复功能是不能用于有逻辑先后关系的流程测试当中的。当然QC的运行恢复可以有限制的使用一些，在一些能够重新运行的节点上可以试着重新运行一次，如果两次连续失败，那么我们认为必定是存在某一方面的问题的，如果能够重新运行成功，那么环境、数据存在问题的可能性就比较大了。
抛开运行环境问题不论，无论是QTP的场景恢复功能还是QC的运行恢复机制，他们的最终的目的是在运行已经发生异常的情况下争取最大的测试执行覆盖面，最直接的作用就是在测试脚本程序开发的时候节省手工的运行逻辑判断，减少开发工作量，降低开发难度。特别是在测试脚本程序层面上，QTP场景恢复的使用实质上是降低了对测试脚本程序的要求，是录制、回放级别自动化测试应用较多的功能之一。通过上文的阐述，想必大家都知道它的应用是多么的有限，而且在这有限的应用中也是可被轻易替代的。如果大家对自己测试脚本代码比较有自信，或是对系统测试本身要求比较高的话，还是自己去想办法解决这一系列的运行异常问题吧，场景恢复者，鸡肋也！
基于上文的分析，笔者提倡将异常判断写在程序里面，并且根据各自系统的特点对判断逻辑加以丰富，不要过于依赖场景恢复功能。下图（图七）示例是笔者编写的对未预期的Dialog、应用runtime exception的简单捕捉程序，同理，也有对不同页面层次的模态窗口、业务逻辑控制提示页面、业务逻辑异常错误页面的判断处理程序，这里不再一一列举。这些判断处理可以写在一个公共的可复用action中，测试操作一旦触发了业务系统前后台交互，都可以进行调用，这样，牺牲几秒钟的判断时间可以赢得最真实的测试结果，并且一定程度上能够根据用户的选择对系统的异常进行相应的处理。
最终在测试框架里面使用自产程序还是工具自带的功能，可依据自动化测试实现的程度去选择，上文分析了1+2×2=5种情况，希望大家可以参照一下自己的使用情况思考一下；运行异常恢复所使用的程序和文件，不消多说，想必大家也都知道应该放在哪里。
图（七） IE弹出Dialog和应用异常的判断
(9) 统计分析管理
前文已经提到大规模自动化测试开始最早应该是在软件开发成熟度达到“已定义级”的时候，这样的话，要么自动化测试正立足于“定量管理级”，要么伴随着迈向“定量管理级”的步伐，甚至也可能已经置身于“持续优化级”的过程当中了。在这些情况下，将自动化测试相关的指标和指标的达成情况做详细的分析是很重要的一点，这些分析数据能够用于监测自动化的成本效益、改进不合理的过程环节、裁剪冗余、提供决策支持。
作为测试工程师技能和贡献度的评估标准之一，自动化相关的考核指标是非常重要的。这些指标的制定来自历史经验和测试人员的年度工作计划或者系统年度工作计划，在前年的年末或当年的年初由自动化测试的相关主管给出并且定期跟踪和检视。这些指标可能包括如：系统规模（代码行数）、总测试场景数、自动化测试场景数、自动化测试运行报告分析效率、自动化测试缺陷产出数、自动化测试执行消耗时间、测试脚本维护消耗总时间和平均时间、自动化脚本开发消耗总时间和平均时间等等。这些指标核心的作用就是评估分析自动化测试在所有测试过程中所占的比例、达成的贡献度，分析从事自动化测试工作人员的工作成果，为他们的绩效考核保留大量客观实际的数据。
当然，统计分析并不单指KPI的管理和跟踪，对测试过程中各个环节本身的统计与分析也是必须的，这些数据的采集、管理和状态跟踪等工作的工作量是很大的，必须依赖一个强大的分析处理工具或系统。笔者个人比较推崇使用测试管理工具本身的数据库服务开发一个专门用于测试管理的报表系统，主要以自动化测试管理为主，兼容手工测试的多维分析。使用测试管理工具作为为测试分析、设计、执行、缺陷全过程的管理工具，很多分析参考数据很容易从数据库中直接获取。虽然它们可能有自带的报表分析支持，但是对于统计、加工过的数据，我们需要将它直接写入一些新的表中，为更多维度的分析提供方便。
1、 测试管理层面的统计与分析，这是一种比较宏观的统计分析，主要是针对部门、分组、项目、人员进行的年度、季度、月度、周的多维数据统计分析，对指标和指标达成情况进行分析，给中高层管理人员的管理、考核等工作提供数据支持。
2、 测试执行的统计分析，针对项目、子系统的一次或几次运行进行统计性的数据采集，用以对测试运行结果和版本质量进行评估。例如XXX版本首次移交部署到测试环境之后自动化冒烟测试开始执行，运行完毕之后90%通过，10%运行失败，如果未移交版本之前运行通过率是100%，那么说明有10%的测试场景因为新版本的变更受到了影响，测试经理可以要求测试负责人对这10%的运行失败逐一进行分析并且给出测试报告。
3、 测试运行日志，包含测试运行时的结果导出、截图、打印出来的调试信息、测试工具使用日志以及被测系统本身的日志等。测试工具或测试程序本身的日志可以从固定的服务目录和测试管理工具中获取，被测系统的日志可以从中间件控制台获取。运行日志用于分析每单个的测试脚本程序的运行情况，主要是用于定位程序发生异常时的操作步骤和异常发生的原因，相对于其他两种统计，这是一种比较微观的统计分析。
在测试框架中，统计分析这个模块乍看起来比较抽象，但是如果有了较好的测试管理工具和报表平台，这项工作就清晰可见了，并且将之与日常的自动化测试、管理工作结合起来，可以取得很大的便利。此外，统计分析的范围至少要包含对以上所有提到的测试框架元素实例化数据的采集分析，最好以最直观的方式呈现在使用者面前，尤其是管理者。从管理者的角度上理解，足够的统计数据才是他们所需要的决策支持。
上文提及测试综合分析管理系统的开发可以在已有的测试管理工具上扩展，系统的框架很容易搭建，最主要的是设计开发的需求确定，例如，不同的统计分析报表功能有不同的使用对象，报表系统是否应该有用户的角色区分和权限控制等，要结合组织的需求进行分析。
3. 自动化测试成本收益分析
(1) 真正的成本降低来自何处
前文反复提到自动化的投入与收益，很多人都会知道把自动化测试收益这个概念理解为产出减去投入，而更多的人单纯的把自动化测试收益理解为测试投入的人力、时间在使用自动化前和使用自动化后的差值，至于这个差值具体如何计算，也很少有人能理得清。前文在阐述自动化特征和模式对成本收益影响的时候用的也就是这个基本概念，但是自动化的效益只是以测试人力和时间来计算的么？当然不是！笔者认为，自动化的收益计算至少要考虑以下几个方面，如有思虑不周之处，还请各位读者补充。
1、 测试人力、测试时间，这是最直观的概念，也是项目管理三要素中的其中两点。如何计算呢？最根本的计算方法就是用同一个系统或者项目，分别使用自动化进行测试和完全不使用自动化进行测试，测试完毕之后测试人力和测试时间综合的差值就是收益。其中投入人力或时间不能直接相减，需要拿时间和人力的积去做差值，因为如果单纯的去将时间、人力投入做差值，那么在准备对比之初就会因为努力要达成节约成本的意图而影响资源配置的合理性。当然，很少有公司会无聊到把一个项目用两种模式去分别测试的程度，除非是做专业测试研究……所以能给出这个差值的人自然也就非常少了。那么如何计算这个比例呢？可以让经验丰富的测试经理把一个系统、项目的测试分成不同的模块，采用不同的方式去测试，使用不同测试方式的模块的复杂度和工作量应该基本一致，然后同步进行测试就可以体现出不同测试方式的差别了。大家会发现，往往在这种对比测试的时候，自动化在测试人力和测试时间上毫无优势，基本上自动化测试消耗的成本要比手工测试多得多，这也就是很多人凭直观感受就能迅速判断出“自动化测试根本不能节省人力”的原因。
2、 非测试的人力和时间，大家考虑人力和时间成本的时候都习惯于站在自己的角度去考虑问题，而开发部门的人力和时间与自动化测试之间的关系往往被忽略。举一个很简单的例子：一个新的版本移交到Staging环境免不了要做冒烟测试，如果测试执行的人力足够充裕，那么手工就可以在短时间内把被测系统的绝大多数的测试用例执行一遍，以便更早的发现潜在的缺陷。只不过“测试执行人力充裕”这个概念很少存在，没有哪个老板会为了冒烟测试养着一大群测试人员。那么如何能够把冒烟测试尽可能快地做完呢？自动化可以。那么冒烟测试可不可少做或不做呢？可以！但是这就得要考虑一下另外一个问题了，由于没有在版本移交之初做完整的冒烟测试，而在系统测试过程中测试人员主要在关注新功能、需求的实现情况，那么由于当次移交带来的隐患都留到了测试后期才能被发现了。如果是一个简单的小功能上的疏漏倒无所谓，但是如果是设计上没有足够科学，导致在回归测试的时候发现必须要去修改系统设计重新实现一些东西，那么对于开发部门来说这个打击是非常大的，另一方面，如果编码、设计人员加班，估计测试人员也落不着好。从这个角度出发去考虑，在系统测试阶段内缺陷发现越早解决成本越低的理论是正确的、有据可依的，所以自动化测试对减少系统开发的反复性、降低编码设计的人力和时间是很有作用的。
3、 测试管理水平的提升，从管理者的角度来说，自动化测试的引入是一种优化版本测试周期划分的手段，同时也是一种优化管理模式的手段。假设我们的现状是这样的：在为期1个月的版本中要测试20个SRS，1周时间用于做测试分析设计，2周的时间用于系统测试执行和缺陷跟踪，而上千用例的回归测试，我们需要近一周时间去完成，因为要保证版本质量，回归测试必须尽可能地覆盖到系统的每一个角落，那么联系下图可知：
a) 如果使用自动化测试进行支持，回归测试执行的时间长度是可以缩短的；从而固定的时间长度内，测试分析、设计和测试执行的可用时间变多，从测试的角度考虑一个版本就可以支持更多的需求测试，这便是测试能力的提高。
b) 如果使用自动化测试来支持，冒烟测试将会因为可以轻易地反复、多次快速完成而变得比较充分，版本的质量与可靠性对定版之前最后一次进行的回归测试的依赖程度将会大幅度降低，版本因回归测试发现严重问题而延期的风险大大降低。
c) 目前大部分公司为了不断地满足用户的新需求，为了支持销售、创造利润，系统版本发布会非常的频繁，笔者了解到甚至有一个系统在一个月内向生产发布将近10个版本。正是由于自动化测试的介入，冒烟测试和回归测试的周期大大缩短，从而固定时间内，测试可支持的版本数量大大提升，同时还能保证版本的质量。
图（八） 测试周期划分：非自动化和自动化的差别
综合以上几点可知，对自动化的收益的评估不能只立足于测试人力和测试时间的投入，不能只立足于测试部门，甚至不能只立足于IT本身，要替客户、替领导从大局上考虑。当然，并不是说不替领导考虑就不会升职涨工资，但如果只是因为不识自动化测试的“庐山全貌”，还为了使用自动化测试是否值得一个劲的跟领导较劲，那就是相当不智的行为了。之所以劝大家替领导想，那是因为我们需要知道组织的需求，然后我们才能明白我们要做什么，要做的有什么意义，如果出发点都没有搞清楚，做不出彩来也就是情理之中的事儿了。
(2) 影响成本收益的关键因素
上文简要的分析了一些自动化测试能够带来的有形或无形的收益，下面让我们简单看一下几个关系到自动化测试获益程度的因素。
1) 系统的个数与收益的关系
在测试框架搭建或设计过程中，一切可复用组件的设计都需要考虑的相当周全，而且必须经过反复的论证和测试，所以测试框架的搭建和辅助工具的开发成本是非常的昂贵。如果一套框架和工具开发完毕之后只应用于少数的几个系统，那么参与测试框架和工具开发成本分摊的单位数越少。假设开发自动化测试框架和测试工具使用了400个人日，开发完成之后每个使用该框架和工具的系统都要分担这部分成本。如果应用于100个系统，那么每个系统的自动化开发成本将等于400/100加上系统自动化测试本身的人力；而如果只应用于10个系统，那么每个系统的自动化开发成本将等于400/10加上系统自动化测试本身的人力，差别是非常大的。
虽然算是这么个算法，但是请注意：不要因为急于找“摊派”对象而强行要求某些系统必须使用自动化测试或者必须使用成型的自动化测试框架。如前文所述，如果失去对自动化测试的理性调研、论证的态度，被迫做自动化的系统或项目可能会因此消耗更多的时间和精力，甚至得不偿失。
2) 运行的频度与收益的关系
每个系统的自动化开发时间固定的情况下，测试脚本程序使用的情况也是决定收益的最为关键的因素之一，现在广为流传的一种说法就是自动化用得越多则效果越好，我们就以自动化冒烟、回归测试为例，看一下这种说法是否正确并且是否有依据。
- 运行次数越多，分摊到每次运行所需的测试脚本程序的平均开发成本越低，而维护修改的成本则累积上升。考虑到版本测试的质量问题，冒烟测试和回归测试的越频繁越好，由此可以引申为：自动化测试运行的次数越多，版本的质量更容易保证。
- 假设开发一个系统的测试脚本程序需要P（常量）人日，该系统每年发版本个数为M（常量），平均每个版本的测试执行时间是N（常量）工作日，平均每X天向Staging环境修复移交部署一次，必须冒烟测试，每Y（变量）天自动化冒烟测试一次，每次冒烟测试手工需要A（常量）人日，自动化需要J（常量）人日，每个版本回归测试一次，每次回归测试手工需要B（常量）人日，自动化需要K（常量）人日，每次运行因程序更新而带来的脚本程序更新需要Q（常量）人日。除去测试相关工具和硬件资源等不可变成本，按系统测试要求冒烟测试频率不得小于移交频率的要求，那么，我们能看到的人力上的效益将能通过如下公式计算：
总收益
由以上公式可知变量Y的取值影响到测试人力的投入与产出，我们带入具体的值：开发一个系统的测试脚本程序需要60人日，每年发版本15个，平均每个版本的执行时间是12工作日，平均每2天向Staging环境修复移交部署一次，每2天冒烟测试一次，每次冒烟测试手工需要1.5人日，自动化需要0.5人日，每个版本回归测试一次，每次回归测试手工需要2人日，自动化需要0.5个人日（由于绝大部分使用自动化并行执行，故而与冒烟测试一致），每次运行因程序更新而带来的脚本程序更新需0.5人日。那么利用公式计算首年收益为104.43，次年收益等于104.71；如果每1.5天自动化执行一次则首年收益为74.78，次年为74.89；如果每1天自动化执行一次则首年收益为14.69，次年为14.85。这样一来，我们发现自动化执行次数越接近版本变更部署次数，则收益越大；同时我们可以知道，自动化开发完毕之后使用多少年对收益来说没有多大影响，每一年内自动化测试所能获取的利益在数字上只有很细微的差别。
- 我们不妨对这个公式做更多的猜测与引申，上面的公式中大部分是常量参数，如果把情况设想得稍微复杂一些，考虑的变参量多一些呢？
a) 首先明确一点：在符合系统测试质量要求的前提下（冒烟测试频率不得小于系统修复移交频率），并非测试执行频率越大获取的收益越多，只有在测试执行频率等于变更移交频率的时候，收益才能最大化。
b) 如果平均每次运行和每次因维护测试脚本程序所花的时间总和超过了每次手工执行所花的时间( A<J+Q, B<K )，那么无论如何努力，自动化也无法带来任何人力上的收益，所以要使得每次自动化运行的时间越短越好，维护所需要花的时间越短越好。
c) 如果首期开发投入时间P较多则维护所花的时间Q所需较少，反之，P值越小则Q值越大，这是自动化测试脚本程序本身的健壮性所决定的。由此结合以上公式可知：如果Staging修复版本移交的频率越大、向生产版本发布的次数越多就越应该控制维护脚本所花的时间，也就是说首期开发时必须投入相对较多的时间以保证测试脚本程序的质量。否则，即便是被减数P值很小，得出的结果也可能是负值，即，得不偿失。
d) 最根本的一点，自动化测试在每次冒烟测试中的使用。如果只是任自动化测试脚本自生自灭，测试运行就不作为缺陷发现或者版本变更跟踪的手段——即，无视每次冒烟测试带来的作用，只是为了运行而运行，那么不难从上面的公式中得出这么一个结论：自动化开发基本不会带来任何效益。
总之，各个因素总是相互影响、相互制约的，如上文所述，自动化测试收益不仅仅来自测试人力和时间的节省，如果一味的追求测试人力和时间的节省，那么就会忽略掉测试管理成本和关联部门的人力和时间等因素。笔者没有能力给出所有收支的平衡之策，这里只做简单分析，希望大家能够结合自己所处的地位和自己的需求去处理这些问题。
3) 软件成熟度与收益的关系
软件成熟度与自动化测试的关系本文在第一章第二节已有简述，它又与自动化测试收益之间有什么关系呢？笔者认为，软件开发成熟度越高，自动化测试收益越明显。原因如下：
- 需求管理更为科学，自动化测试脚本程序修改、维护的工作量因用户需求变更的管控而变得可控制、可估量。即便不考虑考虑其他手段带来的测试设计时间、人力的减少，只要没有因反复的用户需求导致测试脚本程序的反复修改更新，客观上也已经是一种变相的成本降低了，而成本的降低也就意味着收益的提升。
- 系统编码设计人员所采用的开发模式较为先进，可以轻易做到高度复用并且十分规范的软件系统开发，在这样的开发模式下，有经验的测试人员在结合需求规格很容易知道一个操作之后下一个页面上的细节会是什么样的，这样测试分析设计可以很早地介入。由于系统操作的预期结果很容易预判，自动化开发可以在设计、编码的同时进行，甚至可以领先于系统编码的进度，而且由于开发难度的降低，自动化开发速度可以大幅提高，从而自动化开发的投入可以相对少很多，开发完成之后应用的次数也会比较多。
- 在明确、成熟的测试领域规范下，自动化的规划设计和流程规范也清晰明朗，会少走很多弯路。随着整个测试领域规范的发展，自动化的规划发展也是需要同步紧跟整个领域的发展的。虽然自动化测试看起来比较独立一些，但它终究还是测试的一部分，在没有使用自动化测试的时候看起来自动化测试只是测试的一部分，但是从开始使用自动化测试开始，自动化测试技术和整个测试的流程规范之间就存在着一种相辅相成的关系了。所以如果该组织的测试领域流程规范已经比较成熟，那么自动化测试的介入将比较轻松，不会给组织规范带来较大的冲击。
4) 测试覆盖率与收益的关系
简单讨论一下自动化覆盖率、自动化测试层次、测试脚本编写水平之间的关系。笔者简单统计了一下，笔者所在部门的94个关键业务系统平均自动化完成率是91.55%，想必在业界也是一个相当高的值。但是这里我们要搞清楚所谓的完成率到底是主流程的覆盖还是场景分支的覆盖：假设没有自动化测试介入，并且测试执行人力充足，那么手工回归测试的案例应该被执行的次数（注意：不是案例个数）就是自动化待开发的场景数总和；而手工回归测试覆盖是否全面则由测试、编码、SA、BA共同评估得来的。如果只是针对业务系统的主流程做测试，则这个91.55%的完成率是真实的，如果是对每个分支场景的自动化覆盖率，那么我们当前这个比例应该是多少呢？据笔者抽查脚本统计，在我们现有的框架下，乐观估计，有至少70%的脚本是简单的录制编辑得到的，其余的部分是不完全数据驱动的，只有极个别的系统是完全数据驱动的。这70%的自动化脚本走的基本全是主流程，而分支流程还可能有很多，因为业务系统的逻辑不同而不同，粗略估计，每一个脚本至少对应着2个左右的未覆盖流程；30%的数据驱动脚本中估计有一半是覆盖了3个流程中的2个，其余的只覆盖了3个中的1个。那么事实上真实的完成率应该是这样的：
91.55 %* (1/3*70%+2/3*30%*0.5+30%*0.5*1/3)/100%=35.1%
其实也就是35.1%而已，当然，按照本文第三章最后一节的理论，如果继续提升这个比例，那么自动化运行覆盖率也会提升，从而投入的人力将会越来越多，而收益基本处于一个较为稳定的水平甚至会逐渐降低。事实上，细心的读者会发现这么简单的规律：如果自动化测试驱动层次越高、测试脚本编写越科学健壮，自动化覆盖率就越能够较为轻易地达到一个较高的水平。笔者也是这么认为的：录制回放在自动化测试开发维护上使用的成本是天价，数据驱动则是较为优化的一个水平，而关键字驱动——拆分事物、方法、数据的做法则能够更容易随意组合已经开发好的测试组件，为更多更全面的测试覆盖打下非常好的基础。当然同样的道理，在测试框架级上的开发和驱动控制要达到一个高的水平也是需要更多的成本的，至于如何权衡投入和产出，每个组织都有自己的看法和对策，不能说谁是对的谁是错的，只是看各自侧重的需求点在何处，需求急迫程度有多大而已。没有必要以一个统一的标准来要求所有人，只是要分析清楚这个中影响到成本和产出的因素在哪里，是不是可以由自己控制（变参量）。
笔者十分期望有人能够建模来算一下到底第三章第2节第（4）点提到的这种狭义上的收益曲线在多大的百分比甚至场景个数上出现拐点，如果能给出一个公式来那么就真的是造福无数测试经理和主管了，可载入测试发展史，善了个哉的！很多经验丰富的测试经理都会凭直觉给出一个大致的比例，但是至于到底与哪些因子有关，成什么样的比例关系却至今未见成熟的理论和论证过程，当然笔者也自认为力有不逮，只好放弃具体的分析，望来日能有机会再补，而当下实在很是遗憾。
除上文四点外，还有一些其他的因素，如资源配备、环境管理等等，都与自动化测试有着比较大的关系。不过这些因素属于客观不可改变的现实，即便讨论，到最后无非是绕到是否有必要做自动化测试的问题上来，所以笔者不再赘述。
在笔者写这一节之前，自己也始终坚持认为自动化运行频率越高效益越高，但是仔细推敲之后发现却不是那么回事。所以大家无论持自动化可节省人力还是自动化不可节省人力的论点，都需要拿出自己的理由或者客观事实来论证，单凭主观印象去臆断是绝不可行、不可信的。
附录：笔者的牢骚和现世报
磨磨唧唧都敲出4万字了，事实证明这些字组合起来其实就是懒婆娘的裹脚带，又臭又长！不过没关系，笔者不介意手段，只要能表达自己的意思就好了，字数多点可以原谅。
(1) 批判精神：笔者人缘比较差，其实并不是因为人格人品有多大问题，而是因为脾气差，喜欢以自己的标准衡量别人。领导可能不太在意，最多认为这小伙不适合做管理而已，但是同事们就很反感了：你一天到晚跟我们做着一样的事情，凭什么恁嚣张，问你一个简单的问题你都爱答不理的？我的确没有什么耐性，对不喜欢思考、依赖性强的同事总是不怎么爱搭理，注定无法做领导啊，杯具！还有一部分同事很奇怪：这人怎么看这个不对、看那个不爽呢？这个好解释，这世界既然有建设者那也有批判者，这些批判者看问题总是抱着怀疑的态度，就像我们做容错测试一样：如果这样了会怎么样，如果那样了会怎么样……很不幸，笔者就是这类人。如果要我去搭一个体系或者构建一个规范流程，那我做得可能很烂，甚至是所有人中最烂的，但是一旦别人做出来了，我就会冲上去狠狠批判一把——不是与人家有仇，只是想让这个东西更完美。
(2) 完美主义：背着完美主义这四个字在工作中无非是到处碰壁而已，不过笔者很庆幸工作4年了还这么“有追求”。回想明朝那一大堆御史言官，整天屁事不做，就扛着折子骂人，内阁首辅重臣就骂走十来个。他们拿自己的名节、操守、脑袋（枭首）、屁股（廷杖）与皇帝老儿死磕，不过事实证明帝国的机器如果真的缺了这些完美分子过不了多久的的确确就会生锈腐烂。不过那些入了土的老头们大部分一辈子都信奉一个信条：严以待人、宽以律己，这八个字放在当今社会的职场里那是肯定要遭结结实实痛扁的，话说回来，不论怎么说人家的负责任的态度和宁死不屈的职业道德操守都是今人很少能够企及的。想到这些笔者心里又觉得泰然一些了，就当为自己的人缘差找个借口吧。
(3) 责任意识：提到职业道德操守，本以为自己能学学前辈，弄个假清高来混混，没想到这玩意在我们这儿已经被量化了，分大操守和小操守，大的2块钱一斤，小的3块钱一斤，开玩笑的……职业操守中最重要、最常见的就是责任意识问题，自动化测试做不好很多时候不是因为是技术或是理念不好，而是责任人意识不够，这很要命！拿残次测试程序糊弄别人、糊弄自己，最终被糊弄的将是软件系统的质量，失去的将是自己的职业道德，也终将被整个行业所抛弃。
(4) 理智创新：自动化软件测试终归还是软件测试，随着基础理论水平的发展与提升，自动化测试的方方面面也跟着日新月异。但是倘若这些规则变化太快、太不可预期，那么自动化测试流程和体系也会受到很大影响。所以我想说：思考不可不细致广泛，“创新”不可太恶俗、太泛滥，实事求是，解决问题才最重要。那么为何在流程体系建设的时候让人感觉连软件测试都这么崇尚“创新”了呢？我觉得大约是这么个原因：测试领域流程规范跟进成熟度发展的时候，这些规范没有经过深思熟虑，摸着石头过河，等到发现不适用、不可行的时候立刻又转向别处，典型的游击型体系建设。决策这项工作的人必须有足够丰富的测试经验，必须有足够灵活的头脑和全局性的目光；很难想象如果没有这样的人，我们将如何制定我们的发展计划，不知是通过累积沉淀还是通过拿来主义或是异想天开……看来有些时候创新也是被逼无奈的，而在它无奈之后，大家也不得不被逼无奈地想：不是我不明白，而是这规则变化太快！
对于测试来说，或者索性就自动化测试来说，基本没有什么技术问题——凡是存在的，必定是可以解决或变通解决的，最重要的还是观念和意识问题。观念落伍了，技术再怎么细致强大对自动化测试发展来说都是没有多大作用的。以上四点为笔者所信奉，愿与诸君共勉。
TIB自动化测试工作室专注于自动化测试技术研究与自动化测试项目应用 ，如果您和您的公司在自动化测试实施过程中碰到任何问题，欢迎及时联系我们，我们将尽力给予支持，帮助您走出自动化测试的困境！
