SOA技术规范

服务特征与粒度 服务特征

务分析规范

候选服务的特征是：

提供一定的功能性，有构成服务的前提条件 可能转变到服务 有待经过评审流程的确认

通过评审的候选服务，成为服务： 有明确的范围和业务价值 可能被实现，也可能需要构建 具备契约、接口及实现

服务是网络中可用的软件资源。服务提供者通过标准机制提供服务，服务使用者通过网络有计划性地使用服务。服务代理发布服务所在位置，并在使用者请求服务时定位服务。服务使用者和提供者的角色不是唯一的；服务提供者也可以是使用者，反之亦然。

下图显示了 SOA 中的三个基本角色（服务提供者、使用者和代理）及其各自的分工和操作。

图：SOA 的角色和交互

提供者在服务约定中以标准语言描述其服务，并向代理发布服务。客户从服务代理处（或登记处）查询所需的服务，并接收有关服务访问的约定和信息。随后，客户或使用者便可绑定到服务，并可与提供者直接通信。

服务包括两部分：接口和实现

图：服务部件

接口定义了使用者和提供者之间可编程的访问约定。服务接口必须包含以下内容：

服务的识别

服务输入和输出数据的详细情况 服务功能和目的的元数据

服务实现包含了服务的功能或业务逻辑。对于服务使用者来说，服务实现应该是一个“黑匣子”；用户没必要知道服务的功能实现细节。

服务粒度判定原则和方法

服务的粒度可以按基于服务的功能及发送和接收的数据数量来定义服务，如细粒度服务、粗粒度服务或组合服务。

在 SOA 中服务粒度有两种相关的意思：服务是如何实现的，服务使用和返回了多少数据或多少消息。细粒度服务执行了最小的功能，发送和接收少量的数据。粗粒度服务执行了较大的业务功能，并交换了更多的数据。

细粒度服务是供粗粒度服务或组合服务使用的，而不是由终端应用直接使用的。如果应用是使用细粒度服务建立的，则应用将不得不调用网络上多个服务，并且发生在每个服务上的数据量较少，因而会对对系统整体性带来影响。所以细粒度服务的用户不能直接调用他所使用的细粒度服务。然而，由于粗粒度服务可能使用多个细粒度服务，因此它们不能提供粒度级的安全和访问控制。

组合服务可以使用粗粒度服务和细粒度服务进行组装。数据数量数量不是粗粒度服务和组合服务之间的区别。

粗粒度服务例子，如创建新客户，在这一过程的操作是：需要通过一些外部服务验证对客户进行验证，并在 营销应用系统中创建客户记录。

组合服务例子可以是提供一个新的DSL线，这需要一个服务调用来验证定单、创建或验证客户，确认产品库存及为数据线分配资源。

下图描述了服务粒度的不同级别及其相互关系。

图：服务粒度

作为复用的服务，应注册到服务总线上进行管理和调用，在未来引入服务注册管理软件后进行统一的命名空间管理，路径管理，Qos，SLA等元数据管理。在注册到服务总线时，要根据域模型来定义管理路径。

服务识别方法

服务的识别是从业务模型开始的。根据实施SOA的不同初始点，分为自顶向下和自底向上及基于流程的方式。

通常来说，新建以SOA为建设方的系统，我们推荐使用自顶向下的方式，统一的定义划分业务域，根据业务域的业务实体模型来定义在其上的服务，进行服务分类，分离出数据服务，业务服务，复合服务，公用服务，定义好其颗粒度。基于SOA来改造现有系统，要对现有系统进行服务化，根据颗粒度的定义原则提炼出服务。然后基于企业级和部门级的流程来服用服务。

自顶向下的服务分析，主要是从全局业务流程的角度出发，按照业务流程的详细程度发现流程中需要调用那些业务系统提供的服务，并且需要提供哪些流程服务注册到业务服务总线上被业务系统调用。

