软件测试与发布程序文件.docx
《软件测试与发布程序文件.docx》由会员分享,可在线阅读,更多相关《软件测试与发布程序文件.docx(15页珍藏版)》请在冰豆网上搜索。
![软件测试与发布程序文件.docx](https://file1.bdocx.com/fileroot1/2023-7/13/8fdf834a-d837-4b21-96a0-8ad765836dd7/8fdf834a-d837-4b21-96a0-8ad765836dd71.gif)
软件测试与发布程序文件
软件测试与发布程序
文件编号:
Q/XKYWT-C-JS-07-2007
1目的
做好产品的测试与检验、试验工作,确保产品质量符合用户要求。
2适用范围
适用对象:
技术部
业务范围:
综合测试、确认测试
3方针和职责
技术部测试工程师负责开发过程中的测试;技术部软件设计工程师负责针对测试中发
现的问题进行修改。
4工作程序
4.1测试
项目经理接受过软件工程、项目的应用领域知识、项目管理的培训或具备相应的能
力。
软件综合测试人员和确认测试人员接受过软件测试理论、方法、技术、工具等的培训
或具备相应的能力。
综合测试人员和确认测试人员依据〈项目计划》中定义的项目软件过程,计划和实施软
件测试。
在〈项目计划》中,要尽早分配测试软件的资源,以做好充分的测试准备。
4.1.1概述Overview
软件测试级别包括以下四种:
单元测试、综合测试、确认测试、用户测试。
这四级软
件测试应按顺序进行,前者完成方可开始后续测试(特殊情况下确认测试可与用户测试合
并进行)。
当被测试软件或软件环境发生变化时,应在相关级别上适当进行回归测试。
单
元测试在软件实现程序》中描述,综合测试、确认测试和用户测试在本程序中描述。
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.122实施测试
输入Input
1.通过评审并形成基线的《测试计划》
2.已通过综合测试且纳入基线的可执行程序
3.通过评审并形成基线的操作手册》
过程活动Processactivities
1.依据<测试计划》中的测试环境要求,测试组负责完成测试环境的搭建。
2.测试组依据《测试计划》实施测试。
3.对照纳入确认测试基线的软件,对操作手册》进行验证。
合适时,由用户和软件
维护人员对其进行评审和认可。
4.测试组将《操作手册》、可执行程序功能和性能的测试过程和测试结果记录在《测试报告》的详细测试记录”中。
5.测试完成后,测试负责人填写<测试反馈单》反馈给开发负责人。
6.开发负责人负责将修改完成后的软件重新提交给测试组。
7.测试组进行回归测试。
&以上步骤重复进行,直到发现的缺陷全部被关闭。
当出现以下情况时,确认测试负责人可以终止确认测试(异常终止)。
1.测试中发现的缺陷太多;
2.软件出现缺陷,致使无法进行后续测试
输出Output
1•〈测试报告》
2•《测试反馈单》
4.123编写〈测试报告》
输入Input
1.〈测试记录单》
2•《测试反馈单》
过程活动Processactivities
1.测试组汇总分析《操作手册》、可执行程序功能和性能的测试情况,编写<测试报
告》(参见<测试报告模板》)。
测试报告应包括:
测试概要、实际测试与测试计划的偏差、在测试中发现的缺陷、缺陷解决后再次测试的结果,并对测试结果进行分
析,重点是评价软件的能力是否达到预定目标,是否可以开始下一阶段活动,并
以此判断软件是否满足需求。
2.《测试报告》编写完成后,项目分管高层经理批准。
输出Output
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.0aBuild105。
合同类项目的产品发布过程通常包括:
发布a版产品、发布B版产品和发布正式版产
品。
如下图所示:
产品开发类项目的产品发布过程通常包括
发布m.n(例如:
1.1)版产品、发布正式
版产品。
如下图所示
4.2.2产品的对外发布(SCMAC7)
作产品无论是外部使用还是内部使用,都必须由受控库中的配置项构成
输入Input
受控库中的配置项
过程活动Processactivities
1.项目经理确定需要发布的产品配置项。
并指定审计人员进行配置审计。
2.配置管理员根据项目经理确定的要发布的配置项填写并向CCB提交〈发布通知》。
3.QA对拟发布的产品进行评价,并在〈发布通知》上签字。
4.CCB在〈发布通知》上签字,批准本次发布。
5.配置管理员从受控库中提取配置项,然后在产品库中建立该次发布的目录(目录名
据〈发布通知》中的约定而定),并将提取出来的配置项放入该目录中。
6.配置管理员(或项目经理指定的人员)将需要发布的工作产品复制到物理介质上
(如:
光盘、磁盘等),然后发布。
输出Output
1.放入产品库中的产品。
2.经CCB批准的〈发布通知》。
3.放在物理介质上的需要发布的产品。
4.2.3发布中间版产品
输入Input
通过确认测试的软件工作产品
过程活动Processactivities
1、将经过确认测试,且验证和关闭了所有已发现缺陷的软件工作产品标识为aBuild1版,如:
XX系统2.0aBuild1。
填写〈发布通知》,并将相应产品放入产品库。
2、合同类项目需从产品库中提取要发布的产品包交付用户测试或使用,产品类项目需
将产品包发送给公司内部测试。
3、用户在测试或使用过程中如果有反馈信息则按照以下过程活动处理:
a.收集、分析反馈信息
客户经理、或由项目经理指定的负责人要定期的或事件驱动的收集用户测试/
使用的反馈信息(参见〈中创软件客户沟通规范》),并对这些信息进行分析,提取出对软件工作产品进行变更的要求,提交给项目经理。
b.软件工作产品的变更。
项目经理组织软件工程组人员对变更要求进行评估,明确需要变更的内容项、
以及受影响的软件工作产品后提交SCCB评审,评审通过后修改相应的软件工作
产品。
(参见软件配置管理程序》之变更控制)。
c.测试
在项目组修改完软件工作产品后,确认测试负责人需要组织对产品中本次修改
可能受影响的部分进行确认测试。
d.发布Buildn版产品
将经过确认测试,且验证和关闭了所有已发现缺陷的软件工作产品标识为a
Buildn版(其中n为前一个Build号数字的递增),并放入受控库中,同时编写〈发布通知》进行产品的发布。
女口:
XX系统2.0aBuild105。
从受控库中提取产品包,
发送给用户测试/使用。
注:
对于合同类项目,如果某次发版的产品通过用户初验,则转入第二步一一发布3
版产品;对于产品类项目,如果产品通过测试用户的测试,并且达到了预期的功能、质量要求,即可转入第三步一一发布正式版产品。
输出Output
1、《发布通知》;
2、〈评审报告》;
3、软件工作产品输出标准outputcriteria
1、上述各活动中,所有经过评审和测试发现的缺陷均得到验证并关闭。
2、所有对纳入基线的软件工作产品的更改都是按照软件配置管理程序》进行的。
4.2.4发布正式版产品
输入Input
通过用户终验(合同类项目)或经过大范围用户测试、达到了预期的功能、质量要求
的产品。
过程活动Processactivities
1、将通过用户终验(合同类项目)或经过大范围用户测试、达到了预期的功能、质量
要求的产品标识为正式的发行版本,女口:
XX系统2.0。
并放入受控库中。
同时编写
〈发布通知》进行产品的发布。
2、由项目经理将受控库访问权限进行修改,使得任何人不能够再对其中的软件工作产品进行修改。
3、软件产品的升级需经过收集信息、变更、测试、发布等各步骤,参照发布a版产品中过程活动3步骤进行。
输出Output
1、《发布通知》;
2、评审记录;
3、成为正式版的软件产品。
输出标准outputcriteria
1、本过程活动中所涉及测试的活动中,所有经过评审和测试发现的缺陷均得到验证并关闭。
2、所有对纳入基线的软件工作产品的更改都是按照软件配置管理程序》进行的。
4.2.5变更Modification
过程活动Processactivities
正式版形成基线后,其更改应按照《软件配置管理程序》进行,并相应更新〈需求跟踪
矩阵》。
更改后的发布参照上述流程进行。
输出Output
形成新基线的软件产品工程各阶段产品。
4.2.6度量Measurement
发版过程中应进行的度量包括:
1、评审发现的缺陷数、严重程度、缺陷起源阶段;
2、评审产品发布上的工作量。
以上数据分别体现在〈里程碑报告》及〈项目状态报告》中。
4.2.7验证Verification
事业部高层经理定期通过项目周报》、项目状态报告》、项目月报》、重大里程碑
评审来评审软件测试活动。
项目经理定期通过项目例会、〈项目月报》、重大里程碑评审或遇到重要需求分析问题
时来评审软件测试活动。
QA人员评审和验证:
1、软件产品已经过评审,符合规定的标准和需求,可以发布;
2、软件产品发布活动满足准备就绪准则和完成准则;
3、按照〈项目计划》中的测试计划,完成所要求的测试,而且测试满足其验收准则;
4、评审和测试发现的问题和缺陷已记录,并进行了跟踪和解决;
5、通过〈需求跟踪矩阵》对需求进行了跟踪。
6、在软件产品交付给客户或最终用户之前,进行了确认测试。
7、在软件产品交付给客户或最终用户之前,依据软件基线和需求验证了用来管理和
维护软件的文档。
4.2.8剪裁指南TailoringGuideline
纯硬件集成类项目可以剪裁产品发布过程。
其它具体的裁剪指南请参考本文中的斜体字部分。
6相关文件
无
7质量记录
《测试方案》
《测试报告》
《测试反馈表》