如何写一份靠谱的软件测试计划？(5)

　　回到上面的“月圆之夜”的故事片段上来，这个片段提醒了我们在时间计划的时候还有一些问题需要注意。上面提到计划失败是因为“月圆”这个外界因素没有达到要求，这就提醒我们在计划的过程中，应当尽量减少对于外界的依赖，如果依赖是必需的，那么对于依赖可能导致的意外我们要多出几套应急方案。另外，在项目执行过程中，及时检查项目进度也是必要的，这可以避免我们跑在错误的道路上，那样只会越错越远，这部分不属于计划测试的范畴，因此不做考虑了，如果有兴趣可以看一下持续集成相关的资料。

　　(六)——事

　　本计划的上一篇《计划测试系列(五)——时》，是Aaron的软肋，写得很糟糕，但为了保持完整性，Aaron还是贴出来了，看着寥寥几人的访问量，Aaron觉得应该加油写出更好的东西出来。废话少说，开始念叨计划测试系列中关于事的部分。

　　测试是做什么事的呢?测试是为了……赶紧打住，Aaron指的“事” 是一个测试项目过程中所做的具体的事，不是拿着《软件测试》或者其他的经典来念句子的。按照Aaron自己在上一篇中的理解，软件项目流程或者说一个迭代必定要经过计划实施总结这几个阶段。对于测试来讲我们可以将各个阶段再细分，然后就成了下面这个样子：

　　制定测试计划

　　至于计划的作用就不再赘述了，而测试计划作为计划测试活动的结晶，理应受到重视。在实际项目中Aaron发现自己写出来的测试计划这个文档本身意义并不大，至少没有计划测试的过程那般有意义。在很多软件作坊之中，测试计划自一出生便被打入冷宫，测试计划的意义仅仅是作坊主朝自己脸上贴金而使用的一种手段。Aaron推荐的方法是完成一个交差的测试计划后，维护一个名为测试计划实质上更像测试设计(Test Design Spec)的文档，在整个测试执行过程中该文档都起着提纲的作用，而且任何读者都可以通过这份Test Design Spec中了解Aaron对项目测试的想法和测试思路。Aaron在自己所处的项目组中争取到了Test Design Spec的Review机会。Aaron是这样告诉他们的：Aaron担心自己理解错误了PM的意思，Aaron担心自己想的跟Dev不一样，Aaron 想先把事情说清楚，所以Aaron要Review。

　　关于测试计划的内容Aaron在本系列文章的第二篇也聊过——《计划测试系列(二)——测试计划 》。

　　测试软件需求

　　软件需求是测试应该覆盖到的地方，这也是为什么很多软件方法提倡测试尽早介入到软件开发进程中的原因之一。对于PM提供的那份Feature列表或者 Feature Spec，我们应该抱着怀疑的态度，PM不是项目对象领域的专家，他会犯错，他也会马虎，他也会有脑袋短路的时候，所以这个时侯需要包括测试人员在内的很多项目成员来一起检查这个list或者spec，称之为Review。对于测试人员及其他参与Review的人员应该实现阅读文档并了解项目相关领域的知识。Aaron刚才提到的Test Design Spec的Review工作比较好地完成了任务，当然限于相关业务知识和经验，Test Design Spec的质量会有高有低，Reivew的效果也就可能很不一样。Aaron建议先不断锤炼自己的Test Design Spec之后再提交Review，Aaron自己一般要到V1.3版本才敢拿出去跟PM和Dev“分享”。

　　测试用例设计

　　有关测试用例设计的方法，诸如等价类划分，边界值分析，甚至需求矩阵方法等等，Aaron在这里就不在闲聊，这些东西网络上已有的文档要比Aaron讲的专业的多，更何况这些内容也不是本文的目的所在。

　　执行测试

　　主要是指测试用例的执行，但是还应该包括测试用例的更新，还包括bug的提交和管理等等内容。Aaron在周期稍长的迭代中还会每周发一个Weekly Test Report给项目组成员，帮助他们了解一周来测试工作的进展(以测试用例的数量趋势，分布)，还会报告当前的bug相关的信息(Bug总数，趋势，严重 bug分布，区域分布等)，这些对于帮助项目顺利进行很有帮助。

　　报告测试结果

　　Aaron在周期稍长的迭代中会每周发一个Weekly Test Report给项目组成员，帮助他们了解一周来测试工作的进展(以测试用例的数量趋势，分布)，还会报告当前的bug相关的信息(Bug总数，趋势，严重 bug分布，区域分布等)，这些对于帮助项目顺利进行很有帮助。当然，在一个迭代结束或者项目结束之后我们也要提交一个测试报告，这是一份总结性的报告。

原文转自：http://www.uml.org.cn/Test/200911128.asp