选项1（由于最佳做法，应首选）：在下面
重构配置文件，WEB-INF并将公用部分（你也希望从集成测试中访问）移至
src/main/resources/。然后写入特定于测试的配置文件
src/test/resources/（如果你只需要从中导入几个不同的配置文件
src/main以组装你的测试上下文，请跳过此步骤，并
@ContextConfiguration优先使用）。
选项2（hack）：
使用类似的引用：
@ContextConfiguration("file:src/main/webapp/WEB-INF/dataSource.xml")选项3（hack）：
如果你有Maven项目，则可以配置maven-surefire-plugin（在测试阶段使用）src/main/webapp在测试执行期间声明为其他classpath元素。
后两个选项被认为是hack，因为下面的文件src/main/webapp根本不应该位于类路径中。
现在详细说明：
之所以不能引用这些文件，
classpath:/WEB-INF/*.xml是因为它们确实不在类路径中。重要的是要了解你的Web应用程序是如何打包的，以及最终在类路径上结束的内容。假设默认的Maven项目结构为：
- Java类从编译后
src/main/java
进入/WEB-INF/classes
。 - 资源也从
src/main/resources
转到/WEB-INF/classes
。 - 项目依赖项转到
/WEB-INF/lib
。 - 你拥有的所有内容都
src/main/webapp
将到达/（包的根目录）。当然，这意味着所有文件都从src/main/webapp/WEB-INF
转到/WEB-INF
。
要知道的最重要的一点是，classpath将只包含/WEB-INF/classes一个条目，其中的每个jar 都包含一个条目/WEB-INF/lib。因此，对于类加载器，这两个位置之外的资源是完全不可见的。直接位于下 的xml配置文件也是如此/WEB-INF，这就是为什么该引用classpath:/WEB-INF/dataSource.xml永远无法工作的原因。
你可能会问自己，如果无法从类路径访问Spring，那么这些xml配置文件又会如何加载呢？答案很简单：启动webapp（而不是仅执行单元/集成测试）时，它运行在Servlet容器中，该容器提供
ServletContext对Servlet API的实际类的访问，因此它用于
ServletContext.getResourceAsStream()加载这些应用程序文件。理解的关键是该方法的javadoc中的以下引号：
此方法与使用类加载器的
java.lang.Class.getResourceAsStream不同。此方法允许Servlet容器从任何位置使servlet可以使用资源，而无需使用类加载器。
