What Is Exception Testing and How to Conduct It

Exception testing is a testing type different from functional and performance testing; it helps discover system problems caused by system exceptions, dependency service exceptions, or application anomalies, and assists in improving design schemes and enhancing system stability.

During regular functional testing, the focus is on normal business logic and potential performance issues under concurrent execution, often overlooking the impact of various exception scenarios; as product scale grows, it becomes impossible to anticipate every possible exception, so both positive and exception scenario testing are needed.

To carry out exception testing, one must first design exception test cases and choose appropriate test methods to simulate exception scenarios. This article uses a recycling business example to illustrate interface exception testing and business operation exception testing.

1. Interface Exception Testing

Interface exception testing is suitable during the interface testing phase and can lay the groundwork for subsequent business operation exception testing.

Overall process: understand product requirements, analyze requirement characteristics → understand interface implementation logic → design interface test cases → determine test methods.

Focus: whether the business code can tolerate dependency service call exceptions and input exceptions, and whether the tolerance logic is reasonable.

Test content: includes input exceptions, operation exceptions, service exceptions, etc.

Interface types: HTTP interfaces, SCF interfaces.

1.1 HTTP Interface Testing

The recycling valuation platform has many create, delete, and modify operations that require non‑empty and non‑duplicate validation. Front‑end validation alone cannot verify back‑end checks, so HTTP interface testing covers back‑end validation logic.

Key exception scenarios include:

Duplicate and non‑empty checks: name duplication, required fields empty.

Abnormal parameters: incomplete or duplicate parameters.

Abnormal queries: missing pagination info, missing category or model IDs.

Value validation: parameters set to non‑numeric types, containing special characters.

Testing tools: Yapi platform – design interface cases with abnormal parameters to verify interface responses under exception scenarios.

1.2 SCF Interface Testing

When testing the order process, focus is on order status flow; for the bidding interface, concurrency testing is performed to ensure the back‑end validates the recycle order status and prevents overselling.

Test configuration uses TestNG annotations to set invocationCount (execution times) and threadPoolSize (number of threads in the pool).

2. Business Operation Exception Testing

Usually performed after functional testing, this requires deep understanding of the project.

Overall process: combine business requirements → understand development implementation logic → design exception scenario cases → determine test methods.

2.1 Page Exception Operations

Idea: interface exception cases have already been covered, so focus on page‑level abnormal operations during functional testing.

Exception points: rapid multiple clicks on submit, frequent add/delete actions.

Test method: repeatedly operate the page to verify system behavior under concurrent conditions.

2.2 Excel Upload Exceptions

Idea: understand upload validation logic and design abnormal cases.

Exception points: special characters in content, incorrect file format, non‑empty validation, maximum row limit, header order consistency, internal business logic.

Test method: modify the Excel file to simulate abnormal data uploads.

2.3 General Exception Scenarios

(1) Idempotency Checks

Message resend: many submissions are asynchronous (e.g., SMS); verify that repeated sends are handled correctly.

Business retries: when connections timeout or fail, verify idempotent handling by simulating network or service timeouts.

(2) Cache Testing

DB synchronization: when important attributes (price, inventory) are added, edited, or deleted, ensure cache reflects DB changes.

Cache expiration: test data that should expire based on business rules.

Cache failure handling: simulate cache overflow or loss and verify system fallback (retry mechanisms, DB fallback).

(3) Interaction with Third‑Party Services

Interactions usually involve MQ or service calls; focus on idempotency verification and service timeout handling.

Duplicate MQ sending.

Use Yapi to mock interfaces, modify service timeout response times, and simulate third‑party service exceptions.

Summary and Outlook

Overall, the early interface testing, functional testing, and later exception testing together form a complete testing solution covering the entire test lifecycle.

Future work will continue to explore new testing methods, refine testing schemes, and strengthen quality control as the final safeguard.