使用消息驱动的 Bean 和 Web 服务对 Java EE 应用程序进行功能测试的工具

发布于 2024-12-02 15:04:05 字数 573 浏览 1 评论 0原文

我需要测试一个完整的系统,该系统完全通过 JMS 和 JAX-WS 与世界通信。流程或多或少是这样的:

  1. 由单个 JMS 消息触发,
  2. 查询一些其他外部系统(通过 JMS 或 Web 服务)。
  3. 侦听队列上的答案(有时对于 1 个请求,预计会有许多回复)。
  4. 处理所需内容并将回复(通过 JMS)发送回调用系统(每一条触发消息也有一个或多个回复)。

我一直在寻找一种工具,它可以:

  • 模拟外部系统(即监听队列的另一端,分析请求并根据请求的内容进行回复),
  • 连接到不同的消息代理、Active MQ 和 Websphere MQ 是最需要的,
  • 创建测试用例逻辑,
  • 将结果与预期行为进行比较。

到目前为止,唯一接近的是 jMeter;它只缺乏侦听队列的能力。 还有其他想法吗?可以是免费的,也可以是商业的。

最后,在我看来,我必须部署一系列消息驱动的 bean 作为模拟,但我想确保我不会重新发明轮子。

I need to test a complete system that talks to the world entirely by JMS and JAX-WS. The flow, more or less, is this:

  1. Triggered by a single JMS message,
  2. Queries a few other external systems (via JMS or webservice).
  3. Listens for the answers on queues (sometimes for 1 request there are many replies expected).
  4. Processes what's needed and sends replies back (via JMS) to the calling system (also one or more replies per one triggering message).

I've been searching for a tool that could:

  • mock the external systems (that is, listen on other ends of queues, analyze requests and reply based on the contents of the request),
  • connect to different message brokers, Active MQ and Websphere MQ being the most wanted,
  • create test case logic,
  • compare the results with the expected behaviour.

The only thing that comes close so far is jMeter; it lacks only the ability to listen on a queue. Any other ideas? Could be free or commercial.

In the end, it seems to me I'd have to deploy a series of message-driven beans as mocks, but I want to make sure I'm not reinventing the wheel.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

离去的眼神 2024-12-09 15:04:05

SoapUI 具有对测试 Web 服务和 JMS 的本机支持。如果您不喜欢它,那么使用 Spring (spring-ws) 和 activeMQ 构建一个小型测试框架。

SoapUI has native support for testing web services and JMS. If you doesn't like it then build a small test framework using Spring (spring-ws) and activeMQ.

呆头 2024-12-09 15:04:05

最后我不得不编写自己的一套 MDB。

缺点:

  • 大量重复性工作,
  • 不可重用(项目的专用解决方案),
  • 错过了学习可以让我下次生活更轻松的工具的可能性,

优点:

  • 完全控制测试流程,
  • 能够将其部署到目标环境中(WAS 7) — 对于 SoapUI 来说可能是不可能的,
  • 以允许快速有效地开发大型测试集的方式编写它。

我询问的一些同事也推荐了这种方法。我很失望我没有找到更好的方法。

Finally I resorted to writing my own set of MDBs.

Cons:

  • much repetitive work,
  • not reusable (a dedicated solution to the project),
  • missed the possibility to learn a tool that could make my life easier next time,

Pros:

  • full control of the test flow,
  • ability to deploy it in the target environment (WAS 7) — probably out of the question with SoapUI,
  • wrote it in a way that allows developing large test sets in a fast and efficient way.

Some colleagues I asked also recommended this approach. I'm a disappointed I haven't found a better way.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文