自动化测试目的和常见问题

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、自动化覆盖率：自动化运行场景数除以所有测试场景数，而并非自动化测试开发完成的案例数除以总案例数；

　　2、自动化完成率：自动化测试脚本个数除以所有测试案例个数；

　　3.狭义的自动化收益：是指自动化测试运行总次数乘以每次运行的总时间减去测试开发投入的总时间，这也是经常被大家所津津乐道的“自动化效益”。

　　首先，在业务场景方面，对于简单的录制、回放来说，本身运行的稳定性已经很难保证，加上脚本的复用程度非常低，所以要达到较高的覆盖率是要投入非常多的自动化开发人力的，所以自动化覆盖率本身就很难达到一个较高的水平。对于数据驱动和关键字驱动层次的自动化来说，自动化场景的覆盖率比较依赖测试数据的覆盖率。在业务操作和数据分离之后，流程、场景的组合相比较低层次的录制、回放更加灵活；测试数据准备的足够全的情况下，业务场景的组合将足够丰富，带来的覆盖率更高。第一个矛盾在于对框架设计的要求很高，单个脚本设计平均耗时较多。第二个矛盾在于虽然系统测试提供多少数据就会有对应数量的场景、流程，然而系统测试中并非所有数据都能支持复用或支持数据状态回退操作，所以自动化测试数据准备本身就比较消耗时间。例如保全系统中的保单犹豫期内退保项目的每日回归就需要每天有源源不断的新承保的保单数据产生才能支持该保全项目的自动化测试运行，而新保单承保取决于新契约系统投保功能正常、新契约系统自动化测试运行正常，中间有任何环节出问题则保全系统该项目的自动化测试数据将无法获取得到。这种因实时性要求较高而储备不多的数据准备在手工测试时一般都有一定的缓冲时间；但是自动化却是无法等待的，所以有些时候未必实现了自动化就能一直应用于自动化测试执行，有时候权衡过后，即便是已经自动化的也还是要手工测试的。如果时常受这种数据问题的困扰，那么在受困扰的时候放弃这部分的自动化运行也是可以考虑的，当然牺牲一定的覆盖率，也赢得了灵活性。

　　其次，在技术难度方面，我们一般不提倡把不是非要在一开始就必须解决的问题放到自动化开发的最初阶段来解决，这样很可能会因为技术卡壳影响开发进度甚至打击测试人员的信心。于是，实现上技术难度偏大的模块和功能很可能会被推后开发，开发计划制定的时候一般也会尽量这么安排，否则计划频频变更可能会难以避免。从而在自动化开发后期，技术攻关几乎成了测试开发人员的主要话题——当然，并不是每个项目都能碰到技术问题。那么在稳定的自动化开发投入持续到遇到技术瓶颈的时候，我们何不考虑一下重新评估这些没有实现自动化的模块、功能是否必须实现自动化呢？如果现有的自动化测试脚本加上手工测试用例执行的总周期能够满足版本发布测试的频度和时效要求的话，那么从项目测试角度笔者建议不要再继续开发，避免消耗更多资源；从运营维护的角度考虑可以暂缓——待系统稳定之后再考虑去解决这些问题。

　　最后，结合以上两点分析，从理论上推断不难得出下图中自动化收益和自动化覆盖率之间的关系。也就是说自动化覆盖率的提升带来了人力投入的非线性增长，人力投入的非线性增长也带来了自动化收益上的非线性下降，所以自动化覆盖率的线性增长就间接带来了自动化收益上的非线性降低。至于到底是如何的一种非线性关系，各位还是从图中理解吧，笔者那点数学知识早就还给老师了。

感谢：