6.5 自动化敏捷测试

虽然已经多次提到了IBM的自动化测试社区、专家和各种工具,我们还是看看自动化测试的发迹史,这对许多公司都有借鉴意义。

或许是对代码工作的热恋、对点击鼠标无技术含量的担忧,或许是大量测试工作的累积使我们不得不考虑效率的提升,甚至是片面、客观而非自主地选择了自动化测试这份工作,大量的工程师入职不久后就开始了自动化测试之旅。

2008年之前,IBM测试团队的人数占据开发中心总人数的60%,我们每天为开发中心数以百计的产品进行测试。我测试过的产品大概可以分成三类:一是面向终端用户的消费产品,对于这类产品的测试,我的个人经验是更需要在用户体验、用户并发访问、系统的安全和健壮上多多用心寻找缺陷;二是面向企业的中间件产品,中间件产品的测试更需要关注在大数据量、压力、长时间运转下系统的稳定,以及在异常恢复时数据和状态的健康,因此重点是对API的测试;三是面向解决方案的测试,这一类包括了前两类,除了在上述重点上多用功,好的测试需要尽量真实地再现客户环境。这三个方面的测试都需要大量的用户操作、输入、监视输出,自动、半自动地根据输入和输出产生系统的下一步动作,这些系统中每个对象的变化状态、过程的演示以及数据流的准确都是需要关注的重点。

现在难点来了,很难依靠肉眼和手指的跳动实现完备性的测试。例如,一些数据的中间状态不借助工具就不能展示出来,就无法知道数据从发生到结束是否出现了异常。

那么,全自动化的测试是否能够解决所有测试问题呢?也不可能,因为没有100%的把握证明自动化测试工具和测试方法本身不带来问题,此外还需要考虑自动化测试脚本的开发所需的代价。很有可能在我们的测试脚本还没有完成的情况下,产品的研发已经不得不结束了。

下面,针对自动化测试落足点的选择、自动化测试的完备性、自动化测试工具的选择以及自动化测试开发额外开销的时间对测试进度和测试成本的影响等方面分享我在IBM的自动化测试经历与我对自动化测试的认识。

6.5.1 自动化的落足点

我初次接触自动化测试时还在普适计算部门工作,部门的项目非常多、工作也很繁重,因为更多的测试工作都是针对新功能、新模块开展,自动化测试的工作并没有像后来在测试中心做自动化测试时那么备受重视。

测试工程师每天遇到的都是新问题,许多测试需要“跑”。自动化测试为什么要做、什么时候开始我已经忘记了,而自动化测试的项目我依然记得,那是一个最新的Nokia手机平台上的自动化办公软件的测试,因此自动化测试主要是针对GUI界面展开,自动化测试的成效很差,以至于我印象里从来没有什么有效的问题是通过自动化测试发现的,而是在自动化测试脚本编写过程中发现的。但是大家还是“被”要求完成一定程度的自动化测试,为此我也算是舍本逐末地学习了如何使用Rational Functional Tester这个有趣的工具。

2008年我加入了测试中心,主导的工作就是如何改造原有测试模式,利用较少的资源完成高效的测试。其实,解决方案很简单,就是将那些可以重复的、标准化测试过程独立出去,交付给专业的独立测试团队来做测试。

按理说,任何相似的产品和项目都可以使用同样的测试环境、测试标准和测试策略,但实际工作却没有那么简单。可配置参数的自动化测试脚本开发、运行时负载均衡等多个问题成了时下的焦点。而测试本身占去了团队大量的时间,对自动化测试框架的改良只得见缝插针,我和团队将改良工作划分成一步步细粒度的工作,虽然分身无术,但是这种做法还是可以逐步推进工作的。

我记忆里做得最多的工作就是不断提高自动化测试执行的首次执行成功率,提高可执行脚本的测试点覆盖率,提高测试平台和工具的鲁棒性,减轻环境搭建、配置工作等。在这一年里我和测试团队的同事也同时发表了许多有关测试能力、自动化测试、如何写好测试脚本、如何有选择性地实现自动化等多篇文章,并了解了诸多出色的测试规划、执行、管理工具,例如Rational Build Forge、XDE、Manual Tester、Rational Performance Tester、Rational Quality Manager、Rational Asset Manager等。

