软件测试中的测试计划（示例）

测试计划

A 测试计划 测试计划是一份详细的文档，它描述了软件产品测试的策略、目标、进度安排、估算、交付成果以及所需资源。测试计划有助于我们确定验证被测应用程序质量所需的工作量。测试计划如同蓝图，指导我们如何按照既定流程开展软件测试活动，并由测试经理进行细致的监控和控制。

根据 ISTQB 的定义：“测试计划是一份描述预期测试活动的范围、方法、资源和进度安排的文件。”

让我们从以下测试计划示例/场景开始：在会议上，你想与团队成员讨论测试计划，但他们不感兴趣。

在这种情况下，你会怎么做？请根据下图选择你的答案。

👉 免费注册实时软件测试项目

测试计划的重要性是什么？

制定测试计划文档有很多好处。

• 帮助测试团队以外的人员，例如开发人员、业务经理和客户， 理解 测试的细节。
• 测试计划 导游 我们的思维。它就像一本规则手册，需要我们去遵守。
• 测试评估、测试范围等重要方面 测试策略 旨在 记录 在测试计划中，以便管理团队可以审查并可将其用于其他项目。

测试计划的类型

共有三种主要类型 测试计划 在软件测试中。

1. 主测试计划： 这是一份概述总体测试策略、范围、资源和所有测试级别进度安排的高级文档，作为项目的总体路线图。
2. 级别特定测试计划： 侧重于特定测试级别，例如单元测试、集成测试、系统测试或验收测试。每个计划都详细说明了该级别的测试方法、环境和交付成果。
3. 类型特定测试计划： Target它定义了各种专门的测试类型，例如性能测试、安全测试、可用性测试或自动化测试。它定义了每种测试类型特有的工具、技术和标准。

这些测试计划共同确保了全面的测试覆盖，使测试目标与项目目标保持一致，并改善了团队间的协调，从而提高了软件质量。

如何编写测试计划

你已经知道 测试计划 是最重要的任务 测试管理流程请按照以下七个步骤，根据 IEEE 829 标准创建测试计划。

1. 分析产品
2. 设计测试策略
3. 定义测试目标
4. 定义测试标准
5. 资源规划
6. 规划测试环境
7. 进度及估算
8. 确定测试可交付成果

步骤1）分析产品

如何测试产品 也完全不需要 有相关信息吗？答案是 不可能你必须学习产品 透 在测试它之前。

本次测试的产品是 Guru99 银行网站。您应该对客户和最终用户进行调研，了解他们对该应用程序的需求和期望。

• 谁将会使用该网站？
• 它是干什么用的？
• 它是如何工作的？
• 该产品使用哪些软件/硬件？

您可以使用以下方法分析该网站。

现在让我们将以上知识应用到真实的产品中： 分析 银行网站 https://demo.guru99.com/V4.

你应该采取 环顾四周 该网站以及 检讨 产品文档. Rev查看产品文档有助于您了解网站的所有功能及其使用方法。如果您对任何项目不清楚，您可以 访问 客户、开发者、设计师来获取更多信息。

步骤2）制定测试策略

测试策略是 关键步骤 在软件测试中制定测试计划时，测试策略文档是一份高层次的文档，通常由测试经理编写。该文档定义了：

• 该项目的 测试目标 以及实现这些目标的手段
• 确定测试 努力 与 成本

回到你的项目，你需要为该银行网站制定测试策略。你应该按照以下步骤操作。

步骤2.1）定义测试范围

在开始任何测试活动之前，必须明确测试范围。这一点需要认真思考。

• 待测系统的组成部分（硬件、软件、中间件等）定义如下： “在范围内”
• 系统中哪些组件无需测试也需要明确定义。 “超出范围。”

明确测试项目的范围对所有利益相关者都至关重要。清晰的范围界定有助于您开展工作。

• 让每个人都能参与进来 信心和准确的信息 关于你正在进行的测试。
• 所有项目成员都将拥有 清除 了解考试内容和不考试内容。

