SOA关键技术标准规范.doc

1. 服务分析规范
1.1. 服务特征和粒度
1.1.1. 服务特征
候选服务特征是：
Ø 提供一定功效性，有组成服务前提条件
Ø 可能转变到服务
Ø 有待经过评审步骤确实定
Ø 经过评审候选服务，成为服务：
Ø 有明确范围和业务价值
Ø 可能被实现，也可能需要构建
Ø 含有契约、接口及实现
服务是网络中可用软件资源。服务提供者经过标准机制提供服务，服务使用者经过网络有计划性地使用服务。服务代剪公布服务所在位置，并在使用者请求服务时定位服务。服务使用者和提供者角色不是唯一；服务提供者也能够是使用者，反之亦然。
下图显示了 SOA 中三个基础角色（服务提供者、使用者和代理）及其各自分工和操作。

图：SOA 角色和交互
提供者在服务约定中以标准语言描述其服务，并向代剪公布服务。用户从服务代理处（或登记处）查询所需服务，并接收相关服务访问约定和信息。随即，用户或使用者便可绑定到服务，并可和提供者直接通信。
服务包含两部分：接口和实现

图：服务部件
接口定义了使用者和提供者之间可编程访问约定。服务接口必需包含以下内容：
Ø 服务识别
Ø 服务输入和输出数据具体情况
Ø 服务功效和目标元数据
服务实现包含了服务功效或业务逻辑。对于服务使用者来说，服务实现应该是一个“黑匣子”；用户没必需知道服务功效实现细节。
1.1.2. 服务粒度判定标准和方法
服务粒度能够按基于服务功效及发送和接收数据数量来定义服务，如细粒度服务、粗粒度服务或组合服务。
在 SOA 中服务粒度有两种相关意思：服务是怎样实现，服务使用和返回了多少数据或多少消息。细粒度服务实施了最小功效，发送和接收少许数据。粗粒度服务实施了较大业务功效，并交换了更多数据。
细粒度服务是供粗粒度服务或组合服务使用，而不是由终端应用直接使用。假如应用是使用细粒度服务建立，则应用将不得不调用网络上多个服务，而且发生在每个服务上数据量较少，所以会对对系统整体性带来影响。所以细粒度服务用户不能直接调用她所使用细粒度服务。然而，因为粗粒度服务可能使用多个细粒度服务，所以它们不能提供粒度级安全和访问控制。
组合服务能够使用粗粒度服务和细粒度服务进行组装。数据数量数量不是粗粒度服务和组合服务之间区分。
粗粒度服务例子，如创建新用户，在这一过程操作是：需要经过部分外部服务验证对用户进行验证，并在 营销应用系统中创建用户统计。
组合服务例子能够是提供一个新DSL线，这需要一个服务调用来验证定单、创建或验证用户，确定产品库存及为数据线分配资源。
下图描述了服务粒度不一样等级及其相互关系。

图：服务粒度
作为复用服务，应注册到服务总线上进行管理和调用，在未来引入服务注册管理软件后进行统一命名空间管理，路径管理，Qos，SLA等元数据管理。在注册到服务总线时，要依据域模型来定义管理路径。
1.2. 服务识别方法
服务识别是从业务模型开始。依据实施SOA不一样初始点，分为自顶向下和自底向上及基于步骤方法。
通常来说，新建以SOA为建设方法论系统，我们推荐使用自顶向下方法，统一定义划分业务域，依据业务域业务实体模型来定义在其上服务，进行服务分类，分离出数据服务，业务服务，复合服务，公用服务，定义好其颗粒度。基于SOA来改造现有系统，要对现有系统进行服务化，依据颗粒度定义标准提炼出服务。然后基于企业级和部门级步骤来服用服务。

