.
目的
侧重测试工作流程及规范的控制，明确产品研发的各阶段测试组应完成的工作。测试技术和策略等问题不在本文档描述范围内。
本规范作为所有测试组成员工作前必须掌握的工作规范，也供给其它部门其它组查阅参考，以便于组间的协调沟通，更好的合作完成产品的研发工作。
概念与术语
在整个产品的研发过程中，测试类型按照先后顺序主要分为：单元测试、集成测试、系统测试及产品确认，整个过程如下面的W模型所示：
设计规格 模块设计
图1
有关的测试类型的概念如下：
1）单元测试：验证产品中的模块，测试依据主要为模块详细设计或模块的需求规格。能使问题及早
走查/审核 集成测试 执行集成测试 执行系统测试 暴露，也便于问题的定位解决，单元测试属于早期测试，因而错误发现后能明确知道是某一单元产生的，单元测试允许多个被测单元的测试工作同时开展。根据公司研发流程的实际情况，此测试也可由设计研发人员执行。
2）集成测试是验证模块间接口及匹配关系，测试依据主要为概要设计。一般采用自底向上或自顶向
下的模块集成方法，逐步集成。在此环节中测试组还负责验收研发人员提供的转测试的材料，如果材料不完备，测试组可以拒绝接收。
3）系统测试是对系统的一系列的整体、有效性、可靠性的测试，测试依据主要为设计规格及产品需求规格。目的是确认产品与设计规格、需求、行业标准及公司标准的符合性，同时还要确认性能和系统的稳定性，与之前的集成测试应遵循“相同的被测对象不要做两遍相同的测试” 的基本原则。
.
.
4）除单元测试、集成测试和系统测试之外，还应有“产品确认”环节，即在客户环境中或模拟客户环境测试与验证产品，在有限的试用客户中或模拟客户环境中发现产品问题并加以妥善处理，保证产品质量，提高客户满意度。确认与实验室内部测试的区别在于：实验室内部测试要尽可能多做，多发现问题；确认要在达到质量目标的情况下尽可能少做；两者要在质量和成本之间权衡、综合考虑。
5）TD：全称Mercury TestDirector，一种测试管理工具。
6）黑盒测试：黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。
职责
角色名称 测试主管 相关主要责任 ? 组建测试小组 ? 协调测试小组内外部的沟通 ? 组织编制测试大纲（含测试用例）和计划 ? 组织测试准入检查 ? 测试过程中的进度控制、风险管理 ? 测试过程报告 ? 编写测试报告 ? 召集测试评审 测试人员 ? 识别测试需求 ? 参与编制测试大纲（含测试用例）和计划 ? 协助测试准入检查 ? 执行测试用例，测试结果记录 ? 测试缺陷记录与跟踪 ? 协助测试评审 支持人员 ? 为测试工作提供技术支持，比如环境安装、版本布署、测试工具支持等 备注：该角色可选，可根据项目实际情况设置，一般情况下由研发人员担任。 【注】：当某个项目仅有一个测试人员时，该测试人员同时也为该项目内的测试主管，需要担负起测试主
.
.
管的职责。
测试类型和测试方法
测试类型
测试工作通常分为4个类型，功能测试、联合测试、性能测试及稳定性测试。 测试类型 功能测试 测试意义 ? 确保功能符合需求定义 ? 确保所有功能可以正常完成工作 联合测试 ? 一个新产品或一个产品的新版本发布时，要确保与之相配合的产品可以正常配合使用 性能测试 稳定性测试 ? 在产品有性能要求的部分，进行性能测试和调优，确保产品性能符合需求 ? 模拟用户真正的使用情况，设计相应的测试用例，确保产品可以稳定可靠的长时间运行
测试方法
测试类型 功能测试/ 联合测试 测试方法 ? 以手工黑盒测试为主，手工执行功能测试用例。 ? 正规测试和随机测试相结合： 根据需求文档撰写测试方案及测试用例来进行常规测试，考虑到测试用例有可能写的不全面，所以在进行常规测试过程中，可以加入随机测试。同时，对预测试出来的缺陷，将其执行过程写成一个测试用例，添加到测试用例集合中，以完善测试用例； ? 采用测试工具TD进行测试用例的管理和缺陷记录、跟踪。 性能测试 ? 性能测试要求满足两种情况： 1）产品在特定工况下可以达到的最高性能（例如：测试时将日志等影响性能的选项关闭）； 2）模拟用户真正的使用环境（如：日志功能打开，在一定的用户数量的情况下）， 产品真实可以达到的性能； 稳定性测试 ? 稳定性测试要求模拟用户真正的使用情况，设计相应的测试用例，确保产品可以稳定可靠的长时间运行 .
.
【注】：黑盒测试过程的参考准则：
（1）必须采用边界值分析法；
（2）必要时采用等价类划分法补充测试用例； （3）采用错误判断法，追加测试用例；
（4）对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，
应当补充更多的测试用例；
（5）测试数据应准备充分，应采用有效数据、无效数据、边界数据分别测试验证；
工作流程、模式及规范
工作流程
测试工作可划分为三个阶段，每个阶段由不同的活动组成。 测试需求
测试计划阶段
阶段
设计测试大纲（含测试用例） DCP2 测试实施阶段
测试收尾阶段
测试提交文件及裁剪说明
必须阶段 提交文件 提交 项目组自测试需求 测试需求分析报告 否 定义 项目组自测试计划 测试大纲 是 定义 各项目组根据测试任务的规模可自定义模板 无特殊需求，可省略 模板定义 裁剪条件说明 .
.
项目组自测试计划 测试大纲计划评审记否 录 测试用例 测试用例评审记录 测试准入检查表 测试实施 测试记录 测试报告 测试报告评审记录 测试收尾 项目组自测试工作改进报告 否 定义 项目组自 测试成果提交 否 定义 是 定义 是 否 是 否 否 否 定义 如果测试大纲或设计开发计划中已包括了测试计划的内容，则本文档可省略 公司模板 各项目酌情选用 公司模板 采用公司统一测试用例模板 公司模板 各项目酌情选用 公司模板 各项目酌情选用 项目组自各项目组根据测试任务的规模可自定义模板 公司模板 采用公司统一测试报告模板 公司模板 各项目酌情选用 各项目酌情选用 各项目酌情选用 评审点
评审点定义参照《设计开发控制程序》。
敏捷测试模式 敏捷测试概念
敏捷测试即是不断修正质量指标，正确建立测试策略，确认客户的有效需求得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。
敏捷增量测试方法
测试是敏捷开发过程重要的环节，自始自终测试贯穿于每个迭代。整个产品的敏捷开发生命周期可以分为 4 个阶段，即初始阶段，项目的建设阶段，产品发布阶段和产品的维护阶段，在关键的项目建设阶段中，测试被分成两个部分，验证测试和系统测试。 验证测试：静态测试和关键的功能测试。
.
测试流程及规范
