ข้ามไปที่เนื้อหา

Test Cases

ระบบผู้ดูแลระบบ (System Administrator Management System)

โรงพยาบาลค่ายธนรัชน์


เอกสารเลขที่: SRS-1.2.21-TESTCASES
เวอร์ชัน: 1.0
วันที่: 7 ตุลาคม 2568
ผู้จัดทำ: ทีมพัฒนาระบบ
ผู้อนุมัติ: ผู้อำนวยการโรงพยาบาลค่ายธนรัชน์
การปรับปรุง: ครอบคลุมฟีเจอร์ตาม TOR, SRS, DFD, ERD (IAM, System Config, Monitoring, Reporting, Communication)


📝 ประกอบการทดสอบ

🎯 Scope ของการทดสอบ

ระบบผู้ดูแลระบบจะครอบคลุมการทดสอบฟีเจอร์หลักดังนี้: - การจัดการผู้ใช้งานและกลุ่มผู้ใช้ (User & Group Management) - การจัดการบทบาทและสิทธิ์ (Role & Policy Management) - การตั้งค่าระบบและข้อมูลพื้นฐาน (System Configuration & Master Data) - การจัดการฐานข้อมูลและการสำรองข้อมูล (Database Management & Backup) - การจัดการรายงานและเทมเพลต (Report Management) - ระบบประกาศข่าวและแจ้งเตือน (Communication & Notification) - การตรวจสอบผู้ใช้งานออนไลน์และ Audit Logs (User Session Monitoring & Audit) - การเชื่อมโยงกับระบบอื่นและ API (Integration)

🚫 Out of Scope (ย้ายไประบบอื่น)

  • การจัดการข้อมูลผู้ป่วยโดยตรง → ทดสอบในระบบเวชระเบียน (1.2.1)
  • การดำเนินการทางการแพทย์ → ทดสอบในระบบเฉพาะทาง
  • การบริหารจัดการบุคลากรและเงินเดือน → ทดสอบในระบบ HR

รายการ Test Cases

Test Case Group 1: การจัดการผู้ใช้งาน (User Management)

Test Case: การสร้างผู้ใช้งานใหม่

Test ID: TC-001
Description: ทดสอบการสร้างบัญชีผู้ใช้งานใหม่ตามแนวทาง AWS IAM
Pre-condition: ระบบพร้อมใช้งาน, ผู้ใช้มีสิทธิ์ Super Admin หรือ System Admin
Test Steps:
1. เข้าสู่หน้าจัดการผู้ใช้งาน
2. คลิกปุ่ม "สร้างผู้ใช้งานใหม่"
3. กรอกข้อมูลพื้นฐาน: username, email, display_name, first_name, last_name
4. เลือก user_type: SUPER_ADMIN, SYS_ADMIN, DEPT_ADMIN, SEC_ADMIN, หรือ END_USER
5. กรอกข้อมูลเพิ่มเติม: employee_id, department_id, position_title, phone_number
6. ตั้งค่ารหัสผ่านเริ่มต้นและบังคับเปลี่ยนรหัสผ่าน
7. เปิดใช้ MFA (หากต้องการ)
8. บันทึกข้อมูล
Expected Result:
- ระบบสร้าง user_id ในรูปแบบ UUID อัตโนมัติ
- ระบบสร้าง user_arn ตามมาตรฐาน AWS IAM
- รหัสผ่านถูกเข้ารหัสด้วย bcrypt
- สถานะ status = 'ACTIVE'
- บันทึก created_by และ created_at
- แสดงข้อความยืนยันการสร้างสำเร็จ

Test Case: การตรวจสอบข้อมูลซ้ำซ้อน

Test ID: TC-002
Description: ทดสอบการตรวจสอบ username และ email ซ้ำซ้อน
Pre-condition: มีผู้ใช้งานในระบบแล้ว
Test Steps:
1. เข้าสู่หน้าสร้างผู้ใช้งานใหม่
2. กรอก username ที่มีอยู่ในระบบแล้ว
3. พยายามบันทึกข้อมูล
4. ทดสอบซ้ำกับ email ที่มีอยู่แล้ว
Expected Result:
- แสดงข้อความเตือน "Username นี้ถูกใช้งานแล้ว"
- แสดงข้อความเตือน "Email นี้ถูกใช้งานแล้ว"
- ไม่อนุญาตให้บันทึกข้อมูลซ้ำ
- ระบบเช็ค Unique Key constraints

Test Case: การแก้ไขข้อมูลผู้ใช้งาน

Test ID: TC-003
Description: ทดสอบการแก้ไขข้อมูลผู้ใช้งานที่มีอยู่
Pre-condition: มีผู้ใช้งานในระบบ, ผู้ใช้มีสิทธิ์แก้ไข
Test Steps:
1. ค้นหาและเลือกผู้ใช้งานที่ต้องการแก้ไข
2. คลิกปุ่ม "แก้ไขข้อมูล"
3. แก้ไขข้อมูลต่างๆ เช่น display_name, department_id, position_title
4. อัปเดต user_preferences (JSON)
5. เปลี่ยน status หากจำเป็น
6. บันทึกการเปลี่ยนแปลง
Expected Result:
- บันทึกการเปลี่ยนแปลงสำเร็จ
- อัปเดต updated_at และ updated_by
- เก็บ Audit Trail ของการเปลี่ยนแปลง
- แสดงข้อความยืนยันการอัปเดต

Test Case: การเปลี่ยนรหัสผ่าน

Test ID: TC-004
Description: ทดสอบการเปลี่ยนรหัสผ่านของผู้ใช้งาน
Pre-condition: ผู้ใช้งานล็อกอินอยู่ในระบบ
Test Steps:
1. เข้าสู่หน้า "เปลี่ยนรหัสผ่าน"
2. กรอกรหัสผ่านเก่า
3. กรอกรหัสผ่านใหม่ (ต้องตรงตาม Password Policy)
4. ยืนยันรหัสผ่านใหม่
5. บันทึกการเปลี่ยนแปลง
Expected Result:
- ตรวจสอบรหัสผ่านเก่าถูกต้อง
- รหัสผ่านใหม่ถูกเข้ารหัสด้วย bcrypt
- บันทึกใน PASSWORD_HISTORY
- อัปเดต password_expires_at
- ยกเลิก must_change_password (หากเป็น true)
- แสดงข้อความสำเร็จ

Test Case: การล็อกและปลดล็อกบัญชี

Test ID: TC-005
Description: ทดสอบการล็อกและปลดล็อกบัญชีผู้ใช้งาน
Pre-condition: มีผู้ใช้งานในระบบ, ผู้ใช้มีสิทธิ์ System Admin ขึ้นไป
Test Steps:
1. เลือกผู้ใช้งานที่ต้องการล็อกบัญชี
2. คลิกปุ่ม "ล็อกบัญชี"
3. ระบุเหตุผลและระยะเวลาล็อก
4. ยืนยันการล็อกบัญชี
5. ทดสอบการปลดล็อกบัญชี
Expected Result:
- เปลี่ยน status เป็น 'LOCKED' หรือ 'SUSPENDED'
- กำหนด account_locked_until
- บันทึก Security Event
- ผู้ใช้งานไม่สามารถล็อกอินได้
- สามารถปลดล็อกได้เมื่อถึงเวลา หรือแก้ไขด้วยตนเอง

Test Case: การตั้งค่า Multi-Factor Authentication (MFA)

Test ID: TC-006
Description: ทดสอบการเปิดใช้งาน MFA สำหรับผู้ใช้งาน
Pre-condition: ผู้ใช้งานล็อกอินอยู่ในระบบ
Test Steps:
1. เข้าสู่หน้า "การตั้งค่าความปลอดภัย"
2. เลือก "เปิดใช้งาน MFA"
3. เลือกประเภท MFA: SMS, Email, หรือ Authenticator App
4. ยืนยันการตั้งค่าด้วย OTP
5. บันทึกการตั้งค่า
Expected Result:
- เปลี่ยน mfa_enabled เป็น true
- สร้างข้อมูลใน MFA_CREDENTIALS table
- ทดสอบการล็อกอินด้วย MFA ในครั้งถัดไป
- บันทึก Security Event

Test Case: การค้นหาและกรองผู้ใช้งาน

Test ID: TC-007
Description: ทดสอบการค้นหาและกรองรายชื่อผู้ใช้งาน
Pre-condition: มีผู้ใช้งานหลายคนในระบบ
Test Steps:
1. เข้าสู่หน้ารายชื่อผู้ใช้งาน
2. ทดสอบค้นหาด้วย username
3. ทดสอบค้นหาด้วย display_name
4. กรองตาม user_type
5. กรองตาม department_id
6. กรองตาม status
Expected Result:
- แสดงผลลัพธ์การค้นหาถูกต้อง
- การกรองทำงานได้ตามเงื่อนไข
- รองรับการค้นหาแบบ partial match
- แสดงจำนวนผลลัพธ์ที่พบ

Test Case Group 2: การจัดการกลุ่มผู้ใช้งาน (Group Management)

Test Case: การสร้างกลุ่มผู้ใช้งานใหม่

