制定测试计划

本文深入探讨了测试计划制定的关键步骤,包括需求评估、风险分析与策略规划。通过复审材料确定测试需求,评估风险以优化测试效率,制定策略以确保产品质量。本指南详细阐述了每一步骤的具体操作与注意事项,帮助测试设计员高效执行测试计划。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

http://ir.hit.edu.cn/~car/programming/rup/process/activity/ac_pltst.htm#Identify Requirements for Test

确定测试需求 返回页首

目的
  • 确定测试对象并指明测试范围。
工具向导:

确定测试需求是测试计划活动的开始。测试需求确定测试对象以及测试工作的范围和作用。测试需求还用来确定整个测试工作(如安排时间表、测试设计等)并作为测试覆盖的基础。

被确定的测试需求项必须是可核实的。 即,它们必须有一个可观察、可评测的结果。无法核实的需求不是测试需求。

执行如下步骤确定测试需求:

复审所有材料。

由于测试需求可从多种来源确定,因此作为第一步,对将要开发的应用程序/系统的所有可用材料进行复审是十分重要的。最常用的测试需求来源包括现有的需求列表、用例、用例模型、用例实现、补充规约、设计需求、商业理由、最终用户访谈以及对现有系统的复审。

指明测试需求。

除确定测试需求的来源之外,还必须有某种形式的确定方法来确定将成为测试目标的需求。 这将导致测试需求层次的产生。该层次可能基于现有的层次结构,也可能是新近生成的。层次结构是测试需求的逻辑分组。常用分组方法包括按照用例、商业理由、测试类型(功能、性能等)或者以上各项的组合对项目进行分组。

本步骤产生的结果是一份确定将成为测试目标的需求的报告(层次结构)。

请参见指南:测试计划以获取更多的关于确定测试需求的信息。

评估风险 返回页首

目的
  • 最大限度地提高测试效率并确定测试工作的优先级。
  • 制定一个可接受的测试顺序。
工具向导:

要获得对风险的认识,请执行如下操作:

确定并验证测试风险因子

测试工作需要平衡资源约束和风险。最重要的测试需求能够反映最高的风险。

可从以下几个方面观察风险:

  • 效果 - 用例(需求等)失效造成的影响或后果
  • 原因 - 确定不合需要的结果,并确定哪些用例或需求一旦失效将产生该结果
  • 可能性 - 用例或需求失效的概率

复审每一项测试需求并确定风险因子(比如高、中或低)。有时从两个或更多方面对风险进行评估可能会得到不同的风险因子。在这种情况下,请使用最高的风险因子值。同时还应给出关于对某一给定测试需求为何选择特定风险因子的说明。

确定并验证测试的实施概要因子

大多数应用程序都有某些功能是经常使用的,而另外一些则是较少使用的。因此要对应用程序进行合理的测试,必须确保不仅测试具有最高风险的测试需求,而且还应测试经常使用的功能(因为这些功能通常是最终用户最频繁使用的)。

确定每一个测试需求的实施概要因子,并说明为什么确定特定因子值的原因。这可通过复审商业理由或者同最终用户及其经理访谈来完成。另一种方法是观察最终用户与系统的交互行为或者使用监视/记录软件来记录最终用户与系统的交互行为(供分析用)。

确定并验证测试优先级因子

在确定和验证每一个测试需求的测试风险和实施概要之后,就应该确定和验证测试优先级因子。测试优先级因子确定测试需求的相对重要性以及测试其的顺序或时序。

测试优先级因子通过利用风险因子、实施概要、合同义务、其他约束或者它们的组合来确定。 在确定测试优先级时,考虑所有的因素十分重要,这样可以确保测试适当而有重点。

请参见指南:测试计划以获取关于评估风险和确定测试优先级的详细信息。

制定测试策略 返回页首

目的
  • 确定并传达测试手段和工具
  • 确定并传达用于确定产品质量和测试是否完成的评估方法