自顶向下服务分析，关键是从全局业务步骤角度出发，根据业务步骤具体程度发觉步骤中需要调用那些业务系统提供服务，而且需要提供哪些步骤服务注册到业务服务总线上被业务系统调用。
自底向上服务分析，则需要各业务系统开发上在自己业务系统内部角度把可重用组件服务话，把需要被全局业务步骤调用服务公布出来，注册在业务服务总线上统一管理。
物资系统采取自顶向下为主服务建设策略，从Maxim导出服务以自底向上方法推到服务模型。
1.2.1. 服务分类和抽象
服务能够分为以下五种类型：
Ø 数据访问许可对不一样数据源进行统一访问。
Ø 组件—提供对打包应用服务访问，如 ERP。
Ø 业务—提供使用一个以上打包应用或定制应用功效复杂服务。
Ø 组合—使用以上三种类型服务来创建包含新功效和现有功效新服务。
Ø 共享或企业基础架构服务 — 消息日志之类低级服务，其重用性使快速创建新高级服务成为可能。
1.2.1.1. 信息访问服务
信息访问服务许可用户对来自于企业内多种相关或无关数据源数据进行访问、集成和处理。这些服务通常隐藏了对数据源直接访问、底层格式复杂性和数据直接转换和处理。信息访问服务提供了跨应用统一API、松散耦合、公共数据模型和一致性信息重用。
信息访问服务是SOA架构中最为一般、使用最为广泛和最易于实现服务；将数据层和应用层进行分离通常是很简单。因为数据源被广泛地访问和共享，所以它们成为了服务实现第一目标。
XML 被广泛地应用于应用数据交换。在 SOA 实施中，一个能够提供和数据源无关、抽象化统一数据访问基础架构是很有价值。XML 数据服务 (XDS) 提供了对多个类型数据源访问和数据建模能力，并能够将物理数据翻译和转换为逻辑数据，还支持对逻辑数据基于 XML访问。
1.2.1.2. 组件服务
组件服务是由单个企业资源（不管其是否为ERP、CRM或SCM之类打包应用）公布粗粒度服务。“在ERP 中添加用户”就能够作为组件服务一个范例。这些服务很有价值，能够直接公布。
组件服务实现采取了单独应用API，以提供重用功效。这些服务能够采取分布式计算技术来实现，如 J2EE EJB、COM/DCOM和CORBA。
1.2.1.3. 业务服务
业务服务是功效性，表现在业务应用中，负责实施一个或多个业务操作。业务服务通常由跨多个应用多个业务事务组成。其可能是端到端业务步骤，比如：处理新招聘；或可能作为更大型业务步骤一部分，如以下示例所表示：
Ø 业扩
Ø 增加新职员
业扩需要作为更大型业务步骤——如“业扩业务受理”一部分，它需要该步骤中信息来完成业务功效。
1.2.1.4. 组合服务
组合服务是经过将全新逻辑和现有应用（如业务或组件服务）中事务进行有机组合而创建。服务总线和业务步骤管理工具在组合应用创建过程中饰演了关键角色。
特定功效门户（如营销门户和职员门户）是经典组合应用，其中需要业务、组件和数据服务。
1.2.1.5. 企业基础架构服务
服务注册和目录服务
服务注册和服务目录是SOA平台系统最为基础服务。
服务注册消除服务之间访问位置关系，使服务调用更为透明。服务注册提供下面关键功效：
Ø 关键服务，包含复制、UDDI数据存放和安全
Ø 信息服务，包含数据验证、SOA映射、高级分类和业务信息访问服务
Ø 生命周期服务，包含同意和更改管理、更改通知、业务服务发觉和QoS管理
服务目录库是在服务生命周期（从项目早期到完成）中管理元数据关键组件。其关键目标是存放具体元数据方便在布署前管理和治理资产。服务目录库关键功效包含：
Ø 服务元数据存放和管理，包含公布和发觉元数据，服务依靠管理管理，服务资产版本控制等。
Ø 服务资产使用分析，包含利用率分析，合规分析等，用于在进行更改前估计性地测量更改影响。
Ø 提供服务公布同意工作流。
安全服务
安全服务是附加在整个SOA平台上信息安全控制，其目标在于提供安全可靠处理方案，从而为系统安全建立基础，提供基础安全服务，这些服务包含认证、授权、完整性、机密性、可审计性等，确保系统在一定接入水平上机密性、完整性和可用性。安全服务含有以下多个关键功效：
Ø 身份和策略数据库：用来存放身份和身份属性数据、审核数据、配置信息、策略等。用户包含企业职员、用户和合作伙伴等。通常目录服务能够提供统一用户身份存放、策略和日志信息，作为集中用户布署信息库，是认证和访问控制服务基础。
Ø 用户身份管理：能够提供身份生存周期管理服务，确保用户身份生命周期各个方面全部得到安全、有效管理，比如密码管理、工作流和同时逻辑。并提供一组用户和管理员附加组件，用于简化身份管理架构交互和管理。
Ø 访问控制：依据既定身份和策略数据库实现基于角色和策略认证和授权。
Ø 支持性安全技术：能够支持多个认证方法，如PKI技术、认证技术（智能卡、令牌、生物认证）、加密技术等。
Ø 支持系统间单点登录。
Ø 集中监控用户访问尝试，提供集中审计日志服务。