如何确定项目的范围？

要确定范围，您必须 -

• 精准客户要求
• 项目预算
• 产品规格
• 测试团队的技能和才能

现在，它应该明确定义测试的“范围之内”和“范围之外”。

• 由于软件要求 眼镜，Guru99 Bank项目只专注于测试所有的 功能 以及网站对外接口 Guru99 银行 （在适用范围 测试）
• 非功能性测试，例如 压力、表现 or 逻辑数据库 不会进行测试。位客人评分中获得平均 范围）

问题场景

客户希望你测试他的API，但项目预算不允许这样做。在这种情况下，你会怎么做？

在这种情况下，你需要说服客户： API测试 这会增加额外的工作量，并且会消耗大量资源。请提供数据来佐证你的观点。告诉他，如果将 API 测试纳入项目范围，预算将增加 XYZ 金额。

客户同意，因此，新的范围和超出范围的项目如下：

• 范围内的项目： 功能测试, API 测试
• 超出范围的项目： 数据库测试、硬件和任何其他外部接口

步骤2.2）确定测试类型

A 测试类型 是一种提供预期测试结果的标准测试程序。

每种测试类型都旨在识别特定类型的产品缺陷。但是，所有测试类型都旨在实现一个共同的目标：“早期发现 在将产品交付给客户之前检查所有缺陷”

这个 常用 图中对测试类型进行了如下描述

这里有 大量测试类型 用于测试软件产品。您的团队 无法放置 投入足够的精力来处理各种类型的测试。作为测试经理，您必须设定…… 优先 测试类型

• 应该采用哪些测试类型 重点 用于 Web 应用程序测试？
• 应该采用哪些测试类型 忽视 为了节省成本？

步骤 2.3）记录风险和问题

风险即未来 不确定事件 概率为 发生 和 潜力 损失。当风险实际发生时，它就变成了…… '问题'.

在文章中 风险分析与解决方案，您已经详细了解了‘风险’分析并识别了项目中的潜在风险。

在 QA 测试计划中，您将记录这些风险

风险	减轻
团队成员缺乏网站测试所需的技能。	计划一个 培训课程 提高会员的技能
项目时间太紧，很难按时完成这个项目	米 测试优先级 针对每一项测试活动。
测试经理的管理能力很差	计划 领导力培训 对于经理
缺乏合作会对员工的生产力产生负面影响	鼓励 团队中每个成员都应尽职尽责地完成各自的任务。 并启发 使他们更加努力。
预算估计错误和成本超支	建立 范围 在开始工作之前，要高度重视项目规划，并不断跟踪和衡量进度。

步骤2.4）创建测试物流

在测试物流中，测试经理应该回答以下问题：

• 谁是 會測試嗎？
• 在规划婴儿食品行业的工艺要求时，安全性和可靠性是工艺设计中最重要的方面。 测试会发生吗？

谁来测试？

您可能不知道参与测试的测试人员的确切姓名，但是 测试仪类型 可以定义。

要为特定任务选择合适的成员，您必须考虑他们的技能是否胜任该任务，还要估算项目预算。选择错误的成员可能会导致项目失败。 失败 or 延迟.

具备以下技能的人员是进行软件测试的理想人选：

• 有能力 理解 顾客的观点
• 强 欲望 质量
• 注意 详细
• 固德

在你的项目中，负责执行测试的成员是 测试仪根据项目预算，您可以选择内部成员或外包成员作为测试人员。

测试什么时候进行？

测试活动必须与相关的开发活动相匹配。

您将开始测试，当您有 所有必需物品 如图所示。

步骤3）定义测试目标

测试目标是测试执行的总体目标和预期成果。测试的目标是尽可能多地发现软件缺陷；确保被测软件能够正常运行。 无错误 在发布之前。

要定义测试目标，您应该执行以下两个步骤。

1. 列出所有可能需要测试的软件特性（功能、性能、图形用户界面……）。
2. 定义 目标 或 目标 基于上述特征的测试

