面向服务的船舶电子信息系统 软件测试要求

目   次 前言 II
1 范围 1
2 规范性引用文件 1
3 术语 1
4 一般要求 2
5 详细要求 5
 
前  言
本标准按照GB/T 1.1-2009《标准化工作导则 第1部分：标准的结构和编写》的规则起草。
本标准由中国船舶集团有限公司提出。
本标准由中国指挥与控制学会归口。
本标准起草单位：中国船舶重工集团公司第七一六研究所、中国船舶重工集团公司第七二二研究所、工业和信息化部电子第五研究所。
本标准主要起草人：孙志安、王丽、豆康康、张亚、王立荣、费琪、苏赛、朱昭俊、王强、尚京威王进宁。
面向服务的船舶电子信息系统软件测试要求
1　范围
本标准规定了面向服务的船舶电子信息系统软件测试的一般要求和详细要求。
本标准适用于测评机构进行面向服务的船舶电子信息系统软件测试。
2　规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
GB/T 11457         软件工程术语
3　术语
GB/T 11457的术语和定义适用于本标准。
下列术语和定义适用于本文件。
3.1　 
面向服务的体系架构  Service Oriented Architecture，SOA
是一种构建大型信息系统的结构模型。它将应用程序的不同功能单元通过服务之间定义好的接口和契约联系起来，通过业务流程编排进行服务组合，通过服务总线进行服务的管理和远程调用，进而实现特定的任务。
3.2　 
面向服务的船舶电子信息系统 Ship electronic inrormation system based on SOA
以面向服务的体系架构为基础构建的电子信息系统。
3.3　 
服务 Service
是一个平台独立、低耦合、自包含、基于可编程的应用程序，可使用开放的XML标准来描述、发布、发现、协调和配置这些应用程序，用于开发分布式的互操作的应用程序。
3.4　 
服务实体 Service entity
是一种最基本的服务，它通常由软件模块直接包装构成服务并对外发布。
3.5　 
组合服务  Composite services
是指由一个或多个服务通过一定的调用关系组合构成的服务。组合服务通过调用一个或多个服务构成一定的业务流程，然后自身再以一个服务的形式对外发布。把构成组合服务的服务称为子服务。
3.6　 
简单对象访问协议SOAP  Simple Object Access Protocol
是基于XML在分散或分布式环境中交换信息的简单协议。允许服务提供者和服务客户经过防火墙进行通讯交互，SOAP是一种在非集中或分布式环境中交换信息的轻型网络协议。
3.7　 
Web服务描述语言WSDL  Web service Description Language
定义了一套基于XML的语法，规定了用户调用服务所应了解的信息。
3.8　 
通用描述、发现与集成协议UDDI  Universal Description Discovery and Integration
是描述服务发布和发现的规范；
3.9　 
业务流程执行语言BPEL  Business Process Execution Language
是一种是用XML编写的编程语言，用于自动化业务流程的形式规约语言，BPEL是一种高级的、抽象的、可执行的建模语言，不但支持流程的结构化构造，同时也支持面向图形的流程。
4　一般要求
4.1　测试目的
开展面向服务的船舶电子信息系统软件测试的目的如下：
a） 验证面向服务的船舶电子信息系统软件服务实体和服务的注册发现机制、服务访问机制、服务路由等基础功能、性能、系统与其他系统的适配接入能力、兼容能力的设计与实现是否满足软件研制任务书或合同以及软件需求规格说明等规定的要求；
b） 验证面向服务的船舶电子信息系统软件组合服务构造过程中组合服务对子服务的评估是否满足软件研制任务书或合同以及软件需求规格说明等规定的要求；
c） 验证面向服务的船舶电子信息系统软件的设计与实现是否满足软件研制任务书或合同以及软件需求规格说明等规定的要求；
d） 验证软件中的缺陷和错误统计数是否在所规定的范围之内，对被测软件的质量做出评价；
e） 通过测试，发现或检出软件中的缺陷和错误，提高软件可靠性；
f） 为软件开发过程中的各种验证、确认以及是否可以接收或使用等决策提供依据；
g） 为软件鉴定、定型及技术状态确认和软件产品验收与交付提供依据。
4.2　进入条件
进入软件测试的基本条件如下：
a） 测试文档的要求应满足4.4的规定；
b） 测试前被测试软件通过自测试或技术状态检查，测试委托方应提供自测试报告或技术状态检查报告；
c） 规定的测试环境和测试工具；
d） 测试方和测试委托方应完成对测试准备情况的评审或确认，并就所有歧义达成共识；
e） 对需要特别明确的测试进入条件，应由测试方和测试委托方协商一致后提出。
4.3　测试通过准则
测试通过准则用以判定软件是否通过测试：
a) 完成了测评大纲规定的所有测试项目；
b) 被测软件与软件需求规格说明一致，符合软件设计；
c) 软件文档齐全，正确，软件与文档一致；
d) 针对测试中发现的问题在约定的时间期限内修改正确，未引入新的缺陷，并通过回归测试；
e) 对无法在约定时间期限内修改，且不影响软件主要功能、性能的问题，承研单位应给出处理意见；
f) 特别要求的测试通过准则由测评机构和测试委托方协商提出，纳入合同的相应条款中，并在测评大纲中做出明确的规定和描述。
4.4　测试文档
5.4.1 测试输入文档 对测试输入文档的要求如下：
a) 测试合同或协议：测试之前，由测评机构和测试委托方按合同法等的规定协商签订；
b) 软件研制总要求或系统（设备）研制总要求：测试之前由测试委托方按合同规定或测试需求提供；
c) 软件需求规格说明、软件设计说明、软件用户手册：由测试委托方按合同规定或测试需求提供；
d) 源代码：由测试委托方按合同规定或测试需求提供。
软件测试过程中各阶段的测试输入文档选择见表1。
表1 测试所需文档选择一览表

