API Testing Methods Flashcards

Question 1

What does API testing check that differs from graphical user interface testing?

Accepted Answer

API testing verifies that an application programming interface receives requests, processes them, and returns correct responses directly, without going through the user interface. Testers send calls to endpoints and inspect status codes, payloads, and timing. Because the API is a contract between components, defects found here are cheaper to fix than those found later.

Question 2

Where does API testing usually sit in the test pyramid compared with unit and UI tests?

Accepted Answer

API testing usually sits in the middle of the test pyramid, above unit tests and below end-to-end user interface tests. It is faster and more stable than UI automation because it skips rendering and browser timing. Teams place many checks here because they catch integration defects without the cost of full interface runs.

Question 3

What is the difference between an API request and an API response?

Accepted Answer

An API request is the message a client sends to a server, containing a method, a URL, optional headers, and sometimes a body. An API response is the message the server returns, containing a status code, headers, and a body with the result. Testers check both sides of every exchange.

Question 4

Why is an API described as a contract between software components?

Accepted Answer

An API is described as a contract because it defines what one component may ask for and what it must return. The contract lists endpoints, accepted inputs, response formats, and error behavior. When either side changes without agreement, callers break, so tests compare actual behavior against the documented promises.

Question 5

What is the purpose of a test oracle in API testing?

Accepted Answer

A test oracle is the source that tells a tester whether observed behavior is correct. For APIs, oracles include the specification, an OpenAPI description, business rules, earlier known good responses, and reasonable expectations about speed and format. Without an oracle, a test can run and pass without proving anything useful about the system.

Question 6

What does it mean for an API test to be deterministic?

Accepted Answer

A deterministic test produces the same result every time it runs against the same system state and inputs. Non-deterministic API tests fail intermittently, because they depend on timing, shared data, or unpredictable external services. Testers improve determinism by creating their own test data, controlling dependencies, and avoiding assumptions about the order of responses.

Question 7

Why do testers use a staging or test environment for API checks?

Accepted Answer

A staging or test environment lets testers exercise endpoints with realistic configuration without affecting real customers or production data. It should mirror production in versions, authentication settings, and key integrations as closely as practical. Results there are more trustworthy when the environment is stable, isolated, and reset between runs.

Question 8

What is the difference between verification and validation in API testing?

Accepted Answer

Verification checks that the API is built according to its specification, such as returning the documented field names and status codes. Validation checks that the API meets the real need of its users, such as whether the returned data actually supports a business task. A response can pass verification yet still fail validation.

Question 9

What is the purpose of the GET method in an HTTP API?

Accepted Answer

GET requests retrieve a representation of a resource without intending to change server state. Testers verify that GET returns the expected data, correct status code, and proper content type. They also confirm that repeated GET calls do not alter stored records, since safe methods are expected to be free of side effects.

Question 10

How does a POST request differ from a PUT request in typical REST design?

Accepted Answer

POST is commonly used to create a new resource or submit data for processing, and the server often assigns the new identifier. PUT is commonly used to replace a resource at a known address, so repeating the same request should leave the same final state. Tests should confirm creation codes and idempotent behavior.

Question 11

What does the PATCH method do, and how is it different from PUT?

Accepted Answer

PATCH sends a partial update, changing only the fields included in the request while leaving other fields untouched. PUT normally expects a complete representation and replaces the whole resource. Testers should confirm that omitted fields keep their previous values and that invalid partial changes are rejected without corrupting the stored record.

Question 12

What does the DELETE method signal, and what should testers verify after it?

Accepted Answer

DELETE asks the server to remove the identified resource. After a successful call, testers should verify the expected success code, then confirm that a follow-up GET returns not found or the appropriate status. They should also check that deleting an already removed resource behaves consistently and does not expose internal errors.

Question 13

What do 2xx status codes indicate in an HTTP API response?

Accepted Answer

Status codes in the 2xx range indicate that the request was received, understood, and accepted as successful. The most common example is 200 OK. Examples include 201 Created after a new resource is made and 204 No Content when the action succeeds without a body. Testers should match the code to the action.

Question 14

What is the difference between a 400 and a 404 status code?

Accepted Answer

A 400 Bad Request means the server could not process the request because the input is malformed or invalid, so the problem lies with the request. A 404 Not Found means the server cannot find the requested resource at that address. Testers should confirm each code fits its situation.

Question 15

Why should testers check status codes and response bodies together rather than separately?