自底向上的服务分析，则需要各业务系统开发上在自己业务系统内部的角度把可重用的组件服务话，把需要被全局业务流程调用的服务发布出来，注册在业务服务总线上统一管理。

物资系统采用自顶向下为主的服务建设策略，从Maxim导出的服务以自底向上的方式推到服务模型。

服务分类和抽象

服务可以分为以下五种类型：

数据访问允许对不同数据源进行统一访问。 组件—提供对打包应用服务的访问，如?ERP。

业务—提供使用一个以上打包应用或定制应用功能的复杂服务。 组合—使用以上三种类型的服务来创建包括新功能和现有功能的新服务。

共享的或企业基础架构服务?—?消息日志之类的低级服务，其重用性使快速创建新的高级服务成为可能。

1.1.1.1. 信息访问服务

信息访问服务允许用户对来自于企业内各种有关或无关数据源的数据进行访问、集成和处理。这些服务通常隐藏了对数据源的直接访问、底层格式的复杂性以及数据的直接转换和处理。信息访问服务提供了跨应用的统一API、松散耦合、公共数据模型和一致性信息的重用。

信息访问服务是SOA架构中最为普通、使用最为广泛和最易于实现的服务；将数据层和应用层进行分离通常是非常简单的。由于数据源被广泛地访问和共享，因此它们成为了服务实现的第一目标。

XML 被广泛地应用于应用数据交换。在 SOA 实施中，一个能够提供与数据源无关的、抽象化统一数据访问的基础架构是非常有价值的。XML 数据服务 (XDS)

提供了对多种类型数据源的访问和数据建模能力，并能够将物理数据翻译和转换为逻辑数据，还支持对逻辑数据的基于 XML的访问。

1.1.1.2. 组件服务

组件服务是由单个企业资源（无论其是否为ERP、CRM或SCM之类的打包应用）发布的粗粒度服务。“在ERP 中添加客户”就可以作为组件服务的一个范例。这些服务非常有价值，可以直接发布。

组件服务的实现采用了单独的应用API，以提供重用功能。这些服务可以采用分布式计算技术来实现，如 J2EE EJB、COM/DCOM和CORBA。

1.1.1.3. 业务服务

业务服务是功能性的，体现在业务应用中，负责执行一个或多个业务操作。业务服务通常由跨多个应用的多个业务事务组成。其可能是端到端的业务流程，例如：处理新招聘；或者可能作为更大型业务流程的一部分，如以下示例所示：

业扩 增加新员工

业扩需要作为更大型业务流程——如“业扩业务受理”的一部分，它需要该流程中的信息来完成业务功能。

1.1.1.4. 组合服务

组合服务是通过将全新逻辑与现有应用（如业务或组件服务）中的事务进行有机组合而创建的。服务总线和业务流程管理工具在组合应用的创建过程中扮演了关键的角色。

特定功能门户（如营销门户和员工门户）是典型的组合应用，其中需要业务、组件和数据服务。

1.1.1.5. 企业基础架构服务

服务注册和目录服务

服务注册和服务目录是SOA平台系统最为基础的服务。

服务注册消除服务之间访问的位置关系，使服务调用更为透明。服务注册提供下面的主要功能：

核心服务，包括复制、UDDI数据存储和安全

信息服务，包括数据验证、SOA映射、高级分类以及业务信息访问服务 生命周期服务，包括批准和更改管理、更改通知、业务服务发现和QoS管理

服务目录库是在服务生命周期（从项目初期到完成）中管理元数据的关键组件。其主要目的是存储详细元数据以便在部署前管理和治理资产。服务目录库的主要功能包括：

服务元数据存储和管理，包括发布和发现元数据，服务依赖管理管理，服务资产版本控制等。

服务资产使用分析，包括利用率分析，合规分析等，用于在进行更改前预测性地测量更改的影响。 提供服务发布批准工作流。 安全服务

安全服务是附加在整个SOA平台上的信息安全控制，其目的在于提供安全可靠的解决方案，从而为系统的安全建立基础，提供基本的安全服务，这些服务包括认证、授权、完整性、机密性、可审计性等，确保系统在一定接入水平上的机密性、完整性和可用性。安全服务具备以下几个关键功能：

