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

　　安装测试

　　考虑软件所使用的各种硬软件环境等问题，不仅仅在计划的过程中体现到，还要检查部署文档或者产品说明书中是否包含了安装环境的定义和介绍。

　　自动化测试

　　自动化测试的范畴及涉及的内容很多，根据项目组的实际情况引入和实施自动化测试是软件测试发展的趋势。

　　性能测试

　　性能测试的范畴又包括了压力测试，负载测试，性能测试(狭义)，大容量测试等等，这些都要根据实际需求加以取舍和安排，并在计划中体现出来。

　　更新(软件变更)测试

　　主要指版本的升级测试，尤其对于产品性质的软件更应该注意这方面的问题。

　　测试工作本身还包括了其他很多内容，Failover和Switchover测试等等很多内容都需要考虑，有时候还要对软件的逻辑关系，软件的物理关系进行测试，还有更常见的界面测试，可用性测试，验收测试等。这些测试及测试程度的取舍则取决与项目实际情况(时间，成本等等)以及测试人员个人的经验等等。

　　(七)——我们什么时候停止?

　　我们什么时候停止我们的项目?我们应该在我们达到目标的时候停止。可是，目标是什么?Aaron认为所谓目标，即测试应该实现的可度量的要求，这个东西更常见的叫法——测试停止标准。

　　不知道有没有程序员会笑话Aaron说：我们项目就是一个测试人员在点点，甚至不要测试人员点点我们也可以顺利交付给客户很有用的产品;不知道有没有测试人员会讲：我们测试的时候除了用例之外什么都没有，更不用说什么无聊的测试停止标准 =! 不过Aaron告诉你，真要在项目里面有了这么个东西，只会对大家都好。你想，测试停止标准就是那可以止渴的“梅”，有了它咱就有了奋斗的方向，有了等到出头之日的盼头。同时因为一些项目组中测试标准也会作为版本发布标准——尽管这两者还是有区别的——所以测试停止标准对于开发人员和PM也是有用的。

　　当然，并不是所有的测试停止标准都会有这般功效，在Aaron看来，一个合格的测试停止标准应该满足一下条件：

　　在计划阶段尽早订立测试停止标准

　　没有规矩不成方圆，先定下规矩可以帮助我们一开始就计划的时候就在画着“方圆”，而不是等画了一点点之后才发现用的“规矩”不是标准版的，那样浪费了时间。

　　测试停止标准应该获得项目负责人的确认

　　这一条尤其适用于并不是那么和谐的项目组以及习惯优柔寡断的项目负责人领导的项目组。还要注意口说无凭，所以立字为据有时候也是需要的~我们的目的是要使规矩“定”下来。

　　对于这一条，存在这两个风险：

　　一是容易导致不和谐：如果项目负责人签了，感觉像是兄弟们在给他上枷锁似的，更像是把一些责任推到他的身上去了。(因为存在这样一种情况，大家订立一个规矩，可是后来做的东西让top leader不满意，普通组员这个时候好歹还可以推说我们组的规矩是这样做的，不需要问，当时签字确认的项目负责人这下子责任就大了。)

　　二是因为需求变化，因为测试停止标准要求满足可度量性(具体内容在后文详谈)，所以可能会涉及到比较细致的东西，比如某个核心模块应该怎么样才算行——如果在后期需求变了，会不得不更改“定”下来的测试停止标准了。

　　对于这些风险的预防和处理，Aaron虽然有些心得，但是考虑到各个作坊情况不一样，Aaron就不误导各位了。

　　测试停止标准应该是可度量的

　　Aaron看来，对于测试停止标准，“可度量”这个要求是必需的，用抽象的语言来描述测试停止标准是无意义的。如在测试停止标准里面出现“在适当的时间停止测试”这句话是不对的，所谓“合适的时间”这类词汇，要么让人不解其意，要么出现“一千个观众眼中有一千个哈姆莱特”这种情况，因此一个准确的定义是必需的。

　　测试停止标准都是可以达到的

　　这个很容易理解，如果标准里面出现了要我们三五个人十来杆抢在一个月内造一个跟windows Xp一模一样的操作系统给客户，那定这个标准的人怕是跟Aaron前天一样SB了~测试停止标准之中切忌出现不可能实现的或者很难达到的目标，比如在测试停止标准里面出现“修复所有的bug”这种条文，我们就要考虑实际情况中我们是否可能修复所有的bug，项目的要求是否如此严格——所有的bug都必须修复，而不是被处理(修复，延迟并报告等处理方式)，是否允许部分bug推迟修复?

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