如何提高接口自动化测试的有效性覆盖和案例有效性

大纲

1. 测试分层：接口测试的基石

2 . DevOps 与接口测试

6. 过程回顾评审与优化调整

5. 接口测试案例设计

4. 制定接口测试实施计划

3. 接口测试范围

2. 软件测试是一项工程

在跟很多客户落地企业敏捷或 DevOps 的过程中，客户往往会提出问题：

我们的自动化测试覆盖率已经达到了 90% 以上，对自动化测试的结果还是没信心，最后还需要大量的人工测试来验证，才能有信心上线，该如何保证自动化测试的效果呢？

当然提高自动化测试的测试效果，可不是一两句话能解决的问题。我们首先从自动化测试的分层测试开始唠起。因为不同的测试层次，有不同的测试目的和关注点。

1. 测试分层：接口测试的基石

通常来说，业内把自动化测试分为三层。第一层为单元测试，主要测试单一类和内部方法功能的正确性；第二层为集成测试（包括接口测试在内），主要确保不同模块、服务之间和外部系统（服务）之间的连通性；第三层为 UI 测试，主要验证用户交互性和进行业务场景验收。

图 1 分层测试是最典型的测试思想

我们这次要谈论的接口测试属于中间层（第二层）。在接口测试之前，一般情况下，应该已经通过了单元测试。确保了单个类和类的方法的正确性。如果没有单元测试，或者单元测试不充分，接口测试将会受到拖累，不得不偿还单元测试欠下的技术债。这无疑将增加接口测试的工作量，但却很难达到良好的效果，这是因为不是所有单元测试放过的雷（Bug），在接口测试都能被发现，这时候单元级的功能对于接口测试来说已经成为了黑盒。而且相对于单元测试来说，接口测试的反馈周期也长了许多，接口测试很多情况下是由开发团队以外的独立团队来完成的。这样也增加了缺陷沟通的成本。

因此这里有必要强调一下，良好的接口测试质量，是建立在充分的单元测试之上的，这也是为什么现在都强调整个研发团队（需求提出人、需求分析人员、开发人员、测试人员等）对软件质量负责的原因。

图 2 软件测试就是排雷，埋雷容易排雷难

2. 软件测试是一项工程

很多管理不是太成熟的团队，软件测试（包括接口测试）带有很大的随意性。不同的测试人员因为对测试目标的理解不同，工作经验不同，写出来的测试案例和测试脚本也差异很大。对于同一个接口，经验多工作细致的同学可能设计 10 个测试案例；换另外一个工作经验少或工作马虎的同学，可能只有 1~2 测试案例。这就导致了接口测试效果可信度比较低。

如何确保接口测试结果的可信性度？我们应该把接口测试作为一个工程（小项目 ) 来管理。这个小项目根据具体的团队情况可以参考敏捷管理模型例如 Scrum，也可采用瀑布模型。

3. 接口测试范围

首先我们应该弄清楚，接口测试的范围，根据技术需求（传统瀑布模式项目）或者技术用户故事（敏捷项目）确定接口测试包括哪些接口，根据不同接口的重要性和缺陷影响程度明确接口测试的测试目标。

有可能的情况下，邀请需求分析人员（产品负责人）、开发人员和测试人员一起讨论决定接口测试的范围及接口测试的优先级，是一种很好的办法。可以从不通角色的人员那里获取较为全面的接口测试需求信息。

图 3 测试人员与开发人员、需求分析人员应多沟通

4. 制定接口测试实施计划

完成任何一项工作都会受到各种外界情况的约束，接口测试也不例外。首先在一个项目中可以用于接口测试的人员是一定的，有时可能很少。然而与人力不足相比，更稀缺的是可用于接口测试的时间更少，而接口测试往往又有赖于可以运行的系统。从获得可运行被测试的系统（服务），到与开发团队具体接口的细节沟通，再到调试接口测试脚本，留给真正用来测试的时间更少。因此如果要想保证高效率的接口测试，就需要提前对接口测试进行规划。

接口测试需要先分清哪些工作不依赖于实际的被测试系统（服务），这些工作可以提前进行。例如提前与开发团队梳理好待测接口的技术说明，约定好接口的输入参数和类型、输出结果、接口的使用协议等。接口测试工具也是一个很重要的内容，如果对于选择的工具，项目组内没有足够的测试人员掌握，是否需要安排接口测试工具的培训？所有这些都需要提前安排和规划。

需要说明的是，任何一种新工具的引入都需要学习和熟悉的过程，测试人员使用新的接口测试工具刚开始不会得心应手，工作产出效率低是难免的，这种情况通常遵循学习曲线描述的规律。在安排接口测试计划时，需要考虑学习曲线。

