关于接口测试自动化的总结与思考

作者：云原生

序

近期，阿里云功用测验 PTS 接口测验已上线发布一段时刻，本着以和咱们沟通如何完成高效的接口测验为起点，本文包含了我在接口测验范畴的一些办法和心得，期望咱们一同讨论和分享，内容包含但不仅限于：

• 服务端接口测验介绍
• 接口测验主动化介绍
• 接口测验主动化实践
• 关于接口测验主动化的考虑和总结

服务端接口测验介绍

什么是服务端？

一般所说的服务端是指为用户在 APP 或 PC 运用的互联网功用供给数据服务的背面的一切。以天猫精灵智能音箱系列的产品链路为例，服务端便是网关（包含网关在内）之后的链路。

什么是接口？

官方点说，是计算机体系中两个独立的部件进行信息沟通的共享鸿沟。浅显点说，便是服务端对外供给数据服务最常用的信息沟通方式。供给数据服务的服务端是个可大可小的机构，做的事大多不止一件，它做了这么多事，最终的方针是给 APP 或其它调用方运用，所以服务端就派出了几个代表，比方 API1 担任供给用户信息，API2 担任供给设备信息，API3 担任供给播映的音频信息等等。同事，服务端规定好跟 API1 通讯的接头暗号是param1，param2…，跟 API2 通讯的接头暗号是 param3，param4…，而 params 便是接口参数，便是用来告知服务端你要什么服务，详细的要求是什么。接口一般由三个部分组成：协议、地址及参数。

什么是接口测验？

一般讲的接口测验指的是对某个给定接口进行功用测验，输入不同的参数时，接口回来值是否正确。下图是经典的测验金字塔模型。

在这个模型中，越往下份额会占的越高，也便是说在一个产品测验中，单元测验份额是最高的，依次是接口测验和 UI 主动化测验，最顶端是人工测验部分。服务端接口测验在中部，承上启下，由此可见其重要性。

为什么要做接口测验？

一般做接口测验有如下原因：

• 接口是服务端对外供给数据服务最常用的信息沟通方式，接口大部分内容都是数据，经过数据比照咱们可以推测到体系的逻辑，测接口其实也便是测逻辑。
• 接口测验相对简略完成主动化，也简略完成继续集成，且相对 UI 主动化也比较安稳，可以削减人工回归测验人力成本与时刻，缩短测验周期，支撑后端快速发版需求。

如何做接口测验？

前面提到，接口是由这几个组成部分：接口地址、恳求协议、恳求参数和预期成果。测验接口的过程一般过程是：发送恳求->解析成果->验证成果。

简略来说，接口测验便是参照接口文档，调用接口，看成果的回来是否跟文档说明一致；别的，再测验一下接口对反常逻辑的处理比方非法参数或鸿沟值。

深化来说，接口测验的重视重点在于：

一、接口的数据逻辑是否正确。 咱们需求充沛了解接口的功用，内部是什么样的数据逻辑，它与上下游沟通了那些信息或资源，不单纯地停留在参数调用和程序回来的表象数据。浅显地说，便是要知道这个接口是干什么用的，用到哪里，每次调用会发生什么，然后去查验改发生的有没有发生。

二、接口关于反常参数的处理机制与上下游服务的容错。 如下图所示，被测接口 A 依靠上游服务 A，那么服务A反常的时分被测接口是否很好的容错就很重要，否则服务挂起或宕掉都是有或许的。别的，作为服务供给方接口 B，应当要充沛兼容不同的运用场景、或不同版别的调用方的运用，不能为了服务 E 做的需求，除了E其它的服务运用者都用不了了。总的来说，原则便是 “上游不牢靠，下游要兼容” 。

接口测验主动化介绍

为什么是接口测验主动化？

接口测验主动化，简略来讲便是功用测验用例脚本化，然后履行脚本，发生一份可视化测验报告。

为什么要做接口测验主动化？

不管什么样的测验方式，都是为了验证功用与发现 bug。那为什么要做接口测验主动化呢？一句话归纳便是是为了节约人力成本。详细来说，包含以下几点：

