XOP设计说明书-测试方案及操作日志-V0.0.1.docx

XOP异步消息处理设计说明书

XOP设计说明书
(测试方案和操作日志)

文档版本号：
V1.0
文档编号：

文档密级：
保密
归属部门/项目：
技术与产品
子系统名：
XOP
子系统名：

编写人：
Leo Li
编写日期：
2011-5-26

深圳走秀网络科技有限公司 版权所有

内部资料 注意保密

修订记录：
修订人
日期
修改点
版本
Leo Li
2011/5/26
创建文档
V1.0.0

派发清单：
发文人/部门
日期
电话/传真

受文人/部门
动作类型*
日期
电话/传真

＊动作类型：批准、审核、通知、归档、参与会议，其它（请说明）

目 录
1 简介 4
1.1 背景说明 4
1.2 目的 4
1.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.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系统中商品对接功能的实现方法，用于指导该功能模块的代码实施。
1.3 文档范围
本文档定义了商品对接模块的处理流程、任务调度机制、数据抓取策略、数据库设计等。
1.4 预期的读者和阅读建议
本文档的读者必须对XOP业务规范、XOP与3rd间的业务依赖关系有所了解。本文档的预期读者包括但不限于：产品经理、设计人员、开发人员和测试人员等。
1.5 参考文档
1.5.1 包含文档
N/A：无包含文档；
1.5.2 相关文档
N/A：无包含文档；
1.6 假设与依赖
系统间权限校验通过，具备所需的接口调用和数据访问权限。
1.7 缩略语和术语
缩略语/术语
全 称
说 明
XOP
Xiu open Api
深圳走秀网络科技有限公司用于接入或接出第三方系统的框架平台。
3rd
第三方系统
深圳走秀网络科技有限公司外的第三方系统
XIU Business
走秀业务系统

2 商品对接综述
2.1 概述
我们需要建立一个公共开放的API接口和走秀商品库建立联系，各种渠道都必须通过走秀商品的API接口来执行商品的读取、写入、修改及上下架操作。同步供应商商品时，存在推和拉两种方式。

3 商品对接实现
3.1 商品对接技术架构

供应商

Persistence Layer
SOAP、RESTful
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处理流程图，供应商采用推的方式对接商品，除接口调用方式不同外，后续流程等同于3.2(调用供应商接口对接商品)。
3.4 类目及品牌关联

3.5 任务调度
任务调度采用Quqrtz实现，调度策略为：
(根据需求制定，后期考虑由配置页面进行配置)

3.6 商品对接并发处理方式

采用生产消费者模式，进行处理，其中生产者和消费者都为多线程实现。
生产者：调用供应商接口，获取商品数据源，并将数据源放入处理队列
消费者：从队列中拿出数据，进行解析、过滤、关联等后续工作，直到入库完成
线程数：抓取线程数和解析线程数根据实际运行环境确定。

4 测试方案
4.1 手动测试方案
4.1.1 描述
平台提供接口测试页面，供测试人员手动测试，主要考虑以下因素：
l 界面两级联动，一级为商家，另一级为接口
l 页面采用Ajax发送接口测试请求，并 异步 监听测试运行状态，返回请求结果
l 一次可以测试一个或多个接口，由测试人员自己选择；多个测试同步执行由服务端多线程完成
l 如果已启动一组测试，则需要等待该组测试完成后才能启动下一组(降低编程的复杂度)
每一组测试为一家公司的一个或多个接口
l 如果当前测试为“正在执行”状态，则前台页面JavaScript启动一个Timer监控测试状态，每30秒查询一次执行状态。
4.1.2 类图

4.1.3 时序图

4.1.4 测试状态

列表说明：
编号
名称
说明
1
启动中
测试任务启动后，建立网络连接、初始化需要时间，这段时间为启动状态
2
正在执行
测试一个或多个接口
3
成功完成
正常完成
4
异常失败
异常中断
4.1.5 界面原型

4.2 自动化测试方案
针对测试用例描述，编码实现自动化测试，启动一个测试任务自动执行。每个接口的测试方式与手动测试等同，测试完成以后结出一个整体测试报告(如下表)。

公司名
接口名
测试结果(成功/失败)
测试失败原因

总计：
总计：
总记：成功/失败

(自动化测试考虑后期实现）
4.3 单元测试
采JUnit4对业务方法编写单元测试，单元测试必须严格执行，是系统能够正常运行的重要保障。由编码人员编写自己所负责模块的单元测试用例。
5 操作日志方案
5.1 方案综述
采用Spring AOP记录操作日志。Spring AOP一直是Spring的一个比较有特色的功能，利用它可以在现有代码的任何地方，嵌入我们所想的逻辑功能，并且不需要改变我们现有的代码结构。贯彻面向切面编程的思想，降低程序的耦合度。
两种日志收集方式的比较：
特点
操作记录接口
AOP
技术复杂度
技术简单、易于理解
技术相对复杂，多数情况下开发人员不需要关心
耦合程度
操作接口与组件紧密耦合
操作记录与应用解耦
对现有组件的影响
组件需要增加日志接口业务逻辑
除特殊需求以外，组件不需要修改
业务灵活性
能够以比较明确的方式满足业务需求
多数操作采用统一的逻辑，个别业务可独立编码，但编码相对复杂
综上所述，建议采用AOP的方式进行操作记录的数据收集，能够满足业务的需求且对开发人员透明，具有较低的耦合程度。
5.2 示例说明
使用Spring AOP对Action做日志管理
1. 编写日志处理类
package com.xui.interfacetest
import 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.xiu.interfacetest
public class InterfaceTestAction{
public void test(){
//方法体
}
}
3. Spring配置文件
<bean id="apiLog" class=" com.xui.interfacetest.ApiLog">
</bean>
<!--将日志类注入到bean中。-->
<aop:config>                  
<!--调用日志类-->
<aop:aspect id="b" ref="apiLog">
<!--配置在log包下所有的类在调用之前都会被拦截-->
<aop:pointcut id="log" expression="execution(*com.xui.interfacetest.*.*(..))"/>
<!--在log包下面所有的类的所有方法被调用之前都调用apiLog中的before方法-->
<aop:before pointcut-ref="log" method="before"/>
<aop:after pointcut-ref="log" method="after"/>
<!--在log包下面所有的类的所有方法被调用之前都调用apiLog中的after方法-->
          </aop:aspect>
 </aop:config>

注：现有项目中没有使用注解，最好考虑使用注解配置，做到简单清晰快速
内部资料 第 13 页 注意保密