网站更新服务公司,如何搭建一个企业子账号网站,企业网站源码搜一品资源,哈市哪里网站做的好自动化测试用例失败重跑有助于提高自动化用例的稳定性#xff0c;那我们来看一下#xff0c;python和java生态里都有哪些具体做法#xff1f;
怎么做
如果是在python生态里#xff0c;用pytest做测试驱动#xff0c;那么可以通过pytest的插件pytest-rerunfailures来实现…自动化测试用例失败重跑有助于提高自动化用例的稳定性那我们来看一下python和java生态里都有哪些具体做法
怎么做
如果是在python生态里用pytest做测试驱动那么可以通过pytest的插件pytest-rerunfailures来实现失败用例重跑具体的使用方式有两种一种是通过命令行指定pytest --reruns 2 --reruns-delay 1reruns表示重复运行次数reruns-delay 表示重复运行是的延迟时间。另一种方式是通过pytest.mark.flaky(reruns2, reruns_delay1)这种方式一般运用不想全局所有的测试用例都重跑只是特定的测试用例需要跑那就在特定的测试方法上使用这个标记。 如果是在java生态里用junit做测试驱动junit5提供了注解RepeatTest(2)可以试下测试类或者测试方法的重复运行也可以自定义通过实现个TestRule接口来控制测试用例的运行。
public class MyTestClass {Rulepublic RepeatRule repeatRule new RepeatRule();TestRepeat(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;}Overridepublic void evaluate() throws Throwable {for (int i 0; i repeat; i) {statement.evaluate();}}}Overridepublic 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自动化应该做好显式和隐式等待。
什么样的失败用例应该重跑
在测试框架中最好能区分出什么样的异常时服务异常什么是测试框架本身的异常对于服务异常可以适当重试对于框架异常不进行重跑直接抛出。断言失败当然更不需要重跑。所以在控制测试用例执行的时候不要一股脑儿的全都重跑有选择性的既要保证稳定性还要保证效率让自动化发挥价值。
总结
测试要做到有的放矢在合适的时候做合适的事情自动化测试的价值就是因为它能快速的检查系统如果因为重试导致运行的时间成倍增加是没有任何意义的还不如抛出错了尽快去解决。而且自动化测试用例的运行顺序也要控制处于业务前方的接口尽量先跑处于业务后方的接口尽量后跑。比如登陆接口和下单接口登陆接口属于业务靠前的下单是靠后的一般在测试下单接口的时候都要初始化登陆状态这个时候会调用登陆接口在测试用例批量执行的时候可以先让登陆接口测试用例先跑如果这个接口有问题那么其他需要登陆接口配合的用例全都会失败那这样后面的用例就不用跑了这样会节省很多的时间。
