软件测试与发布程序.doc

1、软件测试与发布程序文件编号：Q/XKYWT-C-JS-07-20071 目的做好产品的测试与检验、试验工作，确保产品质量符合用户要求。2 适用范围适用对象：技术部业务范围：综合测试、确认测试3 方针和职责技术部测试工程师负责开发过程中的测试；技术部软件设计工程师负责针对测试中发现的问题进行修改。4 工作程序4.1 测试项目经理接受过软件工程、项目的应用领域知识、项目管理的培训或具备相应的能力。软件综合测试人员和确认测试人员接受过软件测试理论、方法、技术、工具等的培训或具备相应的能力。综合测试人员和确认测试人员依据项目计划中定义的项目软件过程，计划和实施软件测试。在项目计划中，要尽早分配测试软件

2、的资源，以做好充分的测试准备。4.1.1 概述 Overview软件测试级别包括以下四种：单元测试、综合测试、确认测试、用户测试。这四级软件测试应按顺序进行，前者完成方可开始后续测试（特殊情况下确认测试可与用户测试合并进行） 。当被测试软件或软件环境发生变化时，应在相关级别上适当进行回归测试。单元测试在软件实现程序中描述，综合测试、确认测试和用户测试在本程序中描述。4.1.1.1 综合测试综合测试，也叫组装测试。通常，在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。组装测试就是发现在模块连接中可能出现的缺陷，最终构成要求的软件系统。测试重点是：1 在把各个模块连接起来的时候，穿越模

3、块接口的数据是否会丢失；2 一个模块的功能是否会对另一个模块的功能产生不利的影响；3 各个子功能组合起来，能否达到预期要求的功能的父功能；4 全局数据结构是否有问题；5 单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。4.1.1.2 确认测试确认测试又称有效性测试，是验证软件的功能和性能及其他特性是否与软件需求一致。依据软件需求规格说明进行。合适时，可以邀请用户一起开发和评审测试准则。4.1.1.3 测试的合并对于大部分项目，综合测试、确认测试可以合并进行，进行统一的策划、实施，形成统一的测试计划 、 测试报告 。4.1.2 测试准备 Test Preparation确认测试由所在

4、事业部或部门成立的独立于项目组的测试组进行(必要时，与客户一同进行)，以证明该软件满足软件需求。测试组依据项目计划实施软件测试工作。必要时（如公司不具备测试所需的特殊设备等） ，到用户现场，与客户一同参与测试活动，即将确认测试与用户测试合并进行，详见剪裁指南。当被测试软件或测试环境发生变化时，适当地进行回归测试。4.1.2.1 制定测试计划前置条件 Precondition1.确认测试已在项目计划中定义。2.确认测试负责人已在项目计划中定义。输入 Input1 经过评审并已形成基线的软件需求分析说明书2 已形成基线的项目计划3 其它支持确认测试、并通过评审的工作产品，如概要设计说明书 、 操作

5、手册等过程活动 Process activities1 软件需求分析说明书编写完成后，测试组制定测试计划(含测试用例) ，该计划中要明确操作手册 、软件系统的功能和性能作为测试项。2 软件需求分析说明书变更时，测试组修改测试计划 。3 测试计划编写完成后，应进行同行评审(必要时，用户参与)。4 测试计划通过评审后形成基线，置于配置管理之下。5 当软件需求或被测试软件更改时，相应更改测试方案。输出 Output1 通过评审并形成基线的测试计划4.1.2.2 实施测试输入 Input1 通过评审并形成基线的测试计划2 已通过综合测试且纳入基线的可执行程序3 通过评审并形成基线的操作手册过程活动 P

6、rocess activities1 依据测试计划中的测试环境要求，测试组负责完成测试环境的搭建。2 测试组依据测试计划实施测试。3 对照纳入确认测试基线的软件，对操作手册进行验证。合适时，由用户和软件维护人员对其进行评审和认可。4 测试组将操作手册 、可执行程序功能和性能的测试过程和测试结果记录在测试报告的“详细测试记录”中。5 测试完成后，测试负责人填写测试反馈单反馈给开发负责人。6 开发负责人负责将修改完成后的软件重新提交给测试组。7 测试组进行回归测试。8 以上步骤重复进行，直到发现的缺陷全部被关闭。当出现以下情况时，确认测试负责人可以终止确认测试（异常终止） 。1. 测试中发现的缺陷

