AI Test Engineering Lesson 0006: From Requirements to Executable Test Documentation

Test Case Fundamentals

The IEEE‑829 standard defines eight mandatory elements for a complete test case:

Test Case ID – unique identifier (e.g., TC-LOGIN-001)

Test Item – the feature under test (e.g., user login)

Pre‑condition – state required before execution (e.g., user registered, not logged in)

Input – test data (e.g., email and password)

Steps – exact actions (e.g., open /login, enter credentials, click "Login")

Expected Result – desired system behaviour (e.g., redirect to /dashboard, show welcome message)

Post‑condition – state after execution (e.g., user logged in, session created)

Priority – importance (P0‑P3)

Test‑Case Design Techniques

1. Equivalence Partitioning

Divide input domain into classes that are expected to behave alike and pick one representative per class.

Valid classes – e.g., correct email format, password length 8‑20

Invalid classes – e.g., missing "@", password too short, password too long

有效等价类：
- E1：普通邮箱 ([email protected])
- E2：带点号的邮箱 ([email protected])
- E3：带加号的邮箱 ([email protected])

无效等价类：
- E4：缺少 @ (userexample.com)
- E5：缺少域名 (user@)
- E6：包含空格 (user @example.com)
- E7：超长字符串 (>254 characters)

2. Boundary‑Value Analysis

Most defects appear at the edges of valid ranges. Test the values just inside, on, and just outside the boundaries.

密码长度范围：[8, 20]
边界值：7, 8, 20, 21

| 输入 | 预期结果 |
|------|----------|
| "1234567"   | 提示 "密码长度至少 8 位" |
| "12345678"  | 通过 |
| "12345678901234567890" | 通过 |
| "123456789012345678901"| 提示 "密码长度最多 20 位" |

3. Scenario Testing

Model complete business flows as end‑to‑end scenarios.

Scenario 1: 正常创建任务
  前置：用户已登录
  当：点击 "创建任务"
  那么：任务成功创建并出现在列表顶部

Scenario 2: 网络中断
  前置：用户已登录
  当：网络断开并点击 "保存"
  那么：系统显示 "网络错误"，任务不保存

4. Decision Table

When several conditions combine to affect the outcome, a decision table makes the logic explicit.

条件                | 任务存在 | 有编辑权限 | 任务状态 | 操作
-------------------|----------|------------|----------|------
规则 1             | ✓        | ✓          | 草稿     | 允许编辑
规则 2             | ✓        | ✗          | 草稿     | 拒绝访问
规则 3             | ✗        | ✓          | 已发布   | 允许编辑
规则 4             | ✗        | ✗          | 已发布   | 拒绝访问

Gherkin vs Traditional Test Cases

Both describe test intent but differ in format, audience, executability, granularity and maintenance cost.

Format : Gherkin uses Given‑When‑Then; traditional cases list the eight elements.

Audience : Gherkin is readable by business and technical stakeholders; test cases target test engineers.

Executability : Gherkin can be run by BDD frameworks; test cases require manual or scripted execution.

Granularity : Gherkin works at scenario level; test cases work at step level.

When to use Gherkin : acceptance criteria, automated verification, collaboration with product owners.

When to use test cases : data‑driven verification, complex setups, low‑level technical checks.

Maintenance : Gherkin tends to be lower cost because it is business‑readable; traditional cases need more technical upkeep.

Test‑Case Design Principles

One expected result per case – split multi‑assertion scenarios into separate cases.

Independent execution – each case must set up its own pre‑conditions (e.g., create a test user via script).

Repeatable execution – avoid hard‑coded identifiers; obtain dynamic data via API calls.

Concrete Example: Login Feature

Three complete test cases illustrate the eight‑element structure.

TC‑LOGIN‑001 – 正常登录

Pre‑condition: user registered (email [email protected], password Pass123)

Input: same credentials

Steps: open /login, enter email, enter password, click "登录"

Expected: redirect to /dashboard, welcome message, session created

Priority: P0

TC‑LOGIN‑002 – 密码错误

Pre‑condition: same registration

Input: email [email protected], wrong password

Expected: error "邮箱或密码错误", stay on login page, no session

Priority: P0

TC‑LOGIN‑003 – 邮箱格式无效