Test ID: TC-008
Description: ทดสอบการสร้างกลุ่มผู้ใช้งานใหม่ตาม ERD (GROUPS table)
Pre-condition: ระบบพร้อมใช้งาน, ผู้ใช้มีสิทธิ์ System Admin ขึ้นไป
Test Steps:
1. เข้าสู่หน้าจัดการกลุ่มผู้ใช้งาน
2. คลิกปุ่ม "สร้างกลุ่มใหม่"
3. กรอกข้อมูล: group_name, display_name, description
4. เลือก group_type: MEDICAL, ADMINISTRATIVE, TECHNICAL, หรือ SYSTEM
5. เลือก department_id (หากเป็นกลุ่มเฉพาะแผนก)
6. กำหนด parent_group_id สำหรับ Nested Groups (หากมี)
7. กำหนด max_users (จำนวนสมาชิกสูงสุด)
8. บันทึกข้อมูล
Expected Result:
- ระบบสร้าง group_id ในรูปแบบ UUID อัตโนมัติ
- ระบบสร้าง group_arn ตามมาตรฐาน AWS IAM
- บันทึก created_by และ created_at
- แสดงข้อความยืนยันการสร้างสำเร็จ
- ตรวจสอบ Unique constraint ของ group_name

Test Case: การสร้าง Nested Groups (กลุ่มย่อย)

Test ID: TC-009
Description: ทดสอบการสร้างกลุ่มย่อยภายใต้กลุ่มหลัก
Pre-condition: มีกลุ่มหลักอยู่ในระบบแล้ว
Test Steps:
1. เลือกกลุ่มหลักที่ต้องการสร้างกลุ่มย่อย
2. คลิกปุ่ม "สร้างกลุ่มย่อย"
3. กรอกข้อมูลกลุ่มย่อย
4. ระบบกำหนด parent_group_id อัตโนมัติ
5. บันทึกข้อมูล
Expected Result:
- กลุ่มย่อยถูกสร้างภายใต้กลุ่มหลัก
- มีการ Inheritance สิทธิ์จากกลุ่มแม่
- แสดงโครงสร้างแบบ Tree Structure
- ป้องกัน Circular Reference

Test Case: การเพิ่มสมาชิกเข้ากลุ่ม

Test ID: TC-010
Description: ทดสอบการเพิ่มผู้ใช้งานเข้าเป็นสมาชิกกลุ่ม (USER_GROUPS table)
Pre-condition: มีกลุ่มและผู้ใช้งานในระบบ
Test Steps:
1. เลือกกลุ่มที่ต้องการเพิ่มสมาชิก
2. คลิกปุ่ม "เพิ่มสมาชิก"
3. ค้นหาและเลือกผู้ใช้งานที่ต้องการเพิ่ม
4. กำหนด is_primary_group (กลุ่มหลัก)
5. กำหนด expires_at (วันหมดอายุการเป็นสมาชิก - หากมี)
6. ยืนยันการเพิ่มสมาชิก
Expected Result:
- สร้างข้อมูลใน USER_GROUPS table
- บันทึก joined_at และ assigned_by
- ตรวจสอบ max_users ของกลุ่ม
- อัปเดตจำนวนสมาชิกของกลุ่ม
- ผู้ใช้งานได้รับสิทธิ์ของกลุ่ม

Test Case: การกำหนดกลุ่มหลัก (Primary Group)

Test ID: TC-011
Description: ทดสอบการกำหนดกลุ่มหลักสำหรับผู้ใช้งาน
Pre-condition: ผู้ใช้งานเป็นสมาชิกหลายกลุ่ม
Test Steps:
1. เลือกผู้ใช้งานที่ต้องการกำหนดกลุ่มหลัก
2. แสดงรายการกลุ่มที่ผู้ใช้งานเป็นสมาชิก
3. เลือกกลุ่มที่ต้องการเป็นกลุ่มหลัก
4. ยืนยันการเปลี่ยนแปลง
Expected Result:
- อัปเดต is_primary_group = true สำหรับกลุ่มที่เลือก
- อัปเดต is_primary_group = false สำหรับกลุ่มอื่น
- ผู้ใช้งานมีกลุ่มหลักเพียง 1 กลุ่ม

Test Case: การลบสมาชิกออกจากกลุ่ม

Test ID: TC-012
Description: ทดสอบการลบผู้ใช้งานออกจากกลุ่ม
Pre-condition: ผู้ใช้งานเป็นสมาชิกกลุ่ม
Test Steps:
1. เลือกกลุ่มและสมาชิกที่ต้องการลบ
2. คลิกปุ่ม "ลบสมาชิก"
3. ระบุเหตุผลการลบ
4. ยืนยันการลบ
Expected Result:
- อัปเดต is_active = false ใน USER_GROUPS
- ผู้ใช้งานสูญเสียสิทธิ์ของกลุ่ม
- บันทึก Audit Trail
- ตรวจสอบกลุ่มหลัก (ถ้าลบกลุ่มหลัก ต้องกำหนดกลุ่มใหม่)

Test Case: การแก้ไขข้อมูลกลุ่ม

Test ID: TC-013
Description: ทดสอบการแก้ไขข้อมูลกลุ่มผู้ใช้งาน
Pre-condition: มีกลุ่มในระบบ, ผู้ใช้มีสิทธิ์แก้ไข
Test Steps:
1. เลือกกลุ่มที่ต้องการแก้ไข
2. คลิกปุ่ม "แก้ไขกลุ่ม"
3. แก้ไขข้อมูล: display_name, description, max_users
4. เปลี่ยน parent_group_id (หากจำเป็น)
5. บันทึกการเปลี่ยนแปลง
Expected Result:
- บันทึกการเปลี่ยนแปลงสำเร็จ
- อัปเดต updated_at และ updated_by
- ตรวจสอบ max_users ไม่น้อยกว่าสมาชิกปัจจุบัน
- ป้องกัน Circular Reference ใน parent_group_id

Test Case: การลบกลุ่ม

Test ID: TC-014
Description: ทดสอบการลบกลุ่มผู้ใช้งาน
Pre-condition: มีกลุ่มในระบบ, ไม่ใช่ System Group
Test Steps:
1. เลือกกลุ่มที่ต้องการลบ
2. ตรวจสอบว่าไม่มีสมาชิกหรือกลุ่มย่อย
3. คลิกปุ่ม "ลบกลุ่ม"
4. ยืนยันการลบ
Expected Result:
- ตรวจสอบ is_system_group = false
- ตรวจสอบไม่มีสมาชิกที่ใช้งานอยู่
- ตรวจสอบไม่มีกลุ่มย่อย
- อัปเดต is_active = false
- บันทึก Audit Trail

Test Case Group 3: การจัดการบทบาทและนโยบาย (Role & Policy Management)

Test Case: การสร้างบทบาทใหม่

Test ID: TC-015
Description: ทดสอบการสร้างบทบาท (Role) ใหม่ตาม ERD (ROLES table)
Pre-condition: ระบบพร้อมใช้งาน, ผู้ใช้มีสิทธิ์ Security Admin ขึ้นไป
Test Steps:
1. เข้าสู่หน้าจัดการบทบาท
2. คลิกปุ่ม "สร้างบทบาทใหม่"
3. กรอกข้อมูล: role_name, display_name, description
4. เลือก role_type: CLINICAL, ADMINISTRATIVE, TECHNICAL, หรือ SYSTEM
5. กำหนด max_session_duration (วินาที)
6. สร้าง assume_role_policy และ trust_policy (JSON)
7. กำหนด external_id (หากจำเป็น)
8. บันทึกข้อมูล
Expected Result:
- ระบบสร้าง role_id ในรูปแบบ UUID อัตโนมัติ
- ระบบสร้าง role_arn ตามมาตรฐาน AWS IAM
- ตรวจสอบ Unique constraint ของ role_name
- บันทึก created_by และ created_at
- แสดงข้อความยืนยันการสร้างสำเร็จ

Test Case: การสร้างนโยบายการเข้าถึง

Test ID: TC-016
Description: ทดสอบการสร้างนโยบาย (Policy) ตาม ERD (POLICIES table)
Pre-condition: ระบบพร้อมใช้งาน, ผู้ใช้มีสิทธิ์ Security Admin
Test Steps:
1. เข้าสู่หน้าจัดการนโยบาย
2. คลิกปุ่ม "สร้างนโยบายใหม่"
3. กรอก policy_name และ description
4. เลือก policy_type: MANAGED, INLINE, หรือ CUSTOM
5. สร้าง policy_document (JSON) ตามรูปแบบ AWS IAM:
   - Version: "2024-10-07"
   - Statement: [Effect, Action, Resource, Condition]
6. กำหนด version
7. บันทึกข้อมูล
Expected Result:
- ระบบสร้าง policy_id ในรูปแบบ UUID อัตโนมัติ
- ระบบสร้าง policy_arn ตามมาตรฐาน AWS IAM
- ตรวจสอบ JSON syntax ของ policy_document
- ตั้งค่า is_default_version = true
- บันทึก created_by และ created_at

Test Case: การมอบหมายบทบาทให้ผู้ใช้งาน

Test ID: TC-017
Description: ทดสอบการมอบหมายบทบาทให้ผู้ใช้งาน (USER_ROLES table)
Pre-condition: มีบทบาทและผู้ใช้งานในระบบ
Test Steps:
1. เลือกผู้ใช้งานที่ต้องการมอบหมายบทบาท
2. คลิกปุ่ม "มอบหมายบทบาท"
3. เลือกบทบาทที่ต้องการมอบหมาย
4. กำหนด expires_at (วันหมดอายุ - หากมี)
5. กำหนด conditions (เงื่อนไขการใช้งาน - JSON)
6. ยืนยันการมอบหมาย
Expected Result:
- สร้างข้อมูลใน USER_ROLES table
- บันทึก assigned_at และ assigned_by
- ผู้ใช้งานได้รับสิทธิ์ตามบทบาท
- ตรวจสอบไม่มีบทบาทซ้ำสำหรับผู้ใช้งานคนเดียวกัน

