1、 XOP异步消息处理设计说明书 XOP设计说明书 (测试方案和操作日志) 文档版本号: V1.0 文档编号: 文档密级: 保密 归属部门/项目: 技术与产品 子系统名: XOP 子系统名: 编写人: Leo Li 编写日期: 2011-5-26 深圳走秀网络科技有限公司 版权所有 内部资料 注意保密 修订记录: 修订人 日期 修改点 版本 Leo Li 201
2、1/5/26 创建文档 V1.0.0 派发清单: 发文人/部门 日期 电话/传真 受文人/部门 动作类型* 日期 电话/传真 *动作类型:批准、审核、通知、归档、参与会议,其它(请说明) 目 录 1 简介 4 1.1 背景说明 4 1.2 目的 4 1.3
3、文档范围 4 1.4 预期的读者和阅读建议 4 1.5 参考文档 4 1.5.1 包含文档 4 1.5.2 相关文档 4 1.6 假设与依赖 4 1.7 缩略语和术语 5 2 商品对接综述 5 2.1 概述 5 3 商品对接实现 6 3.1 商品对接技术架构 6 3.2 调用供应商接口进行商品对接 6 3.2.1 处理流程 6 3.2.2 时序图 7 3.3 供应商调用XOP接口进行商品对接 7 3.4 类目及品牌关联 7 3.5 任务调度 8 3.6 商品对接并发处理方式 8 4 测试方案 8 4.1 手动测试方案 8 4.1.1 描述 8 4.1.
4、2 类图 9 4.1.3 时序图 9 4.1.4 测试状态 10 4.1.5 界面原型 10 4.2 自动化测试方案 11 4.3 单元测试 11 5 操作日志方案 11 5.1 方案综述 11 5.2 示例说明 12 1 简介 1.1 背景说明 XOP系统需要与走秀网的业务系统进行商品对接,还需要调用第三方接口,进行商品对接。主要涉及到接口调用、页面解析(现阶段主要为XML)、类目关联、商品入库等过程。技术层面,主要需要考虑接口的可测试性、任务调度等,同时需要考虑资源最大利用率、性能、稳定性以及容错机制。 1.2 目的 本文档主要描述XOP系统中商品对
5、接功能的实现方法,用于指导该功能模块的代码实施。 1.3 文档范围 本文档定义了商品对接模块的处理流程、任务调度机制、数据抓取策略、数据库设计等。 1.4 预期的读者和阅读建议 本文档的读者必须对XOP业务规范、XOP与3rd间的业务依赖关系有所了解。本文档的预期读者包括但不限于:产品经理、设计人员、开发人员和测试人员等。 1.5 参考文档 1.5.1 包含文档 N/A:无包含文档; 1.5.2 相关文档 N/A:无包含文档; 1.6 假设与依赖 系统间权限校验通过,具备所需的接口调用和数据访问权限。 1.7 缩略语和术语 缩略语/术语 全 称 说
6、 明 XOP Xiu open Api 深圳走秀网络科技有限公司用于接入或接出第三方系统的框架平台。 3rd 第三方系统 深圳走秀网络科技有限公司外的第三方系统 XIU Business 走秀业务系统 2 商品对接综述 2.1 概述 我们需要建立一个公共开放的API接口和走秀商品库建立联系,各种渠道都必须通过走秀商品的API接口来执行商品的读取、写入、修改及上下架操作。同步供应商商品时,存在推和拉两种方式。 3 商品对接实现 3.1 商品对接技术架构 供应商 Persistence Layer SOAP、RESTfu
7、l CXF HttpClient RPC Quqrtz 推、拉数据 Service Layer 商品对接技术架构(关注通讯和任务调度) 其它… 说明:本架构图仅用于描述商品对接模块的技术架构 3.2 调用供应商接口进行商品对接 3.2.1 处理流程 流程说明: 供应商API一般为Web Service服务,通常有SOAP和RESTful两种类型,后期我们还要考虑同步通过网络爬虫获取的商品信息。由于商品数据量可能较大,处理过程中应重点关注处理性能。 3.2.2 时序图 3.3 供应商调用XOP接口进行商品对接 参见3.2.1处理流程图,供应
8、商采用推的方式对接商品,除接口调用方式不同外,后续流程等同于3.2(调用供应商接口对接商品)。 3.4 类目及品牌关联 3.5 任务调度 任务调度采用Quqrtz实现,调度策略为: (根据需求制定,后期考虑由配置页面进行配置) 3.6 商品对接并发处理方式 采用生产消费者模式,进行处理,其中生产者和消费者都为多线程实现。 生产者:调用供应商接口,获取商品数据源,并将数据源放入处理队列 消费者:从队列中拿出数据,进行解析、过滤、关联等后续工作,直到入库完成 线程数:抓取线程数和解析线程数根据实际运行环境确定。 4 测试方案 4.1 手动测试方案
9、 4.1.1 描述 平台提供接口测试页面,供测试人员手动测试,主要考虑以下因素: l 界面两级联动,一级为商家,另一级为接口 l 页面采用Ajax发送接口测试请求,并 异步 监听测试运行状态,返回请求结果 l 一次可以测试一个或多个接口,由测试人员自己选择;多个测试同步执行由服务端多线程完成 l 如果已启动一组测试,则需要等待该组测试完成后才能启动下一组(降低编程的复杂度) 每一组测试为一家公司的一个或多个接口 l 如果当前测试为“正在执行”状态,则前台页面JavaScript启动一个Timer监控测试状态,每30秒查询一次执行状态。 4.1.2 类图 4.1.3
10、 时序图 4.1.4 测试状态 列表说明: 编号 名称 说明 1 启动中 测试任务启动后,建立网络连接、初始化需要时间,这段时间为启动状态 2 正在执行 测试一个或多个接口 3 成功完成 正常完成 4 异常失败 异常中断 4.1.5 界面原型 4.2 自动化测试方案 针对测试用例描述,编码实现自动化测试,启动一个测试任务自动执行。每个接口的测试方式与手动测试等同,测试完成以后结出一个整体测试报告(如下表)。 公司名 接口名 测试结果(成功/失败) 测试失败原因
11、 总计: 总计: 总记:成功/失败 (自动化测试考虑后期实现) 4.3 单元测试 采JUnit4对业务方法编写单元测试,单元测试必须严格执行,是系统能够正常运行的重要保障。由编码人员编写自己所负责模块的单元测试用例。 5 操作日志方案 5.1 方案综述 采用Spring AOP记录操作日志。Spring AOP一直是Spring的一个比较有特色的功能,利用它可以在现有代码的任何地方,嵌入我们所想的逻辑功能,并且不需要改变我们现有的代码结构。贯彻面向切面编程的思想,降低程序的耦合度。 两种日志收集方式的比较: 特点 操作记录接口 AOP 技术复杂度 技术简单
12、易于理解 技术相对复杂,多数情况下开发人员不需要关心 耦合程度 操作接口与组件紧密耦合 操作记录与应用解耦 对现有组件的影响 组件需要增加日志接口业务逻辑 除特殊需求以外,组件不需要修改 业务灵活性 能够以比较明确的方式满足业务需求 多数操作采用统一的逻辑,个别业务可独立编码,但编码相对复杂 综上所述,建议采用AOP的方式进行操作记录的数据收集,能够满足业务的需求且对开发人员透明,具有较低的耦合程度。 5.2 示例说明 使用Spring AOP对Action做日志管理 1. 编写日志处理类 package com.xui.interfacetest impo
13、rt org.aspectj.lang.JoinPoint; public classs ApiLog{ public void before(JoinPoint joinpoint){ joinpoint.getArgs();//JoinPoint类可以获取Action所有的相关配置信息和request等内置对象。 //被拦截方法执行前要执行的代码 } public void after(JoinPoint joinpoint){ //被拦截方法调用之后调用此方法 } } 2. 被拦截的Action类(当然也可以是Manager类) package com.xi
14、u.interfacetest
public class InterfaceTestAction{
public void test(){
//方法体
}
}
3. Spring配置文件






