● Project Goal & None Goal
说实话这是我之前认为测试计划里面最没用的部分，因此被我抛弃了很久时间，而据我所知这也是测试计划中最容易被人忽略的部分。不过，现在我却喜欢并且建议将这部分重视起来。作为一个项目来讲，尤其是产品类项目，整个Team需要明确自己应该做什么样的产品，不应该把产品做成什么样子，这个部分写在测试计划的第一部分，时不时瞅一瞅，提醒我们要向着正确的方向走。否则，在错误的道路上跑的越快，错的越远。
● 版本历史信息和状态信息
这一部分容易被人忽略是因为几乎所有的文档中都有这一部分，或许因为这个缘故，这一块反而成了文档中最不受人关注的部分，大多数人一看文档直接跳到目录，甚至直接跳到内容的汪洋中大海捞针。版本变迁中最有用的部分是备注部分，一般这一部分介绍了文档最新更改的部分以帮助读者快速了解文档的一些基本情况。其次，其中的状态信息也会很有用，因为对于读者来讲，花费半小时看一份Draft是没有多大意义的。其他因为类似原因(因经常出现在各种文档中反而遭受忽略)而容易被人忽略的部分还包括“术语和缩略语”“引用”“文档介绍”“目录”，几乎所有的常见文档元素~
一份好的文档中这些部分都会恰到好处，读者阅读一份好的文档可能不会感受到欣喜，但是如果阅读一份没有或者写的很糟的文档则绝对会感受到痛苦甚至直接不看文档，这也从另一个方面导致了文档总是容易被人冷落，尤其是测试文档。
● 测试接收标准和测试结束标准
这一部分主要是容易流于形式而被人忽略，对于很多项目来讲，根本没有所谓的标准而言，领导说开干，什么时候干好，ok，这就是开始标准和结束标准，而对于质量这些东西则早被抛到了最后。是的，或许有人会说，即使我们指定了一份好的测试标准，即使我们的领导也不会毫无理由的横加干涉，但是市场等原因也会造成产品在没有达到产品发布标准的时候发布出去。对于这个观点，网上通用的反对理由是：没有质量保证的产品最终会被淘汰，而且会累及公司的名誉。而我需要另外加一条理由：即使一个人系上安全带开车也会因为车祸挂掉，但系上安全带出事的概率要比不系要低很多吧。
● 风险分析
我之前在写测试计划的时候，这一块一直是流于形式的客套话，写完了就完了，从此再也不去管它，没有把风险分析的作用利用起来。关于风险分析，文章后面还会专门提到。
Part III 测试计划文档中隐含的信息
● 优先级
或许文档的作者并没有直接标出那些计划事项是具有高优先级，哪些是低优先级的工作项，如果在这种情况下读者仍然能很清晰地知道自己先做什么后做什么——至少应该知道今天和明天应该做什么吧——的话，那么测试计划的作者很可能把优先级隐含到了测试进度(Test Scheduler)安排这一部分了，一般来讲先要完成的事情优先级是最高的，而直接将优先级融入测试进度安排也是一种不错的选择。不过这种做法也有一些弊端，如果将工作项“写死”到进度安排中，当遇到某个工作项暂时延迟的时候会造成Test Scheduler的变化而影响其他工作项的执行时间。
● Uncovered
在测试计划中，有一个部分叫做Test Scope，而这一部分一般又会被划分成Covered和Uncovered两个部分。这两部分有什么玄机呢?大家应该知道测试的无穷尽特征，想到了这一点可能会有人马上反应过来：那Uncovered部分岂不是有很多内容?那为什么事实上Uncovered部分并没有洋洋洒洒几千字将我们没有做到的尽可能列出来呢?其实，一份测试计划只能表现出在特定项目中的测试(比如如果不需要security test，那么测试计划中可能就不曾提到security test，甚至在not Covered部分也未曾提到。测试类型方法太多了，如果都在not Covered部分提到，那完全可以另外出一本书了)，所以Uncovered部分提到的只是常见的测试类型或者方法，以及部分功能或者UI等内容，这部分是告诉读者，这一部分我们在测试里面不会——至少是不会专门设计相关的测试用例——测试的啊。这时候，我们一般会在Uncovered内容的后半部分看到关于为什么不覆盖到这一部分的“官方解释”。
文章来源于领测软件测试网 https://www.ltesting.net/
