什么是接口测试？用例设计

接口测试是测试系统组件间接口的一种测试，主要用于测试系统与外部其他系统之间的接口，以及系统内部各个子模块之间的接口。测试的重点是要检查接口参数传递的正确性，接口功能实现的正确性，输出结果的正确性，以及对各种异常情况的容错处理的完整性和合理性。针对软件接口的分类一般有如下几种情况：

1)系统与系统之间的调用，如微信向用户提供统一的对外接口，程序员调用接口完成基于微信的小程序等；

2)同一系统内部上层服务对下层服务的调用，如一个软件程序一般分为表示层，业务层和数据层，表示层调用业务层的接口来完成自己的工作，而业务层又会调用数据层的接口来实现相应的业务等。

其以保证系统的正确和稳定为核心，重要性主要体现为以下几个方面：

（1）能够提早发现 bug，符合质量控制前移的理念。

（2）接口测试低成本高效益，因为接口测试可以自动化并且是持续集成的。

（3）接口测试从用户的角度对系统接口进行全面检测。实际项目中，接口测试会覆盖一定程度的业务逻辑。

接口测试的用例设计

 

接口测试的用例设计与单元测试有相似之处。都需要用到如：边界值法，等价类法等基本测试方法。

首先，设计接口测试用例的出发点是要验证接口实现的功能与性能指标与接口设计文档的一致性，同时测试接口具有良好的容错机制，能在接收到各种异常输入数据时做到：返回对错误定位具有良好参考意义的错误码，屏蔽底层错误信息，同时接口测试用例需要暴露接口代码更多的代码缺陷，以这个出发点为导向。

其次，选择合适的测试对象。对一个系统做接口测试，识别出合理的测试对象才能保证接口测试达到预期效果，甚至能达到事半功倍的效果。一个系统可能有很多的层次结构，也就有了不同层级的许多接口，如果对每个接口分别进行测试，时间和人力消耗较大，且用例数量大，用例的维护成本很大。分析出系统的关键模块和核心接口，并对其进行完整的测试，能以最小的测试投入，达到最好的测试效果。接口测试用例的内容应该包括：

输入参数组合、预期结果、实际运行结果以及备注的其他相关信息，如：测试功能点说明，测试环境说明等。其中，预期结果包括接口返回值以及接口的输出参数的内容。输入参数的组合应遵循等价类法和边界值法等常用用例设计方法，以最少的用例数量覆盖所有典型参数组合，做到每条用例覆盖不同的测试点，且每条用例都不可被取代。另外，接口测试用例设计时，需要注意的是以下几点：

(1)每一条用例需要有完善的初始化操作和结束操作。在每条用例开始时，由于不确定上一条用例的执行结果对测试环境的影响，因此需要把涉及到此条用例的相关数据进行初始化，比如：测试创建文件的接口，需要把已存在的文件全部删除，然后在用例中创建相应数量的文件，才能准确的在验证点中写明，调用创建文件接口以后，设备上存在几个文件，如果不进行初始化操作，有可能上一条用例产生的文件依然存在，那验证点中写明的文件个数就与实际情况不符，该条用例运行结果就是失败，但这个结果实际上是因为没有进行用例数据初始化造成的。同样接口的结束操作也是为了尽可能不影响后续用例的测试环境和执行结果，比如：该条用例创建的文件夹和文件，分配的内存空间等等，都需要在用例执行结束时将其删除或释放空间。我们知道，不管是内存，还是磁盘空间或者是其他资源都不是无限的，如果不在使用完毕后及时释放，就会出现意想不到的测试结果，比如相关资源被耗尽导致接口调用失败，文件数达到上限，内存被耗尽等，尤其是在 API 接口的性能测试和稳定性测试中出现此类问题，会严重影响测试结果的正确性，由于需要排查到底是接口本身的 bug还是测试脚本或用例的 bug 引发的不通过的测试结果，增大了测试难度，也增加了测试的时间成本。

(2)接口的初始化操作和结束操作通常是通过调用其他接口来完成的，部分初始化操作和结束操作的接口调用时，不用判断其接口调用返回值就可以直接往下执行。原因有两点，一是用于初始化和结束操作的接口往往是比较简单的或是基础性的接口，这类接口往往是最先被测试并已通过测试的，因此我们假定这些接口都是被正确实现了，不需要通过判定其返回值来确认该操作是否成功，二是此类接口的调用结果往往既可能成功也可能失败，但就算失败了，也不影响接口测试本身，因此不需要判定其返回值。举个例子，如果我在调用创建文件接口前，为了初始化测试环境调用了删除文件接口，那么它的执行结果有两个，成功或失败。如果执行成功，则证明之前的测试环境中残留有其他用例创建的文件，删除操作有效，如果执行失败，则确认了该测试环境中已无影响测试的其他数据，可以顺利进行下一步接口调用，因此无论初始化接口调用结果为成功或失败，都确保了测试环境与预期一致，不需要对初始化接口进行调用结果判断。不需要对结束清理接口进行结果判断的原因类似，被测接口创建文件的执行结果可能为成功或失败，两种结果会导致测试环境中数据的不同变化，因此统一调用删除文件操作并不判断其调用返回值是简单有效的清理数据的方法。

