软件测试与发布程序Word文档格式.docx

软件测试与发布程序Word文档格式.docx

《软件测试与发布程序Word文档格式.docx》由会员分享，可在线阅读，更多相关《软件测试与发布程序Word文档格式.docx（11页珍藏版）》请在冰豆网上搜索。

单元测试、综合测试、确认测试、用户测试。

这四级软件测试应按顺序进行，前者完成方可开始后续测试（特殊情况下确认测试可与用户测试合并进行）。

当被测试软件或软件环境发生变化时，应在相关级别上适当进行回归测试。

单元测试在《软件实现程序》中描述，综合测试、确认测试和用户测试在本程序中描述。

4.1.1.1综合测试

综合测试，也叫组装测试。

通常，在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。

组装测试就是发现在模块连接中可能出现的缺陷，最终构成要求的软件系统。

测试重点是：

1．在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；

2．一个模块的功能是否会对另一个模块的功能产生不利的影响；

3．各个子功能组合起来，能否达到预期要求的功能的父功能；

4．全局数据结构是否有问题；

5．单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。

4.1.1.2确认测试

确认测试又称有效性测试，是验证软件的功能和性能及其他特性是否与软件需求一致。

依据软件需求规格说明进行。

合适时，可以邀请用户一起开发和评审测试准则。

4.1.1.3测试的合并

对于大部分项目，综合测试、确认测试可以合并进行，进行统一的策划、实施，形成统一的《测试计划》、《测试报告》。

4.1.2测试准备TestPreparation

确认测试由所在事业部或部门成立的独立于项目组的测试组进行（必要时，与客户一同进行），以证明该软件满足软件需求。

测试组依据《项目计划》实施软件测试工作。

必要时（如公司不具备测试所需的特殊设备等），到用户现场，与客户一同参与测试活动，即将确认测试与用户测试合并进行，详见剪裁指南。

当被测试软件或测试环境发生变化时，适当地进行回归测试。

4.1.2.1制定《测试计划》

前置条件Precondition

1.确认测试已在《项目计划》中定义。

2.确认测试负责人已在《项目计划》中定义。

输入Input

1．经过评审并已形成基线的《软件需求分析说明书》

2．已形成基线的《项目计划》

3．其它支持确认测试、并通过评审的工作产品，如《概要设计说明书》、《操作手册》等

过程活动Processactivities

1．《软件需求分析说明书》编写完成后，测试组制定《测试计划》（含测试用例），该计划中要明确《操作手册》、软件系统的功能和性能作为测试项。

2．《软件需求分析说明书》变更时，测试组修改《测试计划》。

3．《测试计划》编写完成后，应进行同行评审（必要时，用户参与）。

4．《测试计划》通过评审后形成基线，置于配置管理之下。

5．当软件需求或被测试软件更改时，相应更改测试方案。

输出Output

1．通过评审并形成基线的《测试计划》

4.1.2.2实施测试

2．已通过综合测试且纳入基线的可执行程序

3．通过评审并形成基线的《操作手册》

1．依据《测试计划》中的测试环境要求，测试组负责完成测试环境的搭建。

2．测试组依据《测试计划》实施测试。

3．对照纳入确认测试基线的软件，对《操作手册》进行验证。

合适时，由用户和软件维护人员对其进行评审和认可。

4．测试组将《操作手册》、可执行程序功能和性能的测试过程和测试结果记录在《测试报告》的“详细测试记录”中。

5．测试完成后，测试负责人填写《测试反馈单》反馈给开发负责人。

6．开发负责人负责将修改完成后的软件重新提交给测试组。

7．测试组进行回归测试。

8．以上步骤重复进行，直到发现的缺陷全部被关闭。

当出现以下情况时，确认测试负责人可以终止确认测试（异常终止）。

1.测试中发现的缺陷太多；

2.软件出现缺陷，致使无法进行后续测试。

1．《测试报告》

2．《测试反馈单》

4.1.2.3编写《测试报告》

1．《测试记录单》

1．测试组汇总分析《操作手册》、可执行程序功能和性能的测试情况，编写《测试报告》（参见《测试报告模板》）。

测试报告应包括：

测试概要、实际测试与测试计划的偏差、在测试中发现的缺陷、缺陷解决后再次测试的结果，并对测试结果进行分析，重点是评价软件的能力是否达到预定目标，是否可以开始下一阶段活动，并以此判断软件是否满足需求。

