3.3 软件生命周期

标准5.3节对软件研发生命周期模型、软件研制过程中各阶段产生的文档成果进行了要求。

3.3.1 标准条款

5.3 Lifecycle issues and documentation

5.3.1 Objectives

5.3.1.1 To structure the development of the software into defined phases and activities.

5.3.1.2 To record all information pertinent to the software throughout the lifecycle of the software.

5.3.2 Requirements

5.3.2.1 A lifecycle model for the development of software shall be selected. It shall be detailed in the Software Quality Assurance Plan in accordance with 6.5. Two examples of lifecycle models are shown in Figure 3 and Figure 4.

5.3.2.2 The lifecycle model shall take into account the possibility of iterations in and between phases.

5.3.2.3 Quality Assurance procedures shall run in parallel with lifecycle activities and use the same terminology.

5.3.2.4 The Software Quality Assurance Plan, Software Verification Plan, Software Validation Plan and Software Configuration Management Plan shall be drawn up at the start of the project and maintained throughout the software development life cycle.

5.3.2.5 All activities to be performed during a phase shall be defined and planned prior to the commencement of the phase.

5.3.2.6 All documents shall be structured to allow continued expansion in parallel with the development process.

5.3.2.7 For each document, traceability shall be provided in terms of a unique reference number and a defined and documented relationship with other documents.

5.3.2.8 Each term, acronym or abbreviation shall have the same meaning in every document. If, for historical reasons, this is not possible, the different meanings shall be listed and the references given.

5.3.2.9 Except for documents relating to pre-existing software (see 7.3.4.7), each document shall be written according to the following rules:

● It shall contain or implement all applicable conditions and requirements of the preceding document with which it has a hierarchical relationship;

● It shall not contradict the preceding document.

5.3.2.10 Each item or concept shall be referred to by the same name or description in every document.

5.3.2.11 The contents of all documents shall be recorded in a form appropriate for manipulation, processing and storage.

5.3.2.12 When documents which are produced by independent roles are combined into a single document, the relation to the parts produced by any independent role shall be traced within the document.

5.3.2.13 Documents may be combined or divided in accordance with 5.3.2.12. Some development steps may be combined, divided or, when justified, eliminated, at the discretion of the Project Manager and with the agreement of the Validator.

5.3.2.14 Where any alternative lifecycle or documentation structure is adopted it shall be established that it meets all the objectives and requirements of this European Standard.

5.3 生命周期问题和文档

5.3.1 目标

5.3.1.1 规范软件开发的阶段和活动。

5.3.1.2 记录贯穿整个软件生命周期的所有相关信息。

5.3.2 要求

5.3.2.1 应为软件开发选择生命周期模型,并根据第6.5节在软件质量保证计划中对该模型加以详细说明。两个生命周期模型的样例如图3和图4所示(图片请翻阅标准原文)。

5.3.2.2 应该考虑生命周期模型各阶段迭代执行的可能性。

5.3.2.3 质量保证规程应与生命周期活动一起运行,并且使用相同的术语。

5.3.2.4 软件质量保证计划,软件验证计划,软件确认计划和软件配置管理计划应该在项目启动阶段起草并且贯穿整个软件开发过程。

5.3.2.5 各阶段所有要进行的活动应在该阶段开始之前先行定义和计划。

5.3.2.6所有文档应该结构化,以便随开发进程不断扩展。

5.3.2.7 各个文档应有唯一的索引编号,与其他文档应有确定的记录在案的文档关系,以便进行文档追溯。

5.3.2.8 每个文档对缩略语和简写词应有相同的解释。如果由于历史的原因,做不到这一点,就应给出不同的释义和参考资料。

5.3.2.9 除早期开发软件的文档外(见7.3.4.7小节),各文档应按以下规则书写:

● 应包括或执行所有与之具有层次关系的前期文档的适用条件和要求;

● 不应与前期文档有抵触。

5.3.2.10 每个文档中,每个条目或概念使用相同的名称或描述。

5.3.2.11所有文档内容应以适合操作、处理和存储的形式来记录。

