软件的兼容性测试验证的是软件与其所依赖的环境的依赖程度，包括对硬件的依赖程度，对平台软件、其他软件的依赖程度等。

　　但在实际的用例描述中可能对环境的描述只是粗描淡写，测试实施时，主要依靠测试实施人员对软件或者模块的熟悉程度的个人经验。熟悉的人员，测试环境的搭建很容易也很迅速就能搭建好，测试效率也是相当的高。但时隔久了，曾经再熟悉的测试环境也会变的陌生，尤其是环境组合而稍微复杂点时，那就不会那么顺利实施了。这还只是有经验的测试员实施一个时隔已久的测试，假如是新人实施测试呢！那他/她为了搭环境除了要花大时间去熟悉环境，同时还要有很多疑问去询问有经验的测试员；或许一时不解，有经验的测试员除了教他搭环境，同时还要有必要去解释的某些环境。否则，测试完成了，新人由于对测试的内容并不是很了解，他的感觉也许像是走走过场，心中还是充满了疑惑。测试环境的搭建没有说明是多么的不方便。

　　以上的描述并不是空想出来的。比如，曾经我也负责过通讯测试，第一次测试时也是一知半解，特别是服务端的搭建更是要在有经验的测试员的帮助下才完成，或者干脆都由他帮我搭建。可是测试过之后，我还是及时的花了很多时间去消化和研究，最后知道怎么搭建这个通讯模块的测试环境大建。可是这次测试过后，换成其他项目测试了，或者该通讯模块后续的回归测试又其他人员负责了。其他人员陌生的话不懂的话，也是去询问那个熟悉该模块的人员，渐渐的一年多过去了。预料之外的是，由于工作方向和工作内容的调整，通讯模块的测试用例和测试程序，都有我负责了。测试实施时，主要由其他人员实施，在我的指导下进行。可想而之，压力那是相当的大。由于绝大多数通讯的用例和测试程序并不是我写的，现在都由我来负责，很快测试提交过来了，指导新人进行测试，还好大多数用例是自动执行的，人工测试用例比较少，所以，测试还算顺利。但测试程序也并不是完美的，测试失败时，除了检查用例描述的正确性，更重要的是检查测试程序的正确性，并最终确定是否是bug.这个过程是必须的；最头疼的还是环境兼容性测试的环境搭建，时隔一年多了，早已记忆模糊了。环境也变得那么陌生，查看用例描述时，只见配合XXX机器测试。这可弄得我一头雾水，还好查找以前的测试记录知道如何搭建测试环境；这还是简单搭建的，最复杂的是如果该XXX机器还需要进行某些配置时，虽然有个对该机器配置的简单的命令描述可是设置好了命令之后，又和PC机及PC端工具如何连接设置等没说明，也许对熟悉该环境的人来说那时常识操作，可是对该领域不是那么熟悉的人来说真是举步为艰。还好，熟悉该环境的和有经验的人员还在，请教下，最终还是搭建好了。经过这次之后，我不再相信经验或记忆是永远的；而是觉得再好的记忆，也会变模糊的，所以，我决定及时补充一个环境搭建说明；方便了自己也方便了后面测试的人员。所以，自此以后尽量对所有的测试环境搭建做个文档说明和履历。

　　所以，对于熟悉该模块的测试人员来说，测试环境习以为常，并没有什么困难，也许只是不值得花精力去投入的小细节，而这么个小细节小到影响测试进度，大到影响测试是否能的顺利实施。如果稍微对这个小细节有个说明文档，那将大大提高测试效率，您说是不是很给力呢！