测试输入文档	所需文档
合同或协议	√
软件需求规格说明	√
软件设计说明	√
软件用户手册	√
源代码	√
注：√表示必备文档，▲表示根据实际情况所产生的文档。

  5.4.2 测试输出文档 对测试输出文档的要求如下：
a) 测评大纲：在测试需求分析和测试策划阶段由测评机构编制，测评大纲描述测试活动的范围、内容、方法、环境、进度、风险等。
b) 测试说明：在测试设计阶段根据需要由测评机构编制。测试说明描述测试活动所需的测试准备、测试用例及测试过程。
c) 测评报告：软件测试结束后，测评机构根据测试过程、测试结果等进行编制。测评报告除了应包括对测试结果的分析，还应包括对被测软件的评价和建议。若被测软件中包含替代软件（货架商品软件或已定型软件），且替代软件已列入测试范围，测评报告应包括替代软件清单及其满足研制要求情况的测试和评价结果。
d) 问题确认报告单：在软件测试过程中，当发现问题时，由软件测试人员填写问题确认报告单。
e) 问题报告单：确认后的问题由软件测试人员填写问题报告单，并作为测评报告的配套文件。
f) 测试记录（测试日志）：测评机构用于记录软件的测试过程、测试数据、测试结果、测试处理等；
软件测试过程中各阶段的测试输出文档选择见表2。
表2 测试输出文档选择一览表

测试输出文档	所需文档
测评大纲	√
测试说明	√
问题确认报告单	▲
问题报告单	▲
测评报告	√
测试记录	√
管理记录	√
注：√表示必备文档，▲表示根据实际情况所产生的文档。

  测评大纲、测试说明、测评报告、问题确认报告单、问题报告单等文档的内容和格式也可按测试委托方制定的格式或规定的要求编制。
4.5　测试偏离处理
软件测试过程中，当发生偏离时，应按如下要求进行处理：
a) 当测试过程中发生偏离规定和程序或出现分歧时，测试方应按照规定的程序进行及时的分析，并采取有效的措施，防止事故的蔓延和扩大。
b) 当测试过程中发生偏离规定和程序或出现分歧时，测试方技术负责人或测试组长应组织有关人员分析发生偏离规定和程序或测试分歧的原因和责任，制定整改措施，填写偏离规定和程序或测试分歧纠正措施报告。
c) 当偏离规定和程序或测试分歧纠正影响测试工作质量时，应按规定的程序及时地书面反馈给测试委托方。
d) 必要时，应对偏离规定和程序或测试分歧的纠正措施进行评审。
e) 由于测试设备、测量设备及配试设备出现偏离时，导致测试报告结果的正确性发生偏离时，应及时以书面形式通知委托方将原报告收回并进行作废处理，经修正后应重新通过评审后发送给委托方，在新的测试报告中应注明被替代的原有报告的编号。
5　详细要求
5.1　对不同安全等级软件的测试要求
根据每个软件的控制类别和系统风险指标确定每个软件的安全性等级。软件安全性等级从高到低为A、B、C、D四个等级。
不同等级软件的测试类型要求参见表3。
表3 不同安全等级软件的测试类型要求

