如何编写测试计划

#1 楼

要知道如何编写测试计划，首先必须学会计划测试。

计划测试是一项真正的思想家任务。您应该问很多难题才能了解项目的领域。
您应该了解项目的利益相关者。

计划的一部分包括测试评估。这可能会让您开始使用它-https://www.patelmilin.com/blog/testing/points-consider-test-estimation.html

这是一小部分问题您应该在开始任务之前先问问-https://www.patelmilin.com/blog/testing/questions-before-testing-software.html

现在不要认为这两个列表是圣经。对于您的情况，它们可能是对是错或不足。经过他们，即兴创作。添加您的想法，并尝试查找有关该项目的尽可能多的信息。然后列出您的发现并进行成本与价值分析。这将开始为您带来测试思路。然后看看您想怎么做。为它准备一个思维导图，中提琴已经准备好测试计划！

哦，我差点忘了，去看看http://apps.testinsane.com/mindmaps/就像糖果乐园一样！

#2 楼

让我给我一些詹姆斯·巴赫的建议。他喜欢区分测试计划和测试计划文件。

测试计划文件是测试计划的书面形式。根据您所工作的公司，这可能会有所不同，并且根据我的经验，范围从精简或最小到肿（我已经看到大型公司基于设计使团队“看起来不错”的模板而templates肿的测试计划文档”或“涵盖所有内容”）。

像IEEE829这样的大多数“测试标准”似乎都更在乎测试计划的文件和结构，然后才在乎对团队或测试人员有利或有用的内容。

测试计划通常包含测试项目的后勤工作和您的测试策略。



物流可以包括谁进行什么测试，何时（估计）和结束日期。

测试策略将是您要测试的事物，有时间进行测试的事物或指导您选择测试的想法的方式。巴赫的启发式测试策略模型（HTSM）旨在帮助测试人员确定您的测试策略应该是什么。

无论您是否写下来（我可以想到一些您不会使用的示例）以及遵循的格式（自行构建一个精益/最小的产品还是使用一个template肿的模板），最重要的部分是了解计划的目的，并以此指导测试。

#3 楼

我同意milinpatel17上面关于测试计划的回答。
测试计划是测试产品或应用程序的详细布局和策略。开始编写测试计划之前，请先考虑以下几点：


为什么要测试-目标
要测试的内容-范围
如何实现目标- -所需的时间和金钱（以及资源​​数量）
采用什么方法-自动化，手动，功能性或非功能性等...
哪种方法-敏捷，瀑布式等...如果需要。 br />什么条件-可能是测试条件。

#4 楼

除上述标题外，测试计划还应包括以下部分及其说明



进入和退出条件：用于开始测试阶段并进行调用

暂停和恢复标准：在测试过程中，可能由于某些或多个原因而需要暂停测试的情况有很多。本节包含您/团队需要暂停测试以及何时恢复测试的条件。
系统验收标准
错误/缺陷管理过程
具有角色和职责的团队组成

里程碑和可交付成果（具有计划的开始和结束日期）

与上面提到的一样，不要像列出“在岩石上划出的线”那样困难而快速地列出清单。

您的测试计划应符合您的项目计划和项目中遵循的SDLC模型。

不要在计划中添加太多内容，保持简明扼要。我已经看到很多人创建测试计划只是为了将另一个文档添加到他们的项目存储库中，并且随着时间的推移它已经过时了，团队开始以测试计划中提到的不同方式开始测试。使用新的策略或方法也不错，可以使自己和策略保持更新，这是一件好事，但与此同时，您也应保持测试计划/相关文档的更新。因此，流程应该是首先更新计划，然后实施计划，而不要这样做。

#5 楼

测试计划详细说明了为获得特定结果而采取的每个步骤，并阐明了每个操作的目标。请按以下步骤操作：

步骤：


编写简介-简介包括一般说明，测试时间表以及任何相关文档
所需资源。本节描述了完成测试所需的所有资源，包括硬件，软件，测试
工具
要测试的内容。列出您将要测试的新方面以及您将要重新测试的旧方面。
您将不测试什么。列出当前项目中将不会测试的所有功能。
将在测试过程中生成的文档列表。
风险和依赖性。详细说明您的项目所依赖的所有因素以及每个步骤中涉及的风险。
项目的结果。概述您希望在测试过程中实现的所有目标。详细介绍可以衡量成功和失败的参数

#6 楼

测试计划必须具有以下规定的最小框架。记住并了解它们之间的差异非常重要。我们在这里不是指测试方法或策略文档。我一直使用Microsoft项目来创建和跟踪计划，因为它是如此强大的工具，并且提供了适合所有人的多种视图，例如，如果您要查看每个详细的项目/任务及其进度百分比，或者跟踪里程碑甚至资源。还请记住，在项目的整个生命周期中，几乎不可能在任何地方看到日期都没有更改，因此，如果对测试计划进行了周密的考虑/构建，维护也将变得更加容易。现在回到特定的问题。

它必须包含：


依赖项
设计完成
b。开发完成
c。准备好测试环境
d。可用的测试资源
测试活动
测试准备完成并签字
b。准备好测试数据
c。测试执行开始
d。测试执行完成
e。测试关闭
上线日期
上线支持

查看示例-

希望这会有所帮助。

最好的问候

#7 楼

测试计划详细说明了测试项目的内容，时间，方式，人员以及其他内容。它应该概述总体策略，并为某人提供足够的信息，以使他们可以开始进行测试。

在被普遍问到应在TestLodge的测试计划中包括哪些细节之后，一起基于IEEE 829格式的示例测试计划，该计划已在之前的文章中提到过。取决于您实际测试的内容和范围。

要了解有关此示例的更多信息以及以其他格式查看它，请查看我们最近的测试计划博客文章。 >

#8 楼

“计划就是一切，计划什么都没有。”-德怀特·艾森豪威尔


我认为学习编写测试计划文档并不比制定计划过程重要。通过在正确的时间提出正确的问题，它有助于在一开始就捕获关键信息。通过正确执行，可以通过有效利用测试资源将测试重点放在业务关键项目上。与此相关的风险和约束。
最后，它不是文档，而是团队之间促进正确沟通的重要内容。

#9 楼

根据IEEE 829格式：这些是要点：


测试计划标识符
参考文献
简介
测试项目
软件风险问题
要测试的功能
要测试的功能
方法
项目通过/失败标准
暂停标准和恢复要求
测试可交付成果
剩余的测试任务
环境需求
人员配备和培训需求
职责
计划表
计划风险和突发事件
批准
词汇表