如何利用TestNG监听器优化测试报告？

分手后的思念是犯贱 2022-01-13 15:19 290阅读 0赞

如何利用testng监听器优化测试报告。

**　　一、给工程添加失败重试机制**

接口用例量上来以后，我们遇到的第一个问题是http方式调用php接口会有部分接口偶尔不稳定或者超时的情况，但第二次运行又正常，每次接口失败都需要花费时间排查，但实际没有问题，为了排除不稳定带来的干扰，给大家节约排查维护时间，首先需要解决的是给工程添加失败自动重试机制。

目前我的做法是实现了testng自带的IRetryAnalyzer接口，定义了一个MAX \_ RETRY\_COUNT，即大重试次数，实现的retry方法非常简单，如下：

public boolean retry(ITestResult result) \{

if (retryCount < MAX\_RETRY\_COUNT) \{

retryCount++;

return true;

return false;

如果团队有人想要使用失败重试的功能也很简单，只需要在Annotation里面加上retryAnalyzer属性即可，如下：

@Test(retryAnalyzer = TestRetry.class)

public void summaryTest()\{

String url = urlList.get(0);

JSONObject map = ResponseJsonBase.manageJson(url， "");

String total = map.getString("total");

assert "7.59".equals(total) : url;

这种方式带来的好处是有比较大的自由度，可以自由选择某个用例是否需要失败重试的功能，因为部分接口重试第二次是不允许的，比如分销的关注接口（有频率限制等）。身为一名IT技术人员磨练自己的技术是必不可少的，欢迎加入测试交流群（1017539290），可以与大牛在线随时讨论自己感兴趣的话题，让自己用最少的时间学到最多的东西。 但是仅仅到这里还是会有问题，首先会发现我们的接口测试报告有问题，其次会发现失败重试后通过的情况下，依然会有邮件提醒，我们还是需要花费很多时间看接口问题。在这里，我为了复现当时遇到的问题，随便造了一个有问题的接口测试报告：

![1240][]

**　　二、通过定义一个监听器优化测试报告**

根据遇到的问题，首先我们需要优化一下测试报告，从而避免给大家带来太多干扰。 我的做法是定义了一个testng的监听器来处理失败重试的用例。具体实现是通过继承TestListenerAdapter类，覆盖onTestFailure、 onStart、 onFinish方法，贴一下主要的代码段：

@Override

public void onTestFailure(ITestResult tr) \{

if (tr.getMethod().getRetryAnalyzer() == null) \{

log(tr.getMethod() + "--Test method failed ");

if (tr.getMethod().getRetryAnalyzer() != null) \{

TestRetry testRetry = (TestRetry)       tr.getMethod().getRetryAnalyzer();

if (testRetry.getRetryCount() < testRetry.getMaxRetryCount()) \{

tr.setStatus(ITestResult.SKIP);

Reporter.setCurrentTestResult(null);

isRemoveSkipNeeded = true;

skippedCases.addResult(tr， tr.getMethod());

else \{

failedCases.addResult(tr， tr.getMethod());

isRetryNeeded = true;

其实上面代码里面是统一对失败的用例做处理，每次失败都会去判断是否已经达到大失败次数，如果没有，会将该用例状态设置为skip，到这里为止，看我们的测试报告，大概长这样：

![1240][1240 1]

可以看到，依然有很明显的问题，我们还需要做的事情是：失败的用例列表去重，以及在Skipped的testcase里面剔除真正Failed的Test Case。 其实测试报告的主要数据获取是下面几个：

getFailedConfigurations()

getSkippedConfigurations()

getFailedTests()

getSkippedTests()

做对应优化很简单了身为一名IT技术人员磨练自己的技术是必不可少的，欢迎加入测试交流群（1017539290），可以与大牛在线随时讨论自己感兴趣的话题，让自己用最少的时间学到最多的东西。，贴下我这边failed Cases去重的代码段，可以举一反三写其他几个：

private void removeFailedTestsInTestNG(ITestContext test) \{

IResultMap returnValue = test.getFailedTests();

for (ITestResult resultToCheck : failedCases.getAllResults()) \{

int c = 0;

for (ITestResult result : returnValue.getAllResults()) \{

if (result.getMethod().equals(resultToCheck.getMethod())) \{

c++;

if (c > 1) \{

returnValue.removeResult(result.getMethod());

test.getFailedConfigurations().removeResult(

result.getMethod());

然后是在每个testSuit运行结束的时候，统一处理：

@Override

public void onFinish(final ITestContext testContext) \{

if(isRetryNeeded)\{

removeIncorrectlySkippedTests(testContext，failedCases);

removeFailedTestsInTestNG(testContext);

else\{

if(isRemoveSkipNeeded)

removeSkippedTestsInTestNG(testContext);

else\{

skippedCases= testContext.getSkippedTests();

failedCases= testContext.getFailedTests();

将该监听器配置到testng.xml内或者pom.xml内可以生效了。

自此为止，看下我们的测试报告已经是我们想要的样子了：

![1240][1240 2]

后是CI的配置，我用了扩展邮件插件，实现了一个相对直观的邮件模版，只对Fail和Fixed的情况进行提醒（见下图右），对于skipped的用例，虽然不再有邮件“骚扰”，但依然可以在jenkins里面查看（见下图左）

![1240][1240 3]

三、后续的优化空间上周，我在工程里面加了日志模块，会记录skip的和返回时间超过1秒的用例，设想是运行一段时间后，对这部分用例进行统计，看是否接口本身存在优化空间，这部分工作后续也是计划优化为自动完成、自动出图表，要看时间是否充足了

转载于:https://blog.51cto.com/14323783/2394588

[1240]: /images/20220113/cfa7bc6091c0431e8ca8a4a57b9d31a3.png
[1240 1]: /images/20220113/2f13321479dc473bb8f1f31e90b63a53.png
[1240 2]: /images/20220113/cb9675a00b8c4e68a950c4f4eb15f20b.png
[1240 3]: /images/20220113/5d35ad3d03744914b6a30b261ec2f71c.png