2. 服务定义规范
2.1. 服务定义描述
服务是一个软件组件，含有明确功效，通常封装着业务或数据。服务由接口、合约和实现组成。

从另外一个角度，我们也能够用下图描述服务定义：

2.1.1. 服务合约和描述
依据SOA要求，服务消费者功过服务接口调用服务，无需了解服务实现细节。服务合约描述为服务消费者提供了该服务相关服务信息，这些信息使得服务消费者能够决定是否调用该服务。通常，服务合约描述以下关键信息（但并不限定在此范围）：
服务存在：服务名称，服务版本，服务拥有者；
服务类型：包含表示服务、步骤服务、业务服务、数据服务等。
服务业务功效定义：即描述该服务完成业务功效。
服务调用约束条件和策略：包含安全，服务质量（QoS），事务，服务等级协议（SLA），怎样和服务交互，比如交互协议，输入和输出单元及格式；
交互协议包含SOAP、非SOAP消息、FTP、SMTP/POP和部分遗留协议等。
2.1.2. 服务接口
服务接口就是一组提供服务消费者调用交互端口，服务接口将服务功效向服务消费者（用户经过网络连接到这个服务）公开。接口描述是服务合约一部分，包含操作协议，接口名，交换信息等，一样需要一组标准名称进行描述，通常采取XML描述。但接口物理实现是服务实现一部分。
2.2. 服务定义输出模板
1物资采购单汇总服务定义：
服务编码
标识服务唯一编码，如：00000001
服务汉字名称
物资采购单汇总
服务英文名称
PurchaseService
方法名称
AggregateOrder
共享范围
部门级
服务目录引用路径
/WebServices/WuziDomain/PurchaseService
服务版本
v0.1
服务公布日期
服务正式服务日期
服务提供者编码
定义该服务单位编码，根据《南方电网企业人事信息分类编码》要求
服务宿主系统编码
提供该服务应用系统
服务性质编码
描述服务特征：
01---关键任务服务
02---机密任务服务
03---高容量服务
04---高水平服务
05---标准服务
服务拥有者
物资企业招标部
服务类型
业务服务
服务业务功效描述
省物资企业招标部门对物资需求进行汇总处理，然后经过省物资企业MAXIMO系统生成采购申请审批。
交互属性
是否需要人工交互
确定部门
确定服务功效规格单位、部门或个人。
服务开发单位
实现服务开发商单位
服务调用约束条件和策略
安全
HTTPS协议。数据加密和摘要，认证方法(WS-Security: Username Token Profile)
服务质量（QoS）
持久化
服务等级协议SLA
对应时间20ms，重试10次
并发性要求
并发量9
能够使用时间
能够使用该服务时间段
消息大小估量
输入10KB，输出消息10KB