让我们应用这些步骤来找到您的 Guru99 Bank 测试项目的测试目标

你可以选择 '自顶向下' 这是一种查找网站可能需要测试的功能的方法。在这种方法中，您需要将待测应用程序分解成多个部分。 组件 与 子组件.

在上一主题中，您已经分析了需求规格并浏览了网站，因此您可以创建一个 思维导图 查找网站功能如下：

该图显示了 Guru99 网站可能具有的所有功能。

基于以上特点，您可以将 Guru99 项目的测试目标定义如下：

• 检查网站 Guru99 是否有效 功能（账户、存款……）在实际业务环境中运行正常，没有任何错误或漏洞。
• 检查网站的外部界面，例如： UI运行正常，符合预期，并且满足客户的需求。
• 验证 可用性 网站的这些功能对用户来说是否方便？

步骤4）定义测试标准

测试标准是测试程序或测试判断所依据的标准或规则。测试标准分为以下两种类型：

停职标准

指定测试的关键暂停标准。如果在测试期间满足暂停标准，则活动测试周期将 暂停 直到标准 解决.

测试计划示例：如果您的团队成员报告说 40% 测试用例失败，你应该 暂停 测试直到开发团队修复所有失败的情况。

退出标准

它指定了表示 乳铁蛋白 测试阶段完成。退出标准是测试的目标结果，在进入下一开发阶段之前必不可少。例如： 95% 所有关键测试用例都必须通过。

定义退出标准的一些方法是指定目标 运行速度 与 通过率.

• 运行率是以下各项的比率： 已执行的测试用例数/测试用例总数 测试规范中共有 120 个测试用例，但测试人员只执行了 100 个测试用例，因此运行率为 100/120 = 0.83 (83%)。
• 通过率是以下各项的比率： 通过的测试用例数 / 已执行的测试用例数例如，在上述执行的 100 个测试用例中，有 80 个测试用例通过，因此通过率为 80/100 = 0.8 (80%)。

该数据可以在测试指标文档中检索。

• 运行 必须 100% 除非给出明确的理由。
• 通过 费率取决于项目范围，但 取得高通过率 是一个目标。

测试计划示例：你的团队已经完成了测试执行。他们向你报告了测试结果，并希望你确认 退出标准。

在上述情况下，运行率是必填项，且为 100%但测试团队只完成了 90% 的测试用例。这意味着运行率未达到要求，因此请勿确认退出标准。

步骤5）资源规划

资源计划是 详细总结 完成项目任务所需的所有类型资源。资源可以包括人力、设备和材料。

资源规划是测试计划中的一个重要因素，因为它有助于…… 确定 这个 数 项目所需资源（员工、设备等）的数量。因此，测试经理可以制定正确的项目进度计划和预算。

本节介绍针对您的项目推荐的资源。

人力资源

下表代表了您的项目团队中的各种成员

序号	委员	任务
1.	测试经理	物业管理 整个项目 定义项目 方向 获取适当的资源
2.	测试仪	识别和描述适当的测试技术/工具/自动化架构 验证并评估测试方法 执行 测试， 日志 结果，以及 报告 缺陷。 测试人员可以是内部员工，也可以是外部员工，具体取决于项目预算。 对于需要 低 技能，我建议你选择 外包 成员 保存 项目成本。
3.	测试中的开发人员	实施 测试用例、测试程序、测试套件等。
4.	测试管理员	建立并确保 测试环境 资产 管理 与 维持 支持测试员 使用测试环境执行测试
5.	SQA 成员	负责质量保证工作。 检查以确认测试过程是否符合规定的要求

系统资源

测试Web应用程序时，应按如下方式规划资源：

序号	资源中心	描述
1.	服务器	安装待测的Web应用程序。 这包括独立的Web服务器、数据库服务器和应用服务器（如果适用）。
2.	测试工具	该测试工具用于自动化测试、模拟用户操作并生成测试结果。 有很多测试工具可用于此项目，例如： Selenium，QTP 等。
3.	网络	您需要一个网络，包括局域网和互联网，来模拟真实的业务和用户环境。
4.	电脑	用户通常用来连接到网络服务器的电脑

