功能测试指南0.1--高.docVIP

功能测试指南 测试组 2011年10月  修订历史记录 日期 描述 作者 版本 2011.10 初稿 张林丰 V0.1 目录 1. 概述 5 2. 适用范围 5 3. 功能测试流程概述 5 4. 测试需求分析指南 5 4.1. 接收测试任务 5 4.2. 提取测试需求 6 4.3. 评审测试需求 6 5. 测试计划制订指南 7 5.1. 预估测试工作量 7 5.2. 获取版本发布信息 8 5.3. 明确测试环境与工具 8 5.4. 制定测试策略 9 5.5. 预估项目风险 10 5.6. 编写测试方案 10 5.7. 评审测试方案 10 6. 测试用例设计指南 11 6.1 理解需求的实现方式 11 6.2 编写测试用例 11 6.3 评审测试用例 12 6.4 维护测试用例 12 6.5 建设测试用例库 12 7. 测试用例执行指南 13 7.1. 进行测试准备 13 7.2. 实施冒烟测试 14 7.3. 检查进入标准 14 7.4. 执行测试用例 15 7.5. 记录测试结果 15 7.6. 报告测试结果 15 7.7. 实施回归测试 15 7.8. 检测准出标准 16 8. 测试缺陷跟踪指南 16 8.1. 提交测试缺陷 16 8.2. 跟踪缺陷扭转 17 9. 测试总结编写指南 18 10.1. 收集测试数据 18 10.2. 分析测试结果 18 10.3. 编写测试总结 18 10.4. 评审测试总结 19 10.5. 回顾测试过程 19 10.6. 整理项目资产 19 10. 其他 19 10.1. 功能测试产出物 19 10.2. 功能测试流程图 19  概述 本文档为测试组新增测试人员尽快熟悉项目的功能测试工作流程，快速并更好的完成功能测试工作而编写，同时为已有测试人员的日常操作提供依据。 适用范围 本文档适用于保险行业协会车险信息平台测试组系统测试阶段的功能测试过程。 系统测试的目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。测试中应尽可能发现系统中存在的隐藏缺陷。 本文档适用于新建类项目或维护类项目的功能测试过程。其中，维护类项目指针对目前已建的车险信息平台中有GUI界面的几个系统，如“查询统计子系统”、“数据维护子系统”、“电子联系单子系统”等系统，在进行业务功能或流程的改造或更新后所进行的功能检测。 功能测试流程概述 功能测试工作主要分为以下五个阶段的工作。本文主要以运维类测试工作为例，分别说明这五个阶段的具体工作规程和方法。 测试需求分析指南 接收测试任务 测试工作第一步，接收测试任务。测试任务一般由平台项目组派发。当平台项目组确定新上线版本的更新内容后，对于从需求联系单获取的业务需求，项目组将提供相关的需求规格说明书给测试组；对于开发组对系统的优化内容，开发组将提供相关的调整方案文档；或均称为需求规格说明书。文档的标题如：《2011-业务-00031-【福建】【电子联系单】需求规格说明书（新增：违规情况选项）.doc》或《行业车险信息集中平台-交强商业-保存历史保单匹配规则-调整方案》等。 提取测试需求 测试人员阅读理解《需求规格说明书》或《调整方案》，进行测试需求的提取。必要时，测试人员需要主动与相关的业务人员或开发人员沟通交流，以理解与明确相关需求。 测试需求并不等同于软件需求，它是以测试的观点根据软件需求整理出来的。测试需求分析是测试活动的起点，也是测试计划的基础与重点，为测试工作是否完成提供了一个可供衡量的标准。另外，测试需求也是测试人员进行测试用例设计和考虑测试覆盖的依据。因此测试人员必须关注这一阶段的工作。测试需求分析中需要注意的是： 一个测试需求应明确的描述一项需要测试的内容，即对于多项测试内容，应尽可能的剥离开来，保证一个测试需求只包含一项测试内容； 通常测试需求对应的需求来源包括客户已明确的，实际可行的解决方案，还包括客户没有明确的内容，即显性需求和隐形需求； 在提取测试需求后，将得到测试需求列表（清单）。 例如：通过《2011-业务-00031-【福建】【电子联系单】需求规格说明书（新增：违规情况选项）.doc》的分析理解，得到如下的测试需求清单： 另外，当《需求规格说明书》或《调整方案》描述不够详细、完整或有相关的对理解需求有帮助的文档时，为了更好的完成测试任务，测试组需要向项目组提出相关文档的请求。 评审测试需求 根据测试版本的复杂程度、重要程度、规模等，测试需求的评审可采用正式评审或非正式评审的方式；可以采用测试组内部评审与外部评审相结合的方式。对于新建类项目的测试或规模比较大的运维类测试，一般在测试需求分析完成后即展开评审，并在评审后根据评审意见进行相关修改；对于规模较小的运