GitLab

สรุปงาน (Summary)

พัฒนาชุดการทดสอบอัตโนมัติแบบครอบคลุม (Comprehensive Automated Test Suite) สำหรับ QA Brain เพื่อพิสูจน์ความปลอดภัยของขอบเขตข้อมูล (Isolation), การควบคุมการทำงานพร้อมกัน (Concurrency & CAS), ความสมบูรณ์ของ Constraints ในฐานข้อมูล, โซ่ Immutable Audit Trail (qa_audit_event), การตรวจ Typed Evidence, และการจำลอง Persona Workflow ระหว่าง AI Agent สองตัวกับ QA Lead (End-to-End Persona Verification)

อ้างอิงข้อกำหนดสถาปัตยกรรม: RFC v4.1 (Section 8)
ลำดับการทำงาน (Dependency): ขึ้นต่อกับ T1, T2, T3, T4, T5, T6

---

ขอบเขตและงานที่ต้องทำ (Scope of Work)

1. ชุดทดสอบความปลอดภัยและการแยกส่วนข้อมูล (Security & Isolation Tests)

1. Isolation Test: กุญแจเครื่อง (Machine Key) หรือบัญชี User ของโปรเจกต์ A ค้นหาหรืออ่านข้อมูลของโปรเจกต์ B ไม่ได้ในทุกมิติ (query, get_entry)
2. DRAFT Retrieval Immunity Test: การสืบค้นปกติ (query) ไม่ส่งคืนบทเรียน DRAFT และการเรียก get_entry ของ Gotcha Draft ตอบกลับเป็น NOT_FOUND เมื่อไม่มีสิทธิ์ QA_EDITOR+
3. Idempotency Replay Authorization Test: จำลองการส่งคำขอเดิมด้วย Idempotency Key ซ้ำหลังจากสิทธิ์ของผู้ใช้ในโปรเจกต์นั้นถูกเพิกถอน ระบบต้องตอบกลับ HTTP 403 FORBIDDEN (ไม่ส่งข้อมูลแคชเดิมคืน)
4. SSRF No-Fetch Test: ส่ง URL อันตรายหรือ Internal IP ใน evidenceRef และ evidenceDetail เซิร์ฟเวอร์ต้องไม่ทำการส่ง HTTP Request ออกไปภายนอกเด็ดขาด
5. Pre-Ingress Sanitizer Fail-Closed Test: จำลองสถานการณ์ Sanitizer เกิดข้อผิดพลาดหรือ ReDoS Timeout คำขอต้องหยุดทำงานแบบ Fail-Closed และไม่หลุด Raw Payload ลงในฐานข้อมูลหรือ Log
6. Machine Key Workspace-Wide Scope Test: ทดสอบ Machine Key ของโปรเจกต์ A สามารถอ่าน Gotcha ส่วนกลางของ Workspace (projectId = null) ได้ แต่ไม่สามารถอ่าน Gotcha ของโปรเจกต์ B ได้
7. Duplicate Advisory Scope Boundary Test: ทดสอบสร้าง Gotcha ในโปรเจกต์ A ด้วยคำที่ตรงกับ Gotcha ในโปรเจกต์ B ระบบต้องไม่ส่งชื่อเรื่องหรือ ID ของโปรเจกต์ B เข้ามาใน advisoryWarnings เด็ดขาด

2. ชุดทดสอบความสอดคล้องและการทำงานพร้อมกัน (Concurrency & DB Constraints Tests)

8. Database Constraint Negative Tests: ทดสอบยิงข้อมูลที่ละเมิด SQL Check Constraints:
   • channel = MCP_MACHINE แต่ระบุ actor_user_id $\rightarrow$ DB Reject
   • status = VERIFIED แต่ไม่มี verified_by_user_id หรือ verified_revision != version $\rightarrow$ DB Reject
   • ระบุ source_repo แต่เว้นว่าง source_path $\rightarrow$ DB Reject
9. Concurrent Atomic Idempotency Test: ยิงคำขอ happyqa_brain_record_gotcha พร้อมกัน 10 เธรดด้วย Idempotency Key เดียวกัน ต้องมีเพียง 1 Transaction บันทึกข้อมูลสำเร็จ อีก 9 คำขอได้รับคำตอบ Replay เดียวกัน
10. CAS Version Conflict Test: ยิงคำสั่ง Edit หรือ Verify ด้วย expectedVersion ที่ล้าหลัง ต้องได้รับข้อผิดพลาด VERSION_CONFLICT (HTTP 409)
11. Promotion Lineage & Cross-Workspace Rejection Test: ยกระดับบทเรียนสู่ Workspace ต้องสร้างแถวใหม่ (Promoted Copy) โดยคงต้นฉบับไว้ และต้องถูกปฏิเสธทันทีหากพยายามเชื่อมโยงข้าม Workspace ผ่าน Foreign Key
12. Typed Evidence (RUN_RESULT) Scope Validation Test: ส่งคำขอบันทึก Gotcha โดยระบุ evidenceType = RUN_RESULT แต่ใช้ Run ID ของโปรเจกต์อื่น ระบบต้องปฏิเสธด้วย VALIDATION_FAILED
13. Immutable Audit Trail Integrity Test: ทดสอบว่าทุกการสร้าง, แก้ไข, รับรอง, ปลดระวาง และโปรโมต มีการบันทึกลง qa_audit_event และสามารถตรวจสอบความต่อเนื่องของ Hash Chain ผ่าน verifyAuditChainRows ได้ 100%
14. Seed Anti-Overwrite Conflict Test: ยิงคำสั่ง Seed ซ้ำบนแถวที่มี manuallyModifiedAt != null ระบบต้องข้ามและรายงาน MANUALLY_MODIFIED_CONFLICT

3. ชุดทดสอบเสมือนจริงข้าม Agent (End-to-End Persona Acceptance Test)

15. Agent Collaboration Workflow Test:
    • Step 1: จำลอง Agent A (Claude Code) รันเทสและเจอบั๊ก/กับดัก $\rightarrow$ บันทึกบทเรียนผ่าน MCP tool happyqa_brain_record_gotcha (ได้สถานะ DRAFT)
    • Step 2: จำลอง QA Lead เข้าสู่ระบบบน Web UI ตรวจสอบรายละเอียดและหลักฐาน $\rightarrow$ กดรับรองบทเรียน (สถานะเปลี่ยนเป็น VERIFIED)
    • Step 3: จำลอง Agent B (ChatGPT หรือ Cursor ใน Session ใหม่) ได้รับมอบหมายงานทดสอบฟีเจอร์เดียวกัน $\rightarrow$ เรียก happyqa_brain_query $\rightarrow$ พบบทเรียนที่ Agent A จดไว้ $\rightarrow$ นำข้อแนะนำไปปรับแผนการทดสอบและหลบกับดักเดิมได้สำเร็จโดยไม่เกิดบั๊กซ้ำ

---

เกณฑ์การตรวจรับ (Acceptance Criteria)

• รันชุดทดสอบความปลอดภัยและการทำงานพร้อมกันทั้ง 14 ข้อแรกผ่าน 100% ในสภาพแวดล้อม CI/CD บน PostgreSQL
• รันการทดสอบจำลอง End-to-End Persona Workflow (ข้อ 15) ผ่านแบบสมบูรณ์ตั้งแต่ต้นจนจบ
• มีเอกสารสรุปผลการทดสอบ Test Run Report ยืนยันความพร้อมก่อนปล่อยฟีเจอร์ขึ้น Production