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

　　接着就是软件环境了，跟硬件环境一样，包括了测试项目依赖的软件和测试工作本身依赖的软件，当然最重要的是要有个操作系统，还要搭上待测的应用程序。

　　关于待测应用程序就不讲了，想想如果没有待测程序那我们还测什么啊，是不?测试项目依赖的软件，这里面的弯弯绕就显得多了一点了。首先，待测程序引用或者操作的一些应用程序得准备齐整，比如说某应用程序用于监测某个人每天打开了多少次Outlook并收发了多少邮件，如果机器上没有装上outlook的那我们就只能测试没有outlook下该应用程序的的表现这一种情况了，虽然这也是一个很重要的用例，但是更多的有用的用例还是需要我们配备上 outlook来测测的。其次待测程序运行的平台，.NET开发的你总得安装上相应的.NET Framework吧，web应用程序没个浏览器也是不行的。

　　测试工作本身依赖的软件，说明白点主要就是测试工具了，这里面的弯弯绕太多，笔者就不绕进去了。

　　操作系统，对于基于windows操作系统的软件，我们就需要考虑到微软这些年来给我们贡献的这么多版本，如果考虑到其他操作系统，我们就不得不考虑到苹果等等的贡献了。

　　总结一下，对于测试人员来讲，在项目里面不需要考虑到所有的部分(图的叶子部分)，但非叶子节点部分还是得好好琢磨琢磨。对于开发人员来讲，比较常出现的一个情况是软件工作的环境问题：应用Team Foundation管理团队项目的时候，项目开发人员A引用了外部DLL(假设为C.DLL)，当签入源代码的时候这个DLL是不被签入到TFS上的，这就会导致服务器上的版本编译不通过，提示无法找到DLL之类的错误信息。这是一个常见的环境错误。另外，如果项目组成员使用的开发环境不一致，也可能导致应用程序集成失败或者BVT运行不通过;如果开发团队开发环境一致，那么在对应用程序有兼容性要求的时候，相关的系统兼容性测试是必需的。

　　(五)——时

　　到了“时”了，这是计划测试过程中最让人纠结的地方了。计划本来就是一件很麻烦的事情，关键点就在于计划的时候很难拿捏准时间的长度。在一本称之为《软件工程中的事实与谬误》的书籍中，作者提到一条软件项目走向失败的两大因素中的一条就是估算不准，由此可见计划之难了。Aaron现在对于时间计划搞得也是没模没样。

　　初一的时候计划在十五月圆之夜一起赏月对饮，可是天有不测风云，到了十五那天天气转阴了，月亮连个影子都没有更不要提月圆了。在项目中也会经常遇到这种情况，我们预计某年某月某日我们实现某项功能，可是等真的到了那一天，才发现原来我们想象中的那项功能依然只能存在与想象之中了。

　　那我们怎么做时间计划呢? 在Aaron看来，因项目性质而异，要知道我们从事的项目大致可以分为两种：产品性质的和外包性质的。这两种性质的项目对于时间的要求，对于测试强度的要求是大不一样的。

　　对于一般外包项目来讲，对于测试要求相对较低，而时间是固定的。当前大多数标榜使用螺旋开发的团队其实只是变相的甚至是变质的瀑布模型，对于测试的现状更是如此。测试先行，测试与项目同时启动在大多数项目中都只是一句口号而已，因为大家心里都明白，口号是不要钱的，所以空喊口号这种最廉价的朝脸上贴金的方式广受软件作坊主们的欢迎甚至推崇。废话不扯了，对于这种项目的测试工作来讲，一般是标准的段段式的，即计划测试，测试用例设计，测试用例执行及bug管理，测试报告提交等等阶段。这就好弄多了，根据经验(如果一点经验都没有，那还有直觉)我们把这几个阶段换算成比例，然后把测试总时间瓜分了，需要提醒大家的就是记得在瓜分之后留点“缓冲时间”来，否则到时候出了点意外就麻烦了，记住是在每段时间之后加上一个缓冲期，而不是最后加上一次。

　　对于产品来讲，测试要求会比较高，时间当然也是需要考虑的，套用IT界最常被引用的一句话，“在这个瞬息万变的时代”，把握时机对于一个产品来讲无疑是很重要的。不过，由于众公司都不愿意自己的产品一出生生了满身毒疮——bug。轻则产品销量受损，重则产夭折，甚至严重影响公司形象乃至导致公司运转等严重问题。这个时候我们还是先将测试分段，对于这种项目，我们首先站在测试质量的角度，实事求是按照功能点数目、难度，测试经验等来估计测试时间，然后将总时间加起来，如果时间充裕，我们考虑加入更多测试面，如果时间紧迫，我们考虑是否删除部分非核心功能，以降低开发和测试的时间成本，从而为测试质量保驾护航。

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