写点什么

TestNG 测试用例重跑详解及实践优化

  • 2020-05-26
  • 本文字数:4369 字

    阅读完需:约 14 分钟

TestNG测试用例重跑详解及实践优化

测试用例运行稳定性是自动化质量的一个重要指标,在运行中需要尽可能的剔除非 bug 造成的测试用例执行失败,对于失败用例进行重跑是常用策略之一。一种重跑策略是所有用例运行结束后对失败用例重跑,另一种重跑策略是在运行时监控用例运行状态,失败后实时重跑。


下面,详细介绍 TestNG 如何对失败测试用例实时重跑并解决重跑过程中所遇到问题的实践和解决方案。对失败测试用例进行实时重跑,有以下几个方面需求:


  1. 测试用例运行失败,监听到失败后立即进行重跑

  2. 测试用例通过 dependsOnMethods/dependsOnGroups 标记依赖其他测试用例,在被依赖的测试用例重跑运行成功后,该测试用例可以继续运行

  3. 对于重跑多次的测试用例,只记录最后一次运行成功或失败结果

一、测试用例重跑

1.1 retryAnalyzer 注解方式

对于希望测试用例中的少量易失败,不稳定的测试用例进行重跑,可采用这种方式。

1.1.1 原理

以下是 TestNG 处理测试用例运行结果的部分代码。