图 4 软件测试是一步步实现的

5. 接口测试案例设计

在编写接口测试可运行的测试脚本之前，我们一般会根据接口测试的范围对接口的优先级进行梳理，确保对重要接口的充分覆盖。接口测试的案例设计可以使用测试大纲来表达测试思路，也可以采用用户场景来描述。通常情况下传统项目偏向于使用测试大纲，敏捷项目或行为驱动开发（BDD）模式下偏向于使用用户场景，使用用户场景时可以使用开发框架直接转换成可执行的测试脚本。无论是测试大纲或者是使用用户场景来描述，都是使用检查点对测试要点进行覆盖。

下面举例说明一下。

假设我们有一个团队正在开发一个机票的销售系统，这个机票销售系统有一个功能就是用户可以通过客户端，包括浏览器、手机、Pad 等，查询航班信息。客户的输入信息有可能是：航班号、日期、出发地和目的地等信息。为了满足对不同客户端的访问支持，研发团队选择 RESTful Web Service 实现航班查询 API 供外部程序调用。

为了提高开发团队和接口测试团队的沟通效率，双方可以约定好航班查询信息 API 的参数输入和查询结果返回信息格式，API 接口的输入参数和返回数据格式我们可以使用 JSON 来表示。

输入参数约定：JSON Schema 格式

{"$schema": "http://json-schema.org/draft-04/schema#","title":"flight","properties":{"flightNumber":{"type":"string","description":"航班号，固定长度为6位数"},"departure":{"type":"string","description":"出发港"},"destination":{"type":"string","description":"到达港"},"time":{"type":"string","description":"起飞时间"}},"required":["flightNumber","departure","destination","time"]
}

查询输入参数举例：

{"flightNumber":"FM9333","departure":"上海虹桥T2","destination":"深圳宝安T2","time":" 2019-06-02 13:00"}

查询结果返回数据约定：JSON Schema 格式

{"$schema": "http://json-schema.org/draft-04/schema#","title":"flight","properties":{"flightNumber":{"type":"string","description":"航班号,长度为6位数"},"departure":{"type":"string","description":"出发港"},"destination":{"type":"string","description":"到达港"},"time":{"type":"string","description":"起飞时间"},"ontime":{"type":"string","description":"到达准点率"},"aircraft_info":{"type":"string","description":"航班信息如机型名称：空客321 飞机类型：中型"}},"required":["flightNumber","departure","destination","time","aircraft_info"]
}

返回结果数据举例：

{"flightNumber":"FM9333","departure":"上海虹桥T2","destination":"深圳宝安T2","time":" 2019-06-02 13:00","ontime":"87%","aircraft_info":"机型名称：空客320 飞机类型：中型机",}

众所周知，测试设计方法包括白盒测试设计和黑盒测试设计。对于 API 来说如果可以看到实现的源代码，可以考虑使用白盒测试与黑盒测试相结合的方法。如果源代码对于测试团队是不可见的，可以采用黑盒测试的方法。我们这里假设测试团队独立与开发团队，不会去阅读相关 API 的实现代码或者实现设计。采用黑盒测试设计方法比较适合。

常用的黑盒测试设计方法包括：

等价类划：选择适当的数据子集来代表整个数据集。
边界值分析：把每个边界的值作为测试条件。
因果图：利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。
决策表：分析和表达多逻辑条件下不同操作的执行结果。

由于篇幅有限我们不对以上黑盒测试设计方法详细讲解，只是提醒大家可以根据具体的 API 的输入参数和输出结果的情况进行选择。

假设我们测试设计使用测试大纲，对航班号（flightNumber）的测试覆盖可以考虑以下方面。

航班号：flightNumber，变量类型为 String，固定长度为 6 位数。

航班号测试大纲

输入参数	预期结果	说明
FM9333	{ "flightNumber":"FM9333", "departure":"上海虹桥T2", "destination":"深圳宝安T2", "time":" 2019-06-02 13:00", "ontime":"87%", "aircraft_info":"机型名称：空客320 飞机类型：中型机", }	输入合法参数
FM933	{ "errorCode":"5001" "message:":"航班号长度必须是6位" }	航班号长度小于6位
FM93335	{ "errorCode":"5001" "error:":"航班号长度必须是6位" }	航班号长度大于6位
FM9335	{ "errorCode":"4001" "message:":"航班号长度必须是6位" }	航班号长度为6，但航班不存在

接口测试案例

