New answers tagged api-testing
0
Assuming that you are working on an isolated test environment (ie, that the only data the whole system works with is your test data), I would recommend approach #2, using a specific dataset.
From your description of approach #2 it seems like the test data also contains data from tests other than yours. That is the problem. If you can control the dataset, ...
1
The main difference in designing the GUI and API test-cases is the parameters verified and its expected result
GUI test-cases mostly validate the user flow and test-cases will comprise of the Pre-requisite, Steps to perform and the expected results at the user end
On the contrary, API test-cases will include endpoint details, the C/R/U/D operation to be ...
4
The user interacts with the GUI
The GUI interacts with the API
The API interacts with the back end
In theory the GUI tests should cover all the API tests, right? Well, what about when the GUI prevents the user from submitting invalid data? You still need to test that the API handles these cases sensibly. Each layer should be tested separately:
GUI: ...
1
Usually for UI testing I'll focus on the major work flows/use cases. You mentioned the CRUD operations. I'll have a test for each of these to make sure it works. Typically you can black box test these imo. "If this UI goes out tonight, and these work flows pass, the UI should be good"
For API's i usually have 1 or multiple tests for each endpoint and verify ...
3
Note: I will talk about testing itself since the documentation of certain activity is only but a product of the activity itself.
I'm not sure is your question is about "the testing for ... is different" or if the "the testing design for ... is different".
The second point talks about the heuristics for exploration, the "meta-hows". E.g.,
HICCUPPS:
...
4
Yes, API and GUI are different from a hardware product or command line enterprise software and as such requires specialized approach and techniques.
But GUIs and APIs are usually a very thin layer above the actual business logic and features, when designing a test you you obviously check that the GUI itself (colors or location of elements for example) or ...
2
you can use tools like owasp zap to find all the api calls . It spiders through most of the endpoints in search of security vulnerabilities.
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
Read about different scans:
https://github.com/zaproxy/zaproxy/wiki/ZAP-Full-Scan
https://github.com/zaproxy/zaproxy/wiki/ZAP-API-Scan
https://zaproxy....
2
If you have no endpoint documentation then the things are really bad. I would use the following aproach:
examine known clients which use the api
extract all possible invokations which the client can do
guess what is the client missing but might be supported by server like if you have order/create then there is a chance the server has order/update as well
...
Top 50 recent answers are included