5.3.2.12 当多个独立角色完成的文档整合成单个文档时,文档中各独立完成部分之间的关系应能够追溯。

5.3.2.13 文档可以根据标准5.3.2.12进行组合与分割。在征得验证者同意后,项目经理可对开发步骤进行合并、分割或者取消(应当经过判断)。

5.3.2.14 被采纳的任何替代生命周期或文档架构的部分应该满足标准中所有的目标和要求。

3.3.2 条款理解及应用

对于软件研发的生命周期,标准中推荐使用V模型进行开发。V模型是软件测试过程中常见的一种模型,它反映了开发过程和测试过程的关系,在测试软件的过程中起着重要的作用。在这种模型的测试过程中,首先进行可行性研究需求定义,然后以书面的形式对需求进行描述,产生需求规格说明书;之后,开发人员根据需求规格说明书来对软件进行概要设计,测试人员根据需求规格说明书设计出系统测试用例;概要设计之后,开发人员根据概要设计对软件进行详细设计,测试人员根据概要设计设计出集成测试用例;详细设计之后,开发人员根据详细设计进行编码,测试人员根据详细设计设计出单元测试用例;编码完成之后,测试人员根据单元测试用例对设定的软件测试单元进行测试,单元测试完成之后,进行集成测试,然后进行系统测试,最后进行验收测试。典型的软件研发V模型如图3-2所示。

图3-2 典型的软件研发V模型

图3-2中每个阶段的目标及具体活动的描述如下:

1)需求分析

目标:明确用户需求,并对需求进行分析和提取。

活动:通过和用户进行充分沟通,了解用户的需求,并对用户的需求进行分析,然后将整理好的需求分析转交给用户,以便用户对自己的需求进行确认。需求分析做好以后,转交给概要设计人员和测试部门,概要设计人员以需求分析为依据进行软件概要设计,测试部门也以需求分析为依据对软件做出系统测试的测试用例。

2)软件架构设计

目标:对软件的结构与组成进行整体的、概要的设计。

活动:本阶段的设计过程中,主要需要明确设计出如下三点,即软件架构、各个模块功能的设计和模块与模块之间的接口。明确软件架构,即需要确定软件在实现过程中需要应用哪种应用服务模式;明确各个模块功能的设计,即需要明确说明各个模块及各个模块需要完成什么功能;明确模块与模块之间的接口,即需要明确模块和模块进行通信的规则。

3)软件部件设计

目标:对各个软件组件进行详细设计

活动:软件部件设计必须遵循软件概要设计来进行。软件部件设计方案的更改,不得影响到软件架构设计方案;如果需要更改软件架构设计,必须经过项目经理的同意。

在软件部件设计阶段,设计者的工作对象是各个具体的软件模块,根据架构设计赋予的局部任务和对外接口,设计并表达出模块的算法、流程、状态转换等内容。软件部件设计阶段需要将各个软件模块的流程图、状态图、局部变量及对外接口用相应的文字进行清晰的描述。此外,组织进行设计评审。

4)软件部件实现

目标:根据软件部件的设计完成软件编码。

活动:软件部件实现过程是使用选定的程序设计语言,把部件的设计描述翻译为用该语言书写的源程序。源程序应该正确可靠、简明清晰,而且具有较高的效率。程序员首先应该选择设计程序的设计语言,选择设计语言是前提,其次再考虑编码过程中的规则与步骤。安全相关软件的编码一般需要保证70%以上的注释率。

5)软件部件测试

目标:验证和确认代码的开发是否符合部件设计的要求,记录测试结果。

活动:软件部件测试阶段的活动包括代码静态分析、代码走查和单元测试。

代码静态分析是进行代码的控制流分析、数据流分析、接口分析、表达式分析和软件结构度量元分析。同时通过静态分析获得程序的基本信息,包括程序规模、模块数、注释率、模块圈复杂度等。

(1)控制流分析。控制流分析是指使用控制流程图系统地检查被测程序的控制结构的工作。控制流按照结构化程序规则和程序结构的基本要求进行程序结构检查,要求被测程序不得包含下述情形:

● 转向并不存在的语句;