测试策略的目的是向每一个人传达如何进行测试以及采用何种评测标准来确定测试的完成和成功程度。策略不必十分详尽,但它应该向读者指明如何进行测试。

制定测试策略包括:

确定和描述测试方法

测试方法是对如何实施测试的说明(陈述)。它应该说明或指出测试对象、测试时采取的主要操作以及如何核实结果等。说明应该为读者提供足够的信息以便他们能够理解测试的对象(尽管尚不了解测试深度),如以下说明陈述:

  • 对于每一个用例,确定并执行测试用例,包括有效和无效的输入数据。
  • 对于每一个用例都将设计和开发测试流程。
  • 利用三个月的时间来实施测试过程以模拟客户账号管理。测试过程包括添加、修改和删除账号以及客户。
  • 实施测试过程并通过 1500 个虚拟用户来执行测试脚本,每个用户都执行功能 A、B 和 C,并且使用不同的输入数据。
确定测试标准

测试标准是关于测试的客观说明,它指明那些用于确定/识别测试完成时间的值和被测试应用程序质量。测试标准可能包括一系列说明或对其他文档(比如方法指南或测试标准等)的引用。测试标准应确定:

  • 测试对象(具体测试目标)
  • 评测方法
  • 评估评测方法所采用的标准

测试标准示例:

对于每一高优先级用例:

  • 所有计划好的测试用例和测试过程已被执行。
  • 所有确定的缺陷已被解决。
  • 所有计划好的测试用例和测试过程已被重新执行并且没有发现新的缺陷。

在上例中,“对于每一高优先级用例”说明测试对象。“所有计划好的测试用例和测试过程已被执行”说明评测的方法。评估标准包含在最后两个陈述“所有确定的缺陷已被解决”和“所有计划好的测试用例和测试过程已被重新执行并且没有发现新的缺陷”之中。

确定测试的特殊事项

应列出所有关于测试或者依赖关系的特殊事项,如下所示:

  • 测试数据库将由操作资源恢复。
  • 测试(性能)必须在办公结束后开始(不受日常的正常操作影响)并且在凌晨 5:00 以前结束。
  • 必须与遗留系统同步(或模拟同步)。

请参照指南:测试计划以获取关于制定测试策略的其他信息。

确定资源 返回页首

目的
  • 确定测试所需的资源,包括人力资源(技能、知识、可用性)、硬件、软件、工具等。

一旦确定测试对象和测试方法,就需要确定执行测试人员及测试活动所需支持。确定资源需求包括确定所需的资源,资源包括如下:

  • 人力资源(人员数量和技能)
  • 测试环境(包括硬件和软件)
  • 工具
  • 数据
确定人力资源需求

对于大多数测试工作而言,您需要符合下列条件的人力资源:

  • 管理和制定测试计划
  • 设计测试及数据
  • 实施测试和数据
  • 执行测试并评估结果
  • 管理和维护测试系统
确定非人力资源需求

测试环境(包括硬件和软件)

推荐使用两个不同的物理环境(尽管这不是必需的):

  • 执行测试管理、设计和实施活动的实施环境,以及
  • 执行所有测试的执行环境,它是一个独立的执行系统(通常是生产系统的克隆)。

软件也有必要进行测试。需要测试的软件最少应包括所测试的应用程序、客户机操作系统、网络以及服务器端操作系统。 此外,可能还需要精确地模拟/复制生产环境的软件,这类软件包括:

  • 与其他系统(如遗留系统)的接口。
  • 其他桌面应用程序,如 Microsoft Office、Lotus Notes 等。
  • 其他驻留于文件服务器和网络或在其中执行的应用程序。当所测试的应用程序不需要这些应用程序时,它们就驻留在其执行环境中。
工具

应该声明何种软件工具(供测试用)将被使用、被谁使用,以及使用各种工具所能够获得哪些信息或好处。

数据

