使用SoapUI测试REST应用程序的登录功能 [英] Using SoapUI to test Login function of REST application

问题描述

我不会轻易提出这个非常笼统的问题，但是我已经尽我所能.

I don't make this very general question post lightly, but I've maxed out what I can figure out on my own.

我正在我的新公司中启动质量检查测试自动化(他们目前不自动化任何事情)，他们选择使用SoapUI进行此过程.

I'm starting up the QA Test Automation at my new company (they don't automate anything currently) and they've elected to use SoapUI for this procedure.

他们正在开发的应用程序是REST应用程序(我真的不知道这意味着什么)，所以我试图构建一个REST请求和测试套件以到达我们的内部测试服务器(这使我得到了XML)不允许在此处发布-但它确实可以成功到达服务器！)，然后尝试执行登录/注销测试.

The application they're developing is a REST application (I don't really have any idea what that means) so I'm trying to build a REST request and Test Suite to reach our internal test server (which gets me XML that I am not allowed to post here - but it does reach the server successfully!) and then try to do a Login/Logout test.

我正在寻求方法学方面的帮助，因为我不知道从哪里开始.我用Google搜索并浏览了他们的支持论坛，并浏览了YouTube的每个角落.每个人都在做一些与我无关或无法使用的事情.

I'm asking for help with methodology, because I have no idea where to start. I;ve Googled and trolled their support forums and looked in every corner of YouTube. Everyone is doing something different enough that I can't relate or use it.

外面有人在REST应用程序中使用SoapUI并测试功能登录吗?我可以编写HTML/CSS，并且非常精通Java，因此如果我知道要寻找的东西和要学习的东西，那么我可以做技术方面的事情.

Does anybody out there use SoapUI and test functional login in a REST application? I can write HTML/CSS and I'm pretty Java savvy, so I can do technical stuff if I know what to look for and what to learn.

感觉不知所措.我刚开始的时候，这不在我的职位描述中.

Feeling overwhelmed. This was not in my job description when I started.

推荐答案

您应该从REST开始，然后从SoapUI开始.

You should start with REST, and after that with SoapUI.

很难理解 REST 的本质.

这就像 SOAP 的杂种和简单的HTML驱动的Web应用 一样.通过 SOAP ，您可以用 WSDL 描述您的 Web服务.通过 Web应用程序，您发送回超媒体 ，因此您不必编写 WSDL 或任何描述符到您的应用程序.这是配置会议常规 ...

It is like the hybrid of SOAP and a simple HTML driven web application. By SOAP you describe your web service with a WSDL. By a web application you send back hypermedia, so you don't have to write a WSDL or any descriptor to your application. This is convention over configuration...

REST 使用相同的方法，因此它也会发送回 Hypermedia ，但是会发送不是 HTML ，因为它不可机加工. REST API 发送的超媒体通常是 XML 或 JSON 派生，例如 ATOM + XML ， hydra 是一个试图以一般方式描述这些应用程序级语义并将其绑定到开放链接数据 的项目.

REST uses the same approach, so it sends back hypermedia as well, but it sends not HTML, because it is not machine processable. The hypermedia sent by a REST API is usually an XML or a JSON derivative, for example ATOM+XML, JSON-LD, etc... If your web service does not send back hyperlinks, then it is not a real REST service just a SOAP web service with some REST constraints. There is a big difference. By SOAP you have to know everything about the operation name and the parameters if you want to send a request. If something changes, then your SOAP client breaks immediately. By REST your automated client follows links, checks their link-relation, or the bound linked data and recognizes which link is what it was looking for. So the modification of the link's url is irrelevant in the client, because it follows the vocabulary of the application, for example: hydra is a project which tries to describe these application level semantics in a general way, and tries to bind it to open linked data.

因此，首先，您必须检查您是否具有真实的 REST API ，该API紧随 端对端测试 反对. 通过测试 REST ，您必须遵循 web API 返回的测试中的链接.通过像 SOAP 这样测试 REST ，您必须在测试中自己构建链接 ... 如何构建这样的 link ?我确定您已经获得了 REST API 的描述，但是链接通常看起来像这样，格式为JSON:

So at first you have to check that you have a real REST API, which follows the HATEOAS principle, or just a REST like SOAP web service. This is very important if you want to write end to end tests against it. By testing REST, you have to follow the links in your tests returned by the web API. By testing REST like SOAP, you have to build the links yourself in your tests... How to build such a link? I am sure you got a description of your REST API, but a link looks usually something like this in a JSON format:

{ rel: "link-relations", method: "METHOD", href: "domain/api-root/version/resource-path?map-reduce", data: {...}, title: "...", ... }

{ rel: "link-relations", method: "METHOD", href: "domain/api-root/version/resource-path?map-reduce", data: {...}, title: "...", ... }

Ofc.每个超媒体都有一些区别，因此您必须检查您的 XML 超媒体类型，它如何表示链接 ... link-relations以及其他属性可能会将您的数据绑定到您的 REST API 的语义 . METHOD始终是动词 ，通常是: GET，POST，PUT，PATCH，DELETE ，也许是 OPTIONS >，依此类推......只有几个 REST动词 ，每个都有特定的含义. 在 url 中: domain是应用程序的域名，例如https://example.com. api-root是REST API (通常是/api)的根. version是当前使用的 API 的版本号，通常为/v1.仅非向后兼容的词汇更改应影响此版本号. resource-path是您的资源 的路径，通常是/users或/users/inf3rno等.通过REST，您拥有资源 .他们每个人都有一个唯一 resource-path，并且您可以看到，该路径中的每个单词都是一个名词 .因此，资源是您可以用动词 进行修改或显示的东西.例如，GET /users/inf3rno应该返回我的个人资料页面的表示形式，而PATCH /users/inf3rno {nick: "Leslie"}会将我的昵称:inf3rno转换为Leslie.通过 REST ，每个资源都应该只有一个 resource-path ，因此，它始终是一个唯一标识符，因此前面的示例中是如果您想让多个用户拥有相同的昵称，则PATCH 并不是那么完美... url的 queryString 中的 map-reduce ，其中包含 resource 您要修改或显示的.例如，您可以检索每个具有名的用户的某些数据:GET /users?filters="firstName: 'Leslie'"&page=3&count=25的"Leslie".以下 url -s之间有区别:/users?id="inf3rno"和/users/inf3rno.第一个指向集合资源，并通过其表示形式过滤结果，第二个指向单个项目资源.因此， GET 应该返回一个 collection表示，其中第一个是单个项，第二个是 item表示.通过 resource 修改 methods ，两个网址之间没有区别...因此，建议仅在中添加唯一标识符 c11>如果要从集合中选择项目资源.通过以任何其他方式减少集合表示，您必须将过滤器添加到 queryString . data部分包含来自输入字段 的 params . title是 link 的标题，依此类推...您可以使用

Ofc. there is some difference by every hypermedia, so you have to check your XML hypermedia type, how it represents links... The link-relations and maybe other attributes bind your data to the semantics of your REST API. The METHOD is always a verb, usually: GET, POST, PUT, PATCH, DELETE, maybe OPTIONS, and so on... There are only a few REST verbs, each of them has a specific meaning. In the url: The domain is the domain name of your application, e.g. https://example.com. The api-root is the root of your REST API, usually /api. The version is the version number of the currently used API, usually /v1. Only non backward compatible vocabulary changes should affect this version number. The resource-path is the path of your resource, usually /users or /users/inf3rno, etc... By REST you have resources. Each of them has a unique resource-path, and as you can see, every word in that path is a noun. So resources are something you can modify or display with a verb. For example a GET /users/inf3rno should return a representation of my profile page, and a PATCH /users/inf3rno {nick: "Leslie"} will turn my nick name: inf3rno into Leslie. By REST every resource should have only a single resource-path, so this is always a unique identifier, therefore the previous example with PATCH was not so perfect if you want to have multiple users with the same nick... The map-reduce in the queryString of the url, and it contains the sorting, pagination and filtering settings of the resource you want to modify or display. For example you can retrieve some data of every user with a first name: "Leslie" with GET /users?filters="firstName: 'Leslie'"&page=3&count=25. There is a difference between the following url-s: /users?id="inf3rno" and /users/inf3rno. The first one points to a collection resource and filters the result by its representation, the second one points to a single item resource. So a GET should return a collection representation with a single item by the first one, and an item representation by the seconds one. By the resource modifying methods there is no difference between the 2 urls... So it is recommended to add only a unique identifier to the resource-path if you want to select an item resource from a collection. By reducing the collection representation in any other ways, you have to add the filters to the queryString. The data part contains the params from the input fields. The title is the title of the link, and so on... You can use url-templates of you want to put input params to the url as well...
By REST the client maintains the session, and it sends the credentials (username, password) with every request. This is because the REST service is like John Snow, it does not know anything about the session or the identity of the user. It has to authenticate every request. To do that it uses a credentials -> permissions cache. This is a good approach, because the service scales very well if it does not have to maintain the session, which is part of the application state (the state of the client)... The REST service maintains only the resource state, which is not dependent on the clients...