Accepted Answer

A status code summarizes the outcome, but the body carries the details. A response can return 200 OK while containing an empty list or an error message in the body, which a code alone would miss. Checking both together reveals contradictions and gives stronger evidence that the API behaves as specified.

Question 16

What does an idempotent HTTP method guarantee, and which methods are typically idempotent?

Accepted Answer

An idempotent method produces the same server state whether it is sent once or several times with identical input. GET, PUT, DELETE, HEAD, and OPTIONS are typically treated as idempotent, while POST usually is not. Testers verify this by repeating requests and comparing stored results, which helps detect duplicate records caused by retries.

Question 17

What is schema validation in API testing, and why does it matter?

Accepted Answer

Schema validation checks that a request or response matches a defined structure, including field names, data types, required properties, and allowed formats. It matters because clients often parse responses automatically, so a missing or renamed field can break an application without any visible error from the server.

Question 18

What are boundary value tests, and how would you apply them to an integer field?

Accepted Answer

Boundary value tests send inputs at the edges of an allowed range, such as the minimum, the maximum, and values outside each limit. For an integer field accepting 1 through 100, a tester would send 0, 1, 2, 99, 100, and 101. Results should show acceptance inside the range and clear rejection outside it.

Question 19

What is equivalence partitioning, and how does it reduce the number of tests?

Accepted Answer

Equivalence partitioning divides input values into groups that the system should treat the same way, then tests one representative from each group. Because values in a partition are expected to behave alike, testers avoid running many redundant cases. For a quantity field, valid, too small, too large, and non-numeric inputs form useful partitions.

Question 20

What should a negative test verify that a positive test does not?

Accepted Answer

A negative test verifies that the API rejects invalid, unauthorized, or unexpected input safely and predictably. Positive tests confirm that valid requests succeed, but they say little about how errors are handled. Negative tests check error codes, messages that avoid exposing internal details, and the absence of partial changes after a rejected request.

Question 21

How do testers verify that an API returns correct data rather than just a successful status?

Accepted Answer

Testers compare response fields with values they know to be correct, either from a seeded database, a fixed fixture, or a calculation performed independently. They check types, ranges, sorting, totals, and relationships between fields. A status code alone cannot show that the right customer, price, or count was returned.

Question 22

What is a contract test, and what problem does it solve?

Accepted Answer

A contract test checks that a provider and a consumer agree on the shape and behavior of their exchange without requiring both systems to run together. It solves the problem of a provider changing a response in a way that silently breaks a consumer. Failures appear early, close to the change that caused them.

Question 23

Why is it useful to test error responses for consistency across endpoints?

Accepted Answer

Consistent error responses let clients handle failures with one strategy instead of writing special cases for every endpoint. Testers check that errors share a common structure, use appropriate status codes, include a stable identifier, and avoid stack traces or internal details. Inconsistency often signals that teams built endpoints separately without shared rules.

Question 24

How do testers check authentication behavior, such as requests with missing or expired tokens?

Accepted Answer

Testers send the same request without credentials, with an invalid token, with an expired token, and as a user lacking permission. The API should return 401 for missing or invalid credentials and 403 when the caller is authenticated but not allowed to act. Protected data should never appear in error bodies.

Question 25

What is the purpose of testing input validation against injection attacks in APIs?

Accepted Answer

Injection testing checks whether untrusted input can change the meaning of a query, command, or template processed by the server. Testers submit characters and strings that commonly exploit weak handling, then confirm the API rejects, escapes, or safely parameterizes them. Successful tests show that user data stays data and never becomes executable instructions.

Question 26

Why should API tests check authorization separately from authentication?

Accepted Answer

Authentication confirms who the caller is, while authorization decides what that caller may access or change. A user can be correctly identified yet still be forbidden from another user's records. Testers should attempt cross-account and cross-role requests, because a valid login does not prove that object-level access rules are enforced.

Question 27

What is rate limiting, and how can testers verify it?

Accepted Answer

Rate limiting restricts how many requests a client can make within a time window, protecting the service from overload. Testers verify it by sending requests beyond the documented threshold and checking for the expected throttling response, commonly 429 Too Many Requests. They confirm that limits reset and that legitimate clients are not blocked early.

Question 28

What is the difference between load testing and stress testing for an API?

Accepted Answer

