测试公共 Web 服务的客户端
测试公共 Web 服务的自定义客户端的方法有哪些？
如今有许多在线服务提供 API。使用这些 API 的小应用程序正在蓬勃发展。示例：社交网络和博客平台的桌面/移动客户端、文档存储和处理中心、云数据库、实时数据流、GIS 数据等。
问题是，此类应用程序中的重要部分通常是与在线通信服务（处理错误、编码/解码数据、处理配额、调整 API 更新等），但客户端的开发人员不控制该服务。因此，我们无法直接看到测试的效果，也无法总是将服务状态回滚到原始状态。
- 您如何设计可重复的客户端测试？
- 你测试什么行为？
- 如何测试破坏性或重负载行为？ （针对公共服务）
- 您是否自动运行此类测试（例如作为预提交挂钩）？
- 如何针对特殊情况进行测试（从服务下降到超出配额、状态不一致、服务行为突然改变）？
What are approaches to test custom clients for public web services?
Today there are many online services which provide an API. There is a boom of little apps using those APIs. Examples: desktop/mobile clients for social networks and blogging platforms, document storage and processing centers, cloud databases, real-time data streams, GIS data etc.
The problem is that often the non-trivial part in such applications is communicating with the online service (handling errors, encoding/decoding data, dealing with quotas, adjusting to API updates etc.), but developers of the client do not control the service. So one cannot see directly what effects of the tests are, and one cannot always rollback the state of the service back to the original.
- how do you design your client tests to be reproducible?
- what behaviors do you test?
- how do you test destructive or heavy-load behaviors? (against a public service)
- do you run such tests automatically (e.g. as a pre-commit hook)?
- how do you test against extraordinary situations (from service is down to exceeding quota, to inconsistent state, to sudden change of service behavior)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
非常清楚您正在测试什么。您是否正在测试您的代码在收到服务响应时是否执行了预期的操作？既正常又不寻常？然后模拟该服务，以便您可以轻松地练习这些路径。
是的，我会设计可重复的测试，并在一些框架下运行它们，让我自动运行它们，最好也作为构建/提交的一部分。
但是测试服务本身又如何呢？有些测试只是在验证您的解决方案时出现的。例如重负载。好吧，虽然重要的是不要反社会，而且让公共服务饱和也是不合理的，但如果有公开的 SLA，那么我认为对其进行测试是合理的。因此，如果您的应用程序预计每秒发出 n 个请求，那么我们肯定至少应该测试这一点。测试我们的整体解决方案以满足其所需的吞吐量。
走向毁灭？也许太反社会了。不过，我确实认为，如果仅作为对您正在使用的服务进行健全性检查，发送有效和无效请求并检查是否发生预期响应可能是有效且有价值的。因此，我至少会有一个用于公共服务的回归套件，这样我就可以轻松验证它的行为是否符合记录。
Be very clear what you are testing. Are you testing that your code does what it's supposed to when it receives responses from the service? Both normal and extraordinary? Then mock the service, so that you can readily exercise those paths.
Yes I would design reprodicible tests and run them under some framework that lets me run them automatically, ideally as part of a build/commit too.
But what about testing the service itself. Some tests just emerge from validating your solution. For example heavy load. Well, although it's important not to be anti-social and it's not reasonable to saturate a public service, if there is a publised SLA, then I think it's reasonable to test up to that. So if your app is expected to emit n requests a second, then surely we should test at least this. Testing our overall solution up to its required throughput.
To destruction? Maybe too anti social. However I do think that sending both valid and invalid requests and checking that expected responses occur may be valid and valuable if only as a sanity check of the service you're using. So I would have at least a regression-suite for the public service, so that I can readily validate that it is behaving as documented.