7、太多；2. 软件出现缺陷，致使无法进行后续测试。输出 Output1 测试报告2 测试反馈单4.1.2.3 编写测试报告输入 Input1 测试记录单2 测试反馈单过程活动 Process activities1 测试组汇总分析操作手册 、可执行程序功能和性能的测试情况，编写测试报告(参见测试报告模板)。测试报告应包括：测试概要、实际测试与测试计划的偏差、在测试中发现的缺陷、缺陷解决后再次测试的结果，并对测试结果进行分析，重点是评价软件的能力是否达到预定目标，是否可以开始下一阶段活动，并以此判断软件是否满足需求。2 测试报告编写完成后，项目分管高层经理批准。输出 Output1. 通过评审的测

8、试报告2. 评审记录输出标准 output criteria1. 测试计划已形成基线。2. 测试报告通过评审。4.1.3 变更 Change测试方案、测试报告形成基线后，其更改（一般为当软件需求或软件设计更改时）应按照软件配置管理程序进行，并相应更新需求跟踪矩阵 。随着对软件理解的加深，如果需要对软件工作产品、计划、过程定义和活动方面进行更改时，应先分析更改对软件的影响，合适时予以采纳。当需要更改用户需求时，应先得到批准，然后再与相关小组协商对软件产品和活动作出相应更改。4.1.4 过程度量 Measurement软件测试活动中应进行的度量包括：1、 测试阶段的评审中发现的缺陷数、严重程度、缺

9、陷起源阶段； 2、 花在评审、纠正和批准各任务活动/软件工作产品上的工作量； 3、 变更各任务活动软件工作产品的规模、费用、工作量。以上数据分别体现在里程碑报告及项目状态报告中。4.1.5 验证 Verification项目分管高层经理定期通过项目周报 、 项目状态报告 、 项目月报 、重大里程碑评审来评审软件测试活动。项目经理定期通过项目例会、 项目月报 、重大里程碑评审或遇到重要需求分析问题时来评审软件测试活动。QA 人员评审和验证：1. 需要进行评审的软件工作产品，已进行了评审；2. 软件测试活动满足准备就绪准则和完成准则； 3. 软件产品符合对它们所规定的标准和要求；4. 已完成了计划

10、的测试，并记录了测试结果；5. 评审和测试发现的问题和缺陷已记录，并进行了跟踪和解决；6. 通过需求跟踪矩阵对需求进行了跟踪。4.1.6 剪裁指南 Tailoring Guideline如果公司不具备确认测试的环境或者应用户要求，需要到用户现场进行确认测试，可以将确认测试与用户测试合并进行。工作程序按用户测试程序进行。根据合同要求，如果用户测试由用户独立进行，则在用户测试活动中，测试组只需取得用户的书面测试报告；如果用户测试过程中的部分活动（如编写用户测试报告 ）由用户独立进行，则测试组仅需执行其它活动，并取得用户的书面测试报告。4.2 发布4.2.1 概述 Outline一般地，软件产品发布

11、在整个软件产品工程过程中所处的位置如下（以瀑布模型为例）：软件产品发布前要从以下三个方面验证其测试的充分性：1 测试级别：软件产品是否经过了 QMS 中规定的所有测试，即单元测试、综合测试、确认测试。2 测试策略：每个级别的测试是否都选择了合适的测试策略。3 测试覆盖率：软件测试是否达到了预定的测试覆盖率。软件产品经过确认测试、所有经过评审和测试发现的缺陷均关闭并得到验证、且各类文档和手册编写完成并通过评审后，依据配置管理计划中的约定放入受控库。此时的软件产品进入发布阶段，以“产品名称 + 产品发行版本号 + 产品发布内部版本号”的形式予以标识，如：XX 系统 2.0 Build 105。合同

12、类项目的产品发布过程通常包括：发布 版产品、发布 版产品和发布正式版产品。如下图所示：实施准备需求分析软件设计实 现确认测试方案编写手册编写综合测试方案编写产品发布综合测试确认测试产品开发类项目的产品发布过程通常包括：发布 m.n（例如：1.1）版产品、发布正式版产品。如下图所示：4.2.2 产品的对外发布（SCM AC7）当项目组要向本项目组外的个人或者组织（如：客户、培训组等）提交软件工作产品时，无论是提供给内部用户还是外部用户使用，须遵循以下发布过程。所有提交的软件工作产品无论是外部使用还是内部使用，都必须由受控库中的配置项构成。输入 Input受控库中的配置项过程活动 Process

13、activities1. 项目经理确定需要发布的产品配置项。并指定审计人员进行配置审计。2. 配置管理员根据项目经理确定的要发布的配置项填写并向 CCB 提交发布通知 。3QA 对拟发布的产品进行评价，并在发布通知上签字。4. CCB 在发布通知上签字，批准本次发布。5. 配置管理员从受控库中提取配置项，然后在产品库中建立该次发布的目录（目录名据发布通知中的约定而定） ，并将提取出来的配置项放入该目录中。6. 配置管理员（或项目经理指定的人员）将需要发布的工作产品复制到物理介质上（如：光盘、磁盘等） ，然后发布。输出 Output1. 放入产品库中的产品。2. 经 CCB 批准的发布通知 。3