Test Case: การแนบนโยบายกับบทบาท

Test ID: TC-018
Description: ทดสอบการแนบนโยบายกับบทบาท (POLICY_ATTACHMENTS table)
Pre-condition: มีบทบาทและนโยบายในระบบ
Test Steps:
1. เลือกบทบาทที่ต้องการแนบนโยบาย
2. คลิกปุ่ม "แนบนโยบาย"
3. เลือกนโยบายที่ต้องการแนบ
4. กำหนด principal_type = 'ROLE'
5. กำหนด effective_from และ effective_to
6. กำหนด conditions (เงื่อนไขเพิ่มเติม - JSON)
7. ยืนยันการแนบ
Expected Result:
- สร้างข้อมูลใน POLICY_ATTACHMENTS table
- อัปเดต attachment_count ใน POLICIES table
- บันทึก attached_at และ attached_by
- บทบาทได้รับสิทธิ์ตามนโยบาย

Test Case: การแนบนโยบายกับผู้ใช้งานโดยตรง

Test ID: TC-019
Description: ทดสอบการแนบนโยบายกับผู้ใช้งานโดยตรง (Inline Policy)
Pre-condition: มีผู้ใช้งานและนโยบายในระบบ
Test Steps:
1. เลือกผู้ใช้งานที่ต้องการแนบนโยบาย
2. คลิกปุ่ม "แนบนโยบายโดยตรง"
3. เลือกนโยบายหรือสร้างนโยบายใหม่ (Inline)
4. กำหนด principal_type = 'USER'
5. กำหนดเงื่อนไขการใช้งาน
6. ยืนยันการแนบ
Expected Result:
- สร้างข้อมูลใน POLICY_ATTACHMENTS table
- ผู้ใช้งานได้รับสิทธิ์ตามนโยบาย
- มีผลทันทีและไม่ขึ้นกับบทบาท

Test Case: การแนบนโยบายกับกลุ่มผู้ใช้งาน

Test ID: TC-020
Description: ทดสอบการแนบนโยบายกับกลุ่มผู้ใช้งาน
Pre-condition: มีกลุ่มและนโยบายในระบบ
Test Steps:
1. เลือกกลุ่มที่ต้องการแนบนโยบาย
2. คลิกปุ่ม "แนบนโยบายกลุ่ม"
3. เลือกนโยบายที่ต้องการแนบ
4. กำหนด principal_type = 'GROUP'
5. กำหนดเงื่อนไขการใช้งาน
6. ยืนยันการแนบ
Expected Result:
- สร้างข้อมูลใน POLICY_ATTACHMENTS table
- สมาชิกทุกคนในกลุ่มได้รับสิทธิ์ตามนโยบาย
- สิทธิ์มีผลแบบ Inheritance

Test Case: การทดสอบการประเมินสิทธิ์ (Permission Evaluation)

Test ID: TC-021
Description: ทดสอบการประเมินสิทธิ์การเข้าถึงตาม Policy Document
Pre-condition: ผู้ใช้งานมีบทบาทและนโยบาย
Test Steps:
1. ผู้ใช้งานพยายามเข้าถึงทรัพยากร (เมนู/ฟังก์ชัน)
2. ระบบประเมินสิทธิ์จาก:
   - User Policies (แนบโดยตรง)
   - Role Policies (จากบทบาท)
   - Group Policies (จากกลุ่ม)
3. ตรวจสอบ Effect: ALLOW vs DENY
4. ตรวจสอบ Conditions (เวลา, IP, ฯลฯ)
Expected Result:
- ระบบอนุญาตหรือปฏิเสธการเข้าถึงถูกต้อง
- DENY มีความสำคัญสูงกว่า ALLOW
- บันทึก Access Log
- แสดงเหตุผลการอนุญาต/ปฏิเสธ

Test Case: การยกเลิกการมอบหมายบทบาท

Test ID: TC-022
Description: ทดสอบการยกเลิกการมอบหมายบทบาทจากผู้ใช้งาน
Pre-condition: ผู้ใช้งานมีบทบาทที่มอบหมายแล้ว
Test Steps:
1. เลือกผู้ใช้งานและบทบาทที่ต้องการยกเลิก
2. คลิกปุ่ม "ยกเลิกบทบาท"
3. ระบุเหตุผลการยกเลิก
4. ยืนยันการยกเลิก
Expected Result:
- อัปเดต is_active = false ใน USER_ROLES
- ผู้ใช้งานสูญเสียสิทธิ์ของบทบาท
- ยังคงมีสิทธิ์จากแหล่งอื่น (User/Group Policies)
- บันทึก Audit Trail

Test Case Group 4: การตั้งค่าระบบ (System Configuration)

Test Case: การตั้งค่าเริ่มต้นของระบบ

Test ID: TC-023
Description: ทดสอบการตั้งค่าเริ่มต้นต่างๆ ตาม TOR ข้อ 1 (SYSTEM_CONFIG table)
Pre-condition: ระบบพร้อมใช้งาน, ผู้ใช้มีสิทธิ์ System Admin
Test Steps:
1. เข้าสู่หน้า "การตั้งค่าระบบ"
2. แก้ไขการตั้งค่าเริ่มต้น:
   - ข้อมูลโรงพยาบาล (ชื่อ, ที่อยู่, โทรศัพท์)
   - การตั้งค่าเวลาและโซนเวลา
   - การตั้งค่าภาษา (ไทย/อังกฤษ)
   - การตั้งค่าสกุลเงิน
   - การตั้งค่า Session timeout
3. บันทึกการเปลี่ยนแปลง
Expected Result:
- บันทึกข้อมูลใน SYSTEM_CONFIG table
- กลุ่มการตั้งค่า (config_group) และคีย์ (config_key)
- ข้อมูลเป็น JSON ใน config_value
- อัปเดต effective_date สำหรับการตั้งค่าใหม่
- บันทึก updated_by และ updated_at

Test Case: การตั้งค่าหมายเลข HN-VN-AN

Test ID: TC-024
Description: ทดสอบการตั้งค่าการทำงานของหมายเลข HN, VN, AN (HN_VN_AN_CONFIG table)
Pre-condition: ระบบพร้อมใช้งาน, ผู้ใช้มีสิทธิ์ System Admin
Test Steps:
1. เข้าสู่หน้า "การตั้งค่าหมายเลข"
2. ตั้งค่า HN (Hospital Number):
   - รูปแบบหมายเลข (prefix, length, suffix)
   - หมายเลขเริ่มต้น (start_number)
   - หมายเลขปัจจุบัน (current_number)
3. ตั้งค่า VN (Visit Number) และ AN (Admission Number) แบบเดียวกัน
4. ตั้งค่าการ Reset (รายปี/รายเดือน/ไม่ Reset)
5. บันทึกการตั้งค่า
Expected Result:
- บันทึกการตั้งค่าใน HN_VN_AN_CONFIG table
- ระบบสร้างหมายเลขตามรูปแบบที่กำหนด
- ตรวจสอบการไม่ซ้ำของหมายเลข
- บันทึก Audit Trail การเปลี่ยนแปลง

Test Case: การตั้งค่าฐานข้อมูล MySQL

Test ID: TC-025
Description: ทดสอบการตั้งค่าการใช้งานฐานข้อมูล MySQL ตาม TOR ข้อ 7
Pre-condition: ระบบพร้อมใช้งาน, มี MySQL Server
Test Steps:
1. เข้าสู่หน้า "การตั้งค่าฐานข้อมูล"
2. ตั้งค่าการเชื่อมต่อ MySQL:
   - Host/IP Address
   - Port (default: 3306)
   - Database Name
   - Username/Password
   - Connection Pool settings
3. ทดสอบการเชื่อมต่อ
4. ตั้งค่า Backup Schedule
5. บันทึกการตั้งค่า
Expected Result:
- บันทึกการตั้งค่าใน DATABASE_CONFIG table
- ทดสอบการเชื่อมต่อสำเร็จ
- ข้อมูล Password ถูกเข้ารหัส
- แสดงสถานะการเชื่อมต่อ

Test Case: การตั้งค่าฐานข้อมูล PostgreSQL

Test ID: TC-026
Description: ทดสอบการตั้งค่าการใช้งานฐานข้อมูล PostgreSQL ตาม TOR ข้อ 7
Pre-condition: ระบบพร้อมใช้งาน, มี PostgreSQL Server
Test Steps:
1. เข้าสู่หน้า "การตั้งค่าฐานข้อมูล"
2. เลือกประเภท: PostgreSQL
3. ตั้งค่าการเชื่อมต่อ PostgreSQL:
   - Host/IP Address
   - Port (default: 5432)
   - Database Name
   - Username/Password
   - SSL Mode
4. ทดสอบการเชื่อมต่อ
5. บันทึกการตั้งค่า
Expected Result:
- รองรับการเชื่อมต่อ PostgreSQL
- ทดสอบการเชื่อมต่อสำเร็จ
- จัดการ SSL Connection
- แสดงข้อมูล Schema และ Tables

