关于接口测试自动化的总结与思考_python接口自动化中,用例数据需要隔离吗(2)

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

这里结合我平常在做接口测试时的一些经验，总结了一些接口测试自动化的规范，抛砖引玉，欢迎大家补充。

文档准备

磨刀不误砍柴工，准备好分详细的接口相关文档能够帮助后续接口自动化测试工作的高效展开。相关文档包括但不限于一下内容：

1.《需求文档》，明确定义了：接口背后的业务场景，即该接口是干什么用的，用到哪里，每次调用会发生什么等；

2.《接口文档》，明确定义了：接口名，各个入参值，各个返回值，和其他相关信息；

3.《UI 交互图》，明确定义了：各单页面需展示的数据；页面之间的交互等；

4.《数据表设计文档》，明确定义了：表字段规则、表 N 多 N 关系（一对一、一对多、多对多）等；

务必和相关需求方确认好文档中的信息是可靠且最新的，只有依赖可靠的文档才能设计出正确详尽的接口用例，才能得到最正确的结果。

明确接口测试自动化需要的功能

1.校验（断言）

测试断言是自动化测试中的测试通过条件，用于判断测试用例是否符合预期。所以支持对返回值校验是一个必须的功能。

2.数据隔离

数据隔离就是指具体的请求接口、参数、校验等数据做到与代码相隔离，便于维护，一旦需要调整接口用例、新增接口用例时可很快速的找到位置。隔离的另一个好处就是可复用，框架可以推广给其他团队，使用者可以使用相同的代码，只需要根据要求填写各自用例即可测试起来。

3.数据传递

做到数据隔离可维护后，数据传递是另外一个更重要的需求。接口测试时，首先我们会实现单接口解耦，后续按照业务场景组合多个接口。而数据传递是则是组合多个接口的必要条件，它让接口用例之间可以做到向下传参。举个例子，我们通过设备信息查询接口查询到当前天猫精灵音箱的设备信息，该接口会返回一个 UUID，接下来我们要通过用户信息查询接口去查询当前设备绑定的用户信息，此时第二个接口的请求数据是需要从第一个接口用例中的返回中提取的。

4.功能函数

实际的业务场景测试会需要各种辅助功能的支持，比如随机生成时间戳，请求 ID，随机的手机号码或位置信息等等，此时我们就需要代码可以支持做到识别对应关键字时可以执行对应的功能函数进行填充。

5.可配置

目前测试环境包括但不限于日常、预发一、预发二、线上等等，因此用例不单单只能在一个环境上执行，需要同一份接口用例可以在日常、预发、线上等多个环境都可以执行。所以框架需要做到可配置，便于切换，调用不同的配置文件可以在不同的环境执行。

6.日志

日志包含执行的具体执行接口、请求方式、请求参数、返回值、校验接口、请求时间、耗时等关键信息，日志的好处一来是可以便于在新增用例有问题时快速定位出哪里填写有问题，二来是发现 bug 时方便向开发反馈提供数据，开发可以从触发时间以及参数等信息快速定位到问题所在。

7.可视化报告

用例执行后，就是到了向团队展示结果的时候了，一个可视化的报告可以便于团队成员了解到每次自动化接口用例执行的成功数、失败数等数据。

8.可持续集成

对于已经有测试用例并测试完成的接口，我们希望能够形成回归用例，在下一个版本迭代或上线之前，通过已有用例进行一个回归测试，确保新上线的功能不影响已有功能。因此，这就需要接口自动化测试是可持续集成的而不是一次性的。

接口测试自动化框架选型

结合我们对接口测试自动化框架的需求及目前市场上的很多测试工具的特点，总结成下表：

这里简单列举一下：

1.fiddler

fiddler 是一个 HTTP 协议调试代理工具，Web 和手机测试都会用到，同时也支持接口测试。它能够记录并检查所有你的电脑和互联网之间的 http 通讯，设置断点，查看所有的“进出”Fiddler 的数据（指 cookie[1],html,js,css 等文件）。

详细介绍见：

https://www.telerik.com/fiddler

[1] cookie：

https://baike.baidu.com/item/cookie/1119

2.postman

它是 Google 开发的一个插件，安装在 Chrome 浏览器上，能支持不同接口测试请求，可以管理测试套件和自动化运行。弱点是自动化断言功能不强大，不能和 Jenkins、代码管理库进行持续集成测试。

3.wireshak