• 减轻自己作业量，把测验从单调的重复劳动的人工测验中解放出来；
• 帮忙手工测验完成很难模仿或无法模仿的的作业；
• 提高作业效率，比方测验环境的主动化编译、打包、部署、继续集成乃至继续交给等。
• 帮忙定位问题，比方接口层发现问题了，可以经过增加的 traceID 定位到日志过错或过错代码行，
• 尽早发现 bug，主动通知测验人员。一旦发现问题，立即通知测验人员，快速高效。

接口测验主动化的规范

这儿结合我往常在做接口测验时的一些经历，总结了一些接口测验主动化的规范，抛砖引玉，欢迎咱们补充。

文档准备

磨刀不误砍柴工，准备好分详细的接口相关文档可以协助后续接口主动化测验作业的高效打开。相关文档包含但不限于一下内容：

1. 《需求文档》 ，清晰界说了：接口背面的事务场景，即该接口是干什么用的，用到哪里，每次调用会发生什么等；

2. 《接口文档》 ，清晰界说了：接口名，各个入参值，各个回来值，和其他相关信息；

3. 《UI 交互图》 ，清晰界说了：各单页面需展现的数据；页面之间的交互等；

4. 《数据表规划文档》 ，清晰界说了：表字段规矩、表 N 多 N 联系（1对1、一对多、多对多）等；

务必和相关需求方承认好文档中的信息是牢靠且最新的，只有依靠牢靠的文档才干规划出正确详尽的接口用例，才干得到最正确的成果。

清晰接口测验主动化需求的功用

1. 校验（断语）

测验断语是主动化测验中的测验经过条件，用于判断测验用例是否符合预期。所以支撑对回来值校验是一个有必要的功用。

2. 数据阻隔

数据阻隔便是指详细的恳求接口、参数、校验等数据做到与代码相阻隔，便于保护，一旦需求调整接口用例、新增接口用例时可很快速的找到方位。阻隔的另一个好处便是可复用，结构可以推广给其他团队，运用者可以运用相同的代码，只需求依据要求填写各自用例即可测验起来。

3. 数据传递

做到数据阻隔可保护后，数据传递是别的一个更重要的需求。接口测验时，首先咱们会完成单接口解耦，后续按照事务场景组合多个接口。而数据传递是则是组合多个接口的必要条件，它让接口用例之间可以做到向下传参。举个比方，咱们经过设备信息查询接口查询到当前天猫精灵音箱的设备信息，该接口会回来一个 UUID，接下来咱们要经过用户信息查询接口去查询当前设备绑定的用户信息，此刻第二个接口的恳求数据是需求从第一个接口用例中的回来中提取的。

4. 功用函数

实践的事务场景测验会需求各种辅助功用的支撑，比方随机生成时刻戳，恳求 ID，随机的手机号码或方位信息等等，此刻咱们就需求代码可以支撑做到识别对应要害字时可以履行对应的功用函数进行填充。

5. 可装备

现在测验环境包含但不限于日常、预发一、预发二、线上等等，因而用例不单单只能在一个环境上履行，需求同一份接口用例可以在日常、预发、线上等多个环境都可以履行。所以结构需求做到可装备，便于切换，调用不同的装备文件可以在不同的环境履行。

6. 日志

日志包含履行的详细履行接口、恳求方式、恳求参数、回来值、校验接口、恳求时刻、耗时等要害信息，日志的好处一来是可以便于在新增用例有问题时快速定位出哪里填写有问题，二来是发现 bug 时便利向开发反馈供给数据，开发可以从触发时刻以及参数等信息快速定位到问题所在。

7. 可视化报告

用例履行后，便是到了向团队展现成果的时分了，一个可视化的报告可以便于团队成员了解到每次主动化接口用例履行的成功数、失利数等数据。

8. 可继续集成

关于现已有测验用例并测验完成的接口，咱们期望可以形成回归用例，鄙人一个版别迭代或上线之前，经过已有用例进行一个回归测验，确保新上线的功用不影响已有功用。因而，这就需求接口主动化测验是可继续集成的而不是一次性的。