测试类型	软件等级
	A	B	C	D
文档审查	√	√	√	√
静态分析	√	√	√	√
功能测试	√	√	√	√
性能测试	√	√	√	√
接口测试	√	√	√	√
余量测试	√	√	○	○
边界测试	√	√	○	○
人机交互界面测试	√	√	√	√
强度测试	√	○	×	×
安全性测试	√	○	×	×
恢复性测试	√	○	×	×
安装性测试	○	○	○	○

  注 1： √ 必须进行的测试， ○ 建议进行的测试， × 不要求进行的测试。
注 2：如果依据合同对本指导性技术文件要求必须进行的测试类型进行裁减，应给出说明。
注3：由于面向服务的船舶电子信息系统软件的安装部署不是由用户使用安装程序来实现，而是由服务的维护方进行服务发布来实现，因此安装性测试根据软件研制任务书或合同以及软件需求规格说明等规定进行裁剪。
5.2　进入条件
除4.2条之外，系统测试还应具备下列进入条件：
a） 软件系统的所有配置项已通过测试；
b） 对于需要固化运行的软件配置项应提供固件；
c） 被测试软件系统为本阶段最终版本，已纳入软件配置管理，取自受控库。
5.3　测试要求
测试要求为：
a） 应按系统/子系统设计说明的规定，逐项测试系统的功能、性能等特性；
b） 系统的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例所覆盖；
c） 测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值；
d） 应测试系统的输出及其格式；
e） 应测试配置项之间及配置项与硬件之间的所有接口；
f） 应在边界状态、异常状态或在人为设定的状态的运行条件下，测试系统的功能和性能；
g） 应测试系统的安全性和数据访问的安全保密性；
h） 应测试系统的全部存储量、输入/输出通道的吞吐能力和处理时间的余量；
i） 应按系统或子系统设计文档的要求，对系统的功能、性能进行强度测试；
j） 应测试人机交互界面提供的操作和显示界面，包括用非常规操作、误操作、快速操作测试界面的可靠性；
k） 应测试设计中用于提高系统安全性和可靠性的方案，如结构、算法、容错、冗余、中断处理等；
l） 对安全性关键的系统，应对其进行安全性分析，明确每一个危险状态和导致危险状态的可能原因，并对其进行针对性的测试；
m） 对有恢复或重置功能需求的系统，应测试其恢复或重置功能和平均恢复时间，并且对每一类导致恢复或重置的情况进行测试；
n） 对软件系统的安装性进行测试；
o） 对不同的实际问题应外加相应的专项测试；
p） 针对功能测试用例，需要避免复杂元素子元素之间组合数量爆炸现象，在满足测试充分性要求的前提下，约简测试用例提高测试效率；
q） 针对被测服务运行时需要调用第三方服务，而该服务不可用或者不可控的情况，需构建虚拟的第三方服务，使其行为与第三方服务一致并处于测试人员可控的状态。
5.4　测试内容
5.4.3 文档审查 文档审查一般需进行：
a） 检查设计代码完整性；
b） 检查设计功能说明文档完整性、一致性、准确性；
c） 各个设计流程的完整性、准确性；
d） 版本说明的完整性、合法性。
5.4.4 静态分析 静态分析一般需要进行：
a） 检查网络服务描述语言WSDL文档规则正确性；
b） 检查业务流程执行语言BPEL文档规则正确性；
c） 检查简单对象访问协议SOAP文档规则正确性；
d） 检查通用描述、发现与集成协议UDDI文档规则正确性。
5.4.5 功能测试 功能测试一般需进行：
a） 用正常服务流程的等价类进行测试；
b） 用异常服务流程的等价类进行测试；
c） 每个功能的合法边界值和非法边界值输入的测试；
d） 用一系列服务和服务流程运行，测试超负荷、饱和及其他“最坏情况”的结果；
e） 对服务提供系统和组件防止计算机程序或数据进行未经授权访问或修改完整性约束进行验证；
f） 对服务组合流程的正确性、合理性等进行验证。
5.4.6 性能测试 性能测试一般需进行：
a） 测试在获得定量结果时程序计算的精确性（处理精度）；
b） 测试其时间特性和实际完成功能的时间（响应时间）；
c） 测试为完成功能所处理的数据量；
d） 测试程序运行所占用的空间；
e） 测试其负荷潜力；
f） 测试配置项各部分的协调性；
g） 测试软件性能和硬件性能的集成；
h） 测试系统对并发服务和并发用户访问的处理能力。
5.4.7 接口测试 系统内部接口和外部接口的正确性测试，一般需进行：
a） 测试所有外部接口，检查接口信息的格式及内容；
b） 对每一个外部输入/输出接口必须做正常和异常服务的测试；
c） 测试硬件提供的接口是否便于使用；
d） 对所有的内部接口的功能、性能进行测试。
5.4.8 余量测试 测试系统的性能余量。根据被测系统需求规格说明的余量要求进行测试。若无明确要求时，一般至少保留20%的余量。
5.4.9 边界测试 软件系统在输入域/输出域、功能界限、容量界限、状态转换、环境约束的边界或端点情况下的运行状态。
5.4.10 人机交互界面测试 人机交互界面测试一般需进行：
a） 人机交互界面字符、文字的正确性；
b） 以非常规操作、误操作、快速操作来检验人机界面的健壮性；
c） 测试对非法服务、错误服务流程输入的检测能力与提示情况；
d） 测试人机界面的可操作性和友好性；
e） 人机交互界面与软件用户手册的一致性。
5.4.11 强度测试 强制系统运行在不正常到发生故障的情况下（设计的极限状态到超出极限），检验系统可以运行到何种程度的测试。一般需进行：
a） 提供最大处理的信息量；
b） 提供数据能力的饱和试验指标；
c） 提供最大存储范围；
d） 在能力降级时进行测试；
e） 在人为错误状态下进行系统反应的测试；
f） 通过启动系统过载安全装置生成必要条件，进行计算过载的饱和测试；
g） 需进行持续一段规定的时间，而且连续不能中断的测试；
h） 系统的负载测试。
5.4.12 安全性测试 安全性测试一般需进行：
a） 验证系统的验证性、认证性、机密性、可说明性、可追溯性、数据加密性和不可依赖性；
b） 对系统中的防火墙、虚拟专网（VPN）、传输过程中的节点基本认证、加密、防篡改和不可否认性进行测试，以确保服务在传输过程中的安全性；
c） 对存储和传输的数据进行加密、防篡改和数字签名测试；
d） 对用户信息管理、用户所属组织部门管理、权限管理进行验证；
e） 验证软件是否满足研制任务书规定的安全性准则和要求，重点检查其防止灾难性故障、防成败性故障的能力和容错能力；
f） 对于具有较高安全性要求的软件系统，应对其安全性内核进行测试，验证软件系统出现潜在的不安全状态或有可能转移到这种状态时，系统能够转移到规定的安全状态的能力；
g） 验证系统防止越权或意外存取以及意外修改的能力。
5.4.13 恢复性测试 对有恢复或重置功能的系统，应验证其恢复或重置能力，以及平均恢复时间；对每一类导致恢复或重置的情况逐一进行测试。一般需进行：
a） 系统探测错误服务的测试；
b） 系统能否切换或自动启动备用服务或者服务组合路径的测试；
c） 在故障发生时能否保护正在运行的服务和系统状态的测试；
d） 在系统恢复后，能否从最后记录下来的无错误状态开始继续执行服务的测试。
5.4.14 安装性测试 安装性测试一般需进行：
a） 对服务的发布、注册过程进行测试；
b） 验证服务的发布、注册等行为与相关文档描述的一致性。