测试流程及规范(修复的)

《测试流程及规范(修复的)》由会员分享，可在线阅读，更多相关《测试流程及规范(修复的)（21页珍藏版）》请在金锄头文库上搜索。

1、文件名称 测试流程及规范文件编号文件版本受控标识处1、 电子文件受控以实时查阅“数据中心”实现；2、 纸质文件受控以主管部门加盖“受控”印章实现。1 目的侧重测试工作流程及规范的控制，明确产品研发的各阶段测试组应完成的工作。测试技术和策略等问题不在本文档描述范围内。本规范作为所有测试组成员工作前必须掌握的工作规范，也供给其它部门其它组查阅参考，以便于组间的协调沟通，更好的合作完成产品的研发工作。2 概念与术语在整个产品的研发过程中，测试类型按照先后顺序主要分为：单元测试、集成测试、系统测试及产品确认，整个过程如下面的 W 模型所示：图 1有关的测试类型的概念如下：1）单元测试：验证产品中的模块

2、，测试依据主要为模块详细设计或模块的需求规格。能使问题及早暴露，也便于问题的定位解决，单元测试属于早期测试，因而错误发现后能明确知道是某一单元产生的，单元测试允许多个被测单元的测试工作同时开展。根据公司研发流程的实际情况，此测试也可由设计研发人员执行。2）集成测试是验证模块间接口及匹配关系，测试依据主要为概要设计。一般采用自底向上或自顶向下的模块集成方法，逐步集成。在此环节中测试组还负责验收研发人员提供的转测试的材料，如果材料不完备，测试组可以拒绝接收。3）系统测试是对系统的一系列的整体、有效性、可靠性的测试，测试依据主要为设计规格及产品需求规格。目的是确认产品与设计规格、需求、行业标准及公司

3、标准的符合性，同时还要确认性能和系统设计规格模块设计集成测试系统测试产品确认N概要设计需求规格单元测试三绘图/编码测试需求测试计划测试计划测试大纲走查/审核 执行单元测试执行集成测试 执行系统测试 产品试用文件名称 测试流程及规范文件编号文件版本受控标识处1、 电子文件受控以实时查阅“数据中心”实现；2、 纸质文件受控以主管部门加盖“受控”印章实现。的稳定性，与之前的集成测试应遵循“相同的被测对象不要做两遍相同的测试” 的基本原则。4）除单元测试、集成测试和系统测试之外，还应有“产品确认”环节，即在客户环境中或模拟客户环境测试与验证产品，在有限的试用客户中或模拟客户环境中发现产品问题并加以妥善

4、处理，保证产品质量，提高客户满意度。确认与实验室内部测试的区别在于：实验室内部测试要尽可能多做，多发现问题；确认要在达到质量目标的情况下尽可能少做；两者要在质量和成本之间权衡、综合考虑。5）TD：全称 Mercury TestDirector，一种测试管理工具。6）黑盒测试：黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件

5、界面和软件功能进行测试。黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。3 职责角色名称 相关主要责任测试主管 组建测试小组 协调测试小组内外部的沟通 组织编制测试大纲（含测试用例）和计划 组织测试准入检查 测试过程中的进度控制、风险管理 测试过程报告 编写测试报告 召集测试评审测试人员 识别测试需求 参与编制测试大纲（含测试用例）和计划 协助测试准入检查 执行测试用例，测试结果记录 测试缺陷记录与跟踪 协助测试评审支持人员 为测试工作提供技术支持，比如环境安装、版本布署、测试工具支持等文件名称 测试流程及规范文件编号文件版本受控标识处1、 电子文件受控以实时查阅“数据中