● 没有使用的语句;

● 没有使用的子程序定义;

● 调用并不存在的子程序;

● 从程序入口进入后无法达到的语句;

● 不能达到停止语句的语句。

(2)数据流分析。数据流分析是指用控制流程图来分析数据发生的异常情况的工作。异常是指被初始化、被赋值或被引用过程中出现的行为序列的异常。

利用数据流分析法可以查出引用未定义变量、对以前未使用的变量再次赋值等程序差错。

(3)接口分析。接口分析包括实际分析和程序静态分析,接口一致性的设计分析涉及模块之间接口一致性和模块与外部数据库之间的一致性。程序的接口分析主要包括子程序以及函数之间的接口一致性,包括检查形参与实参的类型、数量、维度、顺序以及使用的一致性。

(4)表达式分析。表达式分析主要是分析被测软件是否有表达式错误。表达式错误包括但不限于:括号使用不正确、数组引用错误、作为除数的变量可能为零、作为开平方的变量可能为负,作为正切值的变量可能为π/2,浮点数变量比较时会产生错误等。

(5)软件结构度量元分析。通过对软件的度量元,包括扇入、扇出、圈复杂度等进行分析,评价软件的部件或单元间调用关系上的复杂性。

(6)代码语义分析。

依据GB/T 28169—2011《嵌入式软件C语言编码规范》、GJB 5369—2005《航天型号软件C语言安全子集》、MISRA C等相关标准,对源代码进行语义分析,主要包括数组越界检查、内存泄漏检查、指针检查、安全性漏洞扫描、变量未初始化检查以及数据流分析等。

代码走查根据被测软件编程语言及相关编码规范,以及软件需求和设计文档进行。代码走查的测试内容包括:检查软件设计文档与代码实现的一致性;检查代码执行标准的情况;检查代码逻辑表达的正确性;检查代码结构的合理性;检查代码的可读性等。代码走查的审查项包括但不限于以下方面:寄存器使用、格式、入口和出口连接、程序语言的使用、存储器使用、测试和转移、性能、可维护性、逻辑、软件多余物、循环、子程序和过程、嵌套结构、寻址与数组、数据结构等。

单元测试依据委托方提供的软件部件设计文档确定被测软件包含的软件单元,结合被测软件特性、安全重要等级和不同覆盖率类型的优缺点,选取语句覆盖、分支覆盖、路径覆盖或MC/DC覆盖等类型,对全部软件单元开展单元测试,包括功能测试、接口测试、边界测试、结构覆盖测试等。

软件单元测试要达到以下要求:

● 对软件设计文档中规定的软件单元功能进行测试,以验证其是否满足规定的要求;

● 对软件设计文档中规定的软件单元接口进行测试,验证接口实现的正确性;

● 对软件设计文档中规定的软件单元的各输入、输出数据边界值进行测试;

● 对软件单元进行结构覆盖测试,包括语句覆盖、分支覆盖、路径覆盖、MC/DC覆盖等;

● 测试软件单元在运行过程中发生错误时,其错误处理措施是否有效;

● 测试软件单元内部的数据结构是否完整,检查数据类型说明、变量初始化、缺省值设置等是否正确;

● 每个软件特性应至少被一个正常测试用例和一个被认可的异常测试用例覆盖;

● 测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值;

● 对输出数据及其格式进行测试。

6)软件集成与测试

目标:完成软件部件的组装与测试,确认各模块能够正确地结合到一起,实现架构设计的各项指标。

活动:在单元测试的基础上,将软件架构设计文档的要求组装成系统或子系统,进行软件与软件集成、软件与硬件集成,并对集成后的部件进行测试。

在此阶段,对设计测试用例开展功能、性能、安全性、可靠性等方面的测试,验证软件组装后各部分工作是否达到或实现相应技术指标及要求。

(1)功能测试。通过正常值、非正常值的等价类输入数据值和边界值的输入数据值测试,检查:

● 模块(或单元)间参数传递与结果返回的正确性;

● 模块(或单元)组装后,部件功能的正确性;

● 全局数据结构的正确性。