2 地市企业采购单上报服务定义：
服务编码
标识服务唯一编码，如：00000001
服务汉字名称
地市企业采购单上报
服务英文名称
DeclareService
方法名称
DeclareMaterial
共享范围
部门级
服务目录引用路径
/WebServices/WuziDomain/DeclareService
服务版本
v0.1
服务公布日期
服务正式服务日期
服务宿主系统编码
提供该服务应用系统
服务性质编码
描述服务特征：
01---关键任务服务
02---机密任务服务
03---高容量服务
04---高水平服务
05---标准服务
服务拥有者
地市物资部门计划员
服务类型
业务服务
服务业务功效描述
地市局计划员依据需求计划明细生成采购申请单，经过地市部门MAXIMO系统生成物资采购上报，提供给省物资企业物资管理系统调用，进行汇总处理
交互属性
是否需要人工交互
确定部门
确定服务功效规格单位、部门或个人。
服务开发单位
实现服务开发商单位
服务调用约束条件和策略
安全
HTTPS协议。数据加密和摘要，认证方法(WS-Security: Username Token Profile)
服务质量（QoS）
持久化
服务等级协议SLA
优先等级-高，对应时间20ms，重试10次
并发性要求
并发量9
能够使用时间
能够使用该服务时间段
消息大小估量
输入10KB，输出消息10KB

3. 服务设计规范
3.1. 服务设计描述
服务设计负责为服务制订接口，以使服务能够最大化重用。服务接口就是一组提供服务消费者调用交互端口，服务接口将服务功效向服务消费者（用户经过网络连接到这个服务）公开。接口描述是服务合约一部分，包含操作协议，接口名，交换信息等，一样需要一组标准名称进行描述，通常采取XML描述，接口定义了使用者和提供者之间可编程访问约定。

3.2. 服务设计输出模板
1 物资采购单汇总服务设计
基础信息
服务编码
Gzwz001
服务名称
PurchaseService
依靠服务
本服务需要调用其它服务编号列表
服务布署IP地址
提供服务功效网络IP地址
服务接口定义文件
描述服务接口定义文件路径
服务接口
接口名称
AggregateOrder
接口说明
物资计划汇总处理
传输协议
HTTP

接口操作
接口操作名称
AggregateOrder
接口操作描述
物资汇总后提交到省企业领导处理操作
调用方法
同时调用

输入消息格式
(附件)
输出消息格式
(附件)
错误处理
错误代码
错误描述
访问被拒绝
对消息安全进行处理，提供验证WEB服务访问角色，拒绝无效用户名和密码，进行JMS消息提醒
500
服务器不支持集成安全SSPI，服务名称错误，内部服务器发生异常，BAM监控
SoapException
传输数据XML序列化错误，服务端异常或用户端调用错误，SOAP错误结构，统计log日志
访问控制
基于角色，含有访问权限角色有：
物资分企业职能领导，省企业职能领导
事务方法
Don’t support
事务类型
Local

2 供电企业采购单上报服务设计
基础信息
服务编码
Gzwz002
服务名称
DeclareService
依靠服务
本服务需要调用其它服务编号列表
服务布署IP地址
提供服务功效网络IP地址
服务接口定义文件
描述服务接口定义文件路径
服务接口
接口名称
DeclareMaterial
接口说明
供电企业上报物资计划处理
传输协议
HTTP

接口操作
接口操作名称
DeclareMaterial
接口操作描述
上报计划到物资招标部进行汇总处理
调用方法
异步调用

输入消息格式
(附件)
输出消息格式
(附件)
错误处理
错误代码
错误描述
500
服务器不支持集成安全SSPI，服务名称错误，内部服务器发生异常，BAM监控
SoapException
传输数据XML序列化错误，服务端异常或用户端调用错误，SOAP错误结构，统计log日志
访问拒绝
对消息安全进行处理，提供验证WEB服务访问角色，拒绝无效用户名和密码，进行JMS消息提醒
访问控制
基于角色，含有访问权限角色有：
物资企业招标部门，物资企业计划员
事务方法
Support
事务类型
JTA

