我理解的接口测试
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了我理解的接口测试相关的知识，希望对你有一定的参考价值。
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
接口
应用（模块）提供对外信息交互的功能。其实可以把被测模块想象成一个黑盒，那么接口就是用来从盒子里拿东西(data)和放东西(data)。
接口测试验证点
网上很多资料说验证返回字段、验证数据持久化内容等，那我的理解是：验证接口的意图！
接口不会平白无故的设计，接口的设计是为具体的业务功能服务，而我们对该接口的测试就是验证该接口设计是否符合需求，能否正常为业务功能服务。
验证方向：
-
接口设计文档的参数和返回是否满足前端GUI完成登录操作(判断登录成功参数是否足够、返回值是否满足登录操作后的展示页面、参数和返回值的类型是否符合需要、返回值是否冗余等)
-
传入参数后并接口处理完后，是否按需求正确的返回值(正确的传参是否会返回相关返回值、返回的返回值类型和值是否符合接口设计文档、可选参数传入影响返回值、必传参数和可选参数传入符合文档设计、返回内容是否过大等)
-
传入参数后，接口处理符合需求(接口对应持久化的数据，是否持久化)
-
传入参数后，接口处理过程中的性能指标符合需求[性能测试]
-
传入参数后，接口处理恶意数据符合需求[安全测试]
大致就这么多，其实后两者更多属于接口性能和接口安全，但秉着测试左移和测试更高效化，应该在项目前期做更多类型的测试，确保大部分问题在项目前期就能得到解决(性能测试和安全测试建议在接口功能趋于稳定后再做)
接口测试原理
-
通过工具模拟调用方往被测应用发送请求报文
-
被测应用接受请求报文后，会对该报文处理然后再将响应报文发送给调用方(工具)
-
调用方(工具)接受响应报文、断言响应报文和验证处理结果
接口测试流程
跟功能测试一样，需求讨论=>评审需求=>确定需求=>产出接口协议文档=>根据需求静态测试接口文档=>根据需求文档和接口协议文档设计测试用例(测试用例主要从业务场景、上述验证点来考虑)=>评审用例=>冒烟测试接口=>接口测试=>输出测试报告
接口测试价值
测试左移、降低成本、提高效率、提高集成测试版本质量、降低版本发布风险、加深测试人员对被测应用技术架构理解，更加全面测试被测应用
接口测试用例设计
接口测试用例设计除了日常的业务场景以外，还需考虑文中提到的接口测试验证点。
-
输入参数测试：针对输入参数进行的测试，也可以说是假定接口参数的不正确性进行的测试，确保接口对任意类型的输入都做了相应的处理：输入参数合法(不合法)、输入参数为空、为null、输入参数超长、部分参数不传等。
-
功能测试：接口是否满足了所提供的功能，相当于正常情况测试，如果一个接口功能复杂时推荐对接口用例进行结构划分，这样子用例觉有更好的可读性和可维护性
-
逻辑测试：逻辑测试严格讲应为单元测试，单元测试应保持内部逻辑的正确性，可单元测试和接口测试的界限并不是那么清楚，所以我们也可以从给出的设计文档中考虑内部逻辑错误的分支情况和异常(利用传入参数尽可能覆盖代码的各个分支和异常)
-
异常情况测试：接口实现是否对各种情况都进行了处理，接口输入参数虽然合法，但是在接口实现中，也会出现异常，因为内部的异常不一定是输入的数据造成的，而有可能是其他逻辑造成的，程序需要对任何异常都进行处理
当然接口测试用例也应该和普通的功能测试用例一样具有：有效性、可理解性、清晰性、可维护性、可重现性
接下来，会讲讲如何开始做接口测试，敬请期待……
以上是关于我理解的接口测试的主要内容，如果未能解决你的问题，请参考以下文章