接口测验主动化结构选型

结合咱们对接口测验主动化结构的需求及现在市场上的许多测验东西的特色，总结成下表：

这儿简略列举一下：

1、fiddler

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

详细介绍见：

www.telerik.com/fiddler

[1] cookie：

baike.baidu.com/item/cookie…

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 做继续集成测验。

详细介绍见：

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 依靠：

<dependency>
  <groupId>org.testng</groupId>
  <artifactId>testng</artifactId>
  <version>6.8.8</version>
  <scope>test</scope>
</dependency>

• 测验类增加 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版别--><dependency>  <groupId>junit</groupId>  <artifactId>junit</artifactId>  <version>4.4</version>  <scope>test</scope></dependency>

• 测验类增加 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”将一同运转。

<suite name="My test suite">
  <test name="testing">
    <classes>
      <class name="com.fsecure.demo.testng.TestNGTest1" />
      <class name="com.fsecure.demo.testng.TestNGTest2" />
    </classes>   
  </test>
</suite>

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”履行单元测验。

<suite name="My test suite">
  <test name="testing">       
    <groups>       
      <run>         
        <include name="method1"/>       
      </run>     
    </groups>     
    <classes>        
      <class name="com.fsecure.demo.testng.TestNGTest" /></classes>   
  </test> 
</suite>

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

• 缺点：

1. 一个测验类只能有一个静态的参数结构办法；
2. 测验类需求运用 @RunWith(Parameterized.class)，无法兼容 spring-test的runner
3. @RunWith(SpringJUnit4ClassRunner.class)，会导致无法经过注解注入待测服务
4. 需求在测验类中增加一个结构办法（一种冗余规划）

TestNG 参数化测验：

• 过程如下：
  1.经过 @dataProvider 注解标识参数结构办法
  2.测验办法在注解 @Test 中经过 dataProvider 特点指定参数结构办法，便可在测验办法中运用参数

@Test(dataProvider = "Data-Provider-Function")
public void parameterIntTest(Class clzz, String[] number) {       
    System.out.println("Parameterized Number is : " + number[0]);       
    System.out.println("Parameterized Number is : " + number[1]);     
}

除此之外，TestNG 还支撑经过 testng.xml 结构参数：

public class TestNGTest {
    @Test @Parameters(value="number") 
    public void parameterIntTest(int number) {        
        System.out.println("Parameterized Number is : " + number);     
    } 
}

XML 文件的内容如下

<suite name="My test suite">
  <test name="testing">     
    <parameter name="number" value="2"/>     
    <classes>        
      <class name="com.fsecure.demo.testng.TestNGTest" />     
    </classes>   
  </test> 
</suite>

8.依靠测验

“参数化测验”表明办法是依靠性测验，它将在所需办法之前履行。假如依靠办法失利，则一切后续测验将会被越过，不会被标记为失利。

JUnit 4

JUnit 结构着重于测验阻隔; 现在它不支撑此功用。

TestNG

它运用“dependOnMethods”来完成依靠测验如下

@Test public void method1() {
    System.out.println("This is method 1"); 
}
@Test(dependsOnMethods={"method1"}) 
public void method2() {     
    System.out.println("This is method 2"); 
}

TestNG 接口主动化实践

参数化测验示例

以 DeviceStatusHSFService 为例，测验类如下：

public class DeviceStatusHSFServiceTest {
    private DeviceStatusHSFService deviceStatusHSFService;
    @BeforeTest(alwaysRun = true)
    public void beforeTest() {
        String envName = System.getProperty("maven.env");  //运转环境可装备
        SwitchENV switchEnv = new SwitchENV(envName);    //运转环境可装备
        deviceStatusHSFService = HsfRepository.getConsumer(DeviceStatusHSFService.class, switchEnv.getEnv(),
            "HSF", switchEnv.getHsfVersion(), "aicloud-device-center", switchEnv.getTargetIp()).getTarget();
    }
    @Test(dataProvider = "updateDeviceStatus", dataProviderClass = DeviceStatusHSFServiceTestDataProvider.class)
    public void updateDeviceStatusTest(Long userId, String uuid, DeviceStatus deviceStatus){
        Result<Boolean> result = deviceStatusHSFService.updateDeviceStatus(userId, uuid, deviceStatus);
        System.out.println("traceId:"+EagleEye.getTraceId()+result.toString());
        Boolean res = result.getResult();
        assertTrue(res);
    }
}

