如何测试未记录的 Web 服务？
我最近遇到这个问题，有人可以帮助我作为测试人员应该采取什么方法吗？
假设有一个 Web 服务的功能已更改，并且没有可用的文档。您将采用什么方法来测试相同的内容？
更新：如果数据库功能发生更改并且没有文档，相同的答案是否成立。
I came across this question recently, could anyone please help me what should be my approach as a tester.
Suppose, there is a webservice whose functionality have been changed and there is no documentation available of the same. What will be your approach to test the same?
Update: Does the same answer hold if Database functionality changed and no documentation.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您似乎可能会问两个不同的问题之一：
1) 如何发现黑盒 Web 服务的 API。
在这种情况下，最好的来源是 Web 服务的来源（文档存在故障），或者查看现有客户端或服务的 ?wsdl。
2) 如何发现网络服务的正确响应和错误响应。
为此，您需要需求、文档或正确的客户端。在这种情况下最有可能存在的是客户。或者，网络服务可能正在实现某些功能，其结果可以从外部确认。
It seems you might be asking one of two different questions:
1) How to discover the API of a black-box web service.
In this case, the best source would be the source of the web-service (with the existence failure of the documentation), alternatively look at existing clients, or the ?wsdl of the service.
2) How to discover what are correct and incorrect responses from the web service.
For this you need either requirements, or documentation, or correct clients. Probably the most likely to exist in this case is a client. Alternatively the web-service might be implementing some function the results of which can be confirmed externally.
没有文档就无法测试某些东西。您如何知道预期的结果是什么？
也许您在错误的地方寻找“文档”。有人做出了这些改变。他们有一些信息告诉他们要对数据库和服务进行哪些更改。甚至可能有需求文档，但也可能有一些设计文档。
获取这些，并使用它们来找出发生了什么变化。使用该信息来决定如何更改您的测试。
You can't test something with no documentation. How would you know what results to expect?
Maybe you're looking for "documentation" in the wrong place. Somebody made these changes. They had some information telling them what changes to make to the database and to the service. There may even be a requirements document, but maybe also some design documents.
Get those, and use them to figure out what changed. Use that information to decide how to change your tests.
如果您以有用的方式使用该服务，那么可能您有一些调用会返回一些已知的结果，即使这可能没有记录在案。如果是这种情况，那么我会编写测试来验证我对当前服务的期望。那么至少如果进行了更改，您将有更多机会知道哪些部分发生了影响您的更改。
If you are using the service in a useful way, then presumably you have some calls which return some known results, even though this may not be documented. If this is the case then I would write tests which validate my expectations of the service as it is currently. Then at least if changes are made you'll have more chance of knowing which bits have changed that affect you.
一般来说，Web 服务在提供服务和调用者之间提供一致的契约。它指定虽然后端实现可能会发生变化，但服务的接口将保持一致。
如果您有兴趣发现该服务可以使用哪些功能，它很可能会提供记录其可用功能和消息类型的元数据。通常，可以通过将“?wsdl”附加到 Web 服务 URL 来访问，但也存在其他方案。
一旦您很好地了解了可用的功能，您就可以开始通过测试框架调用它们，并根据您通常的测试流程评估响应。
Generally speaking, a web service provides a consistent contract between the providing service and callers. It specifies that whilst the back-end implementation might change, the interface for the service will remain consistent.
If you are interested in discovering what functions are available for the service, it may well provide metadata that documents it's available functions and message types. Usually, this is accessible by appending "?wsdl" to the web service URL, although other schemes exist.
Once you have a good idea of the available functions, you can begin to invoke them through your testing framework and evaluating the responses in accordance with your usual test processes.