持续集成:TestNG组织如何测试用例

 

poptest是国内唯一一家培养测试开发工程师的培训机构,以学员能胜任自动化测试,性能测试,测试工具开发等工作为目标。如果对课程感兴趣,请大家咨询qq:908821478,咨询电话010-84505200。在培训课程中,经常需要写大量的测试用例(Test Case)的例子,然后用TestNG进行自动化测试。随着test case数量的不断增加,发现目前写test case的方法存在一些不足之处。经过几天的思考和探索,找到一种充分利用TestNG的testng.xml配置文件组织test case的方法。

1. 目前组织test case的实践

将所有测试方法放在Common Task的类中,然后根据test case的测试逻辑,创建对应的测试类,然后用TestNG运行这些测试类。

目前实践的实例代码如下:

包含所有测试方法CommonTasks文件:

import java.util.Random;

public class CommonTasks {
public int method1(int max) {
System.out.println("Run method1()");
return new Random().nextInt(max);
} public int method2(int max) {
System.out.println("Run method2()");
return new Random().nextInt(max);
}
}

测试类TestCase1:先执行method1,后执行method2

import org.testng.Assert;
import org.testng.annotations.BeforeClass;
import org.testng.annotations.Parameters;
import org.testng.annotations.Test; public class TestCase1 {
CommonTasks task; @BeforeClass
public void setUp() {
task = new CommonTasks();
} @Test
@Parameters("max")
public void method1(int max) {
Assert.assertEquals(task.method1(max), 0, "Failed");
} @Test(dependsOnMethods = "method1")
@Parameters("max")
public void method2(int max) {
Assert.assertEquals(task.method2(max), 0, "Failed");
}
}

测试类TestCase2:先执行method2,后执行method1

import org.testng.Assert;
import org.testng.annotations.BeforeClass;
import org.testng.annotations.Parameters;
import org.testng.annotations.Test; public class TestCase2 {
CommonTasks task; @BeforeClass
public void setUp() {
task = new CommonTasks();
} @Test(dependsOnMethods = "method2")
@Parameters("max")
public void method1(int max) {
Assert.assertEquals(task.method1(max), 0, "Failed");
} @Test
@Parameters("max")
public void method2(int max) {
Assert.assertEquals(task.method2(max), 0, "Failed");
}
}

测试这两个test case的testng.xml文件:

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd" >

<suite name="Suite" verbose="1">
<parameter name="max" value="2"></parameter>
<test name="testcase1">
<classes>
<class name="com.ibm.testng.test.TestCase1"></class>
</classes>
</test>
<test name="testcase2">
<classes>
<class name="com.ibm.testng.test.TestCase2"></class>
</classes>
</test>
</suite>

目前组织test case的方法的不足:

1) 随着test case数量的增加,像TestCase1和TestCase2这样的测试类会越来越多。

2)TestCase1这样的测试类,只是根据测试逻辑调用测试方法,并Assert测试方法结果,并无其他功能。测试类间有很多像setUp,Assert这样的重复代码。

3)修改Common Task类和testng.xml都会对测试类产生影响。例如,修改CommonTasks中method1的名称,TestCase1和TestCase2中调用method1()的地方都得修改。修改testng.xml中参数max的名称,需要修改TestCase1和TestCase2中所有用到max变量的地方。

4)dependsOnMethods不被推荐使用。因为,method名称同时作为Java方法名称和字符串,只修改任何一个地方,都会导致方法找不到。

2. 新的组织test case的实践

目前的实践方法不仅存在很多重复冗余的代码,而且为以后的重构带来诸多不便。主要原因是测试类介于Common Task类和testng.xml之间,因此,新实践不再为每个test case创建测试类。

新实践的实例代码如下:

CommonTasks文件:

import java.util.Random;

public class NewCommonTasks {

    @Test(groups="method1")
@Parameters("max")
public void method1(int max) {
System.out.println("Run method1()");
Assert.assertEquals(new Random().nextInt(max), 0, "Failed");
} @Test(groups="method2")
@Parameters("max")
public void method2(int max) {
System.out.println("Run method2()");
Assert.assertEquals(new Random().nextInt(max), 0, "Failed");
}
}