(2)性能测试。主要测试运行时间、占用空间、精度等。

(3)接口测试。主要测试:

● 模块(或单元)间接口数据流的正确性;

● 数据通过接口是否丢失;

● 软件单元之间是否相互存在不良影响;

● 全局数据结构是否存在问题。

(4)逻辑测试。要求模块(或单元)间调用满足语句覆盖率、分支判断覆盖率、条件覆盖率等的要求。软件集成测试关注以下几点:

● 在把各个模块连接起来的时候,穿越模块接口的数据是否会丢失;

● 各个子功能组合起来,能否达到预期要求的父功能;

● 一个模块的功能是否会对另一个模块的功能产生不利的影响;

● 全局数据结构是否有问题;

● 单个模块的误差积累起来,是否会放大。

7)软件确认

目标:对最终软件系统进行全面的测试,从而验证和确认软件的质量特性是否满足需求规格说明书的要求。

活动:本阶段一般需要提取软件需求规格说明中的所有测试点,充分考虑系统的全部工况,对软件所在的系统进行验证。

验证一般建议采用黑盒测试的方法开展,包括:功能测试、性能测试、接口测试、人机交互测试、强度测试、安全性测试、安装性测试、兼容性测试、负载测试等。

(1)功能测试。对技术规格中的各项功能进行以下测试,验证系统是否达到所规定的要求:正常值的等价类输入数据检测;非正常值的等价类输入数据检测;边界值的输入数据检测。

(2)性能测试。

● 准确性测试:测试软件产品提供具有所需精确度的正确的或相符的结果或效果的能力。如,软件在获得定量结果时程序计算的精确性;

● 时间特性测试:测试在规定条件下,软件产品执行其功能时,提供适当的响应和处理时间以及吞吐率的能力。测试系统完成其功能的实时性能,测试系统对并发事务和并发访问的处理能力等;

● 资源利用方面:测试在规定条件下,软件产品执行其功能时,使用合适数量和类别的资源的能力。测试系统的负载能力,测试系统的软件或硬件因素是否制约了软件的性能,测试系统运行时占用的空间。

(3)接口测试。

● 测试系统内部接口的正确性和一致性;

● 测试系统外部接口的正确性和一致性,即测试软件产品与一个或更多的规定系统进行交互的能力;

● 容错性测试:测试在软件出现故障或者违反指定接口的情况下,软件产品维持规定性能级别的能力。

(4)人机界面测试。

● 易学性测试:测试软件产品的应用使用户易于学会的能力,如人机交互界面与用户手册或操作手册的一致性;

● 易操作性测试:测试软件产品使用户易于操作和控制的能力,如人机交互界面字符、文字的正确性,人机交互界面的有效性,人机交互界面的健壮性;

● 吸引性:软件产品吸引用户的能力(例如颜色的使用和图形化界面的设计)。

(5)强度测试。

● 性能强度测试:要求处理的信息量,超过设计允许的最大值;数据传输能力的饱和试验,要求超出设计能力传输更多的数据(内存的写入和读出、外部设备、其他分系统及内部界面的数据传输等);存储范围(如缓冲区、表格和临时信息区)超过额定大小的能力。

● 降级能力强度测试。对于设计上允许降级运行的软件,测试计算机部分硬件失效(或瞬间失效)时其自恢复能力。

● 健壮性测试。测试系统在遇到意外的情况下,是否具有足够的健壮性。

(6)安全性测试。验证被测试软件是否满足软件技术规格书或需求规格说明书的要求,重点检查软件的防止灾难故障能力、容错能力、对数据非法访问的保护能力。

● 测试系统在硬件或软件出现故障情况下的处理和保护能力;

● 测试当软件/硬件配置切换到标准配置以下时的处理和保护能力;

● 测试系统容错操作的能力。

(7)兼容性测试

● 测试嵌入式软件的软硬件之间的兼容性;

● 测试系统与外设的兼容性;

● 测试应用软件与操作系统之间的兼容性;

● 测试不同应用软件之间的兼容性。

(8)负载测试。负载测试是一种性能测试,测试数据在超负荷环境中运行时程序的承担能力。