2．《测试报告》编写完成后，项目分管高层经理批准。

1.通过评审的《测试报告》

2.评审记录

输出标准outputcriteria

1.《测试计划》已形成基线。

2.《测试报告》通过评审。

4.1.3变更Change

测试方案、测试报告形成基线后，其更改（一般为当软件需求或软件设计更改时）应按照《软件配置管理程序》进行，并相应更新《需求跟踪矩阵》。

随着对软件理解的加深，如果需要对软件工作产品、计划、过程定义和活动方面进行更改时，应先分析更改对软件的影响，合适时予以采纳。

当需要更改用户需求时，应先得到批准，然后再与相关小组协商对软件产品和活动作出相应更改。

4.1.4过程度量Measurement

软件测试活动中应进行的度量包括：

1、测试阶段的评审中发现的缺陷数、严重程度、缺陷起源阶段；

2、花在评审、纠正和批准各任务活动/软件工作产品上的工作量；

3、变更各任务活动软件工作产品的规模、费用、工作量。

以上数据分别体现在《里程碑报告》及《项目状态报告》中。

4.1.5验证Verification

项目分管高层经理定期通过《项目周报》、《项目状态报告》、《项目月报》、重大里程碑评审来评审软件测试活动。

项目经理定期通过项目例会、《项目月报》、重大里程碑评审或遇到重要需求分析问题时来评审软件测试活动。

QA人员评审和验证：

1.需要进行评审的软件工作产品，已进行了评审；

2.软件测试活动满足准备就绪准则和完成准则；

3.软件产品符合对它们所规定的标准和要求；

4.已完成了计划的测试，并记录了测试结果；

5.评审和测试发现的问题和缺陷已记录，并进行了跟踪和解决；

6.通过《需求跟踪矩阵》对需求进行了跟踪。

4.1.6剪裁指南TailoringGuideline

如果公司不具备确认测试的环境或者应用户要求，需要到用户现场进行确认测试，可以将确认测试与用户测试合并进行。

工作程序按用户测试程序进行。

根据合同要求，如果用户测试由用户独立进行，则在用户测试活动中，测试组只需取得用户的书面测试报告；

如果用户测试过程中的部分活动（如编写《用户测试报告》）由用户独立进行，则测试组仅需执行其它活动，并取得用户的书面测试报告。

4.2发布

4.2.1概述Outline

一般地，软件产品发布在整个软件产品工程过程中所处的位置如下（以瀑布模型为例）：

软件产品发布前要从以下三个方面验证其测试的充分性：

1．测试级别：

软件产品是否经过了QMS中规定的所有测试，即单元测试、综合测试、确认测试。

2．测试策略：

每个级别的测试是否都选择了合适的测试策略。

3．测试覆盖率：

软件测试是否达到了预定的测试覆盖率。

软件产品经过确认测试、所有经过评审和测试发现的缺陷均关闭并得到验证、且各类文档和手册编写完成并通过评审后，依据《配置管理计划》中的约定放入受控库。

此时的软件产品进入发布阶段，以“产品名称+产品发行版本号+产品发布内部版本号”的形式予以标识，如：

XX系统2.0αBuild105。

合同类项目的产品发布过程通常包括：

发布α版产品、发布β版产品和发布正式版产品。

如下图所示：

产品开发类项目的产品发布过程通常包括：

发布m.n（例如：

1.1）版产品、发布正式版产品。

4.2.2产品的对外发布（SCMAC7）

当项目组要向本项目组外的个人或者组织（如：

客户、培训组等）提交软件工作产品时，无论是提供给内部用户还是外部用户使用，须遵循以下发布过程。

所有提交的软件工作产品无论是外部使用还是内部使用，都必须由受控库中的配置项构成。

受控库中的配置项

1.项目经理确定需要发布的产品配置项。

并指定审计人员进行配置审计。

2.配置管理员根据项目经理确定的要发布的配置项填写并向CCB提交《发布通知》。

3．QA对拟发布的产品进行评价，并在《发布通知》上签字。

4.CCB在《发布通知》上签字，批准本次发布。

5.配置管理员从受控库中提取配置项，然后在产品库中建立该次发布的目录（目录名据《发布通知》中的约定而定），并将提取出来的配置项放入该目录中。

6.配置管理员（或项目经理指定的人员）将需要发布的工作产品复制到物理介质上（如：