身份和策略数据库：用来存储身份和身份属性数据、审核数据、配置信息、策略等。用户包括企业员工、客户和合作伙伴等。通常目录服务可以提供统一的用户身份存储、策略和日志信息，作为集中的用户部署信息库，是认证和访问控制服务的基础。

用户身份管理：可以提供身份生存周期管理服务，确保用户身份生命周期的各个方面都得到安全、有效的管理，例如密码管理、工作流和同

步逻辑。并提供一组客户和管理员附加组件，用于简化身份管理架构的交互和管理。

访问控制：根据既定的身份和策略数据库实现基于角色和策略的认证和授权。

支持性安全技术：能够支持多种的认证方式，如PKI技术、认证技术（智能卡、令牌、生物认证）、加密技术等。 支持系统间的单点登录。

集中监控用户的访问尝试，提供集中的审计日志服务。

服务定义规范 服务定义描述

服务是一个软件组件，具有明确的功能，通常封装着业务或者数据。服务由接口、合约和实现组成。

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

服务合约和描述

根据SOA的要求，服务消费者功过服务接口调用服务，无需了解服务实现的细节。服务的合约描述为服务消费者提供了该服务相关的服务信息，这些信息使得服务消费者可以决定是否调用该服务。通常，服务合约描述以下关键信息（但并不限定在此范围）：

服务存在：服务名称，服务版本，服务拥有者；

服务类型：包括表示服务、流程服务、业务服务、数据服务等。 服务业务功能定义：即描述该服务完成的业务功能。

服务调用的约束条件和策略：包括安全，服务质量（QoS），事务，服务级别协议（SLA），如何与服务交互，比如交互协议，输入和输出单元及格式；

交互协议包括SOAP、非SOAP的消息、FTP、SMTP/POP以及一些遗留协议等。

服务接口

服务接口就是一组提供服务消费者调用的交互端口，服务接口将服务的功能向服务消费者（客户通过网络连接到这个服务）公开。接口描述是服务合约的一部分，包括操作协议，接口名，交换信息等，同样需要一组标准的名称进行描述，通常采用XML描述。但接口的物理实现是服务实现的一部分。

1.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系统生成物资采购上报，提供给省物资公司的物资管理系统调用，进行汇总处理 交互属性 确认部门 服务开发单位 服务调用的约束条件和策略 服务质量（QoS） 服务级别协议SLA 并发性要求 可以使用的时间 消息大小估量 服务设计规范 服务设计描述

是否需要人工交互 确认服务功能规格的单位、部门或个人。 实现服务的开发商单位 HTTPS协议。数据加密和摘要，认证方式(WS-Security: Username Token Profile) 持久化 安全 优先级别-高，相应时间20ms，重试10次 并发量9 可以使用该服务的时间段 输入10KB，输出消息10KB 服务设计负责为服务制定接口，以使服务能够最大化的重用。服务接口就是一组提供服务消费者调用的交互端口，服务接口将服务的功能向服务消费者（客户通过网络连接到这个服务）公开。接口描述是服务合约的一部分，包括操作协议，接口名，交换信息等，同样需要一组标准的名称进行描述，通常采用XML描述，接口定义了使用者和提供者之间可编程的访问约定。

服务设计输出模板

1 物资采购单汇总的服务设计

