我们正在向SOA过渡。
我们目前的目标是尝试确保更多的应用程序被开发为＆＃34;服务＆＃34; （主要是为了提高能力，再利用和降低风险的可见性）。其中一些服务将作为Web服务公开，但许多（可能是大多数）不会，并且用于＆＃34;内部＆＃34;仅用于帮助获得SOA的一些好处。
对于那些＆＃34;内部＆＃34;我们目前打算将它们作为OSGi包实现的服务;然而，我们正在努力了解如何最好地测试它们。我们的目标是使当前的系统测试团队能够测试所有类型的服务，并且我们一直在研究SoapUI和SOA Test等工具;但是，我们可能会越来越清楚地看到，在使用这些工具测试我们作为OSGi捆绑软件实现的服务时，我们可能面临一些挑战;并且确实要求测试团队这样做。
因此，我们正在寻找一些关于如何最好地测试我们的功能方面的建议，这些功能旨在充当＆＃34;服务＆＃34;，但实现为OSGi捆绑而不是Web服务。
人们会推荐哪些工具，这是传统上由开发人员在单元测试期间完成的一种测试，或者可以由技术较少的测试人员完成，采用相同的测试界面基本原则（即输入，处理，输出）？
答案 0 :(得分：1)
理论上，您可以使用远程服务管理实施（如Aries RSA或Eclipse ECF）在测试期间将内部服务暴露给外部，以使用外部系统测试工具访问它们。
我不建议让外部团队测试您的OSGi服务。使用像pax exam这样的集成测试工具测试您自己的构建中的服务要好得多。它允许定义要安装的捆绑包和其他配置。然后，它会使用您的设置启动OSGi框架，并针对它运行修改后的junit测试。优点是这样的测试非常现实，而且非常简单。 请参阅此处了解aries rsa或apache karaf中的一些pax考试。 第一个示例使用pax检查分叉容器进行非常快速的测试（每个测试小于1秒），而第二个示例使用apache karaf容器（每个测试大约10秒）进行非常接近生产系统的测试。
因此，与外部系统测试团队相比，您获得的反馈要快得多，而后者总是落后于您当前的开发阶段。它还允许您在提交之前建立每个团队成员在本地运行测试的策略。