光盘、磁盘等），然后发布。

1.放入产品库中的产品。

2.经CCB批准的《发布通知》。

3.放在物理介质上的需要发布的产品。

4.2.3发布中间版产品

通过确认测试的软件工作产品

1、将经过确认测试，且验证和关闭了所有已发现缺陷的软件工作产品标识为αBuild1版，如：

XX系统2.0αBuild1。

填写《发布通知》，并将相应产品放入产品库。

2、合同类项目需从产品库中提取要发布的产品包交付用户测试或使用，产品类项目需将产品包发送给公司内部测试。

3、用户在测试或使用过程中如果有反馈信息则按照以下过程活动处理：

a.收集、分析反馈信息

客户经理、或由项目经理指定的负责人要定期的或事件驱动的收集用户测试/使用的反馈信息（参见《中创软件客户沟通规范》），并对这些信息进行分析，提取出对软件工作产品进行变更的要求，提交给项目经理。

b.软件工作产品的变更。

项目经理组织软件工程组人员对变更要求进行评估，明确需要变更的内容项、以及受影响的软件工作产品后提交SCCB评审，评审通过后修改相应的软件工作产品。

（参见《软件配置管理程序》之变更控制）。

c.测试

在项目组修改完软件工作产品后，确认测试负责人需要组织对产品中本次修改可能受影响的部分进行确认测试。

d.发布Buildn版产品

将经过确认测试，且验证和关闭了所有已发现缺陷的软件工作产品标识为αBuildn版（其中n为前一个Build号数字的递增），并放入受控库中，同时编写《发布通知》进行产品的发布。

如：

从受控库中提取产品包，发送给用户测试/使用。

注：

对于合同类项目，如果某次发版的产品通过用户初验，则转入第二步——发布β版产品；

对于产品类项目，如果产品通过测试用户的测试，并且达到了预期的功能、质量要求，即可转入第三步——发布正式版产品。

1、《发布通知》；

2、《评审报告》；

3、软件工作产品。

1、上述各活动中，所有经过评审和测试发现的缺陷均得到验证并关闭。

2、所有对纳入基线的软件工作产品的更改都是按照《软件配置管理程序》进行的。

4.2.4发布正式版产品

通过用户终验（合同类项目）或经过大范围用户测试、达到了预期的功能、质量要求的产品。

1、将通过用户终验（合同类项目）或经过大范围用户测试、达到了预期的功能、质量要求的产品标识为正式的发行版本，如：

XX系统2.0。

并放入受控库中。

同时编写《发布通知》进行产品的发布。

2、由项目经理将受控库访问权限进行修改，使得任何人不能够再对其中的软件工作产品进行修改。

3、软件产品的升级需经过收集信息、变更、测试、发布等各步骤，参照发布α版产品中过程活动3步骤进行。

2、评审记录；

3、成为正式版的软件产品。

1、本过程活动中所涉及测试的活动中，所有经过评审和测试发现的缺陷均得到验证并关闭。

4.2.5变更Modification

正式版形成基线后，其更改应按照《软件配置管理程序》进行，并相应更新《需求跟踪矩阵》。

更改后的发布参照上述流程进行。

形成新基线的软件产品工程各阶段产品。

4.2.6度量Measurement

发版过程中应进行的度量包括：

1、评审发现的缺陷数、严重程度、缺陷起源阶段；

2、评审产品发布上的工作量。

4.2.7验证Verification

事业部高层经理定期通过《项目周报》、《项目状态报告》、《项目月报》、重大里程碑评审来评审软件测试活动。

1、软件产品已经过评审，符合规定的标准和需求，可以发布；

2、软件产品发布活动满足准备就绪准则和完成准则；

3、按照《项目计划》中的测试计划，完成所要求的测试，而且测试满足其验收准则；

4、评审和测试发现的问题和缺陷已记录，并进行了跟踪和解决；

5、通过《需求跟踪矩阵》对需求进行了跟踪。

6、在软件产品交付给客户或最终用户之前，进行了确认测试。

7、在软件产品交付给客户或最终用户之前，依据软件基线和需求验证了用来管理和维护软件的文档。

4.2.8剪裁指南TailoringGuideline

纯硬件集成类项目可以剪裁产品发布过程。

其它具体的裁剪指南请参考本文中的斜体字部分。

6相关文件

无

7质量记录

《测试方案》

《测试报告》

《测试反馈表》