14、. 放在物理介质上的需要发布的产品。4.2.3 发布中间版产品输入 Input通过确认测试的软件工作产品过程活动 Process activities1、 将经过确认测试，且验证和关闭了所有已发现缺陷的软件工作产品标识为 Build 1 版，如：XX 系统 2.0 Build 1。填写发布通知 ，并将相应产品放入产品库。2、 合同类项目需从产品库中提取要发布的产品包交付用户测试或使用，产品类项目需将产品包发送给公司内部测试。3、 用户在测试或使用过程中如果有反馈信息则按照以下过程活动处理：a. 收集、分析反馈信息客户经理、或由项目经理指定的负责人要定期的或事件驱动的收集用户测试/使用的反馈信息

15、（参见中创软件客户沟通规范 ） ，并对这些信息进行分析，提取出对软件工作产品进行变更的要求，提交给项目经理。b. 软件工作产品的变更。项目经理组织软件工程组人员对变更要求进行评估，明确需要变更的内容项、以及受影响的软件工作产品后提交 SCCB 评审，评审通过后修改相应的软件工作产品。 （参见软件配置管理程序之变更控制） 。c. 测试在项目组修改完软件工作产品后，确认测试负责人需要组织对产品中本次修改可能受影响的部分进行确认测试。d. 发布 Build n 版产品将经过确认测试，且验证和关闭了所有已发现缺陷的软件工作产品标识为 Build n 版(其中 n 为前一个 Build 号数字的递增)，

16、并放入受控库中，同时编写发布通知进行产品的发布。如：XX 系统 2.0 Build 105。从受控库中提取产品包，发送给用户测试/使用。注：对于合同类项目，如果某次发版的产品通过用户初验，则转入第二步发布 版产品；对于产品类项目，如果产品通过测试用户的测试，并且达到了预期的功能、质量要求，即可转入第三步发布正式版产品。输出 Output1、 发布通知 ；2、 评审报告 ；3、软件工作产品。输出标准 output criteria1、上述各活动中，所有经过评审和测试发现的缺陷均得到验证并关闭。2、所有对纳入基线的软件工作产品的更改都是按照软件配置管理程序进行的。4.2.4 发布正式版产品输入 I

17、nput通过用户终验（合同类项目）或经过大范围用户测试、达到了预期的功能、质量要求的产品。过程活动 Process activities1、 将通过用户终验（合同类项目）或经过大范围用户测试、达到了预期的功能、质量要求的产品标识为正式的发行版本，如：XX 系统 2.0。并放入受控库中。同时编写发布通知进行产品的发布。2、 由项目经理将受控库访问权限进行修改，使得任何人不能够再对其中的软件工作产品进行修改。3、 软件产品的升级需经过收集信息、变更、测试、发布等各步骤，参照发布 版产品中过程活动 3 步骤进行。输出 Output1、 发布通知 ；2、评审记录；3、成为正式版的软件产品。输出标准 o

18、utput criteria1、本过程活动中所涉及测试的活动中，所有经过评审和测试发现的缺陷均得到验证并关闭。2、所有对纳入基线的软件工作产品的更改都是按照软件配置管理程序进行的。4.2.5 变更 Modification过程活动 Process activities正式版形成基线后，其更改应按照软件配置管理程序进行，并相应更新需求跟踪矩阵 。更改后的发布参照上述流程进行。输出 Output形成新基线的软件产品工程各阶段产品。4.2.6 度量 Measurement发版过程中应进行的度量包括：1、评审发现的缺陷数、严重程度、缺陷起源阶段； 2、评审产品发布上的工作量。以上数据分别体现在里程碑报告及项目状态报告中。4.2.7 验证 Verification事业部高层经理定期通过项目周报 、 项目状态报告 、 项目月报 、重大里程碑评审来评审软件测试活动。项目经理定期通过项目例会、 项目月报 、重大里程碑评审或遇到重要需求分析问题时来评审软件测试活动。QA 人员评审和验证：1、 软件产品已经过评审，符合规定的标准和需求，可以发布； 2、 软件产品发布活动满足准备就绪准则和完成准则；3、 按照项目计划中的测试计划，完成所要求的测试，而且测试满足其验收准则；4、 评审和测试发现的问题和缺陷已记录，并进行了跟踪和解决； 5、 通过需求跟踪矩阵对需求进行了跟踪。