Generating 152 Login/Registration Test Cases with DeepSeek Harness
This article demonstrates using DeepSeek Harness to automatically generate 152 detailed test cases for login and registration modules, covering normal flows, boundary values, exception scenarios, security tests, and multi-condition combinations with verifiable expected results.
Overview
This article provides a complete walkthrough of using DeepSeek Harness ( @deepseek-ai/dsh) to generate comprehensive test cases for login and registration functionality. The process starts with environment setup, proceeds through requirement documentation and test design specification, and culminates in 152 structured test cases with full traceability to requirements.
1. Environment Setup
Ensure Node.js version >= v22.x.x (check via node --version).
Run npx @deepseek-ai/dsh web to launch the harness UI.
Access http://127.0.0.1:3080/ and create a skill.md file in the working directory defining the test generation rules.
2. Skill Definition ( skill.md )
The skill file specifies:
Inputs: PRD documents, API specifications, historical high-frequency bugs (optional).
Output format: Fixed table with columns: Case ID | Module | Test Scenario | Case Type | Priority | Preconditions | Steps | Expected Result.
Coverage requirements:
Normal flow: main path full coverage.
Exception scenarios: null, oversize, special characters, illegal enums, API idempotency.
Boundary values: parameter length limits, numeric critical values.
Multi-condition combinations: scenarios involving intersecting business rules listed separately.
Quality constraint: every expected result must be verifiable; vague phrases like "system handles normally" are forbidden.
3. Requirement Documents
Two Word documents under ./docs/:
登录测试.docx (Login Test): Account (5-20 chars, letters required, digits optional, no duplicates), Password (5-30 chars, must include uppercase, lowercase, digit, special char, SHA-256 hashed), Success message "系统欢迎您", Failure message "账号或密码错误", Security: XSS/CSRF/SQL injection prevention, Direct URL access redirects to login page.
注册测试.docx (Registration Test): Account (same rules), Password (same rules), Confirm password match, Phone (China format), Email (international format), Register button, Success message "注册成功!", Security: XSS/CSRF/SQL injection prevention, Uniqueness: account, email, phone each unique.
4. Requirement Extraction & Test Point Breakdown
DeepSeek Harness parsed both documents into 15 atomic requirements for login (L1-L18) and 19 for registration (R1-R19), each with a verifiable acceptance criterion. For example:
L1: Account length 5-20 → length 5 and 20 pass; 4 and 21 rejected with length-range message.
L11: Password SHA-256 in transit → request body shows 64-char hex digest, no plaintext.
R6: Password four character classes → missing any class rejected with specific missing-item message.
R9: Phone matches China format → 11 digits, first digit 1, second 3-9 pass; others rejected.
5. Assumptions for Unspecified Details (A1-A9)
Nine ambiguities were resolved with explicit assumptions, each linked to affected test cases:
A1: Special character set = !@#$%^&*()_+-=[]{};:,.?/.
A2: Password spaces allowed as literal characters, no server-side trim.
A3: Account case-sensitive (binary comparison for uniqueness).
A4: Messages displayed as visible page text (not alert), exact match with doc.
A5: Phone regex 1[3-9]\d{9} (11 digits).
A6: Email max length 254 chars.
A7: Login lockout after 5 consecutive failures for 15 minutes.
A8: Session timeout 30 minutes inactivity.
A9: Registration success stays on page showing "注册成功!".
6. Test Cases – Login Module (64 cases)
Cases are organized by type and priority (P0/P1/P2). Key examples:
Normal flow (10): TC-LOGIN-001 valid credentials → HTTP 200, "系统欢迎您", non-empty session token, protected API returns 200. TC-LOGIN-002 alphanumeric account, TC-LOGIN-003 all-letter account, TC-LOGIN-004 uppercase account, TC-LOGIN-005 mixed-case account.
Boundary values (10): TC-LOGIN-006 account length 5 (lower bound), TC-LOGIN-007 account length 20 (upper bound), TC-LOGIN-008 account length 4 (reject), TC-LOGIN-009 account length 21 (reject), TC-LOGIN-010 frontend input max-length enforcement, TC-LOGIN-011 password length 5, TC-LOGIN-012 password length 30, TC-LOGIN-013 password length 4 (reject), TC-LOGIN-014 password length 31 (reject).
Null/empty (6): TC-LOGIN-015 empty account, TC-LOGIN-016 empty password, TC-LOGIN-017 both empty, TC-LOGIN-018 account whitespace-only, TC-LOGIN-019 password whitespace-only, TC-LOGIN-020 no-parameter API call.
Illegal enum (11): TC-LOGIN-021 digits-only account, TC-LOGIN-022 underscore, TC-LOGIN-023 symbol, TC-LOGIN-024 Chinese chars, TC-LOGIN-025 leading/trailing spaces, TC-LOGIN-026 internal space, TC-LOGIN-027 emoji, TC-LOGIN-030 missing uppercase, TC-LOGIN-031 missing lowercase, TC-LOGIN-032 missing digit, TC-LOGIN-033 missing special char.
Special characters (2): TC-LOGIN-034 full special-char set in password, TC-LOGIN-035 + and space encoding consistency.
Security (13): TC-LOGIN-036 password XSS payload, TC-LOGIN-037 password masking, TC-LOGIN-048 account XSS, TC-LOGIN-049 reflected XSS via URL param, TC-LOGIN-050 account SQL injection, TC-LOGIN-051 password SQL injection, TC-LOGIN-052 UNION injection probe, TC-LOGIN-053 missing CSRF token, TC-LOGIN-054 forged cross-site login, TC-LOGIN-055 error response no sensitive leakage, TC-LOGIN-056 password SHA-256 in transit (packet capture), TC-LOGIN-057 password SHA-256 at rest (DB check), TC-LOGIN-058 tampered digest rejected, TC-LOGIN-059 session cookie attributes (HttpOnly, Secure, SameSite).
Multi-condition (10): TC-LOGIN-038 invalid account + valid password, TC-LOGIN-039 success message exact match, TC-LOGIN-040 post-login redirect, TC-LOGIN-041 failure message exact match, TC-LOGIN-042 non-existent account same message as wrong password (timing ≤200ms), TC-LOGIN-043 both wrong, TC-LOGIN-044 case mismatch, TC-LOGIN-045 5 failures trigger lockout, TC-LOGIN-046 success resets counter, TC-LOGIN-047 logged-in revisit login page, TC-LOGIN-060 unauthenticated direct URL to /home, TC-LOGIN-061 expired session direct URL, TC-LOGIN-062 logout then direct URL, TC-LOGIN-063 browser back after logout, TC-LOGIN-064 deep protected URL.
7. Test Cases – Registration Module (88 cases)
Similar structure with registration-specific fields:
Normal flow (10): TC-REG-001 all valid fields, TC-REG-002 alphanumeric account, TC-REG-003 all-letter account, TC-REG-004 uppercase account, TC-REG-005 account length 5, TC-REG-006 account length 20, TC-REG-041 valid phone, TC-REG-053 valid email, TC-REG-066 register then immediate login, TC-REG-074 success message exact match.
Boundary values (15): Account length 4/5/20/21, password length 4/5/30/31, phone 10/11/12 digits, email 254/300 chars, etc.
Null/empty (6): Missing account, password, confirm password, phone, email, all four.
Illegal enum (26): Account character set violations, password complexity missing each class, phone format violations (non-1 start, second digit 2, +86 prefix, spaces, hyphens, letters, full-width digits), email structure violations (missing @, double @, no dot in domain, leading dot, spaces).
Special characters (5): Password full set, + /space encoding, whitespace-only password, email spaces, email trim behavior.
Security (12): Stored XSS in account/email, error response leakage, SQL injection in account/email/phone, missing CSRF token, forged cross-site registration, extra fields (role/admin) ignored, invalid HTTP method (GET returns 405).
Idempotency (2): TC-REG-064 rapid button clicks (≤1 request, 1 DB row), TC-REG-065 request replay (first 200, subsequent 409).
Multi-condition (8): Password missing multiple classes, confirm password real-time validation, three-field uniqueness collision, case-sensitivity uniqueness, concurrent case-variant registration, all-fields oversize.
8. Statistics & Coverage Mapping
Total 152 cases: Login 64 (35 P0, 21 P1, 8 P2), Registration 88 (36 P0, 31 P1, 21 P2). Coverage matrix maps each skill.md requirement to representative test cases for both modules, demonstrating full coverage of normal flows, null, oversize, special chars, illegal enums, idempotency, boundary lengths, numeric thresholds, multi-condition combinations, and verifiable expected results.
9. Execution Prerequisites
Prepare 10 sets of unique account/email/phone for uniqueness tests; clean data after each use.
Fixed boundary datasets: account 4/5/6/19/20/21 chars, password 4/5/6/29/30/31 chars.
Tools: Fiddler/Charles (HTTPS capture), Burp Suite/Postman (tamper/replay), curl, DB client.
Environment: HTTPS, DB query/search permissions, server log access.
State reset: login failure counters, lockout states cleared between cases; registration data cleaned in order.
Confirm assumptions A1-A9 with product before execution; update expected results accordingly.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Woodpecker Software Testing
The Woodpecker Software Testing public account shares software testing knowledge, connects testing enthusiasts, founded by Gu Xiang, website: www.3testing.com. Author of five books, including "Mastering JMeter Through Case Studies".
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