4. 服务实现规范
4.1. 服务实现描述
服务实现包含了服务功效或业务逻辑。对于服务使用者来说，服务实现应该是一个“黑匣子”；用户没必需知道服务功效实现细节。
服务实现在物理上提供所需业务逻辑和合适数据。在技术上实现服务合约。服务实现由一个或多个工件组成：如业务程序或数据访问等。服务实现并没有强制要求和特定提议。
提议使用JWS基于注释Web Services编程方法以简化开发。这种开发方法利用JDK5元数据注释(JSR-175)，在编写上述Java Bean或EJBBean类时在业务逻辑代码中添加部分特殊注释，然后用ANT部分扩展任务能够生成部分相关JAVA类代码和配置文件，最终自动编译这些类代码并自动打包。
下图描述了JWS文件生成可布署J2EE模块具体过程。

4.1. 服务实现输出模板
1 物资采购单汇总服务实现
服务名称
实现类型
Java/EJB:
步骤服务
实现平台
Oracle Service Bus 10gR3, J2SE 1.6,
BPM Studio 10.3,IBM Maximo 6.2.1
实现提议
跨业务系统之间调用经过服务总线ESB实现交互，MAXIMO公布提供WEB服务，BPM进行步骤自动处理
组件设计
(见附件)BPMN
类设计
(见附件)状态图
数据设计
附件

2 供电企业采购单上报服务实现
服务名称
实现类型
Java/EJB:
步骤服务
实现平台
Oracle Service Bus 10gR3, J2SE 1.6,
BPM Studio 10.3,IBM Maximo 6.2.1
实现提议
跨业务系统之间调用经过服务总线ESB实现交互，MAXIMO公布提供WEB服务，BPM进行步骤自动处理
组件设计
(见附件)BPMN
类设计
(见附件)状态图
数据设计
附件

5. 步骤设计规范
应包含步骤说明，步骤图和节点描述。以下以物质采购协议签署步骤为范例进行说明。
5.1. 步骤说明
物资管理系统物资采购模块依据招投标结果制订并审核完采购清单后，调用协议管理系统提供“协议签署服务”进行采购协议签署，输入协议基础信息（甲方、乙方、协议金额等，采购单能够作为文本附件）；采购协议在协议管理系统中流转审批完成后，返回正式协议编号，然后同时调用物资管理系统提供“采购信息更新服务”更新采购信息（输入协议编号，采购单号，状态）和财务管理系统提供“冻结预算可用值服务”更新预算可用值（输入项目编号，预算实施值）。
5.2. 步骤图

5.3. 节点描述
序号
节点名称
节点说明
调用服务
备注
1
采购协议签署
调用协议系统协议签署服务完成采购协议签署和流转审批，并返回正式协议编号及关联信息
4-1协议签署服务

2
采购信息更新
采购协议签署完成后，依据采购单号更新物资系统中采购信息
3-12采购信息更新服务

3
冻结预算
采购协议签署后依据协议金额冻结财务系统中项目预算可用值。
5-8冻结预算可用值服务

6. 元数据设计规范
所谓企业元数据，指是服务定义内容描述和业务对象描述。前者请参见4.1，4.2。怎样对这些元数据进行有效管理和使用对于企业信息资产积累和管理至关关键。
6.1. 元数据形态定义
Ø 数据模型XML Schema描述元数据
关键是指将数据建模生成基于XML Schema语言描述xml文件。这类文件经过数据服务平台导入功效存放在数据服务平台之上。
Ø 数据服务描述元数据
这类元数据关键是指对于统一逻辑数据视图定义、物理数据源定义、物理数据源和数据模型映射关系、数据服务缓存定义、数据服务安全定义等描述信息。数据服务平台对这类元数据提供搜索、运行时设置、查看等管理功效，以实现对数据服务平台监控、运行时管理和业务规则调整功效。
6.2. 业务元数据定义模板
我们在此给出业务数据元数据定义模板范例，作为设计和实施参考文档。
6.2.1. 业务元数据清单
元数据编号
元数据名称
备注
MD01
项目（包）基础信息

