内容简介:自动化测试用例失败重跑有助于提高自动化用例的稳定性,那我们来看一下,python和java生态里都有哪些具体做法?如果是在python生态里,用pytest做测试驱动,那么可以通过pytest的插件pytest-rerunfailures来实现失败用例重跑,具体的使用方式有两种,一种是通过命令行指定pytest --reruns 2 --reruns-delay 1,reruns表示重复运行次数,reruns-delay 表示重复运行是的延迟时间。另一种方式是通过@pytest.mark.flaky(rer
自动化测试用例失败重跑有助于提高自动化用例的稳定性,那我们来看一下,python和 java 生态里都有哪些具体做法?
怎么做
如果是在 python 生态里,用pytest做测试驱动,那么可以通过pytest的插件pytest-rerunfailures来实现失败用例重跑,具体的使用方式有两种,一种是通过命令行指定pytest --reruns 2 --reruns-delay 1,reruns表示重复运行次数,reruns-delay 表示重复运行是的延迟时间。另一种方式是通过@pytest.mark.flaky(reruns=2, reruns_delay=1),这种方式一般运用,不想全局所有的测试用例都重跑,只是特定的测试用例需要跑,那就在特定的测试方法上使用这个标记。
如果是在java生态里,用junit做测试驱动,junit5提供了注解@RepeatTest(2),可以试下测试类或者测试方法的重复运行,也可以自定义,通过实现个TestRule接口,来控制测试用例的运行。
public class MyTestClass { @Rule public RepeatRule repeatRule = new RepeatRule(); @Test @Repeat(10) public void testMyCode() { //your test code goes here } } import static java.lang.annotation.ElementType.ANNOTATION_TYPE; import static java.lang.annotation.ElementType.METHOD; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; @Retention( RetentionPolicy.RUNTIME ) @Target({ METHOD, ANNOTATION_TYPE }) public @interface Repeat { int value() default 1; } import org.junit.rules.TestRule; import org.junit.runner.Description; import org.junit.runners.model.Statement; public class RepeatRule implements TestRule { private static class RepeatStatement extends Statement { private final Statement statement; private final int repeat; public RepeatStatement(Statement statement, int repeat) { this.statement = statement; this.repeat = repeat; } @Override public void evaluate() throws Throwable { for (int i = 0; i < repeat; i++) { statement.evaluate(); } } } @Override public Statement apply(Statement statement, Description description) { Statement result = statement; Repeat repeat = description.getAnnotation(Repeat.class); if (repeat != null) { int times = repeat.value(); result = new RepeatStatement(statement, times); } return result; } }
还有就是如果使用到了maven可以添加一个rerunFailingTestsCount参数,不过这个是控制所有的用例了。
为什么要让失败用例重跑呢
因为自动化一般都会在测试环境或者其他非线上的环境,由于环境的不稳定可能会导致测试用例莫名其妙的失败,是用例的稳定性大打折扣。这个时候加入失败重跑机制,能够在一定范围内提高测试用例的稳定性,做出更多的产出。
什么样的自动化用例要进行失败重跑
接口自动化测试用以建议可以加入这种失败重跑,而对于UI接口接口自动化,失败重跑的话,觉得意义不大,因为往往当用例的失败的时候,要么是由于界面元素没加载出来,要么是用例的逻辑有问题,要么是意外的弹窗影响,这个时候应该让错误尽早的抛出来,好尽快的修复,而不是在哪儿一个劲的重试,没啥用。UI自动化应该做好显式和隐式等待。
什么样的失败用例应该重跑
在测试框架中,最好能区分出什么样的异常时服务异常,什么是测试框架本身的异常,对于服务异常可以适当重试,对于框架异常不进行重跑,直接抛出。断言失败当然更不需要重跑。所以在控制测试用例执行的时候,不要一股脑儿的全都重跑,有选择性的,既要保证稳定性,还要保证效率,让自动化发挥价值。
总结
测试要做到有的放矢,在合适的时候做合适的事情,自动化测试的价值就是因为它能快速的检查系统,如果因为重试导致运行的时间成倍增加,是没有任何意义的,还不如抛出错了,尽快去解决。而且自动化测试用例的运行顺序也要控制,处于业务前方的接口尽量先跑,处于业务后方的接口尽量后跑。比如登陆接口和下单接口,登陆接口属于业务靠前的,下单是靠后的,一般在测试下单接口的时候都要初始化登陆状态,这个时候会调用登陆接口,在测试用例批量执行的时候,可以先让登陆接口测试用例先跑,如果这个接口有问题,那么其他需要登陆接口配合的用例全都会失败,那这样后面的用例就不用跑了,这样会节省很多的时间。
欢迎大家去 我的博客 瞅瞅,里面有更多关于测试实战的内容哦!!
以上所述就是小编给大家介绍的《关于自动化测试用例失败重试的一些思考》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 如何避免移动测试自动化失败
- 快速失败机制 & 失败安全机制
- 通过不断地失败来避免失败,携程混沌工程实践
- 快速失败(fail-fast)和安全失败(fail-safe)
- greenplum 集群启动失败
- Nginx 失败重试机制
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。