c++编写软件_软件验证计划内容模板

1 范围

非必选。有的公司习惯写目的，也是一样。作为文档开头，说明本文的编写目的和应用范围。此处应说明本软件驻留的设备部件号。

2 引用文件

略。

3 缩略语/术语

略。

4 组织及职责

说明项目级的组织架构和职责。职责应明确说明软件验证组内部的角色及每一个角色对应的活动。同时应说明软件验证过程与其它过程之间的交互关系，即DO-178C 11.3 a项中所要求的“Interfaces with other software life cycle processes”。

例：

整个软件项目团队分为软件开发组、软件验证组、软件配置管理组和软件质量保证组。软件验证组的所有组员独立于软件开发组（此处应说明公司实际情况，有时候也可以采用开发和验证交叉兼职的方式），内部分为软件验证组组长及软件验证工程师两个角色。软件验证组组长负责软件验证计划的编写及软件验证活动的监督和执行，软件验证工程师负责每个软件验证活动的执行。

软件验证组对软件开发组产生的输出进行验证，具体包括软件计划、软件高级需求、软件低级需求、软件源代码及软件目标代码等，保证这些输出的正确性及标准符合性。软件验证过程的输出应经在软件配置管理人员的监督下正确纳入配置管理库，同时软件验证过程的所有输出应随时支持质量保证人员的抽检、旁站监督或其它质量保证活动。

5 独立性

说明如何实现软件验证的独立性。此处应参照DO-178C对不同软件级别的验证独立性要求来说明。软件验证的独立性可以采用完全独立的组织机构来实现（如独立的软件验证组），也可以由软件团队的其它人员兼职实现，只要被验证对象的创建者与验证者不是同一人即可。应注意说明被验证对象的创建者与验证者之间的独立性、软件验证活动的执行者与软件测试用例的编写者之间的独立性，以及软件分析活动的执行者及软件分析结果的审查者之间的独立性。

6 验证方法

6.1 评审

6.1.1 软件文档评审

简述整个软件验证过程中采取的文档评审活动和辅助检查单。建议以表格方式呈现，描述更加清晰明了。如不采用表格方式，也应按照下表各列内容对各个评审活动进行清晰描述。

例：

表X 软件文档评审活动列表

注：表X中所有涉及的检查单模板均在XX系统/XX服务器XX地址中存放，并对整个软件团队提供统一下载。填写后的检查单纳入配置管理系统，可随时支持局方检查。

6.1.2 软件验证输出评审

类似于正式文档，软件验证过程中也有很多过程输出，如测试用例、测试规程等等，需要做与上节内容相关的评审。也可以与上节内容合并。以下例子应根据实际情况填写，如软件测试用例和测试规程有可能在同一个文件中，则下表中应填写该文件的名称。

例：

表X 软件验证输出评审活动列表

注：表X中所有涉及的检查单模板均在XX系统/XX服务器XX地址中存放，并对整个软件团队提供统一下载。填写后的检查单纳入配置管理系统，可随时支持局方检查。

6.2 分析

6.2.1 软件追踪性分析

详述软件追踪性分析的转入转出准则、内容、过程和执行角色，以及分析结果的记录形式，同时应说明分析结果不符合要求时所采取的措施。按照DO-178C的要求，追踪数据的维护应包括以下几个方面的双向追踪：

a. 软件高级需求与系统分配给软件的需求之间的双向追踪；

b. 软件高级需求与软件低级需求之间的双向追踪；

c. 软件低级需求与软件源代码之间的双向追踪；

d. 软件需求（包括高低级需求）与软件测试用例之间的双向追踪；

e. 软件测试用例与软件测试规程之间的双向追踪；

f. 软件测试规程与软件测试结果之间的双向追踪。

6.2.2 软件需求的测试覆盖率分析

软件需求的测试覆盖率分析，其实就是检查看看是否针对所有的软件需求你都写了对应的测试用例，这些测试用例是否都执行了。它是检测测试完整性的一种方法。如果分析发现有的需求没有对应的测试用例，那就增加测试用例，并实际测试就好了。此处应描述该分析的转入转出准则、内容、过程和执行角色，以及分析结果的记录形式，同时应说明分析结果不符合要求时所采取的措施。

6.2.3 软件结构覆盖率分析

结构覆盖率分析包括MCDC分析、DC分析、语句覆盖分析及数据和控制耦合分析。首先，应根据在研软件的等级确定需要执行的分析，然后在针对每种分析描述该分析的转入转出准则、内容、过程和执行角色，以及分析结果的记录形式，同时应说明分析结果不符合要求时所采取的措施。D级及以下的软件不需要结构覆盖分析；C级需要做语句覆盖及数据和控制耦合分析；B级在此基础上增加了DC分析；A级最严格，还需要做MCDC分析。

