提升测试的稳定性之高频——阿里测试之道(07)

发表于:2022-4-12 09:33

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:阿里巴巴技术质量小组    来源:51Testing软件测试网原创

  1.5提升测试的稳定性
  很多测试团队面临的最大难题就是自动化测试的通过率低、噪声大。在理想情况下,我们希望每个失败的测试用例都是由真正的Bug引起的。但实际情况是,自动化测试经常因为其他原因导致失败,例如,同时执行的用例之间相互影响、人对测试环境的影响、测试环境底层基建的不稳定、测试环境里的脏数据、测试用例本身有问题等。
  自动化测试稳定性差带来的后果是:
  ·失败用例的排查工作量非常大。
  ·对自动化测试丧失信任和信心。如果发现大部分失败用例都是非代码Bug原因,有些人员就不会重视,只对失败的用例草草看一眼,就说这是一个“环境问题”,不再排查下去了。这样一来,很多真正的Bug就被漏掉了。
  ·更多的问题被掩盖了。
  本节着重讲述我们是如何达到和保持很高的测试稳定性的。《隋唐演义》一书里的程咬金虽然只有三斧子半的招式,但很有效,他就靠着这三斧子半打赢了很多对手。提升测试稳定性,我们也有三斧子半的招式:第一招——高频;第二招——隔离;第三招——用完即抛;最后半招:不自动重跑。

  1.5.1高频
  高频之所以排在第一位,是因为它不但对提高测试稳定性有“奇效”,也是很多其他软件工程中解决问题的方法。用MartinFowler的话来说,就是“Ifithurts,doitmoreoften”。举几个靠高频解决问题(FrequencyReducesDifficulty)的例子。
  持续打包:笔者的团队过去只在部署测试环境前才打包,经常因为打包问题导致部署花费很多时间,影响后面的测试进度。针对这个问题,我们做了持续打包,每隔半小时或一小时对master或者项目分支的HEAD打包,一旦遇到问题,马上修复。
  发布:如果在发布过程中问题很多,那么可以尝试更高频地发布。如果原来每周发布一次,就改成每天发布一次,除了原来每周一次的发布,一周里的其余日子,就算没有新代码合并进来,也要“空转”发布一次。这样做的目的是用高频来暴露问题,倒逼发布过程中各环节的优化。
  证书和密钥的更新:证书容易过期?证书更新的过程不够自动化?用高频。把原来两年一次甚至更久一次的证书更新频率提高到每三个月或六个月一次。用这样的高频率来倒逼证书更新的自动化,暴露证书管理机制中的问题。
  容灾演练:蚂蚁SRE团队用的也是高频的思路,为了加强容灾能力建设、提高容灾演练的成功率,SRE团队的一个主导思想就是高频演练,用高频演练来充分暴露问题,倒逼能力建设。
  另外,从测试稳定性上看。高频测试的好处有以下几点:
  缩短反馈弧。如果一个团队进行功能回归测试的频率是一天一次(例如,每天早上6点),那么星期一白天做的代码改动和Bug修复的测试结果要星期二才能看到。更糟糕的是,如果星期二的测试执行结果显示星期一的代码有问题,那么即便星期二当天就能修复这些问题,修复的效果也要等到星期三才能看到。这样以“天”计的节奏是不符合敏捷开发和业务快速发展要求的。我们希望的节奏是:早上10点改的代码,午饭前就能看到功能测试结果;根据测试结果,做相应的改动,下午就能通过功能回归测试了。
  变主动验证为“消极等待”,减少测试人员的工作量。过去,开发人员修复了一个失败用例背后的代码问题,测试人员要手动触发这个用例,检查是否通过,当Bug数量较多时,测试人员工作量较大。有了高频的功能回归后,功能回归用例集每小时都执行一遍最新的代码。当开发人员提交了Bug修复后,测试人员不再需要手动触发用例,而只要“消极”地等着看下一个小时的测试结果。
  识别和确认小概率问题。当一天只有一次测试时,如果开发人员说一个用例失败的原因是数据库抖动,那么我们也许能接受。但当每小时都有一次测试,连续三次都得出同样的失败结果时,数据库抖动的理由就说不通了,可以推动开发人员进行更深入的排查。
  暴露基建层的不稳定因素。
  倒逼人工环节自动化。如果一个团队进行功能回归的频率是一天一次,那么其中的一些人工步骤就可能被容忍。例如,敲一个命令、编辑一个配置文件、设置几个参数、点几下按钮。这些手动步骤本身很可能出错,导致测试通过率下降。而用高频的手段,把功能回归的频率从一天一次提高到一小时一次,工程师可能就无法容忍这些手动步骤了,就有动力把这些步骤改为自动化实现,从而也减少了人工出错的可能。
  为分析提供更多的数据。
  笔者所在团队的成员一开始并不理解高频的重要性,对高频测试有一些疑问,例如,问题1:为什么一定要定时进行测试呢?为什么不能变成每次有代码提交再触发呢?问题2:进行高频测试,需要更多的资源,成本很高,值得吗?
  问题3:原来一天只测试一次,对于失败的用例,已经没有时间一一排查了,现在频率更高了,岂不是更没有时间排查了?
  对于问题1,可以让每次代码提交都触发测试执行,但定时的测试仍然必须要有,因为代码提交的频率是不均匀的。在每天代码提交较少的时间段,即便代码没有变,我们仍然希望保持测试执行的频率,以便及时发现基建层的问题。另外,我们需要保持测试执行的频率,以产生足够的数据来分析、识别和确认小概率问题。
  对于问题2,高频测试对测试资源的需求的确会成倍地增长,甚至是呈数量级的增长。但多花了这么多钱用来做高频测试,换来的是自动化的噪声大大降低、无效排查大大减少、被掩盖的质量问题大大减少、工程师的幸福感上升,是值得的。另外,高频测试使用的资源有各种优化的途径:可以优化测试用例,缩短每次执行的时间;可以优化资源调度算法,尽可能地把空闲的资源利用起来,提升资源利用率。
  对于问题3,实际上,排查工作量并不会剧增。因为并不是每次执行的结果都一定要排查。而且,高频测试开始以后,问题很快就会收敛,所以需要排查的总量并不会增加太多。以笔者的经验,在开始高频测试后,排查错误的工作量反而小了。
  实际上,1.2节提到的代码门禁和1.3节提到的持续集成所采取的两个破局点都和高频有关。
  代码门禁:我们除了把单元测试接口测试移到代码提交前进行,还在主干分支上高频运行所有的单元测试和接口测试。也就是说,除了在每次代码提交后触发,我们还按照每15分钟一次的固定频率运行,每天运行将近100次。之所以这样做,是因为有些代码问题(包括单元测试和接口测试的代码问题)是以一定的概率发生的,可能在代码门禁和代码提交后触发的执行中都没有发生,而每天运行将近100次的高频测试却能把这类问题很好地暴露出来。
  持续回归:功能回归测试从原先的每天1~2次改为每小时1次,每天24次,以加快将当前版本的代码推进到预发和灰度验证阶段的速度。

查看《阿里测试之道》全部连载章节
版权声明:51Testing软件测试网获得作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可,不得对本文内容复制、转载或进行镜像,否则将追究法律责任
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号