Load testing applies expected or peak traffic levels to confirm that response times and error rates stay within targets. Stress testing pushes the API beyond those levels to find its breaking point and observe how it recovers. Both use realistic request mixes, but stress tests aim to reveal failure behavior rather than normal capacity.

Question 29

What metrics do testers usually track during API performance testing?

Accepted Answer

Testers commonly track response time, often using percentiles such as the 95th percentile, along with throughput, error rate, and resource use on the server. Averages can hide slow outliers, so percentile values give a clearer picture of user experience. Results are most useful when compared against baselines or service level targets agreed in advance.

Question 30

Why is it important to measure API latency at percentiles rather than only at the average?

Accepted Answer

Average latency blends fast and slow requests, so a small number of very slow calls can remain hidden. Percentile measurements, such as p95 or p99, show the response time experienced by the slowest portion of users. This reveals whether tail latency is acceptable, which matters for users who hit the slowest paths.

Question 31

What is a common approach to testing an API's behavior under concurrent requests?

Accepted Answer

Testers send many requests at the same time against shared resources, such as the same account or inventory item, and then check for consistent final state. They look for race conditions like lost updates, duplicate records, or overbooked stock. Checking stored results after the burst helps reveal whether locking and transaction handling work correctly.

Question 32

Why should security scans be treated as a complement to, not a replacement for, manual API security testing?

Accepted Answer

Automated scanners quickly find known patterns, misconfigurations, and common weaknesses across many endpoints. Manual testing is needed for logic flaws, such as a user changing an identifier to read someone else's order, which scanners often miss. Combining both gives broader coverage than either approach achieves alone.

Question 33

What is the main benefit of automating API tests in a continuous integration pipeline?

Accepted Answer

Automated API tests run on every change, so regressions are reported soon after the code is committed. This shortens feedback loops and makes it safer to release frequently. Consistent execution also removes manual variation, although automated suites still need maintenance as the API evolves.

Question 34

What is data-driven testing, and when is it useful for APIs?

Accepted Answer

Data-driven testing separates test logic from test data, so one scripted flow runs repeatedly with many input and expected output combinations. It is useful for APIs with many similar validation rules, such as checking invalid email formats or currency codes. Keeping data in tables or files makes it easier for non-programmers to review coverage.

Question 35

What is mocking or service virtualization, and why would a tester use it for an API?

Accepted Answer

Mocking replaces a dependency with a controlled stand-in that returns predefined responses, while service virtualization simulates a dependent system broadly. Testers use them when a downstream service is unavailable, costly to call, or unable to produce specific error cases on demand. The approach isolates the API under test, but stand-ins must stay realistic.

Question 36

How should testers design assertions so an automated API test fails for the right reasons?

Accepted Answer

Assertions should check specific, meaningful expectations, such as a status code, a required field value, and a schema, rather than only confirming that some response arrived. Overly loose assertions miss defects, while overly rigid ones break when harmless details change. Failure messages should name the expected and actual values so the cause is clear.

Question 37

Why should test data be created and cleaned up within each automated API test?

Accepted Answer

Tests that create their own data avoid depending on records left behind by earlier runs, which keeps results repeatable. Cleaning up afterward prevents accumulated records from slowing queries, colliding on unique values, or changing counts that other tests expect. Shared fixtures can work, but they demand stricter coordination between tests.

Question 38

What should a good API test suite include when a team plans its coverage?

Accepted Answer

A balanced suite covers every endpoint's main success paths, important validation and error cases, authorization rules, and key integration flows. Teams should also prioritize endpoints by business risk, usage volume, and past defects. Coverage numbers help, but they should be read alongside how well the tests detect real faults.

Question 39

How can testers keep an API test suite maintainable as the API changes over time?

Accepted Answer

Maintainable suites keep shared logic in reusable helpers, such as authentication setup and request builders, so a single change updates many tests. Generating or validating tests from the API specification helps detect drift early. Regular review removes obsolete tests and clarifies names so failures remain understandable.

Question 40

What does it mean to shift API testing left in a software delivery process?

Accepted Answer

Shifting left means starting API testing earlier, often while the contract is still being designed, instead of waiting for a finished user interface. Teams write specifications, contract checks, and early tests alongside development. Defects found at this stage are generally cheaper and faster to correct than those discovered late in release preparation.

API Testing Methods Flashcards

1Core Concepts of API Testing

2HTTP Methods and Status Codes

3Functional and Validation Testing

4Security and Performance Testing

5Automation and Test Design

Learning Resources