一、基本概念

在完成了API设计之后，接下来就要进入紧张的开发与测试工作了，也是我们大部分开发者的本职工作。
对于API的开发与测试而言，一般来说所面向的角色是不同的：API开发的主体人是普通的软件开发工程师（SDE），而API测试的主体人则是测试工程师（TSE）。当然，二者也并非完全割裂与对立的，在开发者自测试的牵引背景下，很多时候借助测试平台与自动化测试工具，测试活动也可以由开发者独立完成。

二、关于API开发

API开发态总体来说可以讲述的内容不多，不同编程语言、不同框架，对于API的开发模式都有所不同，我们只需要按照既有的设计文档按部就班实现接口业务逻辑即可。
当然，为了减少接口代码开发的工作量、也为了避免在开发中接口的具体实现与设计存在不一致的现象，我们可以使用一些插件工具，来基于yaml文件直接在代码汇总生成规范的rest风格接口框架代码，保持uri、入参、返回值均与设计时一致。

三、关于API测试

API测试态是一个与开发同等重要的环节，是保证整体服务质量的必要手段。
对于API测试而言，一般分为两种：开发后的本地测试，以及部署后的在线测试。

1、本地测试

对于本地测试，一般开发者都会非常熟悉，具体测试手段非常灵活，既可以自己写测试脚本，也可以使用单元测试等。
这里，我们还有一些创新性的健壮性测试手段，这部分较为复杂，详细说明清楚需要单独开一章说明，其基本原理为：

• 通过分析服务接口yaml文件，获取接口相关参数类型、参数取值范围等条件，而后构造可能是极端值的边界、异常条件发起接口调用请求，观察接口是否能够妥善处理这些情况，例如：对于主键id查询参数，虽然是int类型，但逻辑上是不允许传递小于1的值的。这里利用健壮性测试手段，就可以自动构造0、-1、-65535等情况，看接口是否能够顺利处理这些情况。

2、在线测试

（1）基本方法

对于在线测试，主要是指服务部署到Alpha、Gamma或者生产环境后，我们所采取的在线自动化测试手段。一般来说，这种在线的自动化测试都会依托于平台进行，主要会包含功能测试、性能测试、可靠性测试等。
目前各个稍大的公司都会有自己的DevOps工具链，也都会有自己的在线自动化测试平台。在线测试的基本流程如下：

• 首先，服务会上传自身的接口设计yaml文档到平台，这里一般通过代码仓托管的形式进行，方便yaml修改后自动同步。在完成上传后，工具平台会自动解析、并按照接口去自动生成AW（ActionWord）。这里的AW我们就可以理解为一个独立的接口单元，是我们去构造用例的最基本单位。
• 其次，服务会根据业务需求与接口使用场景，利用图形化的界面对AW进行拖拽、完成用例的基本构造，避免以往大段的测试脚本撰写。一个测试脚本我们一般会将其分为前置步骤setup、测试步骤teststep、teardown三个步骤，对于每个测试步骤，我们也需要妥善定义检查点checkpoint。
• 最后，服务会将写好的用例归档到测试任务中，方便统一测试执行。

（2）测试策略

当服务完成用例撰写、测试任务构造后，一般而言我们有两种方法进行：定时拨测，或流水线测试门禁。

1、定时拨测

对于定时拨测而言，实际上就是我们通过定义第三方微服务定时任务的方法，不断的发起测试任务并获取测试结果，相当于对服务的整体接口与业务逻辑进行巡检。同时，对于拨测结果，我们还可以定义不同等级的告警策略来帮助服务快速发现异常。

2、流水线测试门禁

对于流水线测试门禁而言，在服务升级发版的过程中，我们一般使用流水线来进行。这时，我们会将服务所涉及的所有关键特性与功能相关测试任务关联到发版部署后的一个步骤中，作为一个流水线环节自动进行测试。
这样，我们就能在代码部署后，自动验证上线的新代码是否会影响已有功能。如果自动化测试成功率未能达到100%，则说明整体功能受到的影响、门禁未通过，这时服务就需要详细定位问题、优化整改了。

四、评估方法

在指标维度层面，由于测试与服务质量息息相关，因此考核也主要集中在了API测试阶段，API开发阶段暂不涉及。
这里，我们一般利用API健壮率、API功能拨测覆盖率、API性能测试覆盖率、API门禁覆盖率、API用户场景覆盖率这几个指标来做衡量。

1、API健壮率

