全面的测试计划是软件测试成功的基石，是指导测试团队在整个软件开发生命周期 (SDLC) 的战略文档。
测试计划文档是测试计划过程的记录，它描述了预期测试活动的范围、方法、资源和时间表。
关键组成部分的测试计划
测试计划的组成部分包括:
- 范围
- 定义边界的测试努力
- 指定主题的测试
- 指定任何特性或功能进行测试
- 超出范围的
-
- 描述有目的地排除在测试工作之外的特性/功能
- 定义什么是不被测试
- 时间线
- 设定期望测试完成
- 概述每个测试阶段的时间表，包括里程碑和可交付成果
- 资源分配/角色和职责
-
- 描述角色和职责的团队成员参与测试工作
- 定义资源分配为每个测试阶段
- 工具
- 描述要使用的测试工具 (测试管理工具、自动化工具、CI/CD工具等)
- 环境
- 定义标准的测试环境
- 描述硬件、软件和网络配置组成测试环境
- 可交付成果
- 描述您期望从每个测试阶段得出的结果 (例如测试报告、测试结果和其他相关文档)
- 退出标准
-
- 定义标准完成每个测试阶段
- 定义接受或拒绝系统的标准测试
- 缺陷管理
-
- 描述如何报告、跟踪和管理bug发现在测试
- 定义严重级别的bug以及如何修复它们
六个步骤创建测试计划
<img src="data:image/svg xml,”class =” aligncenter “>
1.定义发布范围
通过定义发布的范围，清楚地勾勒出测试工作的边界。这涉及识别将包含在测试过程中的特性和功能。
要解决的任务包括:
- 指定要测试的模块或组件
- 识别任何排除的功能 (超出范围) 和原因排除
- 与利益相关者合作，确保共同理解发布范围
2.进度时间表
为测试过程制定时间表，以确保测试活动与整个项目进度保持一致。
要解决的任务包括:
- 设置里程碑和最后期限为每个测试阶段
- 考虑依赖于开发活动并相应地调整时间表
- 将测试计划传达给所有相关团队成员
3.定义测试目标
清楚地阐明测试目标 ，或测试工作的目标和目标，使其与总体项目目标保持一致。
要解决的任务包括:
- 指定功能和非功能测试目标
- 使测试目标与业务需求和用户期望
- 确保测试目标有助于整体质量的软件
保持一致
4.确定测试可交付成果
确定将作为测试过程的一部分生成的文档和报告。
要解决的任务包括:
- 列出每个测试阶段的预期可交付成果 (例如，测试计划、测试用例、测试报告)
- 定义格式和结构的每个交付
- 明确受众的每个可交付成果及其服务
5.设计测试策略
制定一个高级策略，概述如何进行测试，考虑测试方法和方法。
要解决的任务包括:
- 定义测试级别 (单元、集成、系统、验收)
- 指定测试类型 (功能/非功能测试、回归测试、性能测试)
- 确定使用手动和自动测试 (如适用)
- 考虑风险分析和缓解策略
- 考虑测试设计
测试设计方法要考虑
测试设计方法是一种系统的策略方法，用于创建测试用例并根据特定标准定义测试条件。它概述了测试活动的方式，以确保全面覆盖被测软件。
| 试验设计方法 | 描述 | 注意事项 |
| 功能列表 | 识别和测试特定功能的软件 | 构建功能列表并将功能制成测试用例。有时称为可追溯性矩阵，这可以显示覆盖中的漏洞，有时还可以显示不需要进一步工作的功能。 |
| 用户旅程地图 | 测试场景基于用户交互和体验 | 考虑从签入到签出的用户行为流程，而不是列出功能。一些在任何用户旅程中都没有显示的功能可能需要更少的测试和更少的未来开发，特别是如果它们在日志中不受欢迎的话。 |
| 日志挖掘 | 分析系统日志以发现潜在问题 | 按功能组织日志条目并进行排序，以查找使用最多的功能; 将测试设计时间集中在这些核心功能上。 |
| 异常条件 | 测试错误处理和异常情况下的代码 | 这些都是测试，当事情出错: 数据库关闭，网站被拒绝，API不返回这么长时间，浏览器超时。快速攻击可以与此类别重叠。 |
| SFDIPOT (结构、功能、数据、接口、平台、操作和时间) | 考虑不同方面的测试设计 | ，测试计划的一个可能的练习是将这些作为节点列出，然后为与软件的这些元素相关的风险创建子注释。 一旦完成，检查该风险列表和测试计划，以确保它们被覆盖。大型程序可能每个主要功能都有一个SFDIPOT图。 |
| 启发式测试策略 | 应用各种启发式方法进行探索性测试 | 这种方法是了解测试任务，产品目标和质量目标的考虑因素的宝库。使用它来开发新的测试方法，然后查看计划以查看是否包含它们。 |
| 域测试 | 专注于特定应用程序域内的测试。域方法识别不同的潜在条件，并尝试为尽可能多的有意义 的条件找到相关且功能强大的测试 |
域测试需要仔细分析需求; 决策表就是基于域的测试的一个例子。 简单地说，当需求创建了一个包含十多个测试想法的 “文本墙” 时，将可视化视为最终确定测试计划之前的中间步骤。决策树创建了一个结构化的，可视化的基础，从中可以得出详细的测试用例。 |
| RCRCRC | 评估代码质量和可读性以进行测试 | 这种助攻是: 可读性，复杂性，相关性，一致性，健壮性和可理解性。 考虑这些元素可以让团队找到重新测试的最高优先级区域，特别是对于回归。 |
6.规划测试环境和测试数据
确保使用所需的硬件、软件和配置设置测试环境。规划必要的测试数据以模拟真实场景。
要解决的任务包括:
- 定义标准的测试环境，包括硬件规格和软件配置
- 确保测试环境镜像生产环境
- 计划创建和管理测试数据
- 考虑任何工具或资源需要测试数据生成和管理
<img src="data:image/svg xml,”style =” width:604px;height:auto “class =” aligncenter “>
图像:TestRail中的每个项目都包含一个专门用于查看和管理该项目可用的测试数据的仪表板。
创建测试计划的这六个步骤为有组织和有效的测试奠定了坚实的基础，解决了范围，时间表，目标，可交付成果，策略和测试环境的关键方面。
敏捷测试计划最佳实践
<img src="data:image/svg xml,”class =” aligncenter “>
迭代规划
- 计划在短迭代或冲刺
- 适应变化并改进计划迭代
优先考虑用户故事
- 优先测试基于用户故事
- 使测试工作与交付价值渐进式
Shift-左侧测试
- 将测试活动提前到开发阶段
- 强调协作以实现早期缺陷检测
自动化回归测试
- 实现自动化回归测试
- 确保快速可靠的验证后的代码更改
鼓励合作
- 促进跨职能团队成员
- 促进共同理解测试需求
之间的协作
持续改进
- 定期反思测试过程
- 确定需要改进的领域并完善实践
根据项目要求
进行定制
- 根据项目需求定制测试，以识别项目的多样性，并促进灵活和自适应的测试方法。这导致更相关和更有影响力的测试工作。
主要考虑事项当定制项目需求:
| 了解项目动态 | 深入了解项目的规模、复杂性和行业背景。了解这些因素如何影响测试策略和整个项目的成功。 |
| 调整测试级别和类型 | 使测试级别和类型的选择与项目中不同方面的重要性保持一致，并遵守行业特定的测试要求。 |
| 自定义测试设计技术 | 深思熟虑地选择适合项目复杂性和适应变化的测试设计技术，确保稳健和面向未来的测试方法。 |
| 优化测试环境设置 | 定制测试环境以准确复制生产条件。考虑硬件、软件和网络配置，以确保实际可靠的测试方案。 |
| 平衡测试覆盖率和效率 | 争取一种平衡的测试方法，将全面的测试覆盖率与效率相结合。优先考虑关键领域，同时优化测试流程以确保资源效率。 |
| 自定义文档标准 | 调整文档标准以满足独特的法规需求和项目文化。在不断发展的环境中，在提供全面的文档和保持敏捷性之间取得平衡。 |
利用高级测试策略 (举例)
<img src="data:image/svg xml,”class =” aligncenter “>
先进的测试策略结合了技术来应对特定的挑战，提高效率，并提高测试过程的整体质量。
Shift-左侧测试
左移测试涉及将测试活动移动到软件开发生命周期的早期，通常是到开发阶段。它强调开发人员和测试人员之间的协作，实现早期缺陷检测和更快的反馈循环。
左移策略会影响测试计划的制定方式。测试计划考虑如何将测试活动集成到早期开发阶段，定义在编码和单元测试阶段要进行的测试类型。
在测试计划过程中强调开发和测试团队之间的协作，以确保测试工作与持续集成和持续交付 (CI/CD) 管道保持一致。
右移测试
Shift-right测试将测试活动扩展到后期制作阶段，重点关注实际用户的监控和反馈。它旨在发现可能仅在现场环境中出现的问题，并收集见解以进行持续改进。
测试计划通过概述生产后测试活动来考虑右移测试策略的实施。这包括计划监控工具，反馈机制以及捕获和分析真实用户数据的策略。
测试计划包含了测试过程将如何适应从实时环境收到的持续反馈，从而能够快速响应问题并持续增强软件。
左移和右移测试策略通过覆盖软件测试生命周期的不同阶段而相互补充。
示例持续集成 (CI) 和持续部署 (CD) 管道
左移:
- 场景:开发人员在开发阶段编写代码并在本地执行单元测试。
- 示例:单元测试是自动化的，并作为开发人员本地构建过程的一部分运行，确保及早发现代码中的问题。
右移:
- 场景:在部署到临时环境之后收集真实用户数据和反馈。
- 示例:真实的用户交互、性能指标和来自暂存环境的反馈将被持续监控，从而在现实环境中提供对应用程序行为的洞察。
将DevOps原则纳入测试规划
DevOps原则影响测试与持续集成和持续交付 (CI/CD) 管道的集成。测试计划概述了测试活动如何无缝地融入DevOps工作流，确保测试是开发过程不可或缺的一部分。
自动化是DevOps的关键组成部分，测试计划详细说明了如何实现测试自动化以支持持续测试，从而实现快速反馈和快速发布周期。
示例DevOps原则在测试计划
自动化集成
- Shift-向左进近:为了确保早期识别缺陷，将自动化单元测试和集成测试作为开发过程的一部分。
- 测试计划示例:概述如何将自动化测试无缝集成到CI/CD管道中，以实现从开发到部署的连续测试。
持续集成 (CI):
- 左移进近示例:开发人员将代码更改提交到共享存储库，从而触发自动构建和基本测试。
测试计划示例: 在CI管道内定义测试活动，包括单元测试、集成测试和代码质量检查，以确保早期快速反馈。
持续部署 (CD):
- 左移进近示例:自动部署到过渡环境，以进行进一步的测试和验证。
- 测试计划示例:指定测试活动如何扩展到CD，确保在实际部署之前在类似生产的环境中进行全面验证。
<img src="data:image/svg xml,”class =” aligncenter “>
测试计划的内容和结构根据使用环境的不同而有所不同。例如，在敏捷开发中，测试计划可能需要经常更改以跟上不断变化的目标。
如果您正在使用DevOps流程，则测试计划可能需要解释测试将如何与您的开发管道集成，现有自动化测试将涵盖测试的哪些部分，以及在此测试周期中您将尝试自动化哪些新测试。
底线是，如果你的测试计划不适合一页，不要担心。目的是尽量减少无关的信息，并获取利益相关者和测试人员执行计划所需的必要信息。
测试规划与测试用例管理工具，如TestRail
<img src="data:image/svg xml,”class =” aligncenter “>
像TestRail这样的测试用例管理工具支持QA团队进行有效的测试计划:
可定制的测试用例
在TestRail中，您可以在不同的项目和测试套件中重用您的测试用例模板，并根据特定的测试方法和项目需求对其进行自定义。这些功能使其成为强大且适应性强的测试工具，可在测试过程中保持一致性，效率和组织。
在TestRail中编写测试用例时，您可以自定义四个默认模板:
- 测试用例 (文本):
<img src="data:image/svg xml,”style =” width:509px;height:auto “class =” aligncenter “>
图像:这个测试用例 (文本) 模板 (四个可定制的模板之一) 允许用户描述测试人员应该采取的步骤来更流畅地测试给定的用例。
缺陷积分
TestRail简化了将团队所选项目管理工具 (Jira、GitHub、Azure DevOps或其他缺陷管理系统) 中跟踪的缺陷链接到TestRail中的对象 (如测试、测试运行、计划和里程碑) 的过程，以实现完整的可跟踪性和覆盖范围的可见性。
如果您使用的是问题跟踪工具集成了TestRail ，则可以无缝地将新缺陷从TestRail填充并推送到该工具，而无需手动复制和粘贴。这加快了报告流程，节省了时间，增强了开发和产品团队的可见性，突出了应用程序中潜在的风险领域。
<img src="data:image/svg xml,”class =” aligncenter “>
图像:TestRail为流行工具提供了现成的缺陷插件，您可以为自定义工具或尚未支持的第三方系统构建自己的插件。
报告
TestRail生成汇总不同类型数据的报告，以提供有关测试过程的深入见解。自动生成测试摘要报告可以节省您的团队工作时间，并跳过收集所需信息并将其输入表格的手动工作。
TestRail允许您通过单击按钮生成报告，而不管框架或编程语言，并根据您想要突出显示的信息自定义状态报告。
<img src="data:image/svg xml,”style =” width:523px;height:auto “class =” aligncenter “>
图像: 通过测试分析和报告更快地做出数据驱动的决策，从而全面了解您的质量运营情况。
TestRail提供的测试过程的可见性级别，使其易于适应任何组织的测试计划工作-请尝试TestRail免费 ，以了解它如何帮助您进行测试计划!
在本文中:
本文档中没有标题。
注册我们的时事通讯
分享这篇文章
</span