基本信息 服务编码 服务名称 依赖的服务 服务部署IP地址 服务接口定义文件 服务接口 接口名称 Gzwz001 PurchaseService 本服务需要调用的其他服务的编号列表 提供服务功能的网络IP地址 描述服务接口定义的文件路径 AggregateOrder 接口说明 传输协议 接口操作 接口操作名称 接口操作描述 调用方式 输入消息格式 输出消息格式 错误处理 物资计划汇总处理 HTTP AggregateOrder 物资汇总后提交到省公司领导处理操作 同步调用 (附件) (附件) 错误代码 访问被拒绝 错误描述 对消息安全进行处理，提供验证WEB服务的访问角色，拒绝无效的用户名和密码，进行JMS消息提示 服务器不支持集成安全SSPI，服务名称错误，内部服务器发生异常，BAM监控 500 SoapException 传递的数据XML序列化错误，服务端异常或客户端调用错误，SOAP错误结构，记录log日志 访问控制 事务方式 事务类型 基于角色，具有访问权限的角色有： 物资分公司职能领导，省公司职能领导 Don’t support Local 2 供电公司采购单上报的服务设计

基本信息 服务编码 服务名称 依赖的服务 服务部署IP地址 服务接口定义文件 服务接口 接口名称 接口说明 传输协议 接口操作 接口操作名称 接口操作描述 Gzwz002 DeclareService 本服务需要调用的其他服务的编号列表 提供服务功能的网络IP地址 描述服务接口定义的文件路径 DeclareMaterial 供电公司上报物资计划处理 HTTP DeclareMaterial 上报计划到物资招标部进行汇总处理 调用方式 输入消息格式 输出消息格式 错误处理 异步调用 (附件) (附件) 错误代码 500 错误描述 服务器不支持集成安全SSPI，服务名称错误，内部服务器发生异常，BAM监控 SoapException 传递的数据XML序列化错误，服务端异常或客户端调用错误，SOAP错误结构，记录log日志 访问拒绝 对消息安全进行处理，提供验证WEB服务的访问角色，拒绝无效的用户名和密码，进行JMS消息提示 访问控制 事务方式 事务类型 服务实现规范 服务实现描述

基于角色，具有访问权限的角色有： 物资公司招标部门，物资公司计划员 Support JTA 服务实现包含了服务的功能或业务逻辑。对于服务使用者来说，服务实现应该是一个“黑匣子”；用户没必要知道服务的功能实现细节。

服务实现在物理上提供所需的业务逻辑和适当数据。在技术上实现服务合约。服务实现由一个或多个工件组成：如业务程序或者数据访问等。服务实现并没有强制规定和特定建议。

建议使用JWS基于注释的Web Services编程方式以简化开发。这种开发方式利用JDK5元数据注释(JSR-175)，在编写上述的Java Bean或EJB的Bean类时在业务逻辑代码中添加一些特殊注释，然后用ANT的一些扩展任务可以生成一些相关JAVA类代码和配置文件，最后自动编译这些类代码并自动打包。

下图描述了JWS文件生成可部署的J2EE模块的详细过程。

1.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 (见附件)状态图 附件 组件设计 类设计 数据设计 流程设计规范

应包含流程说明，流程图和节点描述。以下以物质采购合同签订流程为范例进行说明。

流程说明

物资管理系统的物资采购模块根据招投标结果制定并审核完采购清单后，调用合同管理系统提供的“合同签订服务”进行采购合同签订，输入合同基本信息（甲方、乙方、合同金额等，采购单可以作为文本附件）；采购合同在合同管理系统中流转审批完成后，返回正式的合同编号，然后同时调用物资管理系统提供的“采购信息更新服务”更新采购信息（输入合同编号，采购单号，状态）和财务管理系统提供的“冻结预算可用值服务”更新预算可用值（输入项目编号，预算执行值）。

流程图 节点描述

序号 节点名称 1 采购合同签订 2 采购信息更新 冻结预算 3 节点说明 调用合同系统的合同签订服务完成采购合同的签订和流转审批，并返回正式的合同编号及关联信息 采购合同签订完成后，根据采购单号更新物资系统中采购信息 采购合同签订后根据合同金额冻结财务系统中的项目预算可用值。 调用服务 4-1合同签订服务 备注 3-12采购信 息更新服务 5-8冻结预算可用值服务 元数据设计规范

所谓企业元数据，指的是服务的定义内容描述和业务对象描述。前者请参见4.1，4.2。如何对这些元数据进行有效的管理和使用对于企业信息资产的积累和管理至关重要。