Input: invalid-email, any password

Expected: inline validation "请输入有效的邮箱地址", login button disabled

Priority: P1

TaskFlow – Title Field Test Design

Title rules: required, 1‑200 characters, cannot be only spaces, must be XSS‑safe.

Equivalence classes (E1‑E7) and representative values are:

E1 – valid normal title (e.g., "完成测试文档")

E2 – boundary minimum ("A")

E3 – boundary maximum (200‑character string)

E4 – empty string

E5 – 201‑character string (exceeds limit)

E6 – only spaces (" ")

E7 – XSS payload (e.g., <script>alert(1)</script>)

Derived test cases (TC‑TASK‑001 … TC‑TASK‑007) combine class, input, and expected result:

TC‑TASK‑001 (E1) – "完成测试文档" → Pass, task created

TC‑TASK‑002 (E2) – "A" → Pass, task created

TC‑TASK‑003 (E3) – 200‑char string → Pass, task created

TC‑TASK‑004 (E4) – "" → Error "标题不能为空"

TC‑TASK‑005 (E5) – 201‑char string → Error "标题不能超过 200 字符"

TC‑TASK‑006 (E6) – " " → Error "标题不能只包含空格"

TC‑TASK‑007 (E7) – XSS payload → Input escaped, task created safely (P0)

Gherkin Acceptance Criteria for Task Creation

Feature: 任务创建

  Scenario: 创建有效任务
    Given 我已登录并位于任务列表页
    When 我点击 "新建任务"
    And 我填写标题 "完成测试文档"
    And 我设置截止日期 2026-12-31
    And 我点击 "保存"
    Then 任务创建成功
    And 我看到任务出现在列表顶部
    And 系统显示 "任务创建成功"

  Scenario: 标题为空
    Given 我已登录并位于任务创建页
    When 我不填写标题
    And 我点击 "保存"
    Then 系统显示 "标题不能为空"
    And 任务不被创建

Enterprise Example – Shopify Test‑Case Template

All cases are stored in GitHub, reviewed via pull‑requests, and automated for P0/P1 while manual for P2/P3.

## Test Case: [测试项]
**Test ID**: TC-[模块]-[序号]
**Priority**: P0/P1/P2/P3
**Type**: 功能 / 回归 / 冒烟 / 探索
**Labels**: [功能标签]

### Preconditions
[执行前的系统状态]

### Test Data
[需要的测试数据]

### Steps
1. 步骤 1
2. 步骤 2
3. 步骤 3

### Expected Results
- 结果 1
- 结果 2

### Actual Results (执行后填写)
[实际结果]

AI Practice Prompts

Generate test cases – ask the model to produce equivalence‑class tables, boundary analysis, and at least ten markdown test cases for a given feature.

Convert Gherkin to test cases – provide Gherkin text and request a full eight‑element test‑case document, data table, and expected‑result list.

Review test cases – feed a test case and ask the model to check for missing scenarios, redundancy, incomplete pre‑conditions, ambiguous expectations, and priority appropriateness.

QA Checklist

State the eight test‑case elements.

Explain the core idea of equivalence partitioning.

Explain the core idea of boundary‑value analysis.

Explain the core idea of scenario testing.

Distinguish when to use Gherkin versus traditional test cases.

Design test cases for TaskFlow task titles.

Use AI to assist test‑case generation.

Create a test‑plan document.

Thought Questions

If a feature has 100 input fields, how would you design test cases? Full coverage or selective?

When equivalence‑class boundaries are fuzzy, how do you handle them?

Can Gherkin completely replace test cases? When must traditional cases be used?

Which is more important for a test case – repeatability or independence? Why?

How do you deal with vague requirements in test cases?

Do you prefer "design‑first then write" or "write‑while‑designing" for test cases?

Recommended Reading

How to Write Good Test Cases – SoftwareTestingHelp (https://www.softwaretestinghelp.com/how-to-write-good-test-cases/)

Test Case Design Techniques – Guru99 (https://www.guru99.com/test-case-design.html)

Software Testing – Ron Patton

A Practitioner’s Guide to Software Test Design – Lee Copeland

Test Case Design Techniques – YouTube video (covers equivalence class, boundary value, decision table)