MD02
项目开工信息

MD03
年度资金计划

MD04
月度资金计划

MD05
设备清单

MD06
物资采购信息

MD07
设备重大缺点信息

MD08
项目费用结算信息

MD09
费用结算审计申请单

MD10
施工结算审计结果信息

MD11
物资采购清单

MD12
物资招投标结果信息

MD13
工程协议关联信息

……………….
……………….
……………….
6.2.2. 元数据定义模板
MD01 项目（包）基础信息
序号
数据项名称
数据项描述
数据类型
备注
1
项目名称
输变电工程名称
字符串

2
项目代码
输变电工程编码
字符串

3
项目属性
输变电工程属性
字符串

4
电压等级代码
220KV,500KV还是110KV,35KV,20KV,10KV等级
字符串

5
项目包
输变电工程对应项目包
字符串

6
建设规模
输变电工程建设规模
双精度类型

7
计划开工时间
输变电工程计划开工时间
日期类型

8
变电站座数
输变电工程下变电子工程总数
整数类型

9
变电器容量
输变电工程变电容量
双精度类型

10
总长度
输变电工程线路长度
双精度类型

11
计划投产时间
输变电工程投产时间
日期类型

12
计划投产规模
输变电工程投产规模
字符串

13
建设单位

14
建设性质

15
总投资

16
是否项目包

17
批次号

18
建设阶段

19
机组台数

20
线路条数

21
电缆长度

7. 服务测试规范
SOA测试同传统测试有很大不一样。SOA测试生命周期和测试相关内容包含图部分。

测试内容包含：
1. 服务灵敏性测试
Ø 配置测试
Ø 业务规则测试
Ø 策略测试
2. 步骤一级测试
Ø 赔偿交易测试
Ø 服务失效性测试
3. 步骤 二级测试
Ø 工作步骤测试
Ø 事件响应测试
4. 安全测试
Ø 拒绝服务测试(DOS)
Ø 安全漏洞测试
Ø 安全上下文推送测试/联邦安全测试
5. 服务设计测试
Ø 服务交互操作测试
Ø 服务复合集成测试
Ø 重用性测试
Ø 数据类服务测试

SOA测试生命周期以下图：

7.1. 测试计划
首先,依据用户需求汇报中相关功效要求和性能指标规格说明书,定义对应测试需求汇报,即制订黑盒测试最高标准。以后全部测试工作全部将围绕着测试需求来进行,符合测试需求应用程序即是合格,反之即是不合格;同时,还要合适选择测试内容,合理安排测试人员、测试时间及测试资源等。
测试计划编写应包含以下内容：
Ø 目标
Ø 测试范围
测试内容从商业需求或技术需求中归纳提取。
××××系统——测试范围
第 1 页
共 1 页
序号
测试分类
测试内容
1
T-E
效率测试
2
T-F
功效测试

测试内容
测试需求
测试功效点
响应时间
基准业务测试
（只100用户并发）
登录系统
...................
...................
...................
...................

Ø 测试环境配置
软件测试环境、硬件测试环境、网络测试环境、数据准备等
Ø 人员安排
Ø 时间安排
Ø 测试方法
7.2. 测试入口标准
下列全部标准全部满足时，测试才能开始实施
标准
责任
测试纲领、测试方案、测试计划、测试用例已经过评审
评测机构评审小组
测试组人员配置合理，测试人员工作技能合乎要求
评测机构
测试培训完成
评测机构、相关业务部门
测试所需软、硬件和操作系统等测试环境己经准备就绪
评测机构技术支持部门
缺点跟踪和管理系统已建立
评测机构测试部门
测试所需资源（含待测软件）已经到位
评测机构、相关业务部门
7.3. 测试终止标准
在测试过程中，发觉满足下列条件之一时，测试活动终止
标准/准则
1. 根据软件操作手册、用户手册说明进行操作却无法安装、运行，经申请人指派技术人员帮助仍无法安装、运行
2. 测试过程中，软件运行出现错误（Bug），经三方（开发方，用户方，测试方）确定，测试无法继续进行
7.4. 测试出口标准
下列全部条件满足时，测试完成。
标准/准则
1．测试原始统计已经生成并已被验证
2．测试计划已经实施完成
3．测试实施具体汇报已经完成