因为接口测试的依据往往是需求规格说明书等软件设计文档，测试手段是把接口内的程序逻辑看作一个黑盒，只根据接口定义来编写测试代码，相当于把一个接口当作一个函数来进行测试，为了确保测试的覆盖率，可能会使用到单元测试的用例设计方法。具体的测试用例设计描述如下：

(1)正常用例的设计方法。

具体是指根据该接口实现的功能分析出该接口的正常用例包括哪几种输入参数的组合，从而在用例中构造相应的参数组合来覆盖所有的正常分支。输入参数分为两种类型，一种是可以直接赋值的，这种参数直接赋值即可，另一种参数是其他接口调用的输出参数，无法直接给出，这种参数就需要在调用被测接口前先调用其他接口，将其输出参数作为被测接口所需要的输入参数传入，或者事先将所需要的参数数据写入文件中，通过读取文件的方式获取输入参数的数据。对接口输入参数的组合，一是需要根据自然逻辑进行排列组合，排除无效的组合，以及将可以划分等价类的组合进行合并同类项，控制用例总数，避免冗余重复的用例耗费测试资源。

同时还应从业务上分析有没有特殊的组合是没有考虑到的，此类用例往往不止涉及单一接口，而是涉及到根据某个特定业务流程而产生的接口调用流程，通过接口调用的方式模拟关键业务流程，可以在不用搭建辅助测试环境的情况下单纯的测试被测接口，去除测试环境复杂性对测试结果的影响，极大提升测试效率。比如，要测试该接口涉及到的某个特定关键业务流程，有两种方式覆盖测试，第一种方式是搭建真实的测试环境，将该业务流程涉及到的所有模块，设备，软件全部准备到位，然后进行业务流程测试，此种测试的优点是最大程度还原了用户真实业务使用场景，缺点是出现异常极难定位问题原因到底是出在被测接口上，还是其他陪测设备或软件上，或者是几者之间的衔接出了问题。第二种方式则是刚才提到的通过调用接口模拟业务流程来覆盖业务测试的方式，这种方式不需要额外搭建测试环境，只需要通过编写脚本的方式进行接口调用，来测试业务流程即可，虽然会花费一些人力成本编写脚本代码，但测试结果直观，出现问题后便于定位解决。

还有一种情况会明显体现出这种业务测试方法的优势，就是不同型号的设备或软件都有类似业务流程，测试该接口只需保证接口的业务流程测试通过，就可判断如果实际业务流程出问题，多半是出在其他产品或者产品之间的衔接上，错误定位成本可控。一个完整的用例，除了输入参数的组合，还包括接口执行结果的预期值，预期值也包括两部分，一个是接口调用本身的返回值，该返回值反映了该接口调用结果是成功还是失败，一般来说，结果为0表示执行成功，非0则表示执行失败。非 0 的值一般是事先定义好的错误码，提示接口调用失败的原因，便于用户进行故障诊断。大部分接口的参数除了输入参数外，还包括输出参数，对于正常用例的输出参数也需要在用例中明确写出预期值，作为用例是否成功执行的依据。

(2)异常用例的设计方法。

异常用例的设计一般采用以下方法。选取一条正常用例的数据作为基础数据，然后遍历所有的输入参数，针对每一个输入参数，分别使用等价类法，边界值法等用例设计方法枚举出该参数的所有异常值，该用例除了该参数为异常外，其余参数均保持正常值不变，以保证测试结果仅由异常的那一个参数导致。当所有输入参数都使用上述方法设计了对应的异常用例之后，进一步补充不方便在用例文件中输入的异常参数到测试脚本中，通过 switch 分支判断，在测试脚本中将无法通过文件读取的异常输入值（如：错误指针等），直接赋值给接口的输入参数，测试某些指针类型的数据错误是否被及时捕获并返回正确无歧义的错误码。

异常用例的设计需要注意的是以下几点：

首先，接口应在任何时候都返回错误码，而不能存在未经处理，直接导致调用接口的程序异常退出，或者将底层错误信息直接返回给上一层调用程序。调用程序异常退出会给用户非常不好的用户体验，同时，无法进行故障诊断和错误定位，而未经处理的底层错误信息直接返回给调用程序，有可能将不应被用户知晓的数据信息返回给用户，比如数据库相关信息，造成可能被攻击的漏洞或安全隐患。

其次，错误码的准确性很重要。错误码的准确性对接口调用失败原因的定位有非常重要的意义，将极大降低后续维护成本，错误码的设置应当准确，无歧义，一种错误类型一个错误码，尽量将错误码编得更细，更有利于错误排查。比如：参数长度错误和参数类型错误应当为不同的错误码，而不应该是统一的参数错误的错误码。同时，错误码应当在接口设计文档中有明确定义，并且在不同接口中保持一致。

一个很好的测试用例设计过程应该是建立在前期深入的需求分析和文档设计的基础之上。需求分析得越深入全面、文档描述越详细清晰，则设计的接口测试用例就会越全面，越能暴露出接口的缺陷，从而提供出高质量的服务接口。并且在后续接口维护过程中，有详尽的接口设计文档作为支撑，也可以降低维护成本。