Designing Executable Test Cases: Principles, Common Pitfalls, and Practical Examples

In a product‑driven internet company, the concept of "use case design" is widely applied, treating test cases as an upgraded form of requirements within projects.

According to Wikipedia, a use case in software or systems engineering describes how a system responds to external requests, using user scenarios to capture requirements.

In the author's view, a use case is an executable description of a requirement, characterized by two features: a unique condition and a deterministic result.

Before proceeding, two typical questions are raised:

Should a case cover all possible requirements?

Should a case accommodate extreme situations?

The answers suggest that while a case cannot cover every scenario, it should at least represent a specific scenario or an equivalence class, and it should aim to solve extreme problems rather than merely tolerate them.

All cases—whether automated or functional—must be expressed under clear conditions, with each expected output recorded as an individual case, weaving them into a networked case set that strives to cover the entire requirement.

When analyzing conditions, a case must be executable, meaning it is explicit and unambiguous. For example, a game‑trade feature that offers a free price‑guess opportunity on each account refresh should not be described vaguely; instead, concrete cases such as "refresh from account A to B" or "account A displays one free opportunity" are needed.

Examples of detailed cases for the game‑account scenario include:

case1: from account A refresh to account B

case2: from account A refresh to account A

case3: account A shows one free opportunity by default

case4: clicking "guess price" on account A yields a result

case5: after the first result, a second click requires additional actions (e.g., payment or sharing)

case6: refresh from account A to B and display one free opportunity

case7: account B clicking "guess price" yields a result

case8: after the first result on account B, a second click requires extra steps

case9: refresh back to account A, free opportunity count is zero

Similarly, for a book‑purchase requirement, cases are defined to cover user entry points, purchase status, and sharing scenarios, ensuring each condition is unique and each result is deterministic.

Beyond individual cases, a comprehensive test plan must also consider boundary‑value cases, equivalence‑class cases, enumeration validation, as well as interface, security, compatibility, and performance testing, along with personnel, scheduling, environment, and deployment processes.

Summary

When personnel and schedule are arranged, the rhythm is set.

Understanding interfaces and modules defines the scope.

Designing cases and methods determines quality.