在自动化测试框架的逐步改进过程中,除了能够解放出部分人手外,我们的测试框架能够完成更多的测试点,并且定制了一套开放的标准,产品团队按照这个标准就可以提供新的自动化测试脚本并在这个平台上运行。而公司又提出了更有挑战的目标——希望执行周期缩短一半……面对新的要求,我们希望团队利用各种资源培养自动化测试的能力和技能。下列是我们采用的一些做法:

·最大化地从IBM社区、成熟测试团队那里学习全面的测试方法、自动化测试工具。

·选择容易操作、容易编写测试脚本的工具来建立尽量统一的测试平台,并极大地鼓励测试团队之间的测试资源共享和测试资产的重用。

·最大化地使用本公司的工具和平台,在开发过程中获得官方的帮助和专业的技术支持,同时制造了跨团队合作和学习的机会(而这是IBM个人发展的重要维度)。

我们一边不断提高测试自动化率,但同时意识到我们的工作绝不能100%由机器代工,设计一套能够自动化所有测试用例的平台并非没有技术可能,而是开发所耗费的时间远远超出我们的期望,这种工作到了后期让我们觉得自己像是在努力使用计算机取代人类的智慧那么愚蠢,更不用说自动化测试做测试规划、测试缺陷这样比较少涉足的领域有多少艰难险阻。

测试无法取代完全的手动测试、黑盒测试,所以我们需要自动化测试更多地集中在最有价值的部分,因为所有的自动化测试都不是免费的午餐,无论自己开发还是由其他团队开发,这部分的开发工作量都将划入“成本计算”。因为我们是专业的测试团队,而不是自动化测试工具开发团队,所以我们从来没有想过为了自动化而做自动化测试。我们认为最佳的自动化测试策略是做重复度高、关键的测试,包括:

·重复的测试用例。在可见的、将来最多被测试和执行测试的部分需要做更大比例的自动化,之后每执行一遍测试,就会从自动化中多一分收益。

·敏感、复杂的配置和安装过程。我们之所以需要这部分的自动化是因为,电脑好过人脑,在重复、复杂的配置操作中,如果做错一步都可能带来极大的损失,因此这部分的自动化最重要。

·测试工程师认定最没有价值的部分。当我们觉得手上的工作无趣、疲劳、简直是降低个人价值时,考虑自动化这些工作会给团队带来生气和活力。

并且,我们认为自动化测试的工具应该具备以下特征:

·自动化测试产品需要更“容易”使用。

·自动化测试需要更“适用”于“你”的环境。

·自动化测试产品需要规范编写、系统设计并且尽可能保留可扩展的能力。

·自动化测试产品的单元、任务最好容易被获得。

而为了做好自动化测试的工作,我们还需要培养工程师的如下技能:

·需要良好的软件工程理论和方法指导我们的自动化测试开发工作,例如设计、代码审阅、开发、测试等。

·自动化测试产品需要有清晰的文档、注释,能够系统地组织这些说明和文档,并用版本控制工具管理这些资源。

·懂得自动化测试领域“分享”和“重用”的价值,通过向社区发布最佳实践经验,有能力和渠道向咨询领域专家请教相关问题和寻找解决方案。

6.5.2 ROI指标判断

维基百科对ROI的解释为,在金融学中,ROI被理解为投入产出比(Return on Investment),指投融资的回报率或者投资回报,表示相对于投资额的金钱获得或者损失的比例。金钱的获得或者损失可以理解为利益、利润或者损失、浪费。投资额可以理解为资产、本金。

ROI的最简单的计算公式是

00066.jpeg

其中rarith是产出、收益,Vi是初始投资,Vf是最终价值。

测试的价值是通过找到更多质量缺陷(Defect)使得产品后期投入(Cost)减少而实现的。因此,自动化测试和手动测试一样,Vf最终的价值取决于暴露质量缺陷的数量。

6.5.3 自动化测试的ROI

自动化测试的autoVf取决于最终发现的质量缺陷数量,而自动化测试的初始投资autoVi由自动化工具开发、部署,自动化脚本、程序的开发和维护,以及执行自动化测试所需的成本决定。

因此,autoVf-autoVi越大,autoVi越小,ROI比例将越大,也就证明自动化测试越成功。

而为了证明自动化测试的优势,我们喜欢将它和手动测试的ROI进行对比,得到公式1,从而证明自动化测试比手动测试更有效。

00068.jpeg

如果无论自动化测试和手动测试达到的最终价值都是等量的质量缺陷的暴露,也就是

00002.jpeg

可以推得

00005.jpeg

进而推得

