Comprehensive AI-Generated Test Cases for User Registration Forms

Test Strategy Overview

Design test cases using equivalence class partitioning , boundary value analysis , decision‑tree mapping of field combinations, error‑guessing , and explicit security checks (XSS, SQL injection, concurrency).

Account (username) field

Valid equivalence class

Case ACC-V-001: Alice123 – letters + digits, length 9 → Pass

Case ACC-V-002: Alice – only letters, length 5 (minimum) → Pass

Case ACC-V-003: ALICE – only uppercase letters, length 5 → Pass

Case ACC-V-004: AliceBobCharlieD – 20 letters (maximum) → Pass

Case ACC-V-005: A1b2C3d4E5f6G7h8I9j0 – 20 alphanumeric characters → Pass

Invalid equivalence class

Case ACC-IV-001: Al12 – 4 characters ( Fail : length below minimum)

Case ACC-IV-002: AliceBobCharlieDe – 21 characters ( Fail : exceeds maximum)

Case ACC-IV-003: 12345 – digits only ( Fail : letters required)

Case ACC-IV-004: alice!@# – contains special characters ( Fail )

Case ACC-IV-005: (empty) – required field missing ( Fail )

Case ACC-IV-006: 测试用户 – Chinese characters ( Fail )

Case ACC-IV-007: Alice_123 – underscore (ASCII 95) ( Fail )

Case ACC-IV-008: Alice 123 – space character ( Fail )

Boundary values

Case ACC-BV-001: Abcd – 4 characters ( Fail )

Case ACC-BV-002: Abcde – 5 characters ( Pass )

Case ACC-BV-003: Abcdef – 6 characters ( Pass )

Case ACC-BV-004: ... – 19 characters ( Pass )

Case ACC-BV-005: ... – 20 characters ( Pass )

Case ACC-BV-006: ... – 21 characters ( Fail )

Password field

Valid equivalence class

Case PW-V-001: Pass@123 – meets length, upper, lower, digit, special → Pass

Case PW-V-002: Aa1! (5) – minimum length, all required categories → Pass

Case PW-V-003: Aa1! repeated to 30 chars – maximum length, all categories → Pass

Case PW-V-004: (space)Aa1@ – includes ASCII 32 space → Pass

Case PW-V-005: Aa1~ – includes ASCII 126 tilde → Pass

Invalid equivalence class

Case PW-IV-001: Pass123 – missing special character ( Fail )

Case PW-IV-002: pass@123 – missing uppercase ( Fail )

Case PW-IV-003: PASS@123 – missing lowercase ( Fail )

Case PW-IV-004: Pass@word – missing digit ( Fail )

Case PW-IV-005: 密码@123 – contains Chinese characters ( Fail )

Case PW-IV-006: (empty) – required field missing ( Fail )

Combination missing categories

Case PW-IV-007: abcde – only lowercase letters ( Fail )

Case PW-IV-008: ABCDE – only uppercase letters ( Fail )

Case PW-IV-009: 12345 – only digits ( Fail )

Case PW-IV-010: !@#$% – only special characters ( Fail )

Boundary values

Case PW-BV-001: Aa1! (5) – lower boundary → Pass

Case PW-BV-002: Aa1@ (5) – alternative special char → Pass

Case PW-BV-003: Aa12 (4) – below minimum → Fail

Case PW-BV-004: ... – 30‑character valid password → Pass

Case PW-BV-005: ... – 31 characters → Fail

Special‑character verification

Case PW-SPC-001: Aa1 (space at end) – ASCII 32 → Pass

Case PW-SPC-002: Aa1! – ASCII 33 → Pass

Case PW-SPC-003: Aa1@ – ASCII 64 → Pass