特性: 查询指定航班详细信息
场景: 以 JSON 格式返回指定的航班明细信息
假设 我需要获得航班号为 FM9333 的航班详细信息
当 我使用航班号 FM9333 查询航班详细信息
那么 我可以获得如下航班信息：
"""{"flightNumber":"FM9333","departure":"上海虹桥T2","destination":"深圳宝安T2","time":" 2019-06-02 13:00","ontime":"87%","aircraft_info":"机型名称：空客320 飞机类型：中型机",}
"""

API 自动化测试代码的实现可以是任何一种语言的接口测试工具，Java 语言的实现可以采用 Cucumber+Rest-Assured 组合。

自动化测试代码

   public class FlightDetailsServcieSteps {private String flightNumber; //航班号private Flight matchingFlight; //符合查询结果的航班@Value("SERVICE_URL")private String serviceURL; //航班详细信息查询WebService 地址private Sting receivedFlightJsonData;private String expectedFlightJsonData;@Given("^我需要获得航班号为(.*)的航班详细信息$")public void flight_number(String flightNumber) throws Throwable {this.flightNumber = flightNumber;}@When("^我使用航班号查询航班详细信息$")public void request_flight_details() throws Throwable {//设置服务器基准地址http://www.qatools.cn/demon/api/rest/RestAssured.baseURI = this.serviceURL;//获得服务器响应报文Response response =  given().get("/flights/{"+this.flightNumber+"}");//转化为JSON数据receivedFlightJsonData = response.body().asString();}@Then("^我可以获得如下航班信息:$")public void verify_details(String flightDetails) throws Throwable {//验证Web Service 接口返回的数据是否与期望结果一直assertJsonEquals(receivedFlightJsonData, expectedFlightJsonData);}}

图 5 良好的测试覆盖需要认真的测试设计

6. 过程回顾评审与优化调整

当 API 测试完成后，您需要对整个测试过程进行回顾和评审，根据制定的测试指标对 API 测试实施团队的绩效进行评估和分析。对于 API 接口测试的绩效评估可以考虑编写的接口案例数、自动化测试轮次、发现的缺陷数、发现的缺陷等级分布、接口自动化覆盖率、缺陷遗漏率、严重缺陷遗漏数等指标。

回顾会开展步骤：

回顾目标
评估结果
分析原因
总结规律

回顾会可以开的相对轻松一些，让团队成员可以自由发言，消除紧张和顾虑。有时可以准备一些甜品和饮料。

回顾评审的氛围：

放开心态
坦诚表达
实事求是
自我反思
集思广益

持续的回顾评审和调整，可以让您的 API 测试流程越来越高效，越来越适合您的组织并获取最终的成功。

图 6 可靠的测试质量是不断总结积累的结果

7. DevOps 与接口测试

接口测试的执行可以是接口测试框架，也可以是接口测试平台。一般来说采用接口测试平台的团队，接口测试管理流程相对比较成熟一些。接口测试与 DevOps 的协同是有两个平台共同完成的，例如由 DevOps 平台把被测试的系统（服务）部署到测试环境后，通知接口测试平台执行设定好的接口测试案例集。然后接口测试平台把执行结果返回给 DevOps 平台共开发团队查看。如果采用的是接口测试框架，可以在 Jenkins 等 CI/CD 工具中配置接口测试框架的调用，由 Jenkins 等 CI/CD 工具在部署好被测试系统（服务）后自动调用接口测试框架执行测试集，测试集执行完成后自动化生成测试报告，提高自动化测试结果的反馈效率。

Jenkins 调用接口自动化测试框架的 Pipline 举例。

Jenkinsfile

node {checkout scmenv.DOCKER_API_VERSION="1.23"sh "git rev-parse --short HEAD > commit-id"tag = readFile('commit-id').replace("\n", "").replace("\r", "")appName = "airline"
registryHost = "127.0.0.1:30400/"
imageName = "${registryHost}${appName}:${tag}"
env.BUILDIMG=imageNamestage "UnitTest"mvn teststage "BuildImage"sh "docker build -t ${imageName} -f applications/airline/Dockerfile applications/airline"stage "Push"sh "docker push ${imageName}"stage "Deploy"kubernetesDeploy configs: "applications/${appName}/k8s/*.yaml", kubeconfigId: 'airline_kubeconfig'stage "APITest"mvn test –Papi-test
}

Jenkins 持续构建流水线：

图 7 Jenkins 自动化构建 - 部署 - 测试流水线

接口测试报告

图 8 自动生成测试报告

### GitChat 如何提高接口自动化测试的有效性覆盖和案例有效性