测试开发之路 ---- 数据驱动及其变种

目录

前言：

最开始的数据驱动：例如 testng 自带的机制

改造后的数据驱动：当最原始的这个数据驱动应用的很好的时候，我们发现了一些问题。

继续改造：为了定义复杂类型的参数，我们把 excel 换成 xml

接着改造：关键字驱动

改造一切你想要的：通过定义 XML 标签，我们增加 skip 用例的功能，我们可以规定什么验证什么不验证。等等

---

前言：

在测试开发中，数据驱动是一种非常重要的方法。它可以帮助我们更加高效地进行测试，提高测试的覆盖率并减少测试用例的编写量。 

最开始的数据驱动：例如 testng 自带的机制

　　熟悉 testng 的小伙伴一定已经把 data provider 用烂了。我不细讲了，各位不用 java 的也一定对数据驱动熟的不能再熟了。直接简单介绍下。

@Test(dataProvider = "marNew", dataProviderClass = Dataprovider.class)
    public void testcase(String methodName, Params info) {

　　上面的代码就是 testng 最简单的例子了，测试方法想要什么数据，直接写在参数里。然后@Test标签指定用哪个 data provider 就好了。

@DataProvider(name = "marNew")
    public static Iterator<Object[]> TestDataProvider(Method method) throws Exception {

　　这个就是 data provider 的接口了。只要用注解定义一下，返回一个迭代器就好了。迭代器里的参数会自动的传递给测试方法的参数列表。不细表了，大家都知道。

改造后的数据驱动：当最原始的这个数据驱动应用的很好的时候，我们发现了一些问题。

1. 代码里定义这些数据可读性不是很好
2. 仍然有些代码是重复的，例如定义一个 javaBean，一个 List 等
3. data provider 散落在测试脚本的各个包里，希望能分层出去到另一个文件里
4. data provider 在测试的源代码中，而且是以代码形式定义，不会写代码的人想通过定义测试数据来添加 case 成为了不可能

　　于是我们就想到了把参数定义在一个 excel 里。于是就变成了下面这样。

　　这样就决了很多问题了，例如可读性问题，现在看起来很方便。数据分层出来了，而且最重要的是，我们现在可以有一种模式就是：自动化人员写脚本，业务人员通过数据文件写用例这样效率高多了。但是我们还是有一个问题没有解决----代码重复，我们发现通过 excel 文件搞这事有个最大的问题----无法定义复杂类型的数据。 例如说一个 list，例如说一个对象类型。 我们只能定义 String，int 这种基本数据类型。然后需要在脚本中构建这些对象。 这样就太不爽了，很多重复的代码。而且我们希望脚本里只有测试逻辑，没有构建数据的操作。

继续改造：为了定义复杂类型的参数，我们把 excel 换成 xml

　　面向对象的编程语言中，一个复杂类型其实也是个树形结构。所以我们这一次使用本身就是树形结构的 XML 试一下。

<methods methodName="cancel" invokeType="Spring" className="com.bj58.daojia.ordercenter.agent.house.N