步骤6）规划测试环境

什么是测试环境

测试环境是指测试团队将要执行测试用例的软硬件配置。测试环境包括： 真实的生意 与 用户 环境，以及物理环境，例如服务器和前端运行环境。

如何搭建测试环境

回到你的项目，你是如何设置的？ 测试环境 该银行网站

要完成这个任务你需要 强有力的合作 测试团队和开发团队之间。

你应该问开发人员一些问题来了解被测试的 Web 应用程序 明确地以下是一些建议问题。当然，如果您需要，也可以问其他问题。

• 该网站同时最多可以处理多少用户连接？
• 安装此网站需要哪些硬件/软件？
• 用户浏览该网站时，电脑是否需要进行任何特殊设置？

下图描述了银行网站的测试环境 https://demo.guru99.com/V4

步骤 7）时间表和估算

在文章中 测试评估您已经使用了一些方法来估算完成项目所需的工作量。现在，您应该将这些估算结果以及进度安排都纳入测试计划中。

在测试估算阶段，假设您将整个项目分解成若干小任务，并按如下方式添加每个任务的估算值：

任务	会员专区	估计工作量
创建测试规范	测试设计师	170工时
执行测试	测试员、测试管理员	80工时
测试报告	测试仪	10工时
测试交付		20工时
合计		280工时

然后你创建 始你 来完成这些任务。

制定进度计划是项目管理中的常用术语。通过在测试计划中创建完善的进度计划，测试经理可以将其作为监控项目进度和控制成本超支的工具。

为了制定项目进度计划，测试经理需要以下几种类型的输入：

• 员工和项目截止日期工作日、项目截止日期和资源可用性是影响进度安排的因素。
• 工程概算根据估算，测试经理可以知道完成项目需要多长时间，从而制定合适的项目进度计划。
• 项目风险了解风险有助于测试经理在项目进度计划中预留足够的时间来应对风险。

我们来练习一下一个例子：

假设老板想在 一种 本月，您已在测试估算中估算了每项任务的工作量。您可以按如下方式创建进度计划。

步骤 8）测试交付成果

测试交付物是指为支持测试工作而必须开发和维护的所有文档、工具和其他组件的列表。

每个阶段都有不同的测试交付成果 软件开发生命周期.

提供测试交付成果 before 测试阶段。

• 测试计划文件。
• 测试用例文档
• 测试设计规范。

提供测试交付成果 ，我们将参加 测试

• 测试脚本
• 模拟器。
• 测试数据
• 测试可追溯性矩阵
• 错误日志和执行日志。

提供测试交付成果 after 测试周期结束。

• 测试结果/报告
• 缺陷报告
• 安装/测试程序指南
• 发行说明

测试计划中常见的挑战（及其解决方案）

有效的测试计划常常面临实际困难。认识到这些挑战并采取积极主动的解决方案，可以确保更顺利地执行计划并提高软件质量。

1. 要求不明确
   挑战： 项目需求不明确或不断变化会导致测试覆盖不完整。
   解决方案： 进行需求梳理，并维护动态的需求追溯矩阵。
2. 有限的资源
   挑战： 工具、时间或熟练的测试人员不足会影响测试质量。
   解决方案： 优先处理关键测试用例，并利用自动化完成重复性任务。
3. 不切实际的截止日期
   挑战： 紧迫的日程安排减少了进行适当的测试设计和执行的时间。
   解决方案： 运用风险评估技术，并尽早与利益相关者沟通风险。
4. 沟通不畅
   挑战： 团队间沟通不畅会导致延误和返工。
   解决方案： 定期召开同步会议并共享仪表盘，提高透明度。
5. 风险管理不足
   挑战： 忽视潜在风险可能会延误项目进度。
   解决方案： 及早发现风险，维护风险日志，并制定缓解策略。

常见问题：