你不知道的软件测试计划

你不知道的软件测试计划    软件测试

话说测试计划就那么一些字儿，白纸黑字明明白白放那儿，应该不会有什么玄机。如果你是一个开发人员，这倒也不奇怪；如果你是一个测试计划制定者或审阅者，你还是觉得测试计划如此而已的话，那你可以好好看看我的见解。一不小心写得有点小多，而且全是小字儿，希望不要看花眼。

　　Part I 测试计划阅读的五重境界

　　在我看来，测试计划的作者和读者有以下五重境界。

　　第一重：什么都有用

　　对于一个测试新手来讲，好不容易找到一份测试计划模板，准备大干一场好好看看测试计划里面有哪些道道，看着看着发现很多东西都不知道，所以也分不清主次，自然也就觉得什么都很重要了。

　　第二重：什么都没用

　　当一个测试新手渐渐熟悉了测试的一些基础知识之后，回过头去看那些测试计划，发现里面什么“实质性”的内容都没有，没有他所关心的测试中的具体的方法，还没有一份测试用例来的有用。

　　第三重：仅部分有用

　　渐渐的，这个新手也不可避免地开始关注测试流程这一块的东西，再回过头看那个测试计划模板。这回感觉又不一样了，有些以前觉得没有多大用处的东西还是多多少少可以帮助我们更好的测试，比如测试计划模板中考虑到的要执行哪些类型的测试这部分内容应该就很有用，但是其他部分貌似还是很“虚”，一点实际用处都没有。

　　第四重：什么都有用

　　这是我自认为达到的水平级别~现在的我发现，一份好的测试计划模板中的所有内容都是有用的，包括风险分析这些我之前认为是用来凑字数的部分其实都是有着它的作用的，而且一份好的测试计划模板所包含的内容远远不止你从字面上读出来的那么简单，而这些也是我今天想要和大家一起分享的东西。

　　第五重：什么都没用

　　我还没有达到这种级别，所以这只是我揣测的一种境界。当某一类测试做的非常久非常熟了，对于这类测试的整个流程以及需要注意到的各个方面都已经烂熟于心，自然就不会把测试计划中的条条框框放在眼里了，或许这就是所谓的“随心所欲不逾矩”吧~（不过，我也想过，好记性不如烂笔头，或许这种达人级别的境界压根就没必要应用于实践吧。）

　　Part II 测试计划文档中容易被人忽略的部分

　　● 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内容的后半部分看到关于为什么不覆盖到这一部分的“官方解释”。

原文转自：http://www.ltesting.net