测试这两个test case的testng.xml文件:

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd" >

<suite name="Suite" verbose="1">
<parameter name="max" value="2"></parameter>
<test name="testcase1">
<groups>
<dependencies>
<group depends-on="method1" name="method2"></group>
</dependencies>
<run>
<include name="method1"></include>
<include name="method2"></include>
</run>
</groups>
<packages>
<package name="com.ibm.testng.test.*"></package>
</packages>
</test>
<test name="testcase2">
<groups>
<dependencies>
<group depends-on="method2" name="method1"></group>
</dependencies>
<run>
<include name="method2"></include>
<include name="method1"></include>
</run>
</groups>
<packages>
<package name="com.ibm.testng.test.*"></package>
</packages>
</test>
</suite>

新实践基于TestNG的一个设计目标:Create a clean separation between thestatic model (the code of your tests) and the runtime model (which tests get run)。这里的static model指Java代码中的测试方法,runtime model指运行时的test case。

新实践将之前的测试类删掉,将测试类的annotation移到Common Task类中,将测试类的测试逻辑移到testng.xml中通过<dependencies>实现。这样做具有如下优势:

1)理想情况下,一个Common Task类和一个testng.xml就可以组织出所有test case。不存在代码重复率很高的测试类,class文件数量也不会随着test case数量的增加而增加。

2)修改Common Task类和testng.xml,相互之间的影响会非常小。修改Common Task类,再也不用去修改大量的测试类。修改testng.xml中的参数名称,也只需要修改Common Task类中很少的地方。

3)dependsOnGroups代替了dependsOnMethods,任意修改Common Task类中的method名称,都不会有印象。

当然,这种实现也不是完全没有缺点。例如:测试逻辑也放到testng.xml中后,在test case数量较多的情况下文件会比较长。不过可以根据某些特性将test case放到几个xml配置文件中,然后通过<suite-files>封装成一个suite一起测试。另外,当测试出现问题的时候,测试人员需要读testng.xml文件来追踪错误位置。如果在写testng.xml时将<run>标签中include的groups按逻辑先后顺序排列的话,也不会额外增加追踪错误的难度。

我们会发现这种实现的testng.xml中,每个test case都需要一个相同的<packages>,其实完全可以把这部分移到<suite>中,使其对所有的test case都有效。不过,这样的尝试没有成功,具体问题描述见testng github,希望知道该问题的人能够指点一下。同时,如果一个test case中要多次以不同参数运行同一group,就会遇到传参和dependency的问题。目前只有一种间接解决方案:将这个test case执行同一group的步骤分配到不同test中,TestNG会按照testng.xml中test的顺序去执行test case。

持续集成:TestNG组织如何测试用例的更多相关文章

  1. 持续集成:TestNG组织如何测试用例 1

    持续集成:TestNG组织如何测试用例   poptest是国内唯一一家培养测试开发工程师的培训机构,以学员能胜任自动化测试,性能测试,测试工具开发等工作为目标.如果对课程感兴趣,请大家咨询qq:90 ...

  2. 持续集成:TestNG中case之间的关系

    持续集成:TestNG中case之间的关系   poptest是国内唯一一家培养测试开发工程师的培训机构,以学员能胜任自动化测试,性能测试,测试工具开发等工作为目标.如果对课程感兴趣,请大家咨询qq: ...

  3. (转载)持续集成(第二版)[来自:Martin Fowler]

    转载自:iTech的博客 持续集成(第二版) 作者:Martin Fowler 译者:雷镇 持续集成 是一种软件开发实践.在持续集成中,团队成员频繁集成他们的工作成果,一般每人每天至少集成一次,也可以 ...

  4. Selenium Web 自动化 - 项目持续集成(进阶)

    Selenium Web 自动化 - 项目持续集成(进阶) 2017-03-09 目录 1 背景及目标2 环境配置  2.1 SVN的安装及使用  2.2 新建Jenkins任务3 过程分析 1 背景 ...

  5. CI/CD持续集成/持续部署 敏捷开发

    敏捷软件开发(英语:Agile software development),又称敏捷开发,是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力.它 ...

  6. [持续交付实践] 开篇:持续集成&持续交付综述

    前言 随着微服务架构与容器虚拟化技术的发展,持续集成与持续交付的概念又重新回到了大家的视野,越来越多的公司开始使用持续集成的系统来解决频繁发布带来的质量问题:使用持续交付的工具来实现代码在不同环境上的 ...

  7. 持续集成工具hudson

     2008-07-08  一.什么是持续集成 持续集成的核心概念 CI 过程会经常构建软件组件:在许多情况下,每当源代码存储库(比如 Subversion 或 ClearCase)中的代码发生变化时, ...

  8. 基于 CODING 轻松搞定持续集成

    点击观看视频教程 带你一步一步搞定 CODING 持续集成 持续集成加速软件交付 持续集成这个概念是由 Grady Booch 在 1991 年首次提出,随后成为了 DevOps 的核心实践之一.持续 ...

  9. DevOps - 持续集成(Continuous Integration)

    1 - 持续集成简介 持续集成(Continuous integration,简称CI)是软件的开发和发布标准流程中最重要的部分. 作为一种开发实践,在CI中可以通过自动化等手段高频率地去获取产品反馈 ...

随机推荐

  1. Javascript学习一

    //学习moocjs1 JavaScript-警告(alert 消息对话框) <script type="text/javascript"> var mynum = 3 ...

  2. SQL中的join连接查询

      inner join(交集 ,自然连接, 简写成join)   是最普通的连接查询,相当于早期根据where条件连接的查询     outer join(并集或部分并集,左表 + 右表)   le ...

  3. iOS runtime的应用实例

      一直想弄明白runtime是怎么回事,因为面试的时候这是一道必备问题,但是平时用的机会真的少之又少,我一度以为runtime只是用来装13的利器,没什么卵用.但是随着学习的增多,发现runtime ...

  4. Linux tomcat部署War包,Linux在Tomcat部署JavaWeb项目,Linux部署War包

    Linux tomcat部署War包,Linux在Tomcat部署JavaWeb项目,Linux部署War包 >>>>>>>>>>>& ...

  5. 延时循环数组 DelayLoops

    在操作mongodb数据库时,查询了数据得到一个数组,然后还得遍历这个数组,再对每个数组的值进行数据库相关的增删改查, 如果单纯的遍历会出错.所以才写了这个简单的类. var a = [1,2,3,4 ...

  6. Java 快排

    基于分治法的快排,用递归实现. 首先讲一下实现的过程. 1.在数组中取一个数作为基准,所谓的基准就是用来对比的数. 2.然后在数组中从后往前找,找到一个逆序数为止,找到之后就把它的值赋值到基准数的位, ...

  7. 【Spring】使用Spring和AMQP发送接收消息(上)

    讲AMQP之前,先讲下传统的JMS的消息模型,JMS中主要有三个参与者:消息的生产者.消费者.传递消息的通道(队列或者主题),两种消息模型如下:通道是队列: 通道是队列: 通道是主题: 在JMS中,虽 ...

  8. 队列工厂之RabbitMQ

    本次和大家分享的是RabbitMQ队列的用法,前一篇文章队列工厂之(MSMQ)中在描述的时候已经搭建了简单工厂,因此本章内容是在其之上扩充的子项不再过多讲解工厂的代码了:RabbitMQ应该是现在互联 ...

  9. SEO-发信息注意的问题

    SEO是什么? SEO的全称是Search Engine Optimization,翻译过来就是搜索引擎优化,说到搜索引擎,可能不是特别的清楚.通俗点讲,就是百度,谷歌,雅虎,这些可以直接搜索到你想要 ...

  10. win8和ubuntu双系统

    硬盘安装的话只要分够内存和做好开机启动项就好了,u盘安装要注意分区(挂载)了推荐: http://wenku.baidu.com/view/5052f19b51e79b8968022623.html ...