背景

酷家乐是一家面向未来的大家居全案设计平台及生态解决方案提供商，致力于为数字化升级提供一站式的解决方案。平台以设计为入口，链接大家居行业生态，为家居企业提供设计、营销、生产、管理、供应链等场景的解决方案和服务，助力全行业实现 “所见即所得” 的愿景。其背后都离不开茁壮的技术架构和稳定的基础设施。定制设计工具作为酷家乐工具中帮助用户实现其定制化服务的工具，其能完成定制柜体从建模到设计到图纸再到生产输出，都离不开数据二字，这也就意味着，定制数据的复杂性及多变性在测试过程中会成为一大难点。接口测试作为测试过程中必不可少且极其重要的一环，其数据的正确性在这里会极大地得到保障。接口测试通过率也被加入到发布过程中卡点数据，其重要性显而易见。

如何设计接口测试

优秀的后端测试开发最基础的素养就是懂得如何设计接口测试用例。下图简述了如何做好接口测试。本文不做展开

接口测试痛点

1. 测试数据难准备 – - 定制数据复杂且庞大，测试场景更是千变万化，测试场景难以穷举
2. 测试数据难维护 - - 同样是因为定制数据的复杂性，新功能迭代会导致原有 case 预期不正确，且输入数据需要同期更新。可能某一个字段的小改动，会导致 80% 以上的接口失败。这就表明这些测试数据的生命周期可能就只有一个礼拜，但是测试却需要花上可能一天的时间更新用例。case 越多，时间成本越高。投入产出比不成正比
3. 测试结果校验不精准 – - 一般简单的数据校验 ，可能是针对测试场景中的测试结果数据中的某个字段进行比较，或者测试数据全量校验，但是定制结果相同请求很可能每次的请求结果都不一致。这就要求我们去做 json 降噪处理，从而达到正确比对测试结果。
4. 测试结果同开发沟通不方便 - - 接口测试数据展现会是某个 body，body 内容是纯 json 文本。很难通过 body 去全面的认识该 case 的测试场景。只是单纯的将比对结果告知开发，复现问题会比较麻烦。

接口测试不同阶段的表现

测试数据准备

测试数据维护

测试结果校验

测试结果同开发沟通不方便

• 让开发下载接口测试代码测试？---- 不太现实，繁琐且效率低
• 对比结果截图甩给开发？---- 可能比较懵逼，不知道如何复现问题
• 将对应接口，请求参数，以及测试结果和预期结果，通通发给开发？---- 数据都有了，就是自己累得慌。CV 太多次也是体力活

Tips：
1、使用一些小的工具，自动上传测试结果至 oss
2、将测试数据作为存在模型或者方案中，甩个模型&方案链接
3、维护一个公共区域，记录接口测试变更。沟通可在该文档反馈

定制接口测试是如何做的

案例：

1、如编辑器 modeleditor 服务 3D 接口改造

• 3D 接口作为定制编辑器 modeleditor 服务中预览接口，其承载了编辑器中几乎所有数据，该接口若存在问题，其模型将无法构建。保障该接口的正确性即保证了建模过程中 80% 以上操作的正确性。
  改造前：通过从编辑器前端直接获取 3D 请求的数据，存入到接口测试的 post body 数据中，每次数据（新增减少字段，修改数据结构）的变动都会造成 body 数据不可用，或者数据不够新，测试结果也不可完全信任
  改造后：通过维护模型去维护接口数据，将所需要的场景数据直接保存到模型中，再通过打开模型，获取 3D 接口中的 Editordata 获取所需要的 body 数据，改造后可直接作为 3d 接口的发送数据。再将获取到的结构同上一次稳定版本比较，得到变动内容，看是否符合预期。

2、parameter-model 包拆分测试

parameter-model 包拆分包含底层数据的变更和改动，定制服务一半以上都依赖该包，其涉及相关服务广，范围大，牵一发而动全身。要做到前端无感知拆分，这就必须保证后端提供给前端的数据结构的一致性。简单的 API 返回数据的校验无法满足测试需求。因而采用对象层级的校验、在内存中对 model 层数据进行全量校验，保证拆分前后各对象的一致性。

测试结果：

宗旨

一切非人为确认的，固有的，程式化的操作，我们都需要用自动化来完成。

想了解更多关于酷家乐技术质量的文章，欢迎关注我们的公众号