6、心”实现；2、 纸质文件受控以主管部门加盖“受控”印章实现。备注：该角色可选，可根据项目实际情况设置，一般情况下由研发人员担任。【注】：当某个项目仅有一个测试人员时，该测试人员同时也为该项目内的测试主管，需要担负起测试主管的职责。4 测试类型和测试方法4.1 测试类型测试工作通常分为 4 个类型，功能测试、联合测试、性能测试及稳定性测试。测试类型 测试意义功能测试 确保功能符合需求定义 确保所有功能可以正常完成工作联合测试 一个新产品或一个产品的新版本发布时，要确保与之相配合的产品可以正常配合使用性能测试 在产品有性能要求的部分，进行性能测试和调优，确保产品性能符合需求稳定性测试 模拟用户真正

7、的使用情况，设计相应的测试用例，确保产品可以稳定可靠的长时间运行4.2 测试方法测试类型 测试方法功能测试/联合测试 以手工黑盒测试为主，手工执行功能测试用例。 正规测试和随机测试相结合：根据需求文档撰写测试方案及测试用例来进行常规测试，考虑到测试用例有可能写的不全面，所以在进行常规测试过程中，可以加入随机测试。同时，对预测试出来的缺陷，将其执行过程写成一个测试用例，添加到测试用例集合中，以完善测试用例； 采用测试工具 TD 进行测试用例的管理和缺陷记录、跟踪。性能测试 性能测试要求满足两种情况：1）产品在特定工况下可以达到的最高性能（例如：测试时将日志等影响性能的选项关闭） ；2）模拟用户真

8、正的使用环境（如：日志功能打开，在一定的用户数量的情况下） ，文件名称 测试流程及规范文件编号文件版本受控标识处1、 电子文件受控以实时查阅“数据中心”实现；2、 纸质文件受控以主管部门加盖“受控”印章实现。产品真实可以达到的性能；稳定性测试 稳定性测试要求模拟用户真正的使用情况，设计相应的测试用例，确保产品可以稳定可靠的长时间运行【注】：黑盒测试过程的参考准则：（1）必须采用边界值分析法；（2）必要时采用等价类划分法补充测试用例；（3）采用错误判断法，追加测试用例；（4）对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当补充更多的测试用例；（5）测试数据应准

9、备充分，应采用有效数据、无效数据、边界数据分别测试验证；5 工作流程、模式及规范5.1 工作流程测试工作可划分为三个阶段，每个阶段由不同的活动组成。测试需求阶段测试计划阶段 测试实施阶段 测试收尾阶段5.2 测试提交文件及裁剪说明阶段 提交文件必须提交模板定义 裁剪条件说明测试准入检查 测试成果提交DCP2编写测试报告测试需求分析缺陷管理执行测试用例设计测试大纲（含测试用例）成立测试小组编制测试计划TR5测试工作改进文件名称 测试流程及规范文件编号文件版本受控标识处1、 电子文件受控以实时查阅“数据中心”实现；2、 纸质文件受控以主管部门加盖“受控”印章实现。测试需求 测试需求分析报告 否项目

10、组自定义无特殊需求，可省略测试大纲 是项目组自定义各项目组根据测试任务的规模可自定义模板测试计划 否项目组自定义如果测试大纲或设计开发计划中已包括了测试计划的内容，则本文档可省略测试大纲计划评审记录否 公司模板 各项目酌情选用测试用例 是 公司模板 采用公司统一测试用例模板测试计划测试用例评审记录 否 公司模板 各项目酌情选用测试准入检查表 否 公司模板 各项目酌情选用测试实施测试记录 是项目组自定义各项目组根据测试任务的规模可自定义模板测试报告 是 公司模板 采用公司统一测试报告模板测试报告评审记录 否 公司模板 各项目酌情选用测试收尾测试工作改进报告 否项目组自定义各项目酌情选用测试成果提

11、交 否项目组自定义各项目酌情选用5.3 评审点评审点定义参照设计开发控制程序 。5.4 敏捷测试模式5.4.1 敏捷测试概念敏捷测试即是不断修正质量指标，正确建立测试策略，确认客户的有效需求得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。5.4.2 敏捷增量测试方法测试是敏捷开发过程重要的环节，自始自终测试贯穿于每个迭代。整个产品的敏捷开发生命周期可文件名称 测试流程及规范文件编号文件版本受控标识处1、 电子文件受控以实时查阅“数据中心”实现；2、 纸质文件受控以主管部门加盖“受控”印章实现。以分为 4 个阶段，即初始阶段，项目的建设阶段，产品发布阶段和产品的维护阶段，在关键的项目