Test Case: การจัดการข้อมูลพื้นฐาน (Master Data)

Test ID: TC-027
Description: ทดสอบการตั้งค่าข้อมูลพื้นฐานตาม TOR ข้อ 8 (MASTER_DATA_CATEGORIES, MASTER_DATA_ITEMS)
Pre-condition: ระบบพร้อมใช้งาน, ผู้ใช้มีสิทธิ์ System Admin
Test Steps:
1. เข้าสู่หน้า "จัดการข้อมูลพื้นฐาน"
2. สร้างหมวดหมู่ข้อมูล (Category):
   - ประเภทแผนก (DEPARTMENT)
   - ประเภทสิทธิ์ (RIGHTS)
   - ประเภทโรค (DISEASE)
   - ประเภทยา (MEDICATION)
3. เพิ่มรายการข้อมูลใน Category:
   - รหัส (item_code)
   - ชื่อไทย (name_th)
   - ชื่ออังกฤษ (name_en)
   - คำอธิบาย (description)
4. บันทึกข้อมูล
Expected Result:
- บันทึกข้อมูลใน MASTER_DATA_CATEGORIES และ MASTER_DATA_ITEMS
- ตรวจสอบ Unique constraint ของ item_code
- รองรับการ Import/Export ข้อมูล
- มีการ Validation ข้อมูล

Test Case: การตั้งค่าการสำรองข้อมูลอัตโนมัติ

Test ID: TC-028
Description: ทดสอบการตั้งค่าการสำรองข้อมูลอัตโนมัติ (BACKUP_JOBS table)
Pre-condition: ระบบพร้อมใช้งาน, มีพื้นที่จัดเก็บ Backup
Test Steps:
1. เข้าสู่หน้า "การตั้งค่า Backup"
2. สร้างงาน Backup ใหม่:
   - ชื่องาน (job_name)
   - ประเภท Backup (FULL, INCREMENTAL, DIFFERENTIAL)
   - ตารางหรือฐานข้อมูลที่ต้องการ Backup
   - กำหนดเวลา (schedule_pattern)
   - ที่จัดเก็บ (backup_path)
3. กำหนดการเก็บรักษา (retention_days)
4. เปิดใช้งาน (is_enabled = true)
Expected Result:
- บันทึกข้อมูลใน BACKUP_JOBS table
- ระบบ Backup ทำงานตามกำหนด
- บันทึกประวัติใน BACKUP_HISTORY table
- แจ้งเตือนเมื่อ Backup สำเร็จ/ล้มเหลว

Test Case: การตั้งค่าการแจ้งเตือนระบบ

Test ID: TC-029
Description: ทดสอบการตั้งค่าการแจ้งเตือนเหตุการณ์ต่างๆ ของระบบ
Pre-condition: ระบบพร้อมใช้งาน, มี Email Server
Test Steps:
1. เข้าสู่หน้า "การตั้งค่าการแจ้งเตือน"
2. ตั้งค่า Email Server:
   - SMTP Host และ Port
   - Username/Password
   - SSL/TLS Settings
3. กำหนดประเภทการแจ้งเตือน:
   - System Error
   - Backup Success/Failure
   - Security Events
   - User Login/Logout
4. กำหนดผู้รับการแจ้งเตือน
5. บันทึกการตั้งค่า
Expected Result:
- บันทึกการตั้งค่าใน SYSTEM_CONFIG
- ทดสอบการส่ง Email สำเร็จ
- ระบบส่งการแจ้งเตือนได้
- บันทึก Log การส่งการแจ้งเตือน

Test Case: การ Import/Export การตั้งค่าระบบ

Test ID: TC-030
Description: ทดสอบการ Import/Export การตั้งค่าระบบทั้งหมด
Pre-condition: ระบบมีการตั้งค่าต่างๆ อยู่แล้ว
Test Steps:
1. เข้าสู่หน้า "Import/Export การตั้งค่า"
2. Export การตั้งค่าปัจจุบัน:
   - เลือกกลุ่มการตั้งค่าที่ต้องการ Export
   - เลือกรูปแบบไฟล์ (JSON, XML, CSV)
   - ดาวน์โหลดไฟล์
3. Import การตั้งค่าใหม่:
   - อัปโหลดไฟล์การตั้งค่า
   - ตรวจสอบความถูกต้องของข้อมูล
   - นำเข้าข้อมูล
Expected Result:
- Export ข้อมูลออกมาได้ถูกต้อง
- Import ข้อมูลเข้าระบบได้
- มีการ Validation ข้อมูล
- บันทึก Audit Trail การ Import/Export

Test Case Group 5: การสื่อสารและติดตาม (Communication & Monitoring)

Test Case: การเขียนประกาศข่าว

Test ID: TC-031
Description: ทดสอบการเขียนประกาศข่าวตาม TOR ข้อ 5 (NEWS_ANNOUNCEMENTS table)
Pre-condition: ระบบพร้อมใช้งาน, ผู้ใช้มีสิทธิ์สร้างประกาศ
Test Steps:
1. เข้าสู่หน้า "จัดการประกาศข่าว"
2. คลิกปุ่ม "สร้างประกาศใหม่"
3. กรอกข้อมูลประกาศ:
   - หัวข้อประกาศ (title)
   - เนื้อหาประกาศ (content) - รองรับ Rich Text
   - ระดับความสำคัญ (priority): HIGH, MEDIUM, LOW
   - ประเภทประกาศ (announcement_type): SYSTEM, MAINTENANCE, NEWS, ALERT
4. กำหนดช่วงเวลาแสดง (publish_start_date, publish_end_date)
5. เลือกกลุ่มเป้าหมาย (target_groups, target_users)
6. อัปโหลดไฟล์แนบ (หากมี)
7. บันทึกประกาศ
Expected Result:
- บันทึกข้อมูลใน NEWS_ANNOUNCEMENTS table
- ระบบสร้าง announcement_id ในรูปแบบ UUID
- ประกาศแสดงตามช่วงเวลาที่กำหนด
- ส่งการแจ้งเตือนไปยังกลุ่มเป้าหมาย
- บันทึก created_by และ created_at

Test Case: การส่งข้อความเตือนผู้ใช้งาน

Test ID: TC-032
Description: ทดสอบการส่งข้อความเตือนผู้ใช้งานตาม TOR ข้อ 5 (NOTIFICATIONS table)
Pre-condition: ระบบพร้อมใช้งาน, มีผู้ใช้งานในระบบ
Test Steps:
1. เข้าสู่หน้า "ส่งการแจ้งเตือน"
2. เลือกประเภทการแจ้งเตือน:
   - SYSTEM_ALERT (แจ้งเตือนระบบ)
   - MAINTENANCE_NOTICE (แจ้งบำรุงรักษา)
   - SECURITY_WARNING (แจ้งเตือนความปลอดภัย)
   - GENERAL_INFO (ข้อมูลทั่วไป)
3. กรอกข้อความแจ้งเตือน (message)
4. เลือกผู้รับ:
   - ผู้ใช้งานระบุ (specific users)
   - กลุ่มผู้ใช้งาน (groups)
   - ผู้ใช้งานทั้งหมด (all users)
5. เลือกช่องทางการส่ง (notification_channels): IN_APP, EMAIL, SMS
6. ส่งการแจ้งเตือน
Expected Result:
- บันทึกข้อมูลใน NOTIFICATIONS table
- ส่งการแจ้งเตือนผ่านช่องทางที่เลือก
- ผู้รับเห็นการแจ้งเตือนในระบบ
- บันทึกสถานะการอ่าน (read_status)
- บันทึก sent_at และ sent_by

Test Case: การตรวจสอบผู้ใช้งานออนไลน์

Test ID: TC-033
Description: ทดสอบการตรวจสอบรายชื่อผู้ที่กำลังเข้าทำงานระบบตาม TOR ข้อ 6
Pre-condition: ระบบพร้อมใช้งาน, มีผู้ใช้งานล็อกอินอยู่
Test Steps:
1. เข้าสู่หน้า "ผู้ใช้งานออนไลน์"
2. แสดงรายชื่อผู้ใช้งานที่ออนไลน์:
   - ชื่อผู้ใช้งาน (username, display_name)
   - เวลาล็อกอิน (login_time)
   - IP Address
   - หน้าจอปัจจุบัน (current_screen)
   - สถานะ Session (status)
3. ทดสอบการกรองและค้นหา:
   - กรองตามแผนก
   - กรองตามประเภทผู้ใช้งาน
   - ค้นหาตามชื่อ
4. ทดสอบการ Refresh ข้อมูลแบบ Real-time
Expected Result:
- แสดงข้อมูลจาก USER_SESSIONS table ที่ status = 'ACTIVE'
- ข้อมูลอัปเดตแบบ Real-time
- แสดงจำนวนผู้ใช้งานออนไลน์ทั้งหมด
- สามารถดูรายละเอียดแต่ละ Session ได้

Test Case: การบังคับออกจากระบบ (Force Logout)