元数据的形态定义

数据模型XML Schema描述元数据

主要是指将数据建模生成的基于XML Schema语言描述的xml文件。此类文件通过数据服务平台导入功能存放在数据服务平台之上。

数据服务描述元数据

此类元数据主要是指对于统一逻辑数据视图的定义、物理数据源定义、物理数据源与数据模型映射关系、数据服务缓存定义、数据服务安全定义等描述信息。数据服务平台对此类元数据提供搜索、运行时设置、查看等管理功能，以实现对数据服务平台的监控、运行时管理以及业务规则调整功能。

业务元数据定义模板

我们在此给出业务数据元数据定义的模板范例，作为设计和实施的参考文档。

业务元数据清单

元数据编号 MD01 元数据名称 项目（包）基本信息 备注 元数据编号 MD02 MD03 MD04 MD05 MD06 MD07 MD08 MD09 MD10 MD11 MD12 MD13 ………………. 元数据定义模板

元数据名称 项目开工信息 年度资金计划 月度资金计划 设备清单 物资采购信息 设备重大缺陷信息 项目费用结算信息 费用结算审计申请单 施工结算审计结果信息 物资采购清单 物资招投标结果信息 工程合同关联信息 ………………. 备注 ………………. MD01 项目（包）基本信息 序号 1 2 3 4 5 数据项名称 项目名称 项目代码 项目属性 电压等级代码 项目包 数据项描述 输变电工程的名称 输变电工程的编码 输变电工程的属性 220KV,500KV还是110KV,35KV,20KV,10KV的等级 输变电工程对应的项目包 数据类型 字符串 字符串 字符串 字符串 备注 字符串 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 建设规模 输变电工程的建设规模 计划开工时输变电工程计划的开工时间 间 变电站座数 输变电工程下变电子工程的总数 变电器容量 输变电工程的变电容量 总长度 计划投产时间 计划投产规模 建设单位 建设性质 总投资 是否项目包 批次号 建设阶段 机组台数 线路条数 电缆长度 输变电工程线路长度 输变电工程的投产时间 输变电工程的投产规模 双精度类型 日期类型 整数类型 双精度类型 双精度类型 日期类型 字符串 服务测试规范

SOA的测试同传统的测试有很大的不同。SOA测试的生命周期和测试相关内容包括如图部分。

测试内容包含： 1. 服务敏捷性测试 配置测试 业务规则测试 策略测试 2. 流程一级测试 补偿交易测试 服务失效性测试 3. 流程 二级测试 工作流程测试 事件响应测试

4. 安全测试

拒绝服务测试(DOS) 安全漏洞测试

安全上下文推送测试/联邦安全测试 5. 服务设计测试 服务交互操作测试 服务复合集成测试 重用性测试 数据类服务测试 SOA测试生命周期如下图：

测试计划

首先,根据用户需求报告中关于功能要求和性能指标的规格说明书,定义相应的测试需求报告,即制订黑盒测试的最高标准。以后所有的测试工作都将围绕着测试需求来进行,符合测试需求的应用程序即是合格的,反之即是不合格的;同时,还要适当选择测试内容,合理安排测试人员、测试时间及测试资源等。

测试计划编写应包含以下内容： 目的 测试范围

测试内容从商业需求或技术需求中归纳提取。 ××××系统——测试范围 序号 第 1 页 测试内容 效率测试 功能测试 共 1 测试分类 T-E T-F 测试内容 测试需求 测试功能点 登录系统 ................... 响应时间 基准业务测试 （只100用户并发） ................... ................... ................... 测试环境配置

软件测试环境、硬件测试环境、网络测试环境、数据准备等 人员安排 时间安排 测试方法

测试入口标准

下列所有标准都满足时，测试才能开始执行