这是一款抓包工具，支持 TCP、UDP、HTTP 等协议。如果做底层网络数据测试，一般都需要用到它，但是用作接口测试，它就有点不友好。因为刷新数据太快，不好定位每个操作对应的接口。

4.soupUI

soapUI 是一个开源测试工具，通过 soap/http 来检查、调用、实现Web Service的功能/负载/符合性测试。该工具既可作为一个单独的测试软件使用，也可利用插件集成到 Eclipse，maven2.X，Netbeans 和 intellij 中使用。把一个或多个测试套件（TestSuite）组织成项目，每个测试套件包含一个或多个测试用例（TestCase），每个测试用例包含一个或多个测试步骤，包括发送请求、接受响应、分析结果、改变测试执行流程等。该工具能够支持接口自动化测试和接口性能测试，也支持和 Jenkins 做持续集成测试。

详细介绍见：

https://www.soapui.org/

5.Java 代码做接口测试

为什么要用代码做接口自动化测试呢？一些工具功能是有限制，很多公司需要一些特定的功能，工具不支持，只好用代码进行开发。一般用 Java 做自动化测试，主要利用 httpclient.jar 包，然后利用 JUnit 或者 TestNG 这样的单元测试工具，进行测试用例的开发，接着在 Jenkins 或我们的 aone 上创建一个 job，进行持续集成测试。

6.Python 代码做接口测试

和 Java 一样，用 Python 做接口测试，可以利用一个功能强大的第三方库 Requests，它能方便地创建接口自动化用例。Python 下的单元测试框架，一般采用 unittest。生成测试报告，一般选择 HTMLTestRunner.py。同样，可以结合 Jenkins 做持续集成测试。

接口测试自动化实践

TestNG 与 JUnit 对比

综合性对比

我在日常测试工作中，使用的比较多的自动化测试工具是 Java 代码做接口测试，这里先介绍下我对单元测试工具 TestNG 和 JUnit 的对比。先用一张表格总结一下他们的特点对比。

TestNG 与 JUnit 的相同点如下：

1.都有注解，即都使用 annotation，且大部分 annotation 相同；

2.都可以进行单元测试（Unit test）；

3.都是针对 Java 测试的工具；

TestNG 与 JUnit 的不同点如下：

1.TestNG 支持的注解更丰富，如 @ExpectedExceptions、@DataProvider 等；

2.JUnit 4 中要求 @BeforeClass、@AfterClass 方法声明为 static，这就限制了该方法中使用的变量必须是 static。而 TestNG 中 @BeforeClass 修饰的方法可以跟普通函数完全一样；

3.JUnit 只能使用 IDE 运行，TestNG 的运行方式有：命令行、ant 和 IDE；

4.JUnit 4 依赖性非常强，测试用例间有严格的先后顺序。前一个测试不成功，后续所有的依赖测试都会失败。TestNG 利用 @Test的dependsOnMethods 属性来应对测试依赖性问题。某方法依赖的方法失败，它将被跳过，而不是标记为失败。

5.对于 n 个不同参数组合的测试，JUnit 4 要写 n 个测试用例。每个测试用例完成的任务基本是相同的，只是方法的参数有所改变。TestNG 的参数化测试只需要一个测试用例，然后把所需要的参数加到 TestNG 的 xml 配置文件中或使用 @DataProvider 方式注入不同的参数。这样的好处是参数与测试代码分离，非程序员也可以修改参数，同时修改无需重新编译测试代码。

6.JUnit 4 的测试结果通过 Green/Red bar 体现，TestNG 的结果除了 Green/Red bar，还有 Console 窗口和 test-output 文件夹，对测试结果的描述更加详细，方便定位错误。

详细特性对比

下面详细介绍一下 TestNG 与 JUnit 特性对比：

1.框架整合：

Spring+TestNG+Maven 整合：

pom.xml 中增加 testng 依赖：

org.testng

testng

6.8.8

test

测试类增加 1 条注解 @ContextConfiguration(locations = “classpath:applicationContext.xml”) 并继承 AbstractTestNGSpringContextTests，范例如下

@ContextConfiguration(locations = “classpath:applicationContext.xml”) public class BaseTest extends AbstractTestNGSpringContextTests{           @Test      public void testMethods()     {         …     } }

Spring+JUnit+Maven 整合：

pom.xml 中增加 JUnit 依赖：

junit

junit

4.4

test

测试类增加 2 条注解

@RunWith(SpringJUnit4ClassRunner.class)