Test ID: TC-034
Description: ทดสอบการบังคับให้ผู้ใช้งานออกจากระบบ
Pre-condition: มีผู้ใช้งานออนไลน์, ผู้ใช้มีสิทธิ์ System Admin
Test Steps:
1. เข้าสู่หน้า "ผู้ใช้งานออนไลน์"
2. เลือกผู้ใช้งานที่ต้องการบังคับออกจากระบบ
3. คลิกปุ่ม "บังคับออกจากระบบ"
4. ระบุเหตุผล
5. ยืนยันการดำเนินการ
Expected Result:
- อัปเดต status = 'TERMINATED' ใน USER_SESSIONS
- ผู้ใช้งานถูกออกจากระบบทันที
- บันทึก terminated_at และ terminated_by
- ส่งการแจ้งเตือนให้ผู้ใช้งาน
- บันทึก Security Event

Test Case: การแสดงสถิติการใช้งานระบบ

Test ID: TC-035
Description: ทดสอบการแสดงสถิติการใช้งานระบบแบบ Real-time
Pre-condition: ระบบมีข้อมูลการใช้งาน
Test Steps:
1. เข้าสู่หน้า "สถิติการใช้งาน"
2. แสดงสถิติต่างๆ:
   - จำนวนผู้ใช้งานออนไลน์ปัจจุบัน
   - จำนวนผู้ใช้งานรายวัน/รายเดือน
   - Top 10 หน้าจอที่ใช้งานมากที่สุด
   - เวลาการใช้งานเฉลี่ย
   - Peak Hours ของระบบ
3. เลือกช่วงเวลาสำหรับวิเคราะห์
4. Export รายงานสถิติ
Expected Result:
- แสดงข้อมูลจาก USER_SESSIONS และ AUDIT_TRAIL
- กราฟและแผนภูมิแสดงผลถูกต้อง
- ข้อมูลอัปเดตแบบ Real-time
- สามารถ Export เป็น PDF, Excel ได้

Test Case: การจัดการการแจ้งเตือนแบบเป็นกลุ่ม

Test ID: TC-036
Description: ทดสอบการส่งการแจ้งเตือนแบบกลุ่มตามจุดต่างๆ ตาม TOR ข้อ 5
Pre-condition: ระบบพร้อมใช้งาน, มีกลุ่มผู้ใช้งาน
Test Steps:
1. เข้าสู่หน้า "การแจ้งเตือนแบบกลุ่ม"
2. เลือกเหตุการณ์ที่ต้องการแจ้งเตือน:
   - ผู้ป่วยมาถึง (ส่งไปยังห้องตรวจ)
   - งานค้างทำ (ส่งไปยังแผนกที่เกี่ยวข้อง)
   - เหตุการณ์ฉุกเฉิน (ส่งไปยังทีมฉุกเฉิน)
   - การบำรุงรักษาระบบ (ส่งไปยังผู้ใช้งานทั้งหมด)
3. เลือกกลุ่มเป้าหมาย
4. กำหนดข้อความและช่องทางการส่ง
5. ส่งการแจ้งเตือน
Expected Result:
- ส่งการแจ้งเตือนไปยังสมาชิกทั้งหมดในกลุ่ม
- รองรับการส่งแบบ Broadcast
- ตรวจสอบการส่งสำเร็จ/ล้มเหลว
- บันทึกสถิติการส่ง

Test Case: การตั้งค่าการแจ้งเตือนอัตโนมัติ

Test ID: TC-037
Description: ทดสอบการตั้งค่าการแจ้งเตือนอัตโนมัติตามเงื่อนไข
Pre-condition: ระบบพร้อมใช้งาน, ผู้ใช้มีสิทธิ์ System Admin
Test Steps:
1. เข้าสู่หน้า "การตั้งค่าการแจ้งเตือนอัตโนมัติ"
2. สร้าง Rule การแจ้งเตือน:
   - เงื่อนไข (Condition): เช่น เมื่อมี User login ล้มเหลว > 5 ครั้ง
   - การกระทำ (Action): ส่งการแจ้งเตือนไปยัง Security Admin
   - ช่องทางการส่ง: Email + In-App Notification
3. กำหนดความถี่การแจ้งเตือน (ไม่เกิน 1 ครั้ง/ชั่วโมง)
4. เปิดใช้งาน Rule
Expected Result:
- บันทึก Rule ใน AUTOMATED_ALERTS table
- ระบบตรวจสอบเงื่อนไขอัตโนมัติ
- ส่งการแจ้งเตือนเมื่อเงื่อนไขเป็นจริง
- ป้องกันการส่งซ้ำเกินกำหนด

Test Case: การดู Audit Trail

Test ID: TC-038
Description: ทดสอบการดู Audit Trail และบันทึกการตรวจสอบ
Pre-condition: ระบบมีข้อมูล Audit Trail
Test Steps:
1. เข้าสู่หน้า "Audit Trail"
2. กรองข้อมูล:
   - ช่วงเวลา (วันที่เริ่มต้น - สิ้นสุด)
   - ประเภทการกระทำ (Action Type)
   - ผู้ใช้งาน (User)
   - ผลลัพธ์ (Success/Failure)
3. แสดงรายละเอียด:
   - เวลาที่ทำ (timestamp)
   - ผู้ทำ (user_id, username)
   - การกระทำ (action)
   - ทรัพยากรที่เกี่ยวข้อง (resource)
   - ผลลัพธ์ (result)
   - รายละเอียดเพิ่มเติม (details - JSON)
4. Export รายงาน Audit Trail
Expected Result:
- แสดงข้อมูลจาก AUDIT_TRAIL table
- การกรองทำงานถูกต้อง
- แสดงรายละเอียดครบถ้วน
- Export ได้ตามรูปแบบที่ต้องการ
- ข้อมูลไม่สามารถแก้ไขได้ (Read-only)

Test Case Group 6: การจัดการรายงาน (Report Management)

Test Case: การเข้าถึงข้อมูลในฐานข้อมูล

Test ID: TC-039
Description: ทดสอบการเข้าถึงข้อมูลต่างๆ ในฐานข้อมูลตาม TOR ข้อ 3
Pre-condition: ระบบพร้อมใช้งาน, ผู้ใช้มีสิทธิ์เข้าถึงข้อมูล
Test Steps:
1. เข้าสู่หน้า "เข้าถึงข้อมูลฐานข้อมูล"
2. เลือกฐานข้อมูลที่ต้องการเข้าถึง:
   - ฐานข้อมูลผู้ป่วย (Patient Database)
   - ฐานข้อมูลการรักษา (Treatment Database)
   - ฐานข้อมูลการเงิน (Financial Database)
   - ฐานข้อมูลยา (Medication Database)
3. เลือกตารางและคอลัมน์ที่ต้องการ
4. กำหนดเงื่อนไขการค้นหา (WHERE clause)
5. กำหนดการเรียงลำดับ (ORDER BY)
6. จำกัดจำนวนแถว (LIMIT)
7. แสดงข้อมูล
Expected Result:
- แสดงข้อมูลตามเงื่อนไขที่กำหนด
- ตรวจสอบสิทธิ์การเข้าถึงแต่ละตาราง
- บันทึก Data Access Log
- ป้องกันการเข้าถึงข้อมูลที่ไม่มีสิทธิ์

Test Case: การส่งออกข้อมูลในรูปแบบต่างๆ

Test ID: TC-040
Description: ทดสอบการส่งออกข้อมูลในรูปแบบต่างๆ ตาม TOR ข้อ 3
Pre-condition: มีข้อมูลในระบบ, ผู้ใช้มีสิทธิ์ Export
Test Steps:
1. เลือกข้อมูลที่ต้องการส่งออก
2. เลือกรูปแบบการส่งออก:
   - Excel (.xlsx)
   - CSV (.csv)
   - PDF
   - JSON
   - XML
   - Text file (.txt)
3. กำหนดการตั้งค่าการส่งออก:
   - ชื่อไฟล์
   - การเข้ารหัส (UTF-8, TIS-620)
   - การคั่นคอลัมน์ (สำหรับ CSV)
   - รูปแบบวันที่
4. ดาวน์โหลดไฟล์
Expected Result:
- สร้างไฟล์ในรูปแบบที่เลือก
- ข้อมูลในไฟล์ถูกต้องครบถ้วน
- รองรับภาษาไทยและอักขระพิเศษ
- บันทึก Export Log พร้อมรายละเอียด

Test Case: การสร้างเทมเพลตรายงาน

Test ID: TC-041
Description: ทดสอบการแก้ไขแบบฟอร์มรายงานและสร้างรายงานตาม TOR ข้อ 4
Pre-condition: ระบบพร้อมใช้งาน, ผู้ใช้มีสิทธิ์จัดการรายงาน
Test Steps:
1. เข้าสู่หน้า "จัดการเทมเพลตรายงาน"
2. คลิกปุ่ม "สร้างเทมเพลตใหม่"
3. กำหนดข้อมูลเทมเพลต:
   - ชื่อเทมเพลต (template_name)
   - ประเภทรายงาน (report_type): OPERATIONAL, FINANCIAL, STATISTICAL, COMPLIANCE
   - คำอธิบาย (description)
4. ออกแบบเทมเพลต:
   - เลือกแหล่งข้อมูล (data_sources)
   - กำหนดคอลัมน์ (columns)
   - กำหนดการคำนวณ (calculations)
   - กำหนดการจัดกลุ่ม (grouping)
   - กำหนดการเรียงลำดับ (sorting)
5. ตั้งค่ารูปแบบการแสดงผล:
   - Header และ Footer
   - ขนาดหน้า (Page Size)
   - การจัดหน้า (Page Layout)
   - สีและรูปแบบตัวอักษร
