阿里QA导读：1688商品发布系统升级发品框架GPF，面对商品模型复杂度极高，发布的海量场景、多重业务逻辑如何覆盖？本文从手工测试到自动化测试，以及完善的质量保障方案一一解答。

1、项目背景

1688商品发布系统运行多年，架构逐步腐化，业务逻辑冗余复杂，开发维护成本居高不下。加上1688新赛道（加工定制、工业品、分销）不断孵化，如何降低不同赛道之间在商品管理的业务逻辑耦合，并让业务侧开发同学也能参与进来，提升项目迭代效率，对商品发布架构提出了更高的要求！2017年淘系BC融合后，淘宝、天猫商品发布由业务中台团队统一承接，过程中孵化了统一发品框架GPF，并通过该框架支撑了集团大部分部门的商品发布工作。GPF框架可以快速搭建商品发布业务，通过流程、组件的复用极大提高开发效率，并支持流程、组件层面的定制，保障业务之间相互隔离不影响。考虑到1688现有商品人手短缺，长期来看没有资源维护独立框架，且中台GPF框架在多个部门运行日益成熟，最终方案选型使用GPF。

2、难点分析

2.1 商品发布的海量场景

1688类目体系组合规则：叶子类目*属性*业务场景*商家身份*购买服务*类目资质，需要覆盖的场景是一个庞大的笛卡尔集合，预计测试集数量级达千万。无法通过手工来全量覆盖验证。

2.2 商品发布的多重业务逻辑

商品发布过程涉及很多行动项，需要保证在特定类目与服务下，N多组件展示逻辑、判断逻辑、联动逻辑、标签数据等的准确性和一致性。

2.3 商品模型的高复杂度

商品模型可以具象化为一个JSON对象，部分商品模型格式化后可以达到数百行，该模型决定了商品发布表单是否显示正常、能否提交生成商品、后续依赖业务如交易等能否正常流转，错误的商品模型将会引发客诉、资损、阻塞交易等。

 

3、应对策略

3.1 手工测试

3.1.1 沉淀等价类规则（千万级别 --> 200+）

 

3.1.2 比对工具，提升模型比对效率

商品模型解析后达到数百行，人工比对不现实，模型参数比对工具应运而生，提升了模型比对的效率。

3.2 自动化测试（海量数据解决方案）

3.2.1 使用线上数据做回归测试

灰度开放阶段，提前获取线上计划灰度的类目下的商品，并转化成自动化用例执行

 

可以解决的问题：

• 老版有，新版无；

• 老版有，非必填；新版有，必填；

• 老版无，新版有，且必填

不能解决的问题：

• 老版无，新版有，且非必填；

• 老版有，必填；新版有，且非必填

3.2.2 双发比对做回归测试

数据正确性校验

3.3 完善质量保障方案

3.3.1 建设覆盖主干的自动化保障体系

• 端到端的UI自动化（UI逻辑自动化和图片对比）

• 接口自动化（待接入天启，录制回放对比）

• 单测自动化（在探索基于gpf的组件化的单测能力）

3.3.2 开发迭代阶段，提升研发效率

4、总结分析

商品发布框架升级是一个比较典型的项目——海量场景/复杂数据模型/新老兼容，静下心做好抽象分析，准备好提效方案，棘手问题和繁重的工作自然迎刃而解。

商品发布海量场景，难以人工覆盖；商品模型大，难以人工校验模型准确。 

人工梳理等价类，尽可能提升理论覆盖率；使用对比工具，提升模型比对效率。 

采用线上流量数据，作为商品发布自动化入参，提升覆盖回归不同类目的效率。

过程问题分类：

分类1：特定的类目和服务下，新老版本发布页组件展示逻辑不一致

如：服饰项目、电脑项目、体育运动项目，新老版本产品销售信息组件展示不一样，且新版本发布的商品，在线上商品详情页面出错。

分类2：页面上组件联动，逻辑不一致

如：特定类目（饮料、数码产品等），计量单位组件新老版本不一致。

分类3：新版发布的商品出现部分打标缺失

如：GPF发布的商品出现官方直送标签丢失的现象。

分类4：特定类目下，新版本的组件判断逻辑错误

如：新版发布的商品起批量配置，没有做校验