这种情况是否被视为功能测试或其他形式的测试?

发布于 2024-08-11 17:03:05 字数 311 浏览 4 评论 0原文

我正在编写测试来检查外部服务是否正在提供库存数据(在其测试服务器上),我可以使用这些数据进行检查,也可以取消。此测试是在旅行/酒店领域进行的,我需要进行测试预订,然后取消它们。

我采取以下步骤: 1)搜索未来90天的库存(酒店房间) 2)获取第一个结果,并用它进行测试结账 3) 取消订单并确认我收到取消号码 4)确认执行了适当的数据库条目

此测试涉及系统的广泛部分,并且我(当前)没有隔离它们的机制。因此我不考虑这个单元测试。但是,这会被称为功能测试还是其他什么?

作为后续工作,它可能有助于为我正在交互的每个子系统隔离和编写测试。你们会从哪里开始隔离过程?

I'm writing tests that check that an external service is providing inventory data (on their test server) that I can check out with, and also cancel. This testing is in the travel/hotel world, and I need to place test reservations, then cancel them.

I take the following steps :
1) search for inventory(a hotel room) 90 days in the future
2) get the first result, and do a test checkout with it
3) cancel the order and confirm I get a cancellation number
4) confirm the appropriate database entries are performed

This testing touches wide ranging parts of the system, and I don't (currently) have mechanisms to isolate each of them. I therefore don't consider this unit testing. However, would this be called functional testing, or something else?

As a follow up, it will probably help to isolate and write tests for each of the subsystems I'm interacting with. Where would you guys start in the isolation process?

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

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

发布评论

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

评论(1

沐歌 2024-08-18 17:03:05

您列出的每个步骤都是隔离的良好候选者:

  1. 获取库存 结帐
  2. 获取
  3. 取消
  4. 取消 #

像您现在一样将它们串在一起只是每个步骤单独工作的功能。

您当前正在测试功能(很好!),但您没有提到稳健性。

我将为每个函数(如我所列出的)制作一套数据,试图打破它并探测极端情况。尝试过去预订、尝试覆盖 POST 数据、尝试过度预订房间、尝试同时预订同一个房间两次等。这些都作为输入参数存储在您仅为一个隔离编写的测试中您的申请。

不同的隔离区将具有不同的数据,这些数据对测试有用/有意义,但是随着每次更改/提交/构建,您应该能够针对每个函数运行测试数据并使结果有效(即您返回一个查询,退房、取消预订或取消预订#)

Each of those steps you listed is a good candidate for an isolation:

  1. Get inventory
  2. Check out
  3. Cancel
  4. Get cancellation #

Stringing them together as you do now is only a function of each of them working individually anyhow.

You're currently testing for functionality (good!) but you didn't mention robustness.

I would make a suite of data for each function (as I have listed) that would try to break it and probe corner cases. Try to book in the past, try to over-write POST data, try to over book a room, try to simultaneously book the same room twice, etc. This is all stored as input parameters in a test you have written just for one isolate of your application.

The different isolates will have different data that is useful/meaningful to test with, but with each change/commit/build, you should be able to run the test data against each function and have the results be valid (IE you return a query, check out a room, cancel the reservation, or get the cancellation #)

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