测试不会凭空出现，正是因为之前有过太多的教训，人们开始对质量重视起来。从这个意义上来讲，相关组织是为了避免损失而测试，而减少支出其实是赚了钱，所以他们进行测试是为了获取利润的。从另外一个方面来看，测试也要投资，而测试环境则在这些支出中免不了分一杯“羹”。
先看一个笔者赶制的一个草图
对于上面的图，简单说明一下，或者“按图索骥”吧。 在我们计划测试的过程中，我们使用由顶向下的分析策略。
所谓测试项目依赖的硬件环境，举例来讲我们测试一个手机操作系统，总得要拿出个手机来试一试吧；如果拖拉机也需要软件配备，那么一台拖拉机也是需要的，另外还需要弄一个库房或者至少一个空地来放这个拖拉机；所谓测试工作本身依赖的硬件环境，至少得一台测试用的机器吧，对于特殊要求，比如开发一个嵌入式程序用来监控室内二氧化碳的浓度，这个时候一个特殊的工作室可能也是必要的，至少有一个工具可以改变二氧化碳浓度，有个地方可以困住这些二氧化碳吧。关于机器，我们还需要考虑到机器的配置等等问题。
接着就是软件环境了，跟硬件环境一样，包括了测试项目依赖的软件和测试工作本身依赖的软件，当然最重要的是要有个操作系统，还要搭上待测的应用程序。
关于待测应用程序就不讲了，想想如果没有待测程序那我们还测什么啊，是不？测试项目依赖的软件，这里面的弯弯绕就显得多了一点了。首先，待测程序引用或者操作的一些应用程序得准备齐整，比如说某应用程序用于监测某个人每天打开了多少次Outlook并收发了多少邮件，如果机器上没有装上outlook的那我们就只能测试没有outlook下该应用程序的的表现这一种情况了，虽然这也是一个很重要的用例，但是更多的有用的用例还是需要我们配备上outlook来测测的。其次待测程序运行的平台，.NET开发的你总得安装上相应的.NET Framework吧，web应用程序没个浏览器也是不行的。
测试工作本身依赖的软件，说明白点主要就是测试工具了，这里面的弯弯绕太多，笔者就不绕进去了。
操作系统，对于基于windows操作系统的软件，我们就需要考虑到微软这些年来给我们贡献的这么多版本，如果考虑到其他操作系统，我们就不得不考虑到苹果等等的贡献了。
总结一下，对于测试人员来讲，在项目里面不需要考虑到所有的部分（图的叶子部分），但非叶子节点部分还是得好好琢磨琢磨。对于开发人员来讲，比较常出现的一个情况是软件工作的环境问题：应用Team Foundation管理团队项目的时候，项目开发人员A引用了外部DLL（假设为C.DLL），当签入源代码的时候这个DLL是不被签入到TFS上的，这就会导致服务器上的版本编译不通过，提示无法找到DLL之类的错误信息。这是一个常见的环境错误。另外，如果项目组成员使用的开发环境不一致，也可能导致应用程序集成失败或者BVT运行不通过；如果开发团队开发环境一致，那么在对应用程序有兼容性要求的时候，相关的系统兼容性测试是必需的。
