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

　　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）不过分地追求覆盖率

　　本章开头举了个2×5和5×2的例子，这个例子里，如果能实现100%的自动化测试，那么测试执行周期就会更短，看起来更能体现自动化测试的优越性。不过自动化覆盖程度也是要和自动化开发的投入挂钩的，覆盖率越接近100%，需要的投入也就越多，并且有些自动化模式下这种投入产出不以线性关系呈现。为了论述简单，我们不妨先定义几个概念：

　　● 自动化覆盖率：自动化运行场景数除以所有测试场景数，而并非自动化测试开发完成的案例数除以总案例数；

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

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

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

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

　　最后，综合以上两点分析，从理论上推断不难得出这个结论：自动化覆盖率的提升带来了人力投入的非线性增长，人力投入的非线性增长也带来了自动化收益上的非线性下降，所以自动化覆盖率的线性增长就间接带来了自动化收益上的非线性降低。所以自动化测试覆盖需要量力而行，如果没有足够的资源，那么这种覆盖率的追求势必得不到满足，并且会让原本在可控范围之内的效益白白流走：本末倒置、忘记测试目的，测试脚本质量较低等问题。

　　3、小结：认识创新的原力

　　工作是什么？工作就是不断的遇到新的问题，不断的尝试去解决这些未曾被解决的问题。而创新又是什么呢？创新从来不是刻意为了创新而创新，它的真谛也不是灵感突发带来的奇思妙想，而是在日常工作中不断冥思苦想如何比现有方法更好地去解决问题，以达到提高工作效率乃至生产力的效果。由此而诞生的一系列方法或者技术才是创新的成果，才能够被认作是工作的进步，才能够被放心的应用于所指定的领域。

　　自动化软件测试终归还是软件测试，随着基础理论水平的发展与提升，自动化测试的方方面面也跟着日新月异。但是自动化测试只是测试的一个发展阶段，而并不是创新，只是在自动化实施过程中可能会有创新行为，并且在进行自动化测试技术更新的时候，思考要细致广泛，“创新”不可太恶俗、太泛滥，实事求是，解决问题才最重要。总是感觉我们的自动化测试很崇尚“创新”，大约是因为我们这个自动化测试领域流程规范跟进软件开发成熟度发展的时候，没有经过深思熟虑，摸着石头过河，等到发现不适用、不可行的时候马上又更换新的方法和技术及其相对应的工作流程，这是典型的游击型技术和体系建设，只能最终让我们自己发现自己样样通、样样稀松！既然创新是为了解决问题而生，那么我们不妨就让创新变成一种被逼无奈之举：不主动去思考创新二字，这样，大家就不会忘记我们做这些事情的初衷了！

　　不过还有一种情非得已，那就是被迫做一些为创新而创新的事情，那么在从事这些事情的时候如何避免不切实际的创新泛滥呢？第一，决策这项工作的人必须有足够丰富的测试经验，必须有足够灵活的头脑和全局性的眼光；很难想象如果没有这样的决策者，我们将如何规划我们的发展前景。其次，要集思广益，无论是否精通自动化或者了解测试工程，众人的思想汇集在一起总会产生火花。第三，要坚持需求至上，实用第一，让我们的工作始终保持有意义、有目的，无论进行什么样的活动应该都不会偏离太远。