6. บันทึกเทมเพลต
Expected Result:
- บันทึกข้อมูลใน REPORT_TEMPLATES table
- สร้าง template_id ในรูปแบบ UUID
- เก็บ template_definition เป็น JSON
- ทดสอบเทมเพลตด้วยข้อมูลจำลอง

Test Case: การสร้างรายงานจากเทมเพลต

Test ID: TC-042
Description: ทดสอบการสร้างรายงานจากเทมเพลตที่มีอยู่
Pre-condition: มีเทมเพลตรายงานในระบบ
Test Steps:
1. เข้าสู่หน้า "สร้างรายงาน"
2. เลือกเทมเพลตที่ต้องการใช้
3. กำหนดพารามิเตอร์รายงาน:
   - ช่วงวันที่ (date_range)
   - แผนก/หน่วยงาน (departments)
   - ประเภทข้อมูล (data_types)
   - เงื่อนไขเพิ่มเติม (additional_filters)
4. เลือกรูปแบบการส่งออก (PDF, Excel, CSV)
5. สร้างรายงาน
Expected Result:
- สร้างข้อมูลใน REPORT_INSTANCES table
- ประมวลผลข้อมูลตามเทมเพลต
- สร้างไฟล์รายงานในรูปแบบที่เลือก
- บันทึกสถานะการสร้างรายงาน
- แจ้งเตือนเมื่อรายงานเสร็จสิ้น

Test Case: การกำหนดตารางเวลารายงานอัตโนมัติ

Test ID: TC-043
Description: ทดสอบการตั้งค่าการสร้างรายงานอัตโนมัติตามตารางเวลา
Pre-condition: มีเทมเพลตรายงานในระบบ
Test Steps:
1. เข้าสู่หน้า "ตารางเวลารายงาน"
2. คลิกปุ่ม "สร้างตารางเวลาใหม่"
3. กำหนดข้อมูลตารางเวลา:
   - ชื่อตารางเวลา (schedule_name)
   - เทมเพลตที่ใช้ (template_id)
   - ความถี่ (frequency): DAILY, WEEKLY, MONTHLY, YEARLY
   - วันและเวลาที่ทำงาน (schedule_time)
4. กำหนดพารามิเตอร์รายงาน:
   - พารามิเตอร์เริ่มต้น (default_parameters)
   - การส่งรายงาน (delivery_method): EMAIL, SAVE_TO_FOLDER
   - ผู้รับรายงาน (recipients)
5. เปิดใช้งานตารางเวลา
Expected Result:
- บันทึกข้อมูลใน REPORT_SCHEDULES table
- ระบบสร้างรายงานตามตารางเวลา
- ส่งรายงานให้ผู้รับอัตโนมัติ
- บันทึกประวัติการทำงานใน REPORT_EXECUTIONS

Test Case: การแก้ไขเทมเพลตรายงาน

Test ID: TC-044
Description: ทดสอบการแก้ไขเทมเพลตรายงานที่มีอยู่
Pre-condition: มีเทมเพลตรายงานในระบบ
Test Steps:
1. เลือกเทมเพลตที่ต้องการแก้ไข
2. คลิกปุ่ม "แก้ไขเทมเพลต"
3. แก้ไขส่วนต่างๆ:
   - เพิ่ม/ลบคอลัมน์
   - แก้ไขการคำนวณ
   - เปลี่ยนรูปแบบการแสดงผล
   - อัปเดตแหล่งข้อมูล
4. ทดสอบเทมเพลตที่แก้ไข
5. บันทึกการเปลี่ยนแปลง
Expected Result:
- อัปเดต template_definition ใน REPORT_TEMPLATES
- เก็บ Version History ของเทมเพลต
- ทดสอบการทำงานด้วยข้อมูลจริง
- แจ้งเตือนผู้ใช้งานที่เกี่ยวข้อง

Test Case: การจัดการสิทธิ์การเข้าถึงรายงาน

Test ID: TC-045
Description: ทดสอบการจัดการสิทธิ์การเข้าถึงรายงานต่างๆ
Pre-condition: มีรายงานและผู้ใช้งานในระบบ
Test Steps:
1. เข้าสู่หน้า "จัดการสิทธิ์รายงาน"
2. เลือกรายงาน/เทมเพลตที่ต้องการจัดการสิทธิ์
3. กำหนดสิทธิ์:
   - ผู้ใช้งานที่สามารถดูรายงาน
   - ผู้ใช้งานที่สามารถแก้ไขเทมเพลต
   - ผู้ใช้งานที่สามารถลบรายงาน
   - กลุ่มที่มีสิทธิ์เข้าถึง
4. กำหนดระดับความปลอดภัย (Security Level)
5. บันทึกการตั้งค่าสิทธิ์
Expected Result:
- บันทึกสิทธิ์ใน REPORT_PERMISSIONS table
- ตรวจสอบสิทธิ์เมื่อเข้าถึงรายงาน
- ป้องกันการเข้าถึงโดยไม่มีสิทธิ์
- บันทึก Access Log การเข้าถึงรายงาน

Test Case: การสร้างรายงานแบบ Interactive Dashboard

Test ID: TC-046
Description: ทดสอบการสร้างรายงานแบบ Interactive Dashboard
Pre-condition: ระบบพร้อมใช้งาน, มีข้อมูลสำหรับวิเคราะห์
Test Steps:
1. เข้าสู่หน้า "สร้าง Dashboard"
2. เลือกประเภท Dashboard:
   - Executive Dashboard (ผู้บริหาร)
   - Operational Dashboard (การดำเนินงาน)
   - Clinical Dashboard (ทางการแพทย์)
   - Financial Dashboard (การเงิน)
3. เพิ่ม Widgets:
   - Charts (Line, Bar, Pie, Area)
   - Tables
   - KPI Indicators
   - Gauges
4. กำหนดแหล่งข้อมูลและการ Refresh
5. ตั้งค่าการ Filter และ Drill-down
6. บันทึก Dashboard
Expected Result:
- สร้าง Dashboard แบบ Interactive
- ข้อมูลอัปเดตแบบ Real-time
- รองรับการ Filter และ Export
- แสดงผลบนอุปกรณ์มือถือได้

Test Case Group 7: การเชื่อมโยงและ API (Integration & API)

Test Case: การจัดการระบบ HIS ภายนอก

Test ID: TC-047
Description: ทดสอบการเชื่อมต่อและจัดการระบบ HIS ภายนอกตาม ERD (HIS_SYSTEMS table)
Pre-condition: ระบบพร้อมใช้งาน, มีระบบ HIS ภายนอก
Test Steps:
1. เข้าสู่หน้า "จัดการระบบ HIS"
2. คลิกปุ่ม "เพิ่มระบบ HIS ใหม่"
3. กรอกข้อมูลระบบ:
   - ชื่อระบบ (system_name)
   - ประเภทระบบ (system_type): EMR, LIS, RIS, PACS, ERP
   - URL/Endpoint
   - เวอร์ชัน (version)
   - ผู้ให้บริการ (vendor)
4. กำหนดการเชื่อมต่อ:
   - Connection String
   - Authentication Method (API Key, OAuth, Basic Auth)
   - SSL Certificate
5. ทดสอบการเชื่อมต่อ
6. บันทึกข้อมูล
Expected Result:
- บันทึกข้อมูลใน HIS_SYSTEMS table
- ทดสอบการเชื่อมต่อสำเร็จ
- บันทึกสถานะการเชื่อมต่อ (connection_status)
- เก็บข้อมูล Authentication ที่เข้ารหัส

Test Case: การกำหนด API Endpoints

Test ID: TC-048
Description: ทดสอบการกำหนดและจัดการ API Endpoints ตาม ERD (API_ENDPOINTS table)
Pre-condition: มีระบบ HIS ที่เชื่อมต่อแล้ว
Test Steps:
1. เลือกระบบ HIS ที่ต้องการกำหนด API
2. คลิกปุ่ม "จัดการ API Endpoints"
3. เพิ่ม API Endpoint ใหม่:
   - ชื่อ Endpoint (endpoint_name)
   - URL Path
   - HTTP Method (GET, POST, PUT, DELETE)
   - คำอธิบาย (description)
4. กำหนดพารามิเตอร์:
   - Request Parameters
   - Request Body Schema (JSON)
   - Response Schema (JSON)
   - Headers ที่จำเป็น
5. ตั้งค่า Authentication และ Rate Limiting
6. ทดสอบ API
Expected Result:
- บันทึกข้อมูลใน API_ENDPOINTS table
- ทดสอบ API Call สำเร็จ
- บันทึก API Schema และ Documentation
- กำหนด Rate Limit และ Quota

Test Case: การทดสอบ API Integration

Test ID: TC-049
Description: ทดสอบการเรียกใช้ API และการแลกเปลี่ยนข้อมูล
Pre-condition: มี API Endpoints ที่กำหนดแล้ว
Test Steps:
1. เข้าสู่หน้า "ทดสอบ API"
2. เลือก API Endpoint ที่ต้องการทดสอบ
3. กรอกพารามิเตอร์และข้อมูล:
   - Query Parameters
   - Request Body (JSON/XML)
   - Headers
4. ส่ง API Request
5. ตรวจสอบ Response:
   - HTTP Status Code
   - Response Body
   - Response Time
   - Error Messages (หากมี)