Case PW-SPC-004: Aa1[ – ASCII 91 → Pass

Case PW-SPC-005: Aa1 + \x1F – control character (DEL) → Fail

Confirm Password field

Case CFM-V-001: password Pass@123, confirm Pass@123 → Pass

Case CFM-IV-001: password Pass@123, confirm pass@123 → Fail (case mismatch)

Case CFM-IV-002: password Pass@123, confirm Pass@124 → Fail (one character different)

Case CFM-IV-003: password Pass@123, confirm (empty) → Fail (required)

Mobile (phone) field

Valid format

Case MOB-V-001: 13800138000 – 11 digits starting with 1 → Pass

Case MOB-V-002: 19912345678 – also valid → Pass

Invalid format

Case MOB-IV-001: 1380013800 – 10 digits ( Fail )

Case MOB-IV-002: 138001380000 – 12 digits ( Fail )

Case MOB-IV-003: 23800138000 – does not start with 1 ( Fail )

Case MOB-IV-004: 1234567890a – contains a letter ( Fail )

Case MOB-IV-005: 123 4567 8901 – spaces ( Fail )

Case MOB-IV-006: +8613800138000 – international prefix ( Fail )

Case MOB-IV-007: 08613800138000 – leading 086 ( Fail )

Boundary values

Case MOB-BV-001: 10000000000 – smallest valid number → Pass

Case MOB-BV-002: 19999999999 – largest valid number → Pass

Email field

Case EMA-V-001: [email protected] → Pass

Case EMA-V-002: [email protected] → Pass

Case EMA-IV-001: userexample.com – missing @ → Fail

Case EMA-IV-002: user@ – missing domain → Fail

Case EMA-IV-003: user@example – missing top‑level domain → Fail

Case EMA-IV-004: [email protected] – @ followed by dot → Fail

Case EMA-IV-005: (empty) – required field missing → Fail

Case EMA-SEC-001: <script>alert('xss')</script>@example.com – XSS payload in local part → Fail (filtered)

Form‑level scenarios

Case FORM-V-001: all fields valid → registration succeeds, redirect or success message.

Case FORM-IV-001: any required field empty → submission blocked, field‑specific error shown.

Case FORM-IV-002: multiple fields invalid → all errors displayed, no submission.

Case FORM-SEC-001: concurrent registration of the same account → only one succeeds, others fail due to DB unique constraint.

Case FORM-SEC-002: bypass front‑end validation via modified JavaScript → back‑end still validates and rejects.

Case FORM-SEC-003: submit excessively long data (e.g., 1000‑character password) → back‑end truncates or rejects to prevent buffer overflow.

Security and concurrency tests

Case ACC-SEC-001: XSS payload <script>alert(1)</script> in account field → Fail , input filtered.

Case ACC-SEC-002: SQL injection admin' OR '1'='1 → Fail , no SQL error disclosed.

Case ACC-SEC-003: path traversal ../../etc/passwd → Fail , request rejected.

Case ACC-CON-001: 100 users register different accounts simultaneously → all succeed.

Case ACC-CON-002: 10 users register the same account simultaneously → only one succeeds, others receive duplicate‑account error.

Case PW-SEC-001: SQL injection string ' OR '1'='1 in password field → Fail , filtered.

Case PW-SEC-002: XSS payload <> alert(1) in password field → Fail , filtered.

Case PW-SEC-003: verify that the transmitted password is a SHA‑256 hash (no plaintext) → network request contains hash value.

Case PW-SEC-004: extremely long password (e.g., A*1000) → Fail , server rejects to prevent buffer overflow.

Additional technical recommendations

Uniqueness checks : Account, mobile, and email must have unique indexes in the database if business rules require it. Concurrency tests must verify that duplicate submissions are rejected.

Password handling : Passwords are hashed with SHA‑256 on the client before transmission; the server must apply a per‑user salt and hash again before storage.

Error messages : Do not expose internal details (e.g., database schema). Return generic, user‑friendly messages.

Input filtering : Perform both front‑end and back‑end validation/sanitisation for all fields to prevent XSS and SQL injection.

Performance consideration : Ensure the system correctly processes boundary‑length inputs (e.g., 30‑character passwords) without degradation.

Test priority (P0‑P2)

P0 : Core functionality – required‑field validation and format checks.

P1 : Boundary values, combination testing, uniqueness verification.

P2 : Security testing (XSS, SQL injection, transmission safety), concurrency testing, error‑guessing.

Automation suggestions

Use Selenium or Cypress for UI‑level test automation.

Employ Postman or JMeter for API testing and load/concurrency scenarios.

Run OWASP ZAP or similar tools for automated security scanning.

Database verification checklist

Confirm that submitted data is persisted correctly.

Verify that unique constraints on account, mobile, and email are enforced.

Ensure passwords are stored as salted SHA‑256 hashes, not plaintext.