| 编辑推荐: |
| 本文来自csdn，本文主要介绍了计划的精度的每一层的详细内容，以及测试思路的思维导图等相关内容。 |
|
关于计划的不同观点
因为敏捷宣言说响应高于遵循计划，所以经常有人误以为敏捷开发不需要做计划。而实际上，优秀的敏捷团队的计划性往往比传统瀑布式项目团队更强。它会根据需要把任务分解为足够小的任务块来完成，然后通过快速反馈加以了解和调整。
计划的精度
产品版本：
一个或多个团队开发的一个产品，以明确的时间间隔或明确的日期发布。一个产品版本可能有一个或者许多特性。
特性：
一些业务性能或者用于业务的功能块，它应该是较大特性集的一部分。一个特性通常有许多故事，整个特性可能需要多个迭代才能完成。
故事：
一个小型的、可测试的功能块，通常在一到三天内完成。它可能可以独自发布到生产环境，也可能不可以。一个故事有多个任务。
任务：
故事的一部分工作，在一天内完成。
在探讨每个层级预期可能会产生什么文档和工作的同时，也要探讨一下如何来调整测试计划以适应每个层级的需要，在每一层级上，我们要考虑不同的风险等级。
产品版本层计划精度
高层次的测试方法应该覆盖本产品交付周期内最重要的内容；对发布内容做计划时是识别新测试工具或测试环境需求的最佳时机。
收尾期处于发布产品到生产环境之前，是思考需要再增加什么测试的好时机，这些活动可能会涉及交付团队之外的其他组织，e.g.
运维、客户支持、市场等。
如果该版本包括尚未充分理解的新技术或新特性，那么团队可以计划做一些探究性工作、小实验等对潜在的问题或设计方案进行更多的了解，等探究性工作有结果后之后，再尝试做计划比较适当，甚至高层次的计划也是如此。
在产品版本层，测试计划应该包含测试风险的识别和针对当前版本所做的假设；不仅强调针对产品集成问题的测试，也应该强调针对跨团队依赖可能存在问题的测试。
特性层计划精度
如果需要把特性分解成故事，就和产品负责人一起借助该特性预期行为和非预期行为的实例来创建高阶验收测试。这么做有助于定义范围并使得业务价值可视化。把特性分解为故事前，尝试和整个团队一起来创建该特性的测试思维导图，可以提前把一些可能出现的问题揭露出来。
有些特性会包含多个故事，需要多个迭代来完成，为此规划测试活动会比较复杂，因此为这些特性创建一个”测试该特性”的故事是一种不错的做法，这个故事中的任务大多是相关的测试活动，e.g.
“探索这个特性”，”流程自动化”等。
故事层计划精度
一旦开始投入到故事层的工作就要开始涉及更多的细节内容了，我们在故事准备会期间会做故事级别的计划；从这些会议及讨论中，开始编写测试思路；在迭代计划会期间继续完善，然后通过工具箱中所有工具去定义其他测试，用它们证明故事可以满足预期。
任务层计划精度
当考虑任务层的相关测试活动时，少做计划，更多的是一边做一边调整，e.g. 如果任务是创建测试数据，可能会发现，不得不改变获取数据的来源。有些团队选择在迭代计划会上按实际工时来估算任务，这么做的目标不在于能估得多精确，而是预先了解哪些事会花时间。
可视化你正在测什么
可视化的辅助手段帮助团队始终意识到什么样的测试活动需要发生，并跟踪哪些事情还需要做。使用思维导图和测试矩阵是两种有效的方式：
思维导图：
先在主节点上放中心主题或问题，然后进行相关主题的思考，在适当的层次画上新节点；这没有正确与错误之分，主要是把思路记录下来，并且可利用在先思维导图工具与团队进行协作
测试矩阵：
测试矩阵为已计划的测试活动提供了不同视觉。行是特性，列是测试条件或测试能力。 白色代表还没有测试；
方格表示进行顺利；
点阵表示完成了部分测试，但还要做更多测试；
条纹表示失败了；
灰色表示不适用，不需要测试。 |
