测试过程管理
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• 不测的特性（ Features not to be tested ）
在某些情况下，你知道某些需要测试的特性现在还不能测试，在此 一一列出。
• 方法与步骤（ Approach ）
说明整体的方法或步骤，指出用于测试每个特性组的主要活动、技 术和工具。这里要作到足够详尽，以能够确定主要的测试任务， 并能估计出每项照此作法所需的时间。说明想要的可理解度的最 低要求。确定衡量测试工作的可理解度的技术。确定测试的重要 约束条件，如测试条目的有效性、测试资源可用性、最后时限。
如果有以下材料的话，请提供参考资料： 需求说明书、设计说明书、用户指南、操作指南、安装指南、 问题登记指南、测试外的其它各项。
• 要测的特性（ Features to be tested ）
确定要测试的所有方面的特点。例如性能、移置性、或功能性。 确定与各项性能关联的测试设计规格。
测试计划模板 IEEE829 - 1998
确定测试计划中的可能的高风险，并说明各种意外事故 的应对计划。
• 审批（ Approvals ）。
标识出所有必须同意这个计划的人员的姓名和职务。
软件测试计划模板
• GB-T8567-2006 • 一个经典测试计划模版
计划测试工作
• 测试计划的主题
测试计划文档只是创建详细计划过程的一个副产品，重要的是计划 过程，而不是产生的结果文档。 测试过程的最终目标是交流（而不是记录）测试小组的意图、期望， 以及对将要执行的测试任务的理解。 因此，在测试计划中，要遵循一系列重要主题，这些主题应在整个 项目小组中全面讨论，相互沟通并达成一致。 1、高级期望
建立全面的测试计划，应由测试负责人或测试经 理来做，而测试员是协助建立测试计划。 – 测试计划的目标 – 测试计划模板 – 测试计划的主题
计划测试工作
• 测试计划的目标
软件测试计划（Software Test Plan）是软件测试员与 产品开发小组交流意图的主要方式。 IEEE829-1998关于软件测试文档（software test document）的标准以如下方式表达软件测试计划 的目的：
• 责任和角色（ Responsibilities ）
确定各个不同测试活动小组的责任，如管理、设计、开发、建造、 执行、验证、问题登记以及问题解决。这些小组将包括系统管理 员、开发者、质量保证员、测试分析人员、实际系统用户、帮助 文书员、项目经理人员以及小组长。
测试计划模板 IEEE829 - 1998
规定测试活动的范围、方法、资源和进度；明确正 在测试的项目、要测试的特性，要执行的测试任务、 每个任务的负责人，ቤተ መጻሕፍቲ ባይዱ及与计划相关的风险。 测试计划采用的形式是书面文档。
测试计划模板
• IEEE829
A test plan shall have the following structure: a) Test plan identiÞer; b) Introduction; c) Test items; d) Features to be tested; e) Features not to be tested; f) Approach; g) Item pass/fail criteria; h) Suspension criteria and resumption requirements; i) Test deliverables; j) Testing tasks; k) Environmental needs; l) Responsibilities; m) StafÞng and training needs; n) Schedule; o) Risks and contingencies; p) Approvals.
• “通过/失败”的准则（ Item pass/fail criteria ）
说明用于确定每个条目测试是否通过或失败的准则。
• 测试中止的标准和恢复的条件（ Suspension criteria and resumption requirements ）
说明全部或计划中所列各部分测试活动中止及重启的条件，指出那 些必须重复的测试活动。
• 人员配备和必要的培训（ StafÞng and training needs ）。
确定根据技能水平所需的测试人员配备，以及执行测试 任务所需的培训。
• 时间计划安排（ Schedule ）。
应包括项目计划里确定的各个转折点(Fixpoint/Milestone).
• 风险和意外处理（ Risks and contingencies ）。
测试计划模板 IEEE829 - 1998
• 测试的交付（ Test deliverables ）
确定下要提交的文档，可能包括： 测试计划、测试设计说明书、测试用例说明书、测试流程说明书、 测试项目传输报告、测试记录、测试事件报告、测试汇总报告、 测试输入数据和测试输出数据、测试工具。
• 测试任务（ Testing tasks ）
测试过程管理
测试过程管理
• 测试过程管理
软件测试员的目标：尽可能早地找出软件缺陷， 并保证其得以修复。 因此，为更有可能达到目标，应精心组织测试计 划、测试用例和测试报告，对测试工作进行正 确的记录以及交流。 – 计划测试工作 – 编写、执行和跟踪测试用例 – 报告发现的问题
计划测试工作
• 计划测试工作
测试计划模板 IEEE829 - 1998
• 测试计划标识（ Test plan identiÞer ）
说明赋予该测试文档的唯一编号。
• 背景介绍（ Introduction ）
概述软件背景资料，及要测试的该软件的事项及性能。可以包 括必要的各项目及其历史，以及与之相关的其它计划的参考 材料。
• 测试项目（ Test items ）
确定出需准备并执行的测试一系列任务，标识出所有任务间的依赖 性和所需的特殊技能。
• 需要的环境（ Environmental needs ）
说明测试环境的必需资源、及必要的道具。这些应包括：硬件、通 讯、系统软件、独立平台或局域网，及任何其他需要的专用软件， 如用于侵蚀控制软件的 DOS 下的 KERMIT 工具。
在某些情况下，你知道某些需要测试的特性现在还不能测试，在此 一一列出。
• 方法与步骤（ Approach ）
说明整体的方法或步骤，指出用于测试每个特性组的主要活动、技 术和工具。这里要作到足够详尽，以能够确定主要的测试任务， 并能估计出每项照此作法所需的时间。说明想要的可理解度的最 低要求。确定衡量测试工作的可理解度的技术。确定测试的重要 约束条件，如测试条目的有效性、测试资源可用性、最后时限。
如果有以下材料的话，请提供参考资料： 需求说明书、设计说明书、用户指南、操作指南、安装指南、 问题登记指南、测试外的其它各项。
• 要测的特性（ Features to be tested ）
确定要测试的所有方面的特点。例如性能、移置性、或功能性。 确定与各项性能关联的测试设计规格。
测试计划模板 IEEE829 - 1998
确定测试计划中的可能的高风险，并说明各种意外事故 的应对计划。
• 审批（ Approvals ）。
标识出所有必须同意这个计划的人员的姓名和职务。
软件测试计划模板
• GB-T8567-2006 • 一个经典测试计划模版
计划测试工作
• 测试计划的主题
测试计划文档只是创建详细计划过程的一个副产品，重要的是计划 过程，而不是产生的结果文档。 测试过程的最终目标是交流（而不是记录）测试小组的意图、期望， 以及对将要执行的测试任务的理解。 因此，在测试计划中，要遵循一系列重要主题，这些主题应在整个 项目小组中全面讨论，相互沟通并达成一致。 1、高级期望
建立全面的测试计划，应由测试负责人或测试经 理来做，而测试员是协助建立测试计划。 – 测试计划的目标 – 测试计划模板 – 测试计划的主题
计划测试工作
• 测试计划的目标
软件测试计划（Software Test Plan）是软件测试员与 产品开发小组交流意图的主要方式。 IEEE829-1998关于软件测试文档（software test document）的标准以如下方式表达软件测试计划 的目的：
• 责任和角色（ Responsibilities ）
确定各个不同测试活动小组的责任，如管理、设计、开发、建造、 执行、验证、问题登记以及问题解决。这些小组将包括系统管理 员、开发者、质量保证员、测试分析人员、实际系统用户、帮助 文书员、项目经理人员以及小组长。
测试计划模板 IEEE829 - 1998
规定测试活动的范围、方法、资源和进度；明确正 在测试的项目、要测试的特性，要执行的测试任务、 每个任务的负责人，ቤተ መጻሕፍቲ ባይዱ及与计划相关的风险。 测试计划采用的形式是书面文档。
测试计划模板
• IEEE829
A test plan shall have the following structure: a) Test plan identiÞer; b) Introduction; c) Test items; d) Features to be tested; e) Features not to be tested; f) Approach; g) Item pass/fail criteria; h) Suspension criteria and resumption requirements; i) Test deliverables; j) Testing tasks; k) Environmental needs; l) Responsibilities; m) StafÞng and training needs; n) Schedule; o) Risks and contingencies; p) Approvals.
• “通过/失败”的准则（ Item pass/fail criteria ）
说明用于确定每个条目测试是否通过或失败的准则。
• 测试中止的标准和恢复的条件（ Suspension criteria and resumption requirements ）
说明全部或计划中所列各部分测试活动中止及重启的条件，指出那 些必须重复的测试活动。
• 人员配备和必要的培训（ StafÞng and training needs ）。
确定根据技能水平所需的测试人员配备，以及执行测试 任务所需的培训。
• 时间计划安排（ Schedule ）。
应包括项目计划里确定的各个转折点(Fixpoint/Milestone).
• 风险和意外处理（ Risks and contingencies ）。
测试计划模板 IEEE829 - 1998
• 测试的交付（ Test deliverables ）
确定下要提交的文档，可能包括： 测试计划、测试设计说明书、测试用例说明书、测试流程说明书、 测试项目传输报告、测试记录、测试事件报告、测试汇总报告、 测试输入数据和测试输出数据、测试工具。
• 测试任务（ Testing tasks ）
测试过程管理
测试过程管理
• 测试过程管理
软件测试员的目标：尽可能早地找出软件缺陷， 并保证其得以修复。 因此，为更有可能达到目标，应精心组织测试计 划、测试用例和测试报告，对测试工作进行正 确的记录以及交流。 – 计划测试工作 – 编写、执行和跟踪测试用例 – 报告发现的问题
计划测试工作
• 计划测试工作
测试计划模板 IEEE829 - 1998
• 测试计划标识（ Test plan identiÞer ）
说明赋予该测试文档的唯一编号。
• 背景介绍（ Introduction ）
概述软件背景资料，及要测试的该软件的事项及性能。可以包 括必要的各项目及其历史，以及与之相关的其它计划的参考 材料。
• 测试项目（ Test items ）
确定出需准备并执行的测试一系列任务，标识出所有任务间的依赖 性和所需的特殊技能。
• 需要的环境（ Environmental needs ）
说明测试环境的必需资源、及必要的道具。这些应包括：硬件、通 讯、系统软件、独立平台或局域网，及任何其他需要的专用软件， 如用于侵蚀控制软件的 DOS 下的 KERMIT 工具。