其中经过 SwitchENV 类完成运转环境可装备：

/**
 * 自界说环境装备
 */
public class SwitchENV {
    /**
     * 运转环境
     */
    private Env env;
    /**
     * hsf环境
     */
    private String hsfVersion;
    /**
     * 方针机器
     */
    private String targetIp;
    /**
     * 环境称号
     */
    private String envName;
    public SwitchENV(String envName) {
        Properties prop = new Properties();
        // TODO: 本地主动化测验切换环境专用
        if (envName == null) {
            envName = "pre1";
        }
        switch (envName) {
            case "online": {
                InputStream in = SwitchENV.class.getClassLoader().getResourceAsStream(
                    "config/application-online.properties");
                try {
                    prop.load(in);
                } catch (IOException e) {
                    e.printStackTrace();
                }
                env = Env.ONLINE;
                break;
            }
            case "pre1": {
                InputStream in = SwitchENV.class.getClassLoader().getResourceAsStream(
                    "config/application-pre1.properties");
                try {
                    prop.load(in);
                } catch (IOException e) {
                    e.printStackTrace();
                }
                env = Env.PREPARE;
                break;
            }
            case "pre2": {
                InputStream in = SwitchENV.class.getClassLoader().getResourceAsStream(
                    "config/application-pre2.properties");
                try {
                    prop.load(in);
                } catch (IOException e) {
                    e.printStackTrace();
                }
                env = Env.PREPARE;
                break;
            }
            case "pre3": {
                InputStream in = SwitchENV.class.getClassLoader().getResourceAsStream(
                    "config/application-pre3.properties");
                try {
                    prop.load(in);
                } catch (IOException e) {
                    e.printStackTrace();
                }
                env = Env.PREPARE;
                break;
            }
            default:
                try {
                    throw new Exception("环境变量输入过错！");
                } catch (Exception e) {
                    e.printStackTrace();
                }
                break;
        }
        hsfVersion = prop.getProperty("hsfVersion").trim();
        targetIp= prop.getProperty("targetIp").trim();
        this.envName = envName;
    }
    public Env getEnv() {
        return env;
    }
    public String getHsfVersion() {
        return hsfVersion;
    }
    public String getTargetIp() {
        return targetIp;
    }
    public String getEnvName() {
        return envName;
    }
}

测验参数悉数放在 DeviceStatusHSFServiceTestDataProvider 类中，完成详细的恳求接口、参数、校验等数据做到与代码相阻隔。

/**
 * 自界说环境装备
 */