Expected Result:
- API Response ถูกต้องตาม Schema
- Response Time อยู่ในเกณฑ์ที่กำหนด
- บันทึก API Call Log
- จัดการ Error ได้อย่างเหมาะสม

Test Case: การซิงค์ข้อมูลอัตโนมัติ

Test ID: TC-050
Description: ทดสอบการซิงค์ข้อมูลระหว่างระบบอัตโนมัติ (SYNC_JOBS table)
Pre-condition: มีระบบที่เชื่อมต่อกันและข้อมูลที่ต้องซิงค์
Test Steps:
1. เข้าสู่หน้า "การซิงค์ข้อมูล"
2. สร้าง Sync Job ใหม่:
   - ชื่องาน (job_name)
   - ระบบต้นทาง (source_system)
   - ระบบปลายทาง (target_system)
   - ประเภทข้อมูล (data_type)
3. กำหนดกำหนดการ:
   - ความถี่การซิงค์ (frequency)
   - เวลาที่ทำงาน (schedule_time)
   - การจัดการข้อมูลซ้ำ (conflict_resolution)
4. กำหนด Data Mapping
5. เปิดใช้งาน Sync Job
Expected Result:
- บันทึกข้อมูลใน SYNC_JOBS table
- ซิงค์ข้อมูลตามกำหนดการ
- บันทึกผลการซิงค์ใน SYNC_HISTORY
- จัดการ Conflict และ Error ได้

Test Case: การจัดการ External Systems

Test ID: TC-051
Description: ทดสอบการเชื่อมต่อกับระบบภายนอก (EXTERNAL_SYSTEMS table)
Pre-condition: ระบบพร้อมใช้งาน
Test Steps:
1. เข้าสู่หน้า "ระบบภายนอก"
2. เพิ่มระบบภายนอกใหม่:
   - ชื่อระบบ (system_name)
   - ประเภท (system_type): GOVERNMENT, INSURANCE, BANK, VENDOR
   - ข้อมูลการเชื่อมต่อ (connection_details)
   - API Documentation URL
3. กำหนดการแลกเปลี่ยนข้อมูล:
   - ประเภทข้อมูลที่ส่ง
   - ประเภทข้อมูลที่รับ
   - รูปแบบข้อมูล (JSON, XML, HL7)
4. ทดสอบการเชื่อมต่อ
Expected Result:
- บันทึกข้อมูลใน EXTERNAL_SYSTEMS table
- เชื่อมต่อกับระบบภายนอกสำเร็จ
- แลกเปลี่ยนข้อมูลได้ถูกต้อง
- บันทึก Transaction Log

Test Case: การ Monitor API Performance

Test ID: TC-052
Description: ทดสอบการติดตามประสิทธิภาพของ API
Pre-condition: มี API ที่ทำงานอยู่
Test Steps:
1. เข้าสู่หน้า "การติดตาม API"
2. แสดงสถิติต่างๆ:
   - จำนวน API Calls ต่อวัน
   - Average Response Time
   - Error Rate
   - Most Used APIs
3. แสดงกราฟแสดงแนวโน้ม:
   - Response Time Trend
   - Error Rate Trend
   - Usage Pattern
4. ตั้งค่า Alert เมื่อประสิทธิภาพต่ำ
Expected Result:
- แสดงข้อมูลจาก API_CALL_LOGS table
- กราฟและแผนภูมิแสดงผลถูกต้อง
- ส่งการแจ้งเตือนเมื่อมีปัญหา
- Export รายงานได้

Test Case: การจัดการ Authentication Tokens

Test ID: TC-053
Description: ทดสอบการจัดการ Token สำหรับ API Authentication
Pre-condition: ระบบพร้อมใช้งาน, มี API ที่ใช้ Token
Test Steps:
1. เข้าสู่หน้า "จัดการ API Tokens"
2. สร้าง Token ใหม่:
   - ชื่อ Token (token_name)
   - ระดับสิทธิ์ (permission_level)
   - วันหมดอายุ (expiry_date)
   - IP Whitelist
3. กำหนด Scope และ Permissions
4. Generate Token
5. ทดสอบการใช้งาน Token
Expected Result:
- บันทึกข้อมูลใน API_TOKENS table
- Token ทำงานได้ถูกต้อง
- ตรวจสอบสิทธิ์และ Scope
- จัดการการหมดอายุอัตโนมัติ

Test Case: การทดสอบ Data Transformation

Test ID: TC-054
Description: ทดสอบการแปลงข้อมูลระหว่างระบบที่มีรูปแบบต่างกัน
Pre-condition: มีข้อมูลจากหลายระบบที่ต้องแปลง
Test Steps:
1. กำหนด Data Transformation Rules:
   - Source Format (JSON, XML, CSV, HL7)
   - Target Format
   - Field Mapping
   - Data Validation Rules
2. ทดสอบการแปลงข้อมูล:
   - อัปโหลดไฟล์ข้อมูลตัวอย่าง
   - ประมวลผลการแปลง
   - ตรวจสอบผลลัพธ์
3. จัดการข้อผิดพลาด:
   - Invalid Data Format
   - Missing Required Fields
   - Data Type Mismatch
Expected Result:
- แปลงข้อมูลได้ถูกต้องตาม Rules
- จัดการ Error ได้อย่างเหมาะสม
- บันทึก Transformation Log
- รองรับข้อมูลขนาดใหญ่

📊 สรุปการทดสอบ

จำนวน Test Cases ทั้งหมด: 54 Test Cases

แบ่งตามกลุ่มฟีเจอร์: - User Management (การจัดการผู้ใช้งาน): 7 Test Cases (TC-001 ถึง TC-007) - Group Management (การจัดการกลุ่มผู้ใช้งาน): 7 Test Cases (TC-008 ถึง TC-014) - Role & Policy Management (การจัดการบทบาทและนโยบาย): 8 Test Cases (TC-015 ถึง TC-022) - System Configuration (การตั้งค่าระบบ): 8 Test Cases (TC-023 ถึง TC-030) - Communication & Monitoring (การสื่อสารและติดตาม): 8 Test Cases (TC-031 ถึง TC-038) - Report Management (การจัดการรายงาน): 8 Test Cases (TC-039 ถึง TC-046) - Integration & API (การเชื่อมโยงและ API): 8 Test Cases (TC-047 ถึง TC-054)

ความครอบคลุมตาม TOR

ข้อ 1: การตั้งค่าเริ่มต้นต่างๆ → TC-023, TC-024, TC-029, TC-030
ข้อ 2: การกำหนดสิทธิ์และกลุ่มผู้ใช้งาน → TC-001 ถึง TC-022
ข้อ 3: การเข้าถึงและส่งออกข้อมูลฐานข้อมูล → TC-039, TC-040
ข้อ 4: การแก้ไขแบบฟอร์มรายงานและสร้างรายงาน → TC-041 ถึง TC-046
ข้อ 5: การเขียนประกาศข่าวและส่งข้อความเตือน → TC-031, TC-032, TC-036, TC-037
ข้อ 6: การตรวจสอบผู้ใช้งานออนไลน์ → TC-033, TC-034, TC-035
ข้อ 7: การตั้งค่าฐานข้อมูล MySQL/PostgreSQL → TC-025, TC-026
ข้อ 8: การตั้งค่าข้อมูลพื้นฐานและการทำงานของระบบ → TC-027, TC-028

ความครอบคลุมตาม ERD Tables

USERS, GROUPS, ROLES, POLICIES: ครอบคลุมใน TC-001 ถึง TC-022
SYSTEM_CONFIG, DATABASE_CONFIG, MASTER_DATA: ครอบคลุมใน TC-023 ถึง TC-030
NEWS_ANNOUNCEMENTS, NOTIFICATIONS, AUDIT_TRAIL: ครอบคลุมใน TC-031 ถึง TC-038
REPORT_TEMPLATES, REPORT_INSTANCES: ครอบคลุมใน TC-041 ถึง TC-046
HIS_SYSTEMS, API_ENDPOINTS, EXTERNAL_SYSTEMS: ครอบคลุมใน TC-047 ถึง TC-054


Additional Test Cases - ส่วนเพิ่มเติมที่สำคัญ

Test Case Group 8: Policy Evaluation Engine

Test Case: การประเมินนโยบายการเข้าถึง

Test ID: TC-055
Description: ทดสอบ Policy Evaluation Engine สำหรับการตัดสินใจอนุญาตการเข้าถึง
Pre-condition: มี Users, Roles, Policies ที่ซับซ้อนในระบบ
Test Steps:
1. สร้าง Policy ที่มีเงื่อนไข Effect: Allow/Deny
2. แนบ Policy กับ User ผ่าน Role
3. ผู้ใช้พยายามเข้าถึงทรัพยากรที่ระบุใน Policy
4. ทดสอบกรณี Multiple Policies ขัดแย้งกัน
5. ทดสอบ Conditional Access ตาม IP, เวลา, อุปกรณ์
Expected Result:
- ระบบประเมิน Policy ตามลำดับความสำคัญ (Explicit Deny > Allow)
- บันทึก Access Decision ใน Audit Trail
- แสดงเหตุผลการอนุญาต/ปฏิเสธ
- Response time < 100ms สำหรับการตัดสินใจ

Test Case: การทดสอบ Policy Conflict Resolution