7.5. 测试设计
将测试计划阶段制订测试需求分解、细化为若干个可实施测试过程,并为每个测试过程选择合适测试用例(测试用例选择好坏将直接影响测试结果有效性)。
7.6. 测试开发
建立可反复使用自动测试过程。
7.7. 测试实施
实施测试开发阶段建立自动测试过程,并对所发觉缺点进行跟踪管理,测试实施通常由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成,测试人员应本着科学负责态度,一步一个脚印地进行测试。在此定义测试实施活动，在这些活动中将使用测试用例或测试脚本。
Ø 依据测试计划中相关测试环境内容，检验测试环境（包含硬件及软件），确保测试环境符合要求；
Ø 对于测试用例描述信息,按测试意图对每一个测试用例设计操作步骤中关键步骤动作、输入数据和预期反应；
Ø 实施测试活动，并统计测试原始数据，包含所使用机器及实施日期，对于每个测试用例还应统计关键操作步骤、输入数据和任何和测试人员预期结果不符系统响应；
每个测试用例实施完成后，视具体情况对系统进行备份或依据备份数据对系统进行恢复。
7.7.1. 单元测试
对应于粗粒度服务测试，包含数据服务类型，业务服务类型和复合类型。对于SOA测试来说，单元测试是个迭代过程。粗粒度服务包含了细粒度服务。提议单元测试放在组件等级上。对于不一样类型服务测试关键不一样，要切合服务要求SLA来测试。
提议数据服务类测试选择粒度较小服务，关键关注效率测试和压力测试。复合组件类型要注意路由路径条件满足。
注意实施以下方面测试。
Ø 负载测试 : Load Testing 是指模拟真实用户行为，经过不停加压直到性能出现瓶颈或资源达成饱和。负载测试是我们最常常进行性能测试，用于测量系统容量，发觉系统瓶颈并配合性能调优。有时候也称为可量性测试 Scalability Testing.
Ø 压力测试 : Stress Testing 是指测试系统在一定饱和状态下系统处理能力。负载测试不停加压到一定阶段即是压力测试，二者没有明确界限。压力测试通常设定到CPU使用率达成75%以上，内存使用率达成 70%以上，用于测试系统在压力环境下稳定性。此处是指过载情况下稳定性，略微不一样于7*24长时间运行稳定性。
Ø 失效恢复测试 : Failover Testing 针对有冗余备份和负载均衡系统，检验系统局部故障时用户所受到影响

7.7.2. 集成测试
对应于步骤类测试，包含部门级和企业级。步骤类服务分为两种，自动步骤类要关注SLA，并发压力；人工参与步骤，关注测试分支满足和安全性测试。
关注以下测试方面：
Ø 可靠性测试 : Reliability Testing 是指加载一定业务压力，同时让此压力连续运行一段时间，测试系统是否能够稳定运行. 能够了解为压力测试关注是过载压力，可靠性测试关注是连续时间。
Ø 并发测试 : Concurrency Testing 是模拟用户并发访问同一应用测试，用于发觉并发问题诸如内存泄漏，线程锁，资源争用，数据库死锁。
Ø 配置测试 : Configuration Testing 验证多种配置对系统性能影响，用于性能调优和计划能力.

7.8. 测试评定
结合量化测试覆盖域及缺点跟踪汇报,对于应用软件质量和开发团体工作进度及工作效率进行综合评价。