在互联网产品质量保障精细化的大背景下，根据系统架构从底层通过技术手段发起测试，显得尤为重要，测试分层的思想正是基于此产生的，目前也是较为成熟的测试策略。

一般采用自下而上的测试方式，以最简单的单一前后端系统为例，一般我们先保质底层服务接口的质量，再从前端发起全链路的端到端的业务测试。

测试环境准备

进行测试之前首先需要与开发确认好测试环境，通常情况下，一般情况业务涉及3个测试环境：测试环境、准生产环境及生产环境。测试一般在测试环境实施测试。为了方便快捷切换接口测试环境的 host 指向，我们可借助以下工具进行切 换：Eolink、Nohost、postman 等。

01 后端接口逻辑测试

接口后端逻辑测试思路：输入-业务逻辑-输出。测试人员输入测试用例的入参场景数据，调用接口发起后台服务处理，检查输出结果跟预期是否一致。接口测试用例设计严格按照接口文档设计，出了正常的功能测试外，应根据业务诉求考虑幂等、并发、数据一致性等逻辑。

测试用例设计方法

考虑三个方面：输入-业务逻辑-输出

举例：接口A提供了根据门店ID查询门店详情信息，我们需要关注：输入：门店 ID；业务逻辑：查询（从哪查）；输出：返回结果。

针对输入验证点：必填项校验（哪些字段是必填的）、参数长度校验（参数有无长度限制）、参数有效值校验（参数< 0 就是无效值）、参数组合校验、参数如果是枚举值，枚举值所有值都要测试、参数值的默认值校验，例如有些参数不传，会默认为0、某些参数特定的规则：例如资质编号为13 15 18位等。

业务逻辑：

设计方法：分支覆盖—>路径覆盖—>场景覆盖

一定要先明白接口对外提供的功能是什么，同时接口处理逻辑图也要清晰，准确的画出数据图，例如查询接口是从哪个表查询的，写入接口具体是写入到哪个表中，写入的哪个字段，字段具体是什么，举例：数据流图。

不同的业务场景需要不同的数据，要明白不同类型的数据如何构造，如何验证到真实的业务逻辑，下游 mock 有无风险等。

输出：分为正常输出和异常输出

针对输入点，我们预期结果是什么，一定要明确，比如参数为空，返回结果期望是参数为空；正确的参数，返回结果期望返回正确的结果，要确认返回值返回哪些信息，正确的结果的应该返回的每一个字段都需要校验。

测试方式

手工测试

手工测试就是借助浏览器或者部分测试工具（postman、Eolink https://www.eolink.com/ 等）手动执 行测试用例的过程。针对新开发接口建议首先进行全面的手工测试后再将部分可 重复执行用例加入自动化测试。
自动化测试。

接口测试相对容易实现自动化，且相对 UI 自动化也比较稳定，可以减少人工回归测试人力成本与时间，缩短测试周期，是支持后端快速发版需求，达到低成本高收益的根源。收益比较高的自动化主要体现在核心链路的冒烟和回归上。

接口自动化测试同样需要有需求分析、用例设计，依据用例设计编排测试计划功能，编写自动化测试脚本，实现接口自动化测试、自动执行及自动发送测试报告等环节。可考虑通过 Eolink 实施自动化回归计划的用例编排。

一个好的接口自动化测试框架应该涵盖以下几点：

a) 流程方面：在回归阶段加强接口各种场景的覆盖度，并逐步向系统测试， 冒烟测试阶段延伸，最终达到全流程自动化。

b) 结果展示：更加丰富的结果展示、趋势分析，质量统计和分析等。

c) 问题定位：报错信息、日志更精准，方便问题复现与定位。

d) 结果校验：加强自动化校验能力，如数据库信息校验。

02 前端交互测试

前端页面与后端代码之间的交互测试，可以理解为业务功能测试的一部分。

测试用例准备

根据业务要求编写功能测试用例，最好按业务模块拆分，逻辑清晰，此外针对编辑框可以通过等价类等方法丰富测试场景，按钮功能异常测试等，测试用例要严格评审对齐产品、研发、测试的三方认知。

测试数据准备

测试用例执行之前最好对测试场景进行梳理，需要准备什么样的数据，可以提前准备，比如退货退款场景可以提前铺设购买交易的订单，一些常用测试数据的准备也可以通过Eolink工具一键构造，降低场景数据构造成本。

测试方法

可以使用抓包工具来进行交互层面测试，查看每个交互功能，对应的接口是否正确 （包含请求头、请求参数、响应以及其他约束项），确保前端按照后端的要求正确地进行了调用。

在交互过程中，针对一个接口也会有多个场景，前端会根据不同的入参来调 用不同的场景，根据不同响应结果， 进行响应数据的改写，来获得不同响应，验证不同响应下前端的展示效果。在这里我们也可以使用一些 不同场景的交互测试。推荐 Mock 工具： https://www.eolink.com/

其他关注点

除了上述关注点外，业务质量要求较高的应该做到以下几点：