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.2 自动化测试（海量数据解决方案）
3.2.1 使用线上数据做回归测试
灰度开放阶段，提前获取线上计划灰度的类目下的商品，并转化成自动化用例执行
可以解决的问题：
- 老版有，新版无；
- 老版有，非必填；新版有，必填；
- 老版无，新版有，且必填
不能解决的问题：
- 老版无，新版有，且非必填；
- 老版有，必填；新版有，且非必填
3.2.2 双发比对做回归测试
数据正确性校验
3.3.1 建设覆盖主干的自动化保障体系
- 端到端的UI自动化（UI逻辑自动化和图片对比）
- 接口自动化（待接入天启，录制回放对比）
- 单测自动化（在探索基于gpf的组件化的单测能力）
3.3.2 开发迭代阶段，提升研发效率
4、总结分析
商品发布框架升级是一个比较典型的项目——海量场景/复杂数据模型/新老兼容，静下心做好抽象分析，准备好提效方案，棘手问题和繁重的工作自然迎刃而解。
商品发布海量场景，难以人工覆盖；商品模型大，难以人工校验模型准确。
人工梳理等价类，尽可能提升理论覆盖率；使用对比工具，提升模型比对效率。
采用线上流量数据，作为商品发布自动化入参，提升覆盖回归不同类目的效率。
过程问题分类：
分类1：特定的类目和服务下，新老版本发布页组件展示逻辑不一致
如：服饰项目、电脑项目、体育运动项目，新老版本产品销售信息组件展示不一样，且新版本发布的商品，在线上商品详情页面出错。
分类2：页面上组件联动，逻辑不一致
如：特定类目（饮料、数码产品等），计量单位组件新老版本不一致。
分类3：新版发布的商品出现部分打标缺失
如：GPF发布的商品出现官方直送标签丢失的现象。
分类4：特定类目下，新版本的组件判断逻辑错误
如：新版发布的商品起批量配置，没有做校验
