软件计划测试系列(六)——事 测试计划
本计划的上一篇《计划测试系列(五)——时》，是我的软肋，写得很糟糕，但为了保持完整性，还是贴出来了，看着寥寥几人的访问量，觉得应该加油写出更好的东西出来。废话少说，开始念叨计划测试系列中关于事的部分。
测试是做什么事的呢?测试是为了……赶紧打住，我指的“事” 是一个测试项目过程中所做的具体的事，不是拿着《软件测试》或者其他的经典来念句子的。按照自己在上一篇中的理解，软件项目流程或者说一个迭代必定要经过计划实施总结这几个阶段。对于测试来讲我们可以将各个阶段再细分，然后就成了下面这个样子：
制定测试计划
至于计划的作用就不再赘述了，而测试计划作为计划测试活动的结晶，理应受到重视。在实际项目中我发现自己写出来的测试计划这个文档本身意义并不大，至少没有计划测试的过程那般有意义。在很多软件作坊之中，测试计划自一出生便被打入冷宫，测试计划的意义仅仅是作坊主朝自己脸上贴金而使用的一种手段。 鄙人推荐的方法是完成一个交差的测试计划后，维护一个名为测试计划实质上更像测试设计(Test Design Spec)的文档，在整个测试执行过程中该文档都起着提纲的作用，而且任何读者都可以通过这份Test Design Spec中了解Aaron对项目测试的想法和测试思路。我在自己所处的项目组中争取到了Test Design Spec的Review机会。偶是这样告诉他们的：担心自己理解错误了PM的意思，担心自己想的跟Dev不一样，想先把事情说清楚，所以偶要Review。
关于测试计划的内容在本系列文章的第二篇我们也聊过——《计划测试系列(二)——测试计划 》。
测试软件需求
软件需求是测试应该覆盖到的地方，这也是为什么很多软件方法提倡测试尽早介入到软件开发进程中的原因之一。对于PM提供的那份Feature列表或者Feature Spec，我们应该抱着怀疑的态度，PM不是项目对象领域的专家，他会犯错，他也会马虎，他也会有脑袋短路的时候，所以这个时侯需要包括测试人员在内的很多项目成员来一起检查这个list或者spec，称之为Review。对于测试人员及其他参与Review的人员应该实现阅读文档并了解项目相关领域的知识。刚才提到的Test Design Spec的Review工作比较好地完成了任务，当然限于相关业务知识和经验，Test Design Spec的质量会有高有低，Reivew的效果也就可能很不一样。建议先不断锤炼自己的Test Design Spec之后再提交Review，俺自己一般要到V1.3版本才敢拿出去跟PM和Dev“分享”。
测试用例设计
有关测试用例设计的方法，诸如等价类划分，边界值分析，甚至需求矩阵方法等等，在这里就不在闲聊，这些东西网络上已有的文档要比我讲的专业的多，更何况这些内容也不是本文的目的所在。
执行测试
主要是指测试用例的执行，但是还应该包括测试用例的更新，还包括bug的提交和管理等等内容。我在周期稍长的迭代中还会每周发一个Weekly Test Report给项目组成员，帮助他们了解一周来测试工作的进展(以测试用例的数量趋势，分布)，还会报告当前的bug相关的信息(Bug总数，趋势，严重 bug分布，区域分布等)，这些对于帮助项目顺利进行很有帮助。
报告测试结果
我在周期稍长的迭代中会每周发一个Weekly Test Report给项目组成员，帮助他们了解一周来测试工作的进展(以测试用例的数量趋势，分布)，还会报告当前的bug相关的信息(Bug总数，趋势，严重 bug分布，区域分布等)，这些对于帮助项目顺利进行很有帮助。当然，在一个迭代结束或者项目结束之后我们也要提交一个测试报告，这是一份总结性的报告。
安装测试
考虑软件所使用的各种硬软件环境等问题，不仅仅在计划的过程中体现到，还要检查部署文档或者产品说明书中是否包含了安装环境的定义和介绍。
自动化测试
自动化测试的范畴及涉及的内容很多，根据项目组的实际情况引入和实施自动化测试是软件测试发展的趋势。
性能测试
性能测试的范畴又包括了压力测试，负载测试，性能测试(狭义)，大容量测试等等，这些都要根据实际需求加以取舍和安排，并在计划中体现出来。
更新(软件变更)测试
主要指版本的升级测试，尤其对于产品性质的软件更应该注意这方面的问题。
测试工作本身还包括了其他很多内容，Failover和Switchover测试等等很多内容都需要考虑，有时候还要对软件的逻辑关系，软件的物理关系进行测试，还有更常见的界面测试，可用性测试，验收测试等。这些测试及测试程度的取舍则取决与项目实际情况(时间，成本等等)以及测试人员个人的经验等等。
文章来源于领测软件测试网 https://www.ltesting.net/