00009.jpeg

经过以上推算,我们可以得到结论,如果要使得自动化测试优于手动测试的投入产出比,需要证明同样质量的测试结果前提下,自动化测试的投入成本要低于手动测试的投入成本。

为了进一步实现自动化规划的最优化,我们来分析一次成功的测试案例,首先需要一些假设和前提。

假设1:手动测试用例/自动化测试脚本的粒度是一个用例/脚本足以且仅能发现一个质量缺陷。

假设2:自动化测试不发现质量缺陷,只能发现日志错误,在人工检查日志错误时,需经过分析日志(约等同于一遍手动测试)、人工再现场景以确认产品问题(等同于一遍手动测试),从而定位和暴露真实质量缺陷。

假设3:无论是否采用自动化手段,在当前质量缺陷被修复后,仍然需要花费一遍手动执行测试用例的同等执行时间来验证此修复。

假设4:自动化过的脚本仅执行所花费的时间和投入可以忽略。

如果用100个测试用例来测试一个隐藏了20个质量缺陷的产品,而且每个测试用例的执行时间约为a小时。

当这100个测试用例完全手动测试时,我们最少的测试时间是80a(80个可以完全通过的测试用例的执行时间),加上20个平均3a小时的处理时间,才能完全暴露质量问题(参考假设2,3)并最终完成测试。因此

00013.jpeg

而经过这次测试,可以得到20个质量点的提升manuVf=20Defects。

为达到同样的测试效果,我们仍然对同样的产品采用自动化测试手段。那么基于前提假设,最优的自动化测试比例,也就是将80个可以完全通过的测试用例都生成自动化测试脚本,那么本次测试的autoVi=(x+20×3×a),其中,x为开发和维护80个自动化测试脚本的代价。同样,autoVf=20Defects。

根据公式4得到的结论,最优自动化规划将满足以下不等式

x<80a

结论:如果自动化后的测试脚本在项目中只运行一遍,那么自动化脚本本身的开发成本不应大于手动执行一遍对应测试用例的执行时间,换言之,完全没必要自动化。

6.5.4 合理的投入

真实的场景将比以上案例更复杂,自动化测试脚本可能执行多次,产品中的质量缺陷无法确切得知。为了进一步得到更合理的场景下自动化测试规划的建设性分析,我们需要声明几个变量。

声明1:d%为平均出错率,即一个产品的代码中如果有d%的出错率,对产品质量缺陷的修复仍将带来d%的新质量缺陷。

声明2:质量达到95%的测试通过率后,产品可以发布。

声明3:n为迭代次数,自动化脚本将被执行n次,或者叫做迭代测试n次(n≥1)。

声明4:TotalEf为完成一次完整的手动测试时,测试用例完全通过的执行成本。

声明5:x为自动化的开发和维护成本的上限,x=manuVi-autoVi,也就是说实际的脚本开发维护成本应该大大低于x,这样的自动化测试ROI才是合理的。

利用公式4推导出来的结果manuVi-autoVi>0,可推得

00015.jpeg

因此推导出

00019.jpeg

结论:d%的值越大,质量缺陷越多,我们依赖于手动测试的可靠性更大。

因为新测试用例开发出来很快投入了FVT(功能检验测试),之后测试人员才投入开发自动化测试,所以,此阶段我们必然依赖于手动测试。只有在以后的回归测试阶段,两种测试手段,即自动化测试和回归测试才具备可比性。而真正的自动化收益也来自于测试的回归测试阶段。同时,以上公式表明,TotalEf越大,我们越能够倚重于自动化测试。回归测试的用例重复性使用频率越高,自动化的投入必要性越大。下面就以回归测试作为背景来分析自动化测试的合理规划。

假设一个团队回归重复测试相同用例的出发点是为了确保先前成功的功能不会失效,那么成熟的测试团队应该不断根据现有的产品质量缺陷报告,对回归测试的覆盖范围和计划做出正确估计和调整。在开发团队修复代码的过程中依据d%错误率的平均工作有效性来估计,我们对每个迭代的质量缺陷数量将是上一迭代数量的d%。那么,n次迭代将总共产生的质量缺陷数量为

00021.jpeg

结论:回归测试产生的质量缺陷是产品出错率的等比数列之和。

6.5.5 自动化回归测试