Test ID: TC-056
Description: ทดสอบการแก้ไขความขัดแย้งระหว่าง Policies
Pre-condition: มี Policies หลายตัวที่ขัดแย้งกัน
Test Steps:
1. สร้าง Policy A: Allow access to resource X
2. สร้าง Policy B: Deny access to resource X
3. แนบทั้งสอง Policies กับ User เดียวกัน
4. ผู้ใช้พยายามเข้าถึง resource X
5. ทดสอบการเปลี่ยนลำดับความสำคัญ Policy
Expected Result:
- Deny Policy มีความสำคัญสูงกว่า Allow Policy
- ระบบปฏิเสธการเข้าถึง
- บันทึกการตัดสินใจและเหตุผลใน Audit Trail

Test Case Group 9: Real-time Session Monitoring

Test Case: การติดตามผู้ใช้งานออนไลน์แบบ Real-time

Test ID: TC-057
Description: ทดสอบระบบติดตามผู้ใช้งานออนไลน์แบบ Real-time
Pre-condition: มีผู้ใช้งานหลายคนล็อกอินเข้าระบบ
Test Steps:
1. ล็อกอินผู้ใช้งาน 10 คนพร้อมกัน
2. เข้าสู่หน้า "ผู้ใช้งานออนไลน์"
3. ตรวจสอบรายชื่อผู้ใช้งานที่แสดง
4. ผู้ใช้งาน 1 คนล็อกเอาต์
5. รีเฟรชหน้าจอและตรวจสอบ
6. ทดสอบ Auto-refresh ทุก 30 วินาทีี
Expected Result:
- แสดงรายชื่อผู้ใช้งานออนไลน์ครบถ้วนทันที
- อัปเดตสถานะเมื่อมีการล็อกเอาต์
- แสดงข้อมูล: ชื่อผู้ใช้, เวลาล็อกอิน, IP Address, ระบบที่ใช้งาน
- Auto-refresh ทำงานถูกต้อง

Test Case: การ Force Logout ผู้ใช้งาน

Test ID: TC-058
Description: ทดสอบการบังคับล็อกเอาต์ผู้ใช้งานโดย Admin
Pre-condition: มี Admin และ End User ล็อกอินอยู่
Test Steps:
1. Admin เข้าสู่หน้า "ผู้ใช้งานออนไลน์"
2. เลือกผู้ใช้งานที่ต้องการบังคับล็อกเอาต์
3. คลิกปุ่ม "Force Logout"
4. ยืนยันการดำเนินการ
5. ตรวจสอบสถานะของผู้ใช้งานที่ถูกล็อกเอาต์
Expected Result:
- ผู้ใช้งานถูกล็อกเอาต์ทันที
- Session ถูกยกเลิกในฐานข้อมูล
- ผู้ใช้งานได้รับแจ้งเตือนเมื่อพยายามใช้งานต่อ
- บันทึกการดำเนินการใน Audit Trail

Test Case Group 10: Emergency Broadcast System

Test Case: การส่งข้อความฉุกเฉินแบบ Broadcast

Test ID: TC-059
Description: ทดสอบระบบส่งข้อความฉุกเฉินไปยังผู้ใช้งานทั้งหมด
Pre-condition: มีผู้ใช้งานออนไลน์หลายคนในระบบ
Test Steps:
1. Admin เข้าสู่หน้า "Emergency Broadcast"
2. เลือกประเภทข้อความ: CRITICAL/WARNING/INFO
3. กรอกข้อความและหัวข้อ
4. เลือกผู้รับ: ทั้งหมด/กลุ่มเฉพาะ/แผนกเฉพาะ
5. ตั้งค่า Auto-acknowledge required
6. ส่งข้อความ
Expected Result:
- ข้อความถูกส่งถึงผู้ใช้งานที่ระบุทันที
- แสดง Popup/Banner บน UI ของผู้ใช้งาน
- ส่ง Email/SMS (หากเปิดใช้งาน)
- บันทึกสถานะการอ่านข้อความ
- Admin ดูสถิติการอ่านข้อความได้

Test Case: การตอบกลับข้อความฉุกเฉิน

Test ID: TC-060
Description: ทดสอบการตอบกลับและ Acknowledge ข้อความฉุกเฉิน
Pre-condition: มีข้อความฉุกเฉินที่ส่งแล้ว
Test Steps:
1. ผู้ใช้งานเห็นข้อความฉุกเฉิน
2. คลิกปุ่ม "Acknowledge"
3. กรอกข้อความตอบกลับ (ถ้าจำเป็น)
4. ส่งการตอบกลับ
5. Admin ตรวจสอบสถิติการตอบกลับ
Expected Result:
- สถานะ "อ่านแล้ว" ถูกบันทึก
- ข้อความตอบกลับถูกส่งให้ Admin
- อัปเดตสถิติการตอบกลับแบบ Real-time
- ข้อความหายไปจาก UI ของผู้ใช้งาน

Test Case Group 11: API Integration Testing

Test Case: การเชื่อมต่อกับระบบเวชระเบียน

Test ID: TC-061
Description: ทดสอบการเชื่อมต่อและซิงค์ข้อมูลกับระบบเวชระเบียน (1.2.1)
Pre-condition: ระบบเวชระเบียนพร้อมใช้งาน
Test Steps:
1. ส่ง API Request: GET /api/v1/patients/permissions/{patientId}
2. รับข้อมูลสิทธิ์การเข้าถึงข้อมูลผู้ป่วย
3. ทดสอบ JWT Token Authentication
4. ทดสอบ Rate Limiting (100 requests/minute)
5. ทดสอบ Error Handling (Patient not found, Permission denied)
Expected Result:
- API Response ใน format JSON ที่ถูกต้อง
- Response time < 500ms
- Authentication ทำงานถูกต้อง
- Rate Limiting ทำงานถูกต้อง
- Error messages ชัดเจนและมีรูปแบบมาตรฐาน

Test Case: การซิงค์ข้อมูล Master Data

Test ID: TC-062
Description: ทดสอบการซิงค์ข้อมูล Master Data ระหว่างระบบ
Pre-condition: มีการเปลี่ยนแปลงข้อมูล Master Data ในระบบผู้ดูแลระบบ
Test Steps:
1. แก้ไขข้อมูล Department ในระบบผู้ดูแลระบบ
2. ตรวจสอบ Sync Job ทำงาน
3. ตรวจสอบข้อมูลใน Target Systems (เวชระเบียน, เภสัชกรรม, การเงิน)
4. ทดสอบ Conflict Resolution (กรณีข้อมูลขัดแย้ง)
5. ทดสอบ Rollback (กรณี Sync ล้มเหลว)
Expected Result:
- ข้อมูลถูกซิงค์ไปยังระบบปลายทางทั้งหมด
- เวลาซิงค์ < 5 นาที
- แก้ไข Conflict ตาม Business Rules
- Rollback ทำงานถูกต้องเมื่อเกิดข้อผิดพลาด
- บันทึก Sync History และ Status

Test Case Group 12: Performance and Load Testing

Test Case: การทดสอบภาระงานสูง

Test ID: TC-063
Description: ทดสอบประสิทธิภาพระบบภายใต้ภาระงานสูง
Pre-condition: ระบบพร้อมใช้งาน, Load testing tools พร้อม
Test Steps:
1. จำลองผู้ใช้งาน 500 คนล็อกอินพร้อมกัน
2. ทำ User Management operations 1000 requests/minute
3. ส่ง API requests 5000 calls/minute
4. ตรวจสอบ Response Time และ Error Rate
5. ตรวจสอบ Resource Usage (CPU, Memory, Disk)
Expected Result:
- Response Time < 2 seconds สำหรับ 95% ของ requests
- Error Rate < 1%
- CPU Usage < 80%
- Memory Usage < 85%
- ระบบยังคงทำงานได้ปกติ

จำนวน Test Cases ทั้งหมด: 63 Test Cases

แบ่งตามกลุ่มฟีเจอร์ (อัปเดต): - User Management (การจัดการผู้ใช้งาน): 7 Test Cases (TC-001 ถึง TC-007) - Group Management (การจัดการกลุ่มผู้ใช้งาน): 7 Test Cases (TC-008 ถึง TC-014) - Role & Policy Management (การจัดการบทบาทและนโยบาย): 8 Test Cases (TC-015 ถึง TC-022) - System Configuration (การตั้งค่าระบบ): 8 Test Cases (TC-023 ถึง TC-030) - Communication & Monitoring (การสื่อสารและติดตาม): 8 Test Cases (TC-031 ถึง TC-038) - Report Management (การจัดการรายงาน): 8 Test Cases (TC-039 ถึง TC-046) - Integration & API (การเชื่อมโยงและ API): 8 Test Cases (TC-047 ถึง TC-054) - Policy Evaluation Engine: 2 Test Cases (TC-055 ถึง TC-056) - Real-time Session Monitoring: 2 Test Cases (TC-057 ถึง TC-058) - Emergency Broadcast System: 2 Test Cases (TC-059 ถึง TC-060) - API Integration Testing: 2 Test Cases (TC-061 ถึง TC-062) - Performance and Load Testing: 1 Test Cases (TC-063)


เอกสารนี้จัดทำขึ้นเพื่อใช้ในการทดสอบระบบผู้ดูแลระบบ (System Administrator Management System) สำหรับโรงพยาบาลค่ายธนรัชน์ และต้องได้รับการอนุมัติจากผู้มีอำนาจก่อนนำไปใช้ในการทดสอบระบบ