@ContextConfiguration(locations = “classpath:applicationContext.xml”),如下：

@RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(locations = “classpath:applicationContext.xml”) public class BaseTest{         @Test         public void testMethods()     {         …     } }

2.注解支持

主要区别以下两点：

1.在 JUnit 4 中，我们必须声明“@BeforeClass”和“@AfterClass”方法作为静态方法。TestNG 在方法声明中更灵活，它没有这个约束。

2.在 JUnit 4 中，注释命名约定有点混乱，例如“Before”，“After”和“Expected”，我们并不真正了解“Before”和“After”之前的内容，以及要测试中的“预期” 方法。TestiNG 更容易理解，它使用类似“BeforeMethod”，“AfterMethod”和“ExpectedException”就很明了。

3.异常测试

“异常测试”是指从单元测试中抛出的异常，此功能在 JUnit 4 和 TestNG 中都可实现。

JUnit 4

@Test(expected = ArithmeticException.class) public void divisionWithException() {   int i = 1/0; }

TestNG

@Test(expectedExceptions = ArithmeticException.class) public void divisionWithException() {   int i = 1/0; }

4.忽略测试

忽略测试意思是在单元测试哪些是可以被忽略的，这个特性在两个框架都已经实现。

JUnit 4

@Ignore(“Not Ready to Run”)  @Test public void divisionWithException() {      System.out.println(“Method is not ready yet”); }

TestNG

@Test(enabled=false) public void divisionWithException() {      System.out.println(“Method is not ready yet”); }

5.超时测试

时间测试意思是如果一个单元测试运行的时间超过了一个指定的毫秒数，那么测试将终止并且标记为失败的测试，这个特性在两个框架都已经实现。

JUnit 4

@Test(timeout = 1000)  public void infinity() {      while(true);  }

TestNG

@Test(timeOut = 1000)  public voi

6.套件测试

“套件测试”是指捆绑几个单元测试并一起运行。此功能在 JUnit 4 和 TestNG 中都可实现。然而，两者都使用非常不同的方法来实现它。

JUnit 4

“@RunWith”和“@Suite”用于运行套件测试。下面的类代码表示在 JunitTest3 执行之后，单元测试“JunitTest1”和“JunitTest2”一起运行。所有的声明都是在类内定义的。

@RunWith(Suite.class) @Suite.SuiteClasses({         JunitTest1.class,         JunitTest2.class }) public class JunitTest3 { }

TestNG

XML 文件用于运行套件测试。以下 XML 文件表示单元测试“TestNGTest1”和“TestNGTest2”将一起运行。

TestNG 可以做捆绑类测试，也可以捆绑方法测试。凭借 TestNG 独特的“分组”概念，每种方法都可以与一个组合相结合，可以根据功能对测试进行分类(分组)。例如，

下面是一个有四个方法的类，三个组(method1，method2和method3)

@Test(groups=“method1”) public void testingMethod1() {   System.out.println(“Method - testingMethod1()”); } @Test(groups=“method2”) public void testingMethod2() {   System.out.println(“Method - testingMethod2()”); } @Test(groups=“method1”) public void testingMethod1_1() { System.out.println(“Method - testingMethod1_1()”); } @Test(groups=“method4”) public void testingMethod4() { System.out.println(“Method - testingMethod4()”); }

使用以下 XML 文件，可以仅使用组“method1”执行单元测试。

7.参数化测试

“参数化测试”是指单位测试参数值的变化。此功能在 JUnit 4 和 TestNG 中都实现。然而，两者都使用非常不同的方法来实现它。

JUnit 4 参数化测试：

步骤如下：

1.通过 @Parameters 标识静态参数构造方法

2.通过测试类构造方法引入参数

3.测试方法使用参数

@RunWith(value = Parameterized.class) public class JunitTest {           private int number;           public JunitTest6(int number) {                 this.number = number;          }         @Parameters          public static Collection

　　 data() {                Object[][] data = new Object[][] { { 1 }, { 2 }, { 3 }, { 4 } };                return Arrays.asList(data);          }          @Test          public void pushTest() {                System.out.println("Parameterized Number is : " + number);          } }

缺点：

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

Parameterized Number is : " + number);          } }

　　缺点：




[外链图片转存中...(img-CVEL48du-1715306786038)]
[外链图片转存中...(img-2jjjgb8F-1715306786038)]

**网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

**[需要这份系统化的资料的朋友，可以戳这里获取](https://bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)**

**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**