测试流程及规范讲解.doc

目的 侧重测试工作流程及规范的控制，明确产品研发的各阶段测试组应完成的工作。测试技术和策略等问题不在本文档描述范围内。 本规范作为所有测试组成员工作前必须掌握的工作规范，也供给其它部门其它组查阅参考，以便于组间的协调沟通，更好的合作完成产品的研发工作。 概念与术语 在整个产品的研发过程中，测试类型按照先后顺序主要分为：单元测试、集成测试、系统测试及产品确认，整个过程如下面的W模型所示： 图1 有关的测试类型的概念如下： 1）单元测试：验证。 功能测试/ 联合测试 以手工黑盒测试为主，手工执行功能测试用例。 正规测试和随机测试相结合： 根据需求文档撰写测试方案及测试用例来进行常规测试，考虑到测试用例有可能写的不全面，所以在进行常规测试过程中，可以加入随机测试。同时，对预测试出来的缺陷，将其执行过程写成一个测试用例，添加到测试用例集合中，以完善测试用例； 采用测试工具TD进行测试用例的管理和缺陷记录、跟踪。 性能测试 性能测试要求满足两种情况： 1）产品在特定工况下可以达到的最高性能（例如：测试时将日志等影响性能的选项关闭）； 2）模拟用户真正的使用环境（如：日志功能打开，在一定的用户数量的情况下）， 产品真实可以达到的性能； 稳定性测试 稳定性测试要求模拟用户真正的使用情况，设计相应的测试用例，确保产品可以稳定可靠的长时间运行 【注】：黑盒测试过程的参考准则： （1）必须采用边界值分析法； （2）必要时采用等价类划分法补充测试用例； （3）采用错误判断法，追加测试用例； （4）对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当补充更多的测试用例； （5）测试数据应准备充分，应采用有效数据、无效数据、边界数据分别测试验证； 工作流程、模式及规范 测试提交文件及裁剪说明 阶段 提交文件 必须提交 模板定义 裁剪条件说明 测试需求 测试需求分析报告 否 项目组自定义 无特殊需求，可省略 测试计划 测试大纲 是 项目组自定义 各项目组根据测试任务的规模可自定义模板 测试计划 否 项目组自定义 如果测试大纲或设计开发计划中已包括了测试计划的内容，则本文档可省略 测试大纲计划评审记录 否 公司模板 各项目酌情选用 测试用例 是 公司模板 采用公司统一测试用例模板 测试用例评审记录 否 公司模板 各项目酌情选用 测试实施 测试准入检查表 否 公司模板 各项目酌情选用 测试记录 是 项目组自定义 各项目组根据测试任务的规模可自定义模板 测试收尾 测试报告 是 公司模板 采用公司统一测试报告模板 测试报告评审记录 否 公司模板 各项目酌情选用 测试工作改进报告 否 项目组自定义 各项目酌情选用 测试成果提交 否 项目组自定义 各项目酌情选用 评审点 评审点定义参照《设计开发控制程序》。 敏捷测试模式 敏捷测试概念 敏捷测试即是不断修正质量指标，正确建立测试策略，确认客户的有效需求得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。 敏捷增量测试方法 测试是敏捷开发过程重要的环节，自始自终测试贯穿于每个迭代。整个产品的敏捷开发生命周期可以分为 4 个阶段，即初始阶段，项目的建设阶段，产品发布阶段和产品的维护阶段，在关键的项目建设阶段中，测试被分成两个部分，验证测试和系统测试。 验证测试：静态测试和关键的功能测试。 系统测试：功能测试、联合测试、性能测试、稳定性测试。 敏捷测试流程 敏捷测试流程依据业务场景制定测试策略。在每次敏捷测试的过程中包括验证测试和联合测试。并且不断的进行迭代测试。在系统的所有业务场景都经过敏捷测试过后，进入系统测试阶段。进行所有业务场景的功能测试、联合测试、性能测试、稳定性测试。 根据业务场景制定测试策略流程图 敏捷测试流程图 根据缺陷性质来判断更新提交测试的依据： 严重级别为Urgent和High的修改后立即更新，要保证更新后不能影响其他功能测试。 功能级别为Medium以下的可以等待下一次提交敏捷测试的时候更新。 传统瀑布模式 测试需求分析 过程要点 详细说明 启动条件 需求阶段的工作启动 工作内容 由测试主管根据项目任务复杂程度组织或指定测试人员进行测试需求分析，从客户角度考虑软件测试需要达到的验证状态，并确定是否要形成测试需求分析报告 结束条件 需求分析完成 例外 对于简单设计更改、衍生产品等只需例行测试的，可不进行测试需求分析 责任人 项目经理 参与人 测试主管 成立测试小组或确认测试人员 过程要点 详细说明 启动条件 测试任务明确，前期工作启动 工作内容 确认项目的测试人员，若整个项目的测试需要若干个测试人员，则需要成立一个测试小组； 为测试小组任命一名测试主