软件测试在很大程度上取决于输入数据(创建或支持某一测试条件)和输出数据(同预期结果作比较)的使用。应确定解决以下与测试数据有关的问题的策略:

  • 收集或生成用于测试的数据(输入和输出)。
  • 数据库构架(隔离外界影响的手段以及在测试完成后将数据返回初始状态的方法)。

创建时间表 返回页首

目的
  • 确定并传达测试工作、时间表和里程碑。

创建时间表包括:

估计测试工作

估计测试工作时,应考虑如下假设:

  • 投入到项目中的人力资源的生产率和技能/知识水平(比如他们使用测试工具或程序的能力)。
  • 要构建的应用程序的有关参数(比如窗口数目、构件、数据实体和相互关系以及重复使用的百分比等)。
  • 测试覆盖(实施并执行测试的可接受深度)。如果只实施和执行一个测试用例(对每一个用例/需求),则表述每一个用例/需求是不同的。经常需要多个测试用例来对某一个用例/需求进行可以接受的测试。

测试估计还应考虑到在测试生命周期的各个阶段使用不同方式对工作进行划分,这是因为某些类型的(工作)量在生命周期内是变化的。例如,性能测试工作,由于其包含在复杂环境中建立测试系统并执行测试的工作,因此该测试执行活动就占了工作估计的很大比重。

此划分对于安排时间是很重要的。测试设计和测试实施工作需要一个单独的调度时期,并增加一些小的改进。相比之下,每一个应用程序工作版本都需要重复执行测试,因此必须对测试执行工作做相应的调整。

测试工作需要包含回归测试的时间。下表显示了经过不同测试阶段的几次迭代之后回归测试用例是如何进行积累的。

迭代与阶段系统集成单元
第一次迭代本次迭代中以系
统为目标的测试用例的测试
本次迭代中以工作版本为目标的测试用例
的测试
本次迭代中以单元为目
标的测试用例的测试
下一次迭代本次迭代测试用例以及用于回归测试的先前迭代的测试用例的测试。对本次迭代测试用例以及用于回归测试的先前迭代的测试用例的测试。本次迭代测试用例以及用于回归测试的先前迭代的测试用例的测试。
制定测试进度

测试项目时间表可以通过工作估计和资源分配来建立。在迭代开发环境中,每一迭代都需要一个独立的测试项目时间表。在每一迭代中都将重复所有的测试活动。

在某一特定迭代中,测试计划和测试设计活动处理软件中的新功能。测试实施活动包括为新功能创建新的测试用例,并为已变更的功能修改测试用例。测试执行和评估步骤验证新功能并为现有功能执行回归测试。

早期迭代引入许多新功能和新测试。随着集成流程继续进行,新测试的数目将减少,而需要执行以检验累计功能的回归测试的数目将增加。 因此,早期迭代更多地要求在测试计划和设计上进行工作,而后期迭代则偏重于测试执行和评估。


为每一迭代提供详尽的时间表是不可能的。通常并不知道将会有多少迭代,或者在哪一次迭代中将达到某一测试标准。

使用估计好的工作和已分配的资源创建测试工作的时间表。

以下示例表概述了所有测试活动。显示的工作估计是各项任务的相对工作数量。

在制定时间表时,必须确保它符合实际。有些时间表很有野心,但人们没有足够的时间或精力来按时间安排行动,从而导致无法成功执行测试。这样的时间表是再令人沮丧不过的了。

任务有关工作
工作总计38d
测试计划7d
确定测试项目1d
确定测试策略1d
估计工作1d
确定资源1d
安排测试活动的日程1d
记录测试计划2d
指定测试用例5d
确定测试用例5d
设计测试7d
分析测试需求2d
指定测试过程3d
指定测试用例1d
复审测试需求覆盖1d
实施测试12d
建立测试实施环境1d
记录并回放原型脚本1d
制定测试过程5d
测试与调试测试过程1d
修改测试过程2d
建立外部数据集1d
重新测试与调试测试过程1d
执行系统测试6d
设置测试系统1d
执行测试2d
核实预期结果1d
调查意外结果1d
记录缺陷1d
评估测试1d
复审测试记录0.25d
评估测试用例覆盖0.25d
评估缺陷0.25d
确定是否满足测试完成标准0.25d