对 REST请求的响应通常是超媒体，其中包含链接请按照以及您请求的数据.通过像 SOAP web services 这样的 REST ，您只能获取 JSON 或 XML 格式.每个响应都应包含适当的状态标题.最常见的状态代码是:

The response to your REST requests is usually a hypermedia which contains the links you can follow and the data you requested. By REST like SOAP web services you get only the data in a JSON or XML format. Every response should contain a proper status header. The most frequent status codes are:

• 200-确定(通过成功完成 PUT，PATCH和GET )
• 201-已创建(通过成功的 POST )
• 202-已接受(通过异步请求并最终保持一致)
• 204-无内容(通过成功删除 )
• 206-部分内容(通过与范围标题分页)
• 301-永久移动(通过迁移)
• 304-未修改(通过缓存)
• 400-错误的请求(通过无效输入)
• 401-未经授权(如果未提供密码，或用户名或密码错误)
• 403-访问被拒绝(如果您的帐户没有执行任务的权限)
• 404-找不到(通过未知资源)
• 409-冲突(由于并发问题或重复的请求或数据库约束问题)
• 410-消失了(如果资源以前存在，但是已经被删除)
• 415-不支持的媒体类型(如果客户端希望使用未知的媒体类型进行响应)
• 500-内部服务器错误(如果请求正常，但处理该请求时出现了问题)

• 200 - ok (by successful PUT, PATCH and GET)
• 201 - created (by successful POST)
• 202 - accepted (by async request with eventual consistency)
• 204 - no content (by successful DELETE)
• 206 - partial content (by pagination with range headers)
• 301 - moved permanently (by migration)
• 304 - not modified (by cache)
• 400 - bad request (by invalid input)
• 401 - unauthorized (if no password given, or wrong username or password)
• 403 - access denied (if your account does not have permission to perform the task)
• 404 - not found (by unknown resource)
• 409 - conflict (by concurrency issues or duplicated request or db constraint problems)
• 410 - gone (if the resource was present before, but it is already deleted)
• 415 - unsupported media type (if the client wants the response in an unknown media type)
• 500 - internal server error (if the request was okay, but something went wrong by processing it)

遇到任何错误，您都必须发送带有自定义错误代码的详细错误消息，这不仅对于开发人员，对于用户而言也是可以理解的...

这就是 REST API 的外观.

要使用 e2e测试对其进行测试，您必须设置夹具发送 REST请求并检查其响应.因此，就像任何其他测试一样…… SoapUI 不一定是做到这一点的最佳工具，我读过很多关于它的抱怨……我个人从未使用过它，但是它编写您的自定义测试系统并不难.您需要一个测试框架，该框架可以比较预期值和实际值.您需要一些东西来发送 HTTP请求，或者只是嘲笑 REST API 的 HTTP框架.您需要用于灯具的东西.通过集成测试，您也可以模拟业务逻辑和 HTTP框架，因此对于那些注入 模拟 依赖项并检查呼叫.通过 e2e测试，您需要一个测试数据集，并与您的情况下的结果 XML 进行比较...如果您想进行 e2e测试您的客户，如果硒是基于 HTML 的，则可以使用 nightwatch .js .通过测试真实的 REST API ，您将需要自动浏览器，例如 selenium 用于实现 REST API ，可以选择并遵循正确的链接.如果您要开发 REST API ，则如果您想为第三方客户开发人员提供示例 client ，则无论如何都要编写这样的浏览器.

To test it with e2e tests you have to set fixtures send REST requests and check their response. So it is like any other test... The SoapUI is not necessarily the best tool to do that, I read many complaints about it... I personally never used it, but it is not so hard to write your custom testing system. You need a testing framework, which can compare expected and actual values. You need something to send HTTP requests, or simply mock out the HTTP framework of the REST API. You need something for the fixture. By integration tests you can mock out the business logic and the HTTP framework as well, so by those you just inject the mock dependencies and check the calls. By e2e tests you need a test data set, and compare it with the result XML in your case... If you want to e2e test your client, you can use selenium if it is HTML based, maybe with nightwatch.js. By testing a real REST API, you'll need an automated browser, like selenium for your REST API implementation, which can select and follow the proper links. If you are developing the REST API you would write a browser like that anyways if you want an example client for your 3rd party client developers.

这篇关于使用SoapUI测试REST应用程序的登录功能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！