标准 责任 测试大纲、测试方案、测试计划、测试用例已经过评测机构评审小组 评审 测试组人员配置合理，测试人员的工作技能合乎要求 测试培训完毕 评测机构、相关业务部门 评测机构 测试所需的软、硬件和操作系统等测试环境己经准评测机构的技术支持部门 备就绪 缺陷跟踪与管理系统已建立 测试所需的资源（含待测软件）已经到位 评测机构的测试部门 评测机构、相关业务部门 测试终止标准

在测试过程中，发现满足下列条件之一时，测试活动终止

标准/准则 1. 按照软件操作手册、用户手册说明进行操作却无法安装、运行，经申请人指派的技术人员协助仍无法安装、运行 2. 测试过程中，软件运行出现错误（Bug），经三方（开发方，用户方，测试方）确认，测试无法继续进行 测试出口标准

下列所有条件满足时，测试完成。

标准/准则 1．测试原始记录已经生成并已被验证 2．测试计划已经执行完毕 3．测试执行详细报告已经完成 测试设计

将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程,并为每个测试过程选择适当的测试用例(测试用例选择的好坏将直接影响测试结果的有效性)。

测试开发

建立可重复使用的自动测试过程。

测试执行

执行测试开发阶段建立的自动测试过程,并对所发现的缺陷进行跟踪管理,测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成,测试人员应本着科学负责的态度,一步一个脚印地进行测试。在此定义测试执行活动，在这些活动中将使用测试用例或测试脚本。

根据测试计划中有关测试环境的内容，检查测试环境（包括硬件及软件），确保测试环境符合要求；

对于测试用例的描述信息,按测试意图对每一个测试用例设计操作流程中重要环节的动作、输入数据和预期的反映；

执行测试活动，并记录测试原始数据，包括所使用的机器及执行日期，对于每个测试用例还应记录关键操作步骤、输入数据以及任何与测试人员预期结果不符的系统响应；

每个测试用例执行完毕后，视具体情况对系统进行备份或根据备份数据对系统进行恢复。

单元测试

对应于粗粒度服务测试，包含数据服务类型，业务服务类型和复合类型。对于SOA测试来说，单元测试是个迭代的过程。粗粒度的服务包含了细粒度的服务。建议单元测试放在组件级别上。对于不同类型服务测试重点不同，要切合服务要求的SLA来测试。

建议数据服务类测试选取粒度较小服务，主要关注效率测试和压力测试。复合组件类型要注意路由路径条件的满足。

注意执行以下方面测试。

负载测试 : Load Testing 是指模拟真实的用户行为，通过不断加压直到性能出现瓶颈或资源达到饱和。负载测试是我们最经常进行的性能测试，用于测量系统的容量，发现系统瓶颈并配合性能调优。有时候也称为可量性测试 Scalability Testing.

压力测试 : Stress Testing 是指测试系统在一定的饱和状态下系统的处理能力。负载测试的不断加压到一定阶段即是压力测试，两者没有明确的界限。压力测试通常设定到CPU使用率达到75%以上，内存使用率达到 70%以上，用于测试系统在压力环境下的稳定性。此处是指过载情况下的稳定性，略微不同于7*24长时间运行的稳定性。

失效恢复测试 : Failover Testing 针对有冗余备份和负载均衡的系统，检验系统局部故障时用户所受到的影响

集成测试

对应于流程类测试，包含部门级和企业级。流程类服务分为两种，自动流程类要关注SLA，并发压力；人工参与流程，关注测试分支的满足和安全性测试。

关注以下测试方面：

可靠性测试 : Reliability Testing 是指加载一定的业务压力，同时让此压力持续运行一段时间，测试系统是否可以稳定运行. 可以理解为压力测试关注的是过载压力，可靠性测试关注的是持续时间。 并发测试 : Concurrency Testing 是模拟用户并发访问同一应用的测试，用于发现并发问题诸如内存泄漏，线程锁，资源争用，数据库死锁。 配置测试 : Configuration Testing 验证各种配置对系统性能的影响，用于性能调优和规划能力.

测试评估

结合量化的测试覆盖域及缺陷跟踪报告,对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。