12、建设阶段中，测试被分成两个部分，验证测试和系统测试。验证测试：静态测试和关键的功能测试。系统测试：功能测试、联合测试、性能测试、稳定性测试。5.4.3 敏捷测试流程敏捷测试流程依据业务场景制定测试策略。在每次敏捷测试的过程中包括验证测试和联合测试。并且不断的进行迭代测试。在系统的所有业务场景都经过敏捷测试过后，进入系统测试阶段。进行所有业务场景的功能测试、联合测试、性能测试、稳定性测试。根据业务场景制定测试策略流程图产品业务场景一 业务场景二 。 。 。 。 。 。 业务场景 N模块一 模块二 模块三三。 。 。 。 。 。 模块 N模块四三业务场景一缺陷管理业务场景三TR5业务场景二TR5业

13、务场景 NTR5业务场景四TR5文件名称 测试流程及规范文件编号文件版本受控标识处1、 电子文件受控以实时查阅“数据中心”实现；2、 纸质文件受控以主管部门加盖“受控”印章实现。敏捷测试流程图测试传递项报告敏捷测试测试总结测试通过进入下一次敏捷迭代测试计划提交测试NYYN满足准入条件系统测试条件Y软件测试总结软件评估满足发布条件产品发布测试案例维护系统测试和回归测试测试是否通过YY根据缺陷性质来判断更新提交测试的依据：1） 严重级别为 Urgent 和 High 的修改后立即更新，要保证更新后不能影响其他功能测试。2） 功能级别为 Medium 以下的可以等待下一次提交敏捷测试的时候更新。文件

14、名称 测试流程及规范文件编号文件版本受控标识处1、 电子文件受控以实时查阅“数据中心”实现；2、 纸质文件受控以主管部门加盖“受控”印章实现。5.5 传统瀑布模式5.5.1 测试需求分析过程要点 详细说明启动条件 需求阶段的工作启动工作内容 由测试主管根据项目任务复杂程度组织或指定测试人员进行测试需求分析，从客户角度考虑软件测试需要达到的验证状态，并确定是否要形成测试需求分析报告结束条件 需求分析完成例外 对于简单设计更改、衍生产品等只需例行测试的，可不进行测试需求分析责任人 项目经理参与人 测试主管5.5.2 成立测试小组或确认测试人员过程要点 详细说明启动条件 测试任务明确，前期工作启动工

15、作内容 确认项目的测试人员，若整个项目的测试需要若干个测试人员，则需要成立一个测试小组； 为测试小组任命一名测试主管，若只有一个测试人员，则该测试人员同时也为该测试组的测试主管，同时确定测试小组的其它构成人选； 小组内进行必要的培训。结束条件 测试小组成立例外 若以前的测试任务已成立过测试小组，则可以复用以前的组织人员和形式责任人 项目经理参与人 测试主管5.5.3 编制测试计划过程要点 详细说明启动条件项目阶段性计划确定需求规格说明书、详细设计说明书等已评审文件名称 测试流程及规范文件编号文件版本受控标识处1、 电子文件受控以实时查阅“数据中心”实现；2、 纸质文件受控以主管部门加盖“受控”印章实现。工作内容测试大纲至少包括以下关键内容： 测试目标对本次测试的要求和要达到的目标 测试范围需要测试小组测试的范围，和各个测试需求的测试优先级 工作分工明确测试小组内部及外部配合方的相关责任和工作关系 测试策略整体测试的总体测试策略、环境、方法和工具等 完成标准达到何种条件可以认为测试完成 交付文件测试完成时应提交的文件，比如测试大纲（含测试用例） 、测试报告等等测试计划至少应包括以下关键内容： 主要任务每项任务的时间计划、前置条件及资源 主要里程碑关键任务及