软件计划测试系列（四）——地

        软件计划测试系列（四）——地   测试计划　

   　正所谓，天时地利人和，前面的一片里面笔者花费了大堆口水在“用兵一时，养兵千日”的怎么“养兵”和“兵”自己怎么实现自我修行。 人有了，该是考虑“地利 ”的问题了。所谓地利，即指软件的测试环境，这与开发环境有着很大的不同，同时也保持了一定的联系(废话)。

　　测试不会凭空出现，正是因为之前有过太多的教训，人们开始对质量重视起来。从这个意义上来讲，相关组织是为了避免损失而测试，而减少支出其实是赚了钱，所以他们进行测试是为了获取利润的。从另外一个方面来看，测试也要投资，而测试环境则在这些支出中免不了分一杯“羹”。

　　先看一个笔者赶制的一个草图

　　对于上面的图，简单说明一下，或者“按图索骥”吧。 在我们计划测试的过程中，我们使用由顶向下的分析策略。

　　所谓测试环境(我们这里指的是物理意义上的环境)，对于软件测试来讲“咔嚓”一声分成两半：硬件环境和软件环境。

　　把硬件环境拿出来讲，包括了测试项目依赖的硬件环境，测试工作本身依赖的硬件环境。

　　所谓测试项目依赖的硬件环境，举例来讲我们测试一个手机操作系统，总得要拿出个手机来试一试吧;如果拖拉机也需要软件配备，那么一台拖拉机也是需要的，另外还需要弄一个库房或者至少一个空地来放这个拖拉机;所谓测试工作本身依赖的硬件环境，至少得一台测试用的机器吧，对于特殊要求，比如开发一个嵌入式程序用来监控室内二氧化碳的浓度，这个时候一个特殊的工作室可能也是必要的，至少有一个工具可以改变二氧化碳浓度，有个地方可以困住这些二氧化碳吧。关于机器，我们还需要考虑到机器的配置等等问题。

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

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

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

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

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

原文转自：http://www.ltesting.net