聊一下测试计划

目录

测试计划是最早出现，也是最先被遗忘的测试产物。

下面是我们希望测试计划具有的一些特性

测试计划的指导思想

---

测试计划是最早出现，也是最先被遗忘的测试产物。

测试计划是最早出现、最先被遗忘的测试产物。在项目早期，测试计划代表了对软件功能的预期。但是，除非得到持续的关注，它会很快随着新代码的完成、功能特性的改变以及设计的调整而过期。伴随着计划内或计划外的变更，维护一份测试计划是要花费大量精力的，除非多数项目的成员会定期查看，否则测试计划并没有什么价值。

和测试工程师相比，开发工程师有一个优势就是他们的工作产物是每个人都真正关心的。开发工程师编写代码，构建用户期望的、能为公司赚钱的应用。很明显，代码是项目过程中产生的最重要的文档。

然而，测试工程师要处理的是真正的文档和其他临时性的事物。在项目的早期阶段，测试工程师编写测试计划;然后，他们创建和执行测试用例，编写bug报告;接下来是准备覆盖度报告，收集用户满意度和软件质量数据。在软件成功发布(或失败)之后，很少有人会问及测试产物是什么。如果软件深受人们喜爱，大家就会认为测试所作所为是理所应当的;如果软件很糟糕，人们可能就会质疑测试工作。但其实也没人真正想去了解测试到底做了什么。

测试工程师不应该对测试文档过于珍爱。软件开发过程充满了痛苦的挣扎：编码、评审、构建、测试、一轮接一轮的开发等，在这个过程里实在很难有时间坐下来欣赏一下测试计划。糟糕的测试用例不会受到足够的关注和改善，它们只会被抛弃，而最后留下来的是更好的测试用例。大家的关注点集中在不断增长的代码库，这才是最重要的东西，理应如此。

作为一种测试文档，测试计划的生命周期是所有测试产物中最短的(显然，当客户明确要求编写测试计划，或者出于某些政府法规要求，就没这么灵活了。某些场合必须有测试计划并且保持更新)。在项目早期，人们需要一个测试计划。事实上，项目经理经常坚持必须有一个测试计划，并将编写测试计划作为一个比较重要的里程碑。但是，一旦计划就绪，这些人就把它扔到一边了，既不评审也不更新。测试计划就像是闹脾气的小孩儿手中可爱的毛绒玩具。我们希望它总是存在，到哪里都能带着它，但却从不真正关注它。只有它被拿走的时候，我们才会发出尖叫。

理想情况下，测试计划应当在项目执行中发挥核心作用，应当在软件的整个生命周期中持续有效：随着代码库的更新而更新，时刻代表最新的产品功能，而不是停留在项目开始阶段时的样子。它应该可以帮助一个新加入的工程师迅速跟上项目进展。

下面是我们希望测试计划具有的一些特性

及时地更新。

描述了软件的目标和卖点。

描述了软件的结构、各种组件和功能特性的名称，

描述了软件的功能和操作简介。

从纯粹测试的角度看，我们担心的是测试计划的投入和价值产出是否匹配

不必花过多的时间去撰写，必须随时可以被修改。

应该描述必测点。

应该能在测试中提供有用的信息，从而帮助确定进展以及覆盖率上的不足。

测试计划的指导思想

避免散漫的文字：推荐使用简明的列表。并不是所有的测试人员都想当小说家，也不具备将一个产品的目标或测试需求表达成散文的技能。而且，冗词赘句容易误读，只列出要点和事实就行了。

不必推销：测试计划不是营销文案，既不是要讨论一个产品满足了多么重要的市场定位，也不是讨论这个产品有多么酷的功能。测试计划不是给客户或分析师看的，它的受众人群是工程师。

简洁：测试计划并没有长度的要求。它不是中学的项目作业，长度无关紧要，不是越长越好。计划的大小与测试问题的规模有关，与作者的写作欲望无关。

不要把不重要的、无法执行的东西放进测试计划：相关人员毫不关心的东西，就一个词也不要出现。

渐进式的描述：测试计划的每个部分应该是前面部分的延伸，以便读者可以随时停止阅读并且对产品的功能有一个初步的印象。如果读者希望了解更多的细节，那么他可以继续读下去。

指导计划者的思路：一个好的计划过程能帮助计划者思考产品功能及其测试需求，从而有条不紊地从高层概念过渡到可以被直接实现的低层细节。

最终结果应该是测试用例：在计划完成的时候，它不仅要清楚地描述要做什么样的测试，并且还可以清楚地指导测试用例的编写。做出一个不直接指导测试的计划纯粹是在浪费时间。

对测试的计划而言，它显然应该让我们清楚地知道需要编写哪些测试用例。当你正好处于“完全了解需要编写哪些测试”这一点时，才算完成了测试计划。