作者：云原生
序
近期，阿里云性能测试 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. 校验（断言）
测试断言是自动化测试中的测试通过条件，用于判断测试用例是否符合预期。所以支持对返回值校验是一个必须的功能。
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/...
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 做持续集成测试。
详细介绍见：
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 voi6.套件测试
“套件测试”是指捆绑几个单元测试并一起运行。此功能在 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);
}
} - 缺点：
- 一个测试类只能有一个静态的参数构造方法；
- 测试类需要使用 @RunWith(Parameterized.class)，无法兼容 spring-test的runner
- @RunWith(SpringJUnit4ClassRunner.class)，会导致无法通过注解注入待测服务
- 需要在测试类中添加一个构造方法（一种冗余设计）
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 文件的内容如下
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 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。