对于API健壮率，指的是服务在平台进行API健壮性测试时，不存在相关问题的接口比例。该指标主要为了衡量服务对外提供接口在各种满足参数范围、但取值极端的情况下，这类极端情况的应对办法，能否正确的识别异常并返回给用户以正确的状态码，一般应当达到100%。

2、API功能拨测覆盖率

对应API功能拨测覆盖率，指的是服务在平台配置的用例拨测，对当前服务总体接口的覆盖程度。所谓功能拨测，也即笔者在上文所谈到的定时拨测，该指标也是为了方便衡量当前服务在自动化用例测试与巡检的能力完备度。
这样的定时拨测，可以快速有效地在用户前发现服务故障与接口不可用，拦截版本/环境/脚本稳定性问题，因此我们牵引达到100%。

3、API性能测试覆盖率

对于API性能测试覆盖率，其原理与功能拨测类似，只不过这里将测试任务类型从接口功能测试变成接口性能测试。所谓性能测试，其基本原理就是提前定义好接口的一些性能基线、TPS等指标，然后实行流量压测，观察接口响应、状态码等情况是否正常，以此来判断接口是否能满足既定的性能需求，以及避免可能的接口性能恶化而导致的服务不可用。
需要注意的是，功能测试一般而言是服务每一个接口都需要保证的，但性能测试则不一定：通常来说，只有会被外部服务高频次调用的外部接口，才会有性能评估与测试的需求。因此，这里我们的接口评估范围是服务的OpenAPI、以及服务自身所指定的需要进行性能测试的接口，牵引服务达到100%。

4、API门禁覆盖率

对于API门禁覆盖率，指的是服务在流水线发布阶段，经过门禁检查后接口的功能测试覆盖情况，对应笔者上文所谈到的流水线测试门禁。通过添加这样的门禁检查，我们能够较为全面的拦截由版本引入的接口兼容性问题和功能问题。
一般而言，流水线的发布部署都会包含Alpha与Gamma阶段，因此在门禁覆盖的检查上，不同阶段也是有着不同的要求：在Alpha阶段的用例覆盖检查，我们的要求是达到90%即可；而在Gamma阶段我们的要求则会提升至100%。

5、API用户场景覆盖率

对于API用户场景覆盖率，指的是用例的具体参数配置与用户在现网实际调用时参数的对比情况。这部分与健壮性评估类似，整体逻辑较为复杂，详细说明清楚需要单独开一章说明，这里简单说明一下基本原理。
用例，代表了服务对用户调用接口行为的模仿与预测，并制定出的执行测试样例。虽然在一定程度上可以检验接口功能的可用性，但是会存在这样的问题：

• 对于一个接口而言，不同的参数调用组合，实际代表的其实是用户不同的行为逻辑，而这种不同的参数组合在代码层面可能会代表截然不同的行径与分支，从而带来各种各样的结果。测试人员在编写用例时，只能在局限的范围内尽可能模仿用户的使用行为逻辑，但很难将用户的全部行为都囊括在其中。

因此，基于调用链大数据分析手段，我们对海量的用户接口调用与参数情况做聚类分析，并提出了一种名为 “API用户场景覆盖率” 的看护维度。

对于该指标而言，主要分成三部分内容：

1、用户场景覆盖情况

该场景原始数据来源为调用链，经过我们大数据聚合分析之后可以得到具体结果：在生产环境中，用户调用的相关实际接口、调用参数组合以及各参数组合的调用次数情况。

同时，针对大数据的分析手段，我们可以对具体参数组合调用次数做分析统计，并针对性地引入“高频”的概念以定级：对于调用次数较少的的级别的场景，我们倾向于是不重要的或异常的调用，找出调用次数多的高频场景。

2、用例场景覆盖情况

基于微服务所配置的功能测试套，解析对应的用例接口以及相应的参数选择情况，就可以找到服务侧所定义的接口场景覆盖情况。

3、指标评估

上述两种的参数组合覆盖情况的差集，就可以得到了接口用户实际使用场景未覆盖的情况。

加之结合用例自动化的生成手段，就可以较为方便快捷的为服务提供接口调用场景的缺失与待补充情况，作为用例设计的指导，以100%为目标牵引服务完成用例参数补充，形成正向的用例完善机制。

五、小结

API的开发与测试是生命周期的中间环节，也是作为开发者的关键职责所在。规范的开发流程以及完善的接口测试也是保障API设计顺利落地、交付的重要手段。这里，我们要多加利用自动化的开发工具和框架，以及各类测试工具与平台，以此在保证代码与测试用例质量的同时，降低我们的整体工作量，并且能够从多维度提前感知、发现我们的接口存在的相关问题。