testNG一些总结

发表于 | 分类于

记录一些最近在做平台测试方案的时候，碰到的一些testNG相关的问题。

FAQ

group怎么取交集

// TODO 深坑待入

关于并发和执行顺序

  • 涉及到的配置项，主要有parallel， group-by-instances，priority，preserve-order
  • parallel+thread-count规定了testNG是否在testNG level并发运行，以及在什么层面进行并发

还原当时场景：

  • testNG单线程运行classes
  • classes之间的顺序无所谓
  • class中的methods要相邻运行，并且有序

国际惯例，testNG版本是：

<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>6.9.10</version>

一开始parallel=false，放到CI运行，发现method顺序不对。如果不指定priority，那么testNG默认是按照方法的字母序跑的，不好玩。具体可以参考这个：priority-in-testng-with-multiple-classes

所以改进，方案是：

除了before & after方法之外，都加了priority，并确保顺序正确

但是每个classes中指定了priority之后，一个class中的到是没问题了，可当testNG运行多个classes的时候，priority的scope扩展到了全部的classes，即先运行的是priority=1的方法，不管这个method在那个类，心塞，:(

继续查，找到了一个配置：group-by-instances，看介绍，配置group-by-instances=true之后，testNG就会按照所谓instances顺序运行了。在简单的demo测试中也确实是这样。but迁移到实际场景测试的时候，发现报了个错:

No free nodes found in:[DynamicGraph

好坑爹，搜了下貌似没什么靠谱的解释，可能进一步需要跟进源码搞搞了。

不过实验出来一个解决方案，是修改parallel=tests，再在CI运行，就达到了开头的场景需求。

—update on 20161215

在通过blockqueue实现了框架对test env的管理以后，对testNG运行的需求变成了

  • testNG classes level parallel
  • classes之间的顺序无所谓
  • class中的methods要相邻运行，并且有序

ok那其实就更简单了，修改配置：

  • parallel=classes
  • 删除group-by-instances=true

就达到目的了

另外吐槽下，官网文档指出可以通过实现：IMethodInterceptor来控制不存在dependency的method的order（戳这里）

  • Methods run sequentially. These are all the test methods that have dependencies or dependents. These methods will be run in a specific order.
  • Methods run in no particular order. These are all the methods that don’t belong in the first category. The order in which these test methods are run is random and can vary from one run to the next (although by default, TestNG will try to group test methods by class).

呸这是官方坑啊。。测试了顺序这个点并没有什么用，但是filter功能还是好使的，后续可以跟进一个issue来验证下。

相关的一些文档，记录一下：

instance是个什么鬼

把log变量设置为：verbose=10，可以看到这个instance的相关log，需要更深入的研究

// TODO:

test method fail相关处理

写测试用例并运行，避免不了用例的失败。有些策略和方法，跟其相关的，整理在了这里。

挂我一个大家都挂

一般对待测试method失败，有两种case比较常见：

  • 冒烟测试，hin重要，追求时效性，挂了其他测试也不用跑了，立刻stop并通知
  • 挂了统计下就好了，不影响其他

testng原生配置中，相关的有：configfailurepolicy，alwaysRun

先说configfailurepolicy

他的作用是控制了@beforeClass这种，执行失败后是否需要继续。具体可以戳官网配置

而alwaysRun就分三类咯：

  • 配置在@beforeXXX上面
  • 配置在@afterXXX上面
  • 配置在@Test上面

配置在@beforeXXX上面：For before methods (beforeSuite, beforeTest, beforeTestClass and beforeTestMethod, but not beforeGroups): If set to true, this configuration method will be run regardless of what groups it belongs to.

这个实践没用到，看样子可以考虑用在dependency的服务上，如log或者counter什么之类的。

配置在@afterXXX上面：For after methods (afterSuite, afterClass, …): If set to true, this configuration method will be run even if one or more methods invoked previously failed or was skipped

这个比较实用，类似finally的概念

配置在@Test上面：If set to true, this test method will always be run even if it depends on a method that failed.

因为method没使用dependency机制去维护，故这里也没用到。就算用，应该也是在classes的Test level，而非method。要不不得累死。

并且需要注意的地方是，alwaysRun比tesng中，test的配置enable=false的优先级是高的。具体如：
class的@Test配置了enable=false，而@AfterClass配置了alwaysRun=true，这时候包括@BeforeClass都没运行，而@AfterClass运行了，比较坑爹。

但但但是，针对上面的case，如果@AfterClass本身配置了enable=false，则@AfterClass就不会运行了。这应该也算是config生效的一种约定吧。

command执行test的最终结果

我用的是maven-surefire-plugin+testng的方式。surefire提供了一个配置项

testFailureIgnore, 默认是false

  • testFailureIgnore=true，method就算有失败，exit code也是0
  • testFailureIgnore=false，method只有全部pass，exit code才是0

如果真的使用exit code做些判断，则需要当心了

parallel=classes&dependsOnMethod的坑

hans的自动化方案中，class之间是完全解耦的，但是在class内部，method之间，为了避免默认字母序，还是需要顺序依赖的。testNG中能利用的方案有：

  • priority
  • dependsOnMethod

测试的时候发现一个坑，就是当parallel=classes&存在dependsOnMethod的时候，可能导致methodA运行完之后，methodDependsOnA被切换到另一个thread去运行。这样其实是对parallel=classes的一个破坏:(

官方github issue中也有记录：DependsOnMethods made parallel class use several threads

发现问题的版本是：6.9.12 and 6.9.13.8，继续跟进这个问题吧。

参考资料

  • 发现了一个jenkins的插件，不知道是否会有用，记录下先
    • 地址戳这里
    • 看了下，大概是count多个build中test的汇总
    • 汇总蛮有意思，chart也是，但是不知道能否展示或者搞log