你不知道的测试计划.pdfVIP

你不知道的测试计划 话说测试计划就那么一些字儿，白纸黑字明明白白放那儿，应该不会有什么玄机。如果你是一个 开发人员，这倒也不奇怪；如果你是一个测试计划制定者或审阅者，你还是觉得测试计划如此而 已的话，那你可以好好看看我的见解，一不小心写得有点小多，希望不要看花眼。实在没耐心， 如果看的起的话，可以直接把文档下了。 Part I 测试计划阅读的五重境界 在我看来，测试计划的作者和读者有以下五重境界。 第一重：什么都有用 对于一个测试新手来讲，好不容易找到一份测试计划模板，准备大干一场好好看看测试计划里面 有哪些道道，看着看着发现很多东西都不知道，所以也分不清主次，自然也就觉得什么都很重要 了。 第二重：什么都没用 当一个测试新手渐渐熟悉了测试的一些基础知识之后，回过头去看那些测试计划，发现里面什么 “实质性”的内容都没有，没有他所关心的测试中的具体的方法，还没有一份测试用例来的有用。 第三重：仅部分有用 渐渐的，这个新手也不可避免地开始关注测试流程这一块的东西，再回过头看那个测试计划模板。 这回感觉又不一样了，有些以前觉得没有多大用处的东西还是多多少少可以帮助我们更好的测试， 比如测试计划模板中考虑到的要执行哪些类型的测试这部分内容应该就很有用，但是其他部分貌 似还是很“虚”，一点实际用处都没有。 第四重：什么都有用 这是我自认为达到的水平级别~现在的我发现，一份好的测试计划模板中的所有内容都是有用的， 包括风险分析这些我之前认为是用来凑字数的部分其实都是有着它的作用的，而且一份好的测试 计划模板所包含的内容远远不止你从字面上读出来的那么简单，而这些也是我今天想要和大家一 起分享的东西。 第五重：什么都没用 我还没有达到这种级别，所以这只是我揣测的一种境界。当某一类测试做的非常久非常熟了，对 于这类测试的整个流程以及需要注意到的各个方面都已经烂熟于心，自然就不会把测试计划中的 条条框框放在眼里了，或许这就是所谓的“随心所欲不逾矩”吧~ （不过，我也想过，好记性不如 烂笔头，或许这种达人级别的境界压根就没必要应用于实践吧。） Part II 测试计划文档中容易被人忽略的部分 》Project Goal None Goal 说实话这是我之前认为测试计划里面最没用的部分，因此被我抛弃了很久时间，而据我所 知这也是测试计划中最容易被人忽略的部分。不过，现在我却喜欢并且建议将这部分重视起来。 作为一个项目来讲，尤其是产品类项目，整个Team 需要明确自己应该做什么样的产品，不应该 把产品做成什么样子，这个部分写在测试计划的第一部分，时不时瞅一瞅，提醒我们要向着正确 的方向走。否则，在错误的道路上跑的越快，错的越远。 》版本历史信息和状态信息 这一部分容易被人忽略是因为几乎所有的文档中都有这一部分，或许因为这个缘故，这一 块反而成了文档中最不受人关注的部分，大多数人一看文档直接跳到目录，甚至直接跳到内容的 汪洋中大海捞针。版本变迁中最有用的部分是备注部分，一般这一部分介绍了文档最新更改的部 分以帮助读者快速了解文档的一些基本情况。其次，其中的状态信息也会很有用，因为对于读者 来讲，花费半小时看一份Draft 是没有多大意义的。其他因为类似原因（因经常出现在各种文档 中反而遭受忽略）而容易被人忽略的部分还包括“术语和缩略语”“引用”“文档介绍”“目 录”，几乎所有的常见文档元素~ 一份好的文档中这些部分都会恰到好处，读者阅读一份好的文档可能不会感受到欣喜，但 是如果阅读一份没有或者写的很糟的文档则绝对会感受到痛苦甚至直接不看文档，这也从另一个 方面导致了文档总是容易被人冷落，尤其是测试文档。 》测试接收标准和测试结束标准 这一部分主要是容易流于形式而被人忽略，对于很多项目来讲，根本没有所谓的标准而言， 领导说开干，什么时候干好，ok，这就是开始标准和结束标准，而对于质量这些东西则早被抛到 了最后。是的，或许有人会说，即使我们指定了一份好的测试标准，即使我们的领导也不会毫无 理由的横加干涉，但是市场等原因也会造成产品在没有达到产品发布标准的时候发布出去。对于 这个观点，网上通用的反对理由是：没有质量保证的产品最终会被淘汰，而且会累及公司的名誉。 而我需要另外加一条理由：即使一个人系上安全带开车也会因为车祸挂掉，但系上安全带出事的 概率要比不系要低很多吧。 》风险分析 我之前在写测试计划的时候，这一块一直是流于形式的客套话，写完了就完了，从此再也 不去管它，没有把风险分析的作用利用起来。关于风险分析，文章后面还会专门提到。 Pa