public class SwitchENV {
    /**
     * 运转环境
     */
    private Env env;
    /**
     * hsf环境
     */
    private String hsfVersion;
    /**
     * 方针机器
     */
    private String targetIp;
    /**
     * 环境称号
     */
    private String envName;
    public SwitchENV(String envName) {
        Properties prop = new Properties();
        // TODO: 本地主动化测验切换环境专用
        if (envName == null) {
            envName = "pre1";
        }
        switch (envName) {
            case "online": {
                InputStream in = SwitchENV.class.getClassLoader().getResourceAsStream(
                    "config/application-online.properties");
                try {
                    prop.load(in);
                } catch (IOException e) {
                    e.printStackTrace();
                }
                env = Env.ONLINE;
                break;
            }
            case "pre1": {
                InputStream in = SwitchENV.class.getClassLoader().getResourceAsStream(
                    "config/application-pre1.properties");
                try {
                    prop.load(in);
                } catch (IOException e) {
                    e.printStackTrace();
                }
                env = Env.PREPARE;
                break;
            }
            case "pre2": {
                InputStream in = SwitchENV.class.getClassLoader().getResourceAsStream(
                    "config/application-pre2.properties");
                try {
                    prop.load(in);
                } catch (IOException e) {
                    e.printStackTrace();
                }
                env = Env.PREPARE;
                break;
            }
            case "pre3": {
                InputStream in = SwitchENV.class.getClassLoader().getResourceAsStream(
                    "config/application-pre3.properties");
                try {
                    prop.load(in);
                } catch (IOException e) {
                    e.printStackTrace();
                }
                env = Env.PREPARE;
                break;
            }
            default:
                try {
                    throw new Exception("环境变量输入过错！");
                } catch (Exception e) {
                    e.printStackTrace();
                }
                break;
        }
        hsfVersion = prop.getProperty("hsfVersion").trim();
        targetIp= prop.getProperty("targetIp").trim();
        this.envName = envName;
    }
    public Env getEnv() {
        return env;
    }
    public String getHsfVersion() {
        return hsfVersion;
    }
    public String getTargetIp() {
        return targetIp;
    }
    public String getEnvName() {
        return envName;
    }
}

考虑与总结

关于接口主动化测验，从用例规划到测验脚本完成，总结起来，需求咱们具备如下思维：

• 模块化思维
• 数据驱动思维
• 要害字驱动思维

模块化思维

关于咱们的接口主动化测验工程而言，需求可以创建小而独立的可以描绘的模块、片断以及待测应用程序的脚本。这些树状结构的小脚本组合起来，就能组成能用于特定的测验用例的脚本。

数据驱动思维

简而言之，便是测验脚本与测验数据别离。让测验数据独立于测验脚本独自存在，免除脚本与数据之间的强耦合。测验脚本不再担任办理测验数据，而测验数据在数据驱动测验中会以文件或许数据库的形式存在。脚本每次履行会机械的从数据文件或许数据库中读入测验数据，依据测验数据的不同走进不同的测验途径。在整个测验中，测验脚本是一成不变的，它一向机械的履行它本身的代码，而活着的是咱们的测验数据集，咱们经过不同的数据控制测验脚本中代码的走向。这个思维可以防止测验数据杂糅在测验脚本中，便利测验数据的扩展。再者，在主动化测验中，为了维持回归测验的安稳一致，测验脚本应当尽量防止更改。在非数据驱动的情况下，恰恰违反了这一原则。主动化测验中，跟着项目的深化，测验脚本将会继续增多，测验数据和脚本揉在一同？保护起来将会是一件恐怖的工作，犯错在所难免，所以这时不要这样做，让数据和脚本别离，坚持死的代码，活的数据，保护的大部分作业将只面向数据。

要害字驱动思维

这是一种更为高档的数据驱动测验，中心思维是将测验用例的每个过程独自封装成一个函数，以这个函数名作为要害字，将函数名及传参写入文件中，每个过程映射一行文件。经过解析文件的每行内容，将内容拼成一个函数调用，调用封装好的过程函数，就可以一步步履行测验事例。在一个要害字驱动测验中，待测应用程序的功用和每个测验的履行过程将被一同写到一个表中。这一个思维经过很少的代码来发生很多的测验用例。相同的代码在用数据表来发生各个测验用例的一同被复用。

当咱们的测验思维越靠近上述三种类型的思维，接口测验的完成将越主动化。跟着人工智能的不断发展，AI 浪潮下也将诞生更多的主动化测验东西，比方选用人工智能技术，经过某种自适应的算法来迭代咱们的测验用例，生成测验脚本。这意味着，未来测验人员的努力方向将在规划出愈加牢靠、高效的主动化用例生成东西、脚本构建东西与测验履行东西，而原先那些重复劳动的人工测验作业就让聪明的机器帮咱们做吧。

最终

PTS 接口测验免费公测中，欢迎咱们试用。

更多沟通，欢迎进钉钉群沟通，PTS 用户沟通钉钉群号：44850859。