制定测试计划 返回页首

目的
  • 组织并向其他人员传达测试计划信息。

要生成测试计划,请执行如下步骤:

复审/改进现有材料

在生成测试计划之前,应该复审所有现有项目信息以确保测试计划包含最新和最准确的信息。如果需要,应修改测试相关信息(测试需求、测试策略、资源等)以反映所有变更。

确定测试可交付工件

测试可交付工件部分的目的在于落实和规定创建、维护以及如何向其他人提供测试工件的方法。这些工件包括:

生成测试计划

制定测试计划活动的最后步骤是生成测试计划。它通过集中收集到的所有测试信息来完成,并生成一份报告。

测试计划应至少分发到以下对象:

  • 所有测试角色
  • 开发人员代表
  • 股东代表
  • 涉众代表
  • 客户代表
  • 最终用户代表

© 1987 - 2001 Rational Software Corporation。版权所有。

 

分栏显示 Rational Unified Process

Rational Unified Process   

转载于:https://www.cnblogs.com/chingliu/archive/2011/12/10/2288632.html

制定有效的测试计划是软件测试过程中至关重要的环节,它为整个测试流程提供了清晰的指导和方向。测试计划制定应在产品需求确认并完成测试需求分析之后进行[^2]。以下是制定测试计划的关键要素和步骤: ### 测试目标与范围 明确测试的目标,确保所有测试活动都围绕验证软件是否满足用户需求展开。测试范围应涵盖功能、性能、安全等多个方面,并清晰界定哪些模块或特性将被测试,哪些不在当前测试范围内。 ### 测试策略 选择合适的测试类型,例如单元测试、集成测试、系统测试以及验收测试等,以覆盖不同层面的质量保障需求。同时,还需考虑自动化测试的应用场景,合理分配手工测试与自动化测试的比例,从而提升测试效率和覆盖率。 ### 测试资源规划 确定测试团队的组织结构及人员分工,确保每个测试任务都有专人负责。此外,还需要评估所需的软硬件环境、测试工具(如缺陷管理工具JIRA、自动化测试框架Selenium等)以及其他相关资源。 ### 时间安排与进度控制 根据项目的整体开发计划,制定详细测试进度表,包括各个测试阶段的起止时间、关键里程碑节点等。为了应对可能出现的风险,建议在时间安排上预留一定的缓冲期。 ### 风险识别与应对措施 提前识别潜在风险,例如需求变更频繁、测试环境不稳定或人员技能不足等问题,并针对每类风险制定相应的缓解措施。例如,对于需求不稳定的项目,可采用敏捷测试模式,通过快速迭代实现持续测试。 ### 缺陷管理机制 建立完善的缺陷跟踪流程,包括缺陷报告格式、严重程度分类标准、修复优先级判定规则以及回归测试策略等内容。 ### 测试交付物与质量标准 定义测试完成后需提交的文档资料,如测试用例集、测试执行日志、缺陷统计报表及最终的测试总结报告等。同时设定明确的质量验收指标,比如代码覆盖率、缺陷密度等,用于衡量测试工作的有效性。 通过上述方法可以构建一个系统化且具有可操作性的测试计划,为软件质量提供坚实保障。 ```python # 示例:使用Python伪代码展示测试计划的基本结构 test_plan = { "test_objectives": ["Verify core functionality", "Ensure performance meets SLA"], "scope": ["Login module", "Payment gateway integration"], "testing_strategy": ["Unit testing", "Integration testing", "Performance testing"], "resources": {"team_members": 5, "tools": ["Selenium", "JMeter", "TestRail"]}, "schedule": {"start_date": "2023-10-01", "end_date": "2023-10-31"}, "risk_mitigation": [ {"risk": "Changing requirements", "action": "Adopt agile methodology"} ], "deliverables": ["Test cases", "Defect report", "Final test summary"] } ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值