不同于ToC业务的部署环境，当我们交付ToB业务时，经常会面临需要到客户指定环境部署的任务。主要分成两个类别，一种是必须部署在客户私有的网络环境，与外部物理隔离。另一种通过远程桌面可以访问，但是服务器本身也是与外部物理隔离，不能够直接访问到。

在这种“封闭”的环境之中，执行交付测试，由于网络不通，不能直接使用现成的测试环境，给测试人员带来了很大的困扰。

本文针对以上情况，总结了以Java语言为例的测试方案，包括测试环境搭建，测试代码的注意事项

BadNews First

曾经蹚过一条泥坑，是以后坚决不用的方式：利用java -cp的方式后台执行测试代码的main函数。

最开始选择这种方案是考虑到，交付环境中网络不通畅，如果尽量减少不需要的软件下载和安装，基于最简单的JDK环境就能够执行回归测试，想来会很美~ 哪知道，现实太tm骨感

实际实施方式

1. 改造测试代码结构，将所有的测试代码从test scope移动到src/main/java中。
2. 编写一个新的主类RunCaseTest，通过动态加载配置文件和testng.xml方式获取配置信息，然后加载要执行的测试用例。
3. 实际执行时从cmd进入，利用java -cp的方式后台执行main函数。
4. 先在自己的本子上利用maven-assembly-plugin插件把所有的依赖都打包进一个jar保重，将这个jar包通过U盘或者（邮箱)发送到交付环境中，执行代码

不好使的原因：在真实环境中，测试用例99.9%不能一把跑过。 Anyway，这也是交付测试的意义所在啊~
当测试用例失败的时候，需要要从cmd那一堆黑坨坨的日志里，找到对应测试源代码哪一行验证代码的失败。很难。同时在debug的时候，要人工的不断修改testng.xml里进行修改来执行特定的case，远程桌面上操作起来也很麻烦。

自动化测试方案

测试环境的搭建

通过U盘或者公网在交付环境中下载好三剑客，jdk/maven/idea， 在将测试源码拷贝进去，搭建和公司里一样的测试环境执行测试。 听起来有点蠢吧，哈哈，是的，就是用了最原始的方式。

测试代码注意事项

1. 远程桌面的属于较好的情况，矮子里面拔将军。这时修改maven里的镜像地址为阿里云，可以很快下完

2. 让你的pom.xml里依赖的包尽量都是公网可下载，可以直接用。如果测试代码依赖了公司内部的包，就麻烦了。只能通过U盘或者邮箱，一个一个的给拷贝进去机器上

3. 如果是最差情况即所有机器物理隔绝，没有远程桌面。那就需要从自己的本子上，将repository整个目录拷贝到机器里面去

这种方式和基于idea自动下载依赖包的方式不太一样，所以有概率会遇到即使本地仓库有这个包，当时idea里仍然飘红的找不到包的情况。
解决方案是刷新idea的仓库索引，具体操作步骤是：打开settings，搜索repositories，在搜索出来的页面中，选择Type是local的仓库，然后点击右边的Update按钮

总结

1. 在泥坑里的方式，确实可以将实际拷贝进去的数据变小（最终jar包是100M），如果拷贝仓库repo的话，大概时150M，测试代码本身的大小可以忽略不记
2. 简单而直观，就是美
3. 泥坑方式何时有用？对待你的敌人的时候。比如有个悬赏，如果你能够发现环境中存在的问题，就给你奖赏。那泥坑模式完全够用了。但是我们交付测试的目的却是对自己的检验，发现问题是表象，解决问题才是真正的目的。所以只能用更加多的步骤来发现问题，快速解决问题了