6.2.4 其它分析

其它为本软件项目所执行的必要项目，如Worst Case Timing，Memory Utilization等分析。针对每种分析描述该分析的转入转出准则、内容、过程和执行角色，以及分析结果的记录形式，同时应说明分析结果不符合要求时所采取的措施。

6.3 测试

6.3.1 测试方法概述

基于需求的测试要求所有的需求，包括软件高级需求和软件低级需求，能够被100%测试，但并不规定测试的级别，即不规定哪些测试必须放在模块级去做、哪些测试放在软件集成后的目标码、亦或软硬件集成后的目标机上去做。国外供应商为提高效率，一种方式是把所有的测试都等到软硬件集成完毕后再去测试，一旦发现哪些需求（如部分低级需求）在这个级别测试不了，再回退到软件级或者模块级去做。当然，这样做也有一定的风险，加入软硬件集成后测试发现的问题太多，大部分测试都需要重新做回归测试的话，就得不偿失了。所以，具体如何做，还要由供应商自己决定。此处应描述详细描述本软件项目所采用的测试方式、过程及转入转出准则。

6.3.2 测试用例的选用准则

测试用例应同时选用正常范围测试和鲁棒性测试两种不同范围的用例。正常范围测试用于证明软件正常行为的能力，其输入应从软件设计描述文档中规定的正常范围中选取，选取方式一般采用等价类、边界值等等。

鲁棒性测试用于证明软件按照预期完成了对异常输入的处理。测试输入应选择非法输入，包括错误的初始化、除零运算、变量溢出、数组越界等等，同时鲁棒性测试还用于检测循环控制的正确性。

本节应详细描述测试用例的选用准则，公司内部如有其它文件包含测试用例的选用准则，如《XXX测试标准》，此处可直接引用，该文件备查。

6.3.3 测试用例的格式

此处应描述测试用例文件或表格的格式，并解释其中每个字段/内容的含义。有条件的应使用图表的方法说明及内容结构。同时应说明测试用例的配置管理及存储方式。

6.3.4 测试规程

此处应说明测试规程是写成脚本的形式由工具自动执行，还是会包含人工的测试步骤描述，采用人工执行方式。同样应说明测试规程的格式、配置管理及存储方式。

6.3.5 测试问题的处理

本节说明在测试过程中发现的问题，应如何处理。

7 验证环境

本节应详细分类描述软件验证过程的软硬件环境，如用于软硬件集成后验证的目标机环境、用于模块级软件验证的宿主机环境或其它仿真环境等。同时应说明在每种验证环境中具体会执行哪些验证活动。对于环境中的每一个软件工具或硬件设备，都应介绍此次使用该工具或设备的功能（注意可能不是工具所具有的所有功能）、版本，是否自研或外购等信息。

8 其他考虑

8.1 分区（partitioning）

如果软件采用了分区（partitioning）的策略，应专门描述分区完整性的验证方法。否则此处写无。

8.2 编译器假设

本节应说明以下问题：

a. 编译器的设置信息存储在何处？同时应明确说明不会使用编译器优化选项（一般会在软件每个版本的SCI中注明所使用所有工具的相关设置，包括编译器设置）；

b. 如何保证编译器设置在开发过程中不改变？（每次编译之前应核对编译器设置和SCI文件中记录设置的一致性，如特殊原因需要修改编译器设置，应采用专门的更改控制流程，对该项更改的影响进行分析）；

c. 应明确声明，对编译器和链接器的任何功能和设置的正确性不做前提性假设。换句话说，对编译器和链接器的输出，应该做正确性验证，包括编译器设置的核对、内存映射信息的人工检查、软件部件是否全部链接以及后续的完全测试等。

8.3 重验证

当软件发生更改时，应通过更改分析确定哪些已经验证过的项目需要进行重新验证。此处应描述CIA（Change Impact Analysis）的具体执行过程和方法。一种可行的方法是采用追踪性分析法确定与被更改项相关联的所有配置项，然后进一步确定受影响范围及需要重做的验证活动。

8.4 先前开发软件

如果项目中的先前开发软件未采用DO-178C标准开发，不能完全满足验证目标。此处应描述如何补充相应资料，以满足DO-178C相关验证目标的方法。

8.5 多版本非相似软件

如果已经在软件合格审定计划中声明了本项目会使用多版本非相似软件，则此处应描述针对多版本非相似软件的额外验证活动。