同理,科学规划的回归测试的覆盖范围也是等比递减的。例如,第一次迭代所花费的成本为TotalEf×(1+2×d%),第二次迭代所花费的成本为TotalEf×[1+2×(d%)2],第三次迭代所花费的成本为TotalEf×[1+2×(d%)3],以此继续推导,可以得到第n次迭代总共花费手动测试成本为

00023.jpeg

而引入自动化测试后,第一次迭代所花费的自动化测试执行分析成本为TotalEf×(3×d%),第二次迭代所花费的成本为TotalEf×3×(d%)2,第三次迭代所花费的成本为TotalEf×3×(d%)3,所以n次迭代后总花费自动化测试执行分析成本为

00027.jpeg

因此,根据公式7和公式8以及声明5,我们得到自动化开发和维护的成本上限x为

00032.jpeg

图6-4为公式9所呈现出来的各单元之间的关系。

00036.jpeg

图6-4 自动化测试脚本开发与维护成本规划

结论:当考虑自动化测试成本收益时,我们应该先考虑对那些可能迭代次数更多、运行次数更多的测试用例进行自动化脚本开发。而对于产品的质量缺陷,质量缺陷越少、质量越好的产品,自动化开发成本收益也会比较大。反之,则致使自动化开发并不合算。例如,当前测试用例很可能最多执行2次,但产品中的遗留问题可能使得60%的测试用例不能通过,这时没有必要考虑自动化测试。

而且,即使产品中质量缺陷很少,但是测试用例可能被使用的次数非常少(少于3次),那么自动化测试的开发成本也只允许极少量投入,或许并不可行。

调换n和d的关系,我们再来看看图6-5中x的曲线。

00038.jpeg

图6-5 自动化测试脚本开发与维护成本规划

结论:继续对自动化测试脚本开发与维护成本规划进行分析,我们还能得到另一个信息,那就是迭代次数,即测试重复性基本与可允许投入的自动化开发成本成线性关系。当测试需要迭代的次数是n=k时,允许投入的自动化开发、维护成本可以是n=2时的k倍。

6.5.6 敏捷测试的自动化

自动化测试规划的复杂性已窥见一斑,敏捷测试、Scrum开发模式下的敏捷测试隐约比我们分析过的情形要更加扑朔迷离。众所周知,Scrum模式下的开发、测试遵循了独特的规则。

迭代模式使得代码逐步累加起来,每个迭代周期又是如此短暂,还没来得及验证最后几个质量缺陷,突然需求变化了,一半以上的测试用例和测试脚本不再有用。

由于需要对每个迭代的新功能和新需求进行测试和研究,而迭代周期又很短,因此不容我们考虑诸如测试代码复用这样的问题,也没有时间来计算多少基于上一迭代的测试用例和脚本需要再度测试。

简单地说,测试节奏一下子加快了,在这样的压力下,更加追求迭代价值,以使每项开发、测试、研究活动一定能够服务于当前迭代即将诞生的代码和产品。更多的人开始谨慎选择自动化策略,缩减自动化投入。因而,更多的问题指向敏捷开发专家,我们是不是需要自动化测试,何时开始自动化测试,多少投入自动化测试工具和脚本的开发是值得的。

关于要不要做自动化测试,我们的回答是肯定的。迭代模式使得代码量逐步累加的同时,越靠后的迭代,我们所面临的整合测试压力、测试任务就越重。而且敏捷测试需要测试人员能够随时启动自动化的回归测试对马上发布的迭代代码进行快速验证。

我们借鉴传统测试中自动化测试规划的细则,基于敏捷迭代的特点对自动化测试规划做进一步分析。

6.5.7 与传统自动化的对比

迭代次数(n)、测试覆盖次数越多,自动化测试带来的好处就越多,而产品开发中出错率(d%)越小,自动化测试效果越好。这是我们在之前的分析中得出的结论。

但是,因为迭代目标和对象的差异性,自动化脚本可能需要大幅修改。而重新构造和改变测试脚本带来的代价和成本也非常大。

特别是在敏捷测试中,产品变化之大给自动化测试带来的难度也陡然增加。因此,敏捷测试中,我们要以更精细的单位来计算自动化测试的投入产出比。即决策敏捷自动化测试的投入产出应该基于每个迭代自身的收益,而不是整个产品开发周期。

在每个迭代的2~4周的时间内,我们将经历从测试策略的选择、测试脚本和用例的撰写到即刻的测试执行和短暂的回归测试。我们不能保证回归测试完全自动化,因为我们可能没有足够的时间投入自动化开发,而正是因为测试脚本和用例的生命短暂,我们开发的成本也如期望的一样缩减了。

因为敏捷模式在不同项目中的实践存在较大的差异,所以在进一步分析敏捷测试下的自动化测试规划之前,我们先来描述一个理想的敏捷测试模型。

在这个模型里,我们的迭代周期为4周,团队共有7名成员,其中只有1名是测试人员。在这4周的活动中,我们将讨论敏捷测试的自动化测试规划方案。如图6-6所示。

00041.jpeg

图6-6 敏捷测试工作流最佳实践

迭代的第一周,测试人员集中确定测试策略,制定可行的测试计划并划定充分的测试范围。

第二周,准备开始测试的执行,因此要准备好测试用例和测试环境。需要注意的是,测试人员是根据需求和团队讨论而设计出的用例来开发测试用例的。

第三周的第三天,基于约定,第一个可以执行的产品代码已经能够发布了(这个约定的履行需要整个团队的配合),之后我们便可开始功能测试。直到第三周周末,一部分功能测试已经完成,大部分关键的新功能得到验证。

第四周,我们将要结束迭代的测试,在这一周中,不但要完成新功能和新非功能需求的测试,也要顾及持续性开发带来的老代码的质量风险。也就是说,产品的回归测试将在这周内开始并结束。同样,基于约定,我们将迭代最后的两天或者更少时间作为回归测试阶段。正如基于Scrum的模式拥有严格的周期制度一样,一旦进入了回归测试阶段,所有人都要配合、遵守Code Freeze(代码冻结)等时间约定。

6.5.8 自动化的ROI

我们对自动化的规划也将融入这个4周计划。同样,为了更好地分析,我们需要几个假设和声明。

声明1:n为进入回归测试后我们仍然需要对测试用例反复测试的次数。

声明2:d%为这段时间内测试的平均出错率。

声明3:TotalEf为执行一次回归测试所花费的执行成本。

假设1:产品迭代周期为4周。

假设2:在此次迭代中,第一个可测的产品发布于第三周的第三天。

假设3:回归测试于第四周的倒数第一或者第二天进入,在此之前测试人员要完成新功能测试。

假设4:一个迭代达到退出的标准是(d%)n<5%,即95%的测试都通过了,这样的迭代才能使客户满意。

因此,迭代次数n就必须满足

00043.jpeg

根据测试的最佳实践,我们假设测试人员将用迭代的最后1~2个工作日完成回归测试。

因此,如果TotalEf是执行一次回归测试用例所花费的代价的话,那么

00085.jpeg

根据公式10和公式11,我们可以得出

00080.jpeg

将公式12代入公式9得到公式13(不是十分严谨,不过不影响分析)

00099.jpeg

绘制其曲线时,n为横坐标,取值为1:1:10,x为自动化工具、脚本开发维护的最大投入。

如图6-7所示,我们可以得到以下基于敏捷测试的自动化测试规划的规律:一般产品的测试错误率高于20%,因此,为了达到质量标准使测试足够退出,回归测试至少需要3次,在这种情况下我们允许投入到自动化开发的成本不多于3人天。

00116.jpeg

图6-7 迭代中自动化测试脚本开发与维护成本规划

而当产品质量非常好,错误率低于20%时,因为不需要经过多次测试便可达到退出标准,可以省去自动化测试的步骤。

最后是一点经验之谈,当我们从事敏捷测试活动时,在以4周为周期的迭代测试中,测试人员在第二周的开始进入自动化脚本开发,开发活动不宜超过3天。

6.5.9 小结

基于假设的数学公式所指示的结果和客观规律令人吃惊,但我们的确感同身受,投入自动化测试的研究和调查越久,越客观地感受到自动化测试的好处和弊病。自动化投入并非越多越好,自动化测试对产品的质量提高作用也不是很大(目前不是,希望将来可以)。我们并不指望自动化测试可以取代手动测试,但是测试人员合理、科学地使用自动化测试,是提高测试成效的途径之一。ROI的自动化规划将非常适合敏捷测试、传统测试的最佳原则。

而成功的自动化测试除了拥有良好的规划外,自动化成本越低,开发工具越简易,自动化维护和管理复杂度越小,自动化测试也越容易驾驭。因此,在同等自动化规划下,测试人员应当采用更成熟的自动化测试工具,积极参与自动化测试经验交流,以不断提高测试自动化开发的生产率,以有限的投入获得更大测试收益。