IRetryAnalyzer retryAnalyzer = testMethod.getRetryAnalyzer();boolean willRetry = retryAnalyzer != null && status == ITestResult.FAILURE && failure.instances != null && retryAnalyzer.retry(testResult);if (willRetry) {  resultsToRetry.add(testResult);  failure.count++;  failure.instances.add(testResult.getInstance());  testResult.setStatus(ITestResult.SKIP);} else {  testResult.setStatus(status);  if (status == ITestResult.FAILURE && !handled) {    handleException(ite, testMethod, testResult, failure.count++);  }
复制代码


分析以上代码,其中,接口 IretryAnalyzer 的方法 retry()的返回值作为是否对失败测试用例进行重跑的一个条件。如果 retry()结果为 true,则该失败测试用例会重跑,同时将本次失败结果修改为 Skip;如果结果为 false,则失败的测试用例保持失败结果,运行结束。因此,如果你希望失败测试用例重跑的话,需要把 IretryAnalyzer 的 retry()方法重写,插入自己定义的逻辑,设置返回值为 true。

1.1.2 代码

创建类 RetryImpl,重写 retry()方法,设置失败测试用例的重跑次数,代码如下:


public class RetryImpl implements IRetryAnalyzer {    private int count = 1;    private int max_count = 3;   // Failed test cases could be run 3 times at most    @Override    public boolean retry(ITestResult result) {        System.out.println("Test case :"+result.getName()+",retry time: "+count+"");        if (count < max_count) {            count++;            return true;        }        return false;    }}
复制代码

1.1.3 实例

public class TestNGReRunDemo {    @Test(retryAnalyzer=RetryImpl.class)    public void test01(){        Assert.assertEquals("success","fail");        System.out.println("test01");    }}
复制代码


以上测试用例 test01 可重复运行 3 次。

1.2 实现接口 IAnnotationTransformer 方式

如果希望所有失败的测试用例都进行重跑,采用 retryAnalyzer 注解方式对每个测试用例进行注解就比较麻烦。通过实现 IAnnotationTransformer 接口的方式,可以对全量测试用例的重试类进行设置。该接口是一个监听器接口,用来修改 TestNG 注解。IAnnotationTransformer 监听器接口只有一个方法:transform(ITestAnnotation annotation, Class testClass, Constructor testConstructor, Method testMethod). 上文中,我们自定义了类 RetryImpl 实现接口 IRetryAnalyzer。TestNG 通过 transfrom()方法修改 retryAnalyzer 注解。以下代码对 retryAnalyzer 注解进行修改设置

1.2.1 代码

创建类 RetryListener,代码如下。


public class RetryListener implements IAnnotationTransformer {
public void transform(ITestAnnotation annotation, Class testClass, Constructor testConstructor, Method testMethod) {
IRetryAnalyzer retry = annotation.getRetryAnalyzer(); if (retry == null) { annotation.setRetryAnalyzer(RetryImpl.class); } }}
复制代码

1.2.2 配置 Listener

TestNG 可以在配置文件或者测试类中对Listener类进行配置。


  • 方法一:在 TestNG 的配置 XML 中进行以下配置

  • 方法二:在测试类中通过 @Listeners 配置


@Listeners({RetryListener.class})public class TestNGReRunDemo {    @Test    public void test01(){        Assert.assertEquals("success","fail");        System.out.println("test01");    }}
复制代码


配置完成后,运行测试用例 test01,运行结果显示 test01 将重跑次数 3 次。

二、被依赖的测试用例重跑结果处理

进一步分析 TestNG 的运行代码,其在对失败运行用例重跑时,逻辑如下图。



对于通过 dependsOnMethods 或 dependsOnGroups 注解依赖于其他测试用例的测试用例来讲 ,测试用例执行分为两种情况:


  • alwaysRun=true: 则无论所依赖的测试用例执行情况如何,该测试用例都会执行, 即所依赖的测试用例重跑不会影响该测试用例的执行

  • alwaysRun=false: 或者保持缺省值(false),依赖于其他测试用例或测试用例组的测试结果,在运行时 TestNG 获取所依赖的测试用例的运行结果,检查依赖的测试用例是否全部执行成功,如果不全部成功,则 把该测试用例结果设置为 Skipped

2.1 场景分析:场景一

被依赖的测试用例失败后进行了重跑,并重跑成功。(注:在 RetryImpl 类中,已设置最大重跑次数 max_count = 3


public static int number =0;
@Testpublic void test01(){number++;System.out.println(String.valueOf(number));Assert.assertEquals(number,2); System.out.println("test01");}
@Test(dependsOnMethods = "test01") // alwaysRun = false by defaultpublic void test02(){ System.out.println("test02 is running only if test01 is passed.");}
复制代码


1、TestNG 测试报告



2、问题


测试用例运行次数运行情况测试报告
Test012第一次:skipped ; 第二次:passed在Skipped 和Passed的统计数量中,test01被分别记录一次
Test020Skipped记录一次Skipped


  • 测试报告: test01 运行结果全部被记录,而用例重跑,只希望记录最后的结果。

  • 运行情况: 测试用例 test02 依赖于测试用例 test01 运行结果,在 test01 重跑成功后,测试用例 test02 没有执行,不符合需求预期

2.2 场景分析:场景二

被依赖的测试用例失败后进行了重跑,并且重跑没有成功。(注:在 RetryImpl 类中,已设置最大重跑次数 max_count = 3)


public static int number =0;@Testpublic void test01(){number++;System.out.println(String.valueOf(number));Assert.assertEquals(number,10);    System.out.println("test01");}
@Test(dependsOnMethods = "test01") // alwaysRun = false by defaultpublic void test02(){ System.out.println("test02 is running only if test01 is passed.");}
复制代码


1、TestNG 测试报告



2、问题


测试用例运行次数运行结果测试报告
Test013第一次:skipped;第二次:skipped;第三次:failed在Skipped统计数量中,test01被被记录两次在failed统计中,test01被记录一次
Test020Skipped记录一次Skipped


  • 运行情况: 测试用例 test02 依赖于测试用例 test01 运行结果, 在 test01 重跑失败后,测试用例 test02 没有执行,这种情况符合需求预期

  • 测试报告: 同场景一,test01 重跑失败,运行结果全部被记录,而用例重跑,只希望记录最后的结果。

三、优化解决方案

以下方案解决重跑测试用例成功后后继测试用例无法继续运行的问题,并对测试报告进行优化。

3.1 TestListenerAdapter 方法重写

根据上面分析的 TestNG 逻辑,在对依赖测试用例的结果进行检查如果忽略重跑的中间结果只检查最后一次的运行结果,可以达到需求的。对于测试报告,同样的处理方式,忽略所有中间的测试用例运行结果,只记录最后结测试用例的中间运行结果为 Skipped,下面的代码通过重写 TestListenerAdapter 的 onTestSuccess()和 onTestFailure()方法,对测试用例的中间结果 skipped 进行了。代码如下:


public class ResultListener extends TestListenerAdapter {    @Override    public void onTestFailure(ITestResult tr) {        if(tr.getMethod().getCurrentInvocationCount()==1)        {            super.onTestFailure(tr);            return;        }
processSkipResult(tr); super.onTestFailure(tr); } @Override public void onTestSuccess(ITestResult tr) { if(tr.getMethod().getCurrentInvocationCount()==1) { super.onTestSuccess(tr); return; } processSkipResult(tr); super.onTestSuccess(tr); } // Remove all the dup Skipped results public void processSkipResult(ITestResult tr) { ITestContext iTestContext = tr.getTestContext(); Iterator<ITestResult> processResults = iTestContext.getSkippedTests().getAllResults().iterator(); while (processResults.hasNext()) { ITestResult skippedTest = (ITestResult) processResults.next(); if (skippedTest.getMethod().getMethodName().equalsIgnoreCase(tr.getMethod().getMethodName()) ) { processResults.remove(); } } }}
复制代码

3.2 配置结果处理 Listener 类

在配置文件进行全局设置或者在测试类中标记。


  • 方法一:在 TestNG 的配置 XML 中进行以下配置

  • 方法二:在测试类中通过 @Listeners 配置

3.3 场景一

1、 结果验证



2、结果分析


测试用例运行次数运行结果测试报告
Test012第一次:skipped;第二次:passed只在Passed的统计数量中test01被记录一次
Test021Passed记录一次passed

3.4 场景二

1、结果验证



2、结果分析


测试用例运行次数运行结果测试报告
Test013第一次:skipped;第二次:skipped;第三次:failedtest01只在failed统计中被记录一次
Test021Skipped依赖用例执行失败,test02结果为Skipped,只记录一次结果Skipped


本文转载自公众号宜信技术学院(ID:CE_TECH)。


原文链接


https://mp.weixin.qq.com/s/PLF-1RXbMPU1mWpOwiSamA


2020-05-26 10:001745

评论

发布
暂无评论
发现更多内容

Soul 学习笔记---soul 数据同步的浅显分析(四)

fightingting

Soul网关

Spring 源码学习 15:finishBeanFactoryInitialization(重点)

程序员小航

spring 源码

产品0期-第一周作业

曾烧麦

产品训练营

【并发编程】- 内存模型篇

双木之林

并发编程

作业-week1

赝品

4K高清视频下载(4K视频素材下载)图文教程

科技猫

下载器 4k高清视频下载 4k视频素材下载 8k视频下载 高清视频下载

第一次作业提交

涅米丶

干货丨深度迁移学习方法的基本思路

博文视点Broadview

Java 程序经验小结:消除GC触及不到的过期对象引用

后台技术汇

28天写作

《原神》运维自动化的探索与实践

OpsMind

运维 运维自动化

当前岗位的理想岗位模型

白生

AI无人机出手,让输电线路巡检更“聪明”!

华为云开发者联盟

华为云 modelarts 视觉处理

产品经理训练营-第一周作业

羽室

一种分表平滑扩容方案

非著名架构师

IO系列专题分享 - 概览

公众号:程序猿成神之路

io

一字一句的让你彻底掌握JavaScript中的回调函数

华为云开发者联盟

JavaScript 大前端 同步 回调函数

6道tomcat面试题,最后两道难倒我了

田维常

面试

产品经理训练营第一周作业

Empty

产品经理训练营 极客大学产品经理训练营

经验说丨华为云视频Cloud Native架构下实践

华为云开发者联盟

架构 微服务 华为云 CloudNative

如何构建高效可信的持续交付能力,华为云有绝活!

华为云开发者联盟

软件 DevOps 持续交付 华为云

场外OTC交易APP系统软件开发

系统开发

雪天专注行路思考一则

石君

冥想 28天写作

产品经理训练营-第一章作业

泡面加煎蛋

产品经理训练营

纳豆卡玛

求职 岗位要求 职能描述

开发实战:LocalDateTime转RFC3339格式

worry

量化交易自动炒币软件开发系统

这样提问,大牛才会为你解答(提问的智慧)

yes

开发实战:Float如何保留2位小数

worry

Soul学习笔记---运行 soul-examples-http(二)

fightingting

Soul网关

个人选择理财产品有哪些好方法

v16629866266

产品经理训练营 学习起点

DB

TestNG测试用例重跑详解及实践优化_软件工程_耿燕飞_InfoQ精选文章