# Gate 3 — Thiết kế TC Business và Data, luôn áp dụng

> **File gộp — giảm số lệnh Read khi Gate chạy** (xem `docs/internal/Token Problems.md` §3.6, Vấn đề F). Nội dung dưới đây là bản sao nguyên văn từ các file gốc cùng thư mục (liệt kê ở mỗi mục `## From:`) — **các file gốc vẫn là nguồn sự thật**, dùng để sửa/tham chiếu độc lập từng kỹ thuật. Khi sửa 1 kỹ thuật: sửa file gốc trước, rồi copy lại đúng phần đã sửa vào file gộp này để giữ đồng bộ.

## From: 03-business-testing/03.01.CRUD-testing.md

# Kiểm thử CRUD (Create, Read, Update, Delete)

## Mục đích (Purpose)
Đảm bảo tính toàn vẹn, chính xác và bảo mật của dữ liệu thông qua bốn thao tác cơ bản: Tạo mới (Create), Hiển thị (Read), Cập nhật (Update) và Xóa (Delete). Kỹ năng này giúp xác minh rằng hệ thống xử lý các thực thể dữ liệu đúng theo yêu cầu nghiệp vụ và các ràng buộc kỹ thuật.

## Kiến thức cần có (Required Knowledge)
- Hiểu biết về cấu trúc dữ liệu của thực thể cần kiểm thử (các trường thông tin, kiểu dữ liệu, ràng buộc).
- Nắm vững quy tắc nghiệp vụ (Business Rules) liên quan đến việc tạo, sửa, xóa dữ liệu.
- Kiến thức về Database (SQL/NoSQL) để kiểm tra dữ liệu thực tế.
- Hiểu về phân quyền (Permissions/Roles) cho từng thao tác.

## Quy trình thực hiện (Process)
1. **Phân tích thực thể:** Xác định các trường dữ liệu, trường bắt buộc, định dạng dữ liệu và các ràng buộc duy nhất (Unique constraints).
2. **Thiết kế kịch bản Create:** Kiểm thử các trường hợp dữ liệu hợp lệ, không hợp lệ, trùng lặp và các ràng buộc nghiệp vụ khi tạo mới.
3. **Thiết kế kịch bản Read:** Kiểm thử hiển thị danh sách, chi tiết, tìm kiếm, lọc, phân trang và sắp xếp.
4. **Thiết kế kịch bản Update:** Kiểm thử cập nhật một phần hoặc toàn bộ thông tin, kiểm tra tính toàn vẹn dữ liệu sau khi cập nhật.
5. **Thiết kế kịch bản Delete:** Kiểm thử xóa mềm (soft delete), xóa cứng (hard delete) và các ràng buộc khi xóa (dữ liệu đang được sử dụng ở nơi khác).
6. **Xác minh Database:** Đối chiếu kết quả trên giao diện (UI) với dữ liệu thực tế trong cơ sở dữ liệu.

## Checklist
### Create (Tạo mới)
- [ ] Dữ liệu hợp lệ được lưu đúng và đủ vào Database.
- [ ] Các trường bắt buộc (Mandatory fields) được kiểm tra lỗi nếu để trống.
- [ ] Các ràng buộc định dạng (Email, Số điện thoại, Ngày tháng) hoạt động đúng.
- [ ] Kiểm tra lỗi khi nhập dữ liệu trùng lặp cho các trường duy nhất (Username, Mã nhân viên, ...).
- [ ] Xử lý các ký tự đặc biệt, khoảng trắng đầu/cuối chuỗi.

### Read (Hiển thị)
- [ ] Dữ liệu hiển thị trên danh sách khớp với Database.
- [ ] Trang chi tiết hiển thị đầy đủ và chính xác thông tin thực thể.
- [ ] Tìm kiếm (Search) hoạt động đúng với các từ khóa khác nhau.
- [ ] Các bộ lọc (Filter) trả về đúng kết quả mong đợi.
- [ ] Phân trang (Pagination) hoạt động mượt mà và đúng số lượng bản ghi.
- [ ] Sắp xếp (Sorting) đúng theo thứ tự tăng/giảm dần.

### Update (Cập nhật)
- [ ] Cập nhật thành công khi thay đổi dữ liệu hợp lệ.
- [ ] Các trường không cho phép sửa (ReadOnly) không thể thay đổi.
- [ ] Kiểm tra tính toàn vẹn: Cập nhật thực thể này không làm ảnh hưởng sai lệch đến thực thể khác.
- [ ] Xử lý xung đột (Concurrency): Hai người cùng sửa một bản ghi cùng lúc.

### Delete (Xóa)
- [ ] Thông báo xác nhận xuất hiện trước khi xóa.
- [ ] Bản ghi bị xóa không còn xuất hiện trong danh sách và tìm kiếm.
- [ ] Kiểm tra ràng buộc khóa ngoại: Không cho phép xóa nếu dữ liệu đang được sử dụng (nếu nghiệp vụ yêu cầu).
- [ ] Kiểm tra xóa mềm: Dữ liệu ẩn trên UI nhưng vẫn còn trong DB với cờ `is_deleted = true`.

## Output mong đợi (Expected Output)
- Bộ tài liệu Test Cases chi tiết bao phủ đầy đủ các khía cạnh của CRUD cho thực thể.
- Danh sách các lỗi (Bugs) liên quan đến xử lý dữ liệu (nếu có).
- Báo cáo xác nhận tính ổn định của các thao tác dữ liệu cơ bản.

---

## From: 03-business-testing/03.03.permission-testing.md

# Kiểm thử Phân quyền (Permission Testing)

## Mục đích (Purpose)
Xác minh rằng hệ thống thực thi đúng các quy tắc kiểm soát truy cập (Access Control), đảm bảo người dùng chỉ có thể truy cập và thực hiện các hành động trong phạm vi quyền hạn được cấp. Việc này giúp bảo vệ tính bảo mật, toàn vẹn của dữ liệu và ngăn chặn các hành vi truy cập trái phép.

## Kiến thức cần có (Required Knowledge)
- Hiểu về các mô hình phân quyền: RBAC (Role-Based Access Control), ABAC (Attribute-Based Access Control).
- Nắm vững Ma trận phân quyền (Permission Matrix) của dự án.
- Hiểu về sự khác biệt giữa Phân quyền dọc (Vertical) và Phân quyền ngang (Horizontal).
- Cách thức hệ thống quản lý Session, Token và Cookie để duy trì quyền hạn.

## Quy trình thực hiện (Process)
1. **Phân tích Ma trận phân quyền:** Liệt kê các vai trò (Roles) và các quyền (Permissions/Actions) tương ứng trên từng tài nguyên.
2. **Thiết kế kịch bản Phân quyền dọc (Vertical Access):** Kiểm tra xem người dùng ở vai trò thấp hơn có thể truy cập tính năng của vai trò cao hơn (ví dụ: User truy cập trang Admin) hay không.
3. **Thiết kế kịch bản Phân quyền ngang (Horizontal Access):** Kiểm tra xem người dùng có cùng vai trò có thể truy cập hoặc thao tác dữ liệu của nhau (ví dụ: User A sửa đơn hàng của User B) hay không.
4. **Kiểm thử Truy cập ẩn danh (Unauthenticated Access):** Xác minh các tài nguyên bảo mật không thể truy cập nếu chưa đăng nhập.
5. **Kiểm thử Thay đổi quyền hạn (Dynamic Permissions):** Xác minh hệ thống phản ứng thế nào khi quyền của một người dùng bị thay đổi trong khi họ đang đăng nhập (áp dụng ngay hay cần đăng nhập lại).
6. **Kiểm thử Phân quyền mức dữ liệu (Data-level Security):** Xác minh người dùng chỉ thấy dữ liệu họ được phép thấy (ví dụ: Nhân viên chỉ thấy khách hàng của mình phụ trách).

## Checklist
### Phân quyền dọc (Vertical Access)
- [ ] Người dùng không có quyền Admin không thể truy cập URL/API của Admin.
- [ ] Các Menu, Button của tính năng không có quyền phải bị ẩn hoặc disable.
- [ ] Trả về lỗi 403 Forbidden khi cố tình truy cập trái phép qua URL.

### Phân quyền ngang (Horizontal Access)
- [ ] Không thể xem/sửa/xóa dữ liệu của người dùng khác bằng cách thay đổi ID trên URL/API (IDOR vulnerability).
- [ ] Dữ liệu riêng tư của người dùng này không hiển thị trong các báo cáo/danh sách của người dùng kia.

### Truy cập chưa đăng nhập (Unauthenticated)
- [ ] Hệ thống chuyển hướng về trang Login khi truy cập trang bảo mật mà chưa đăng nhập.
- [ ] API trả về lỗi 401 Unauthorized khi thiếu Token/Session.

### Trạng thái hệ thống khi thay đổi quyền
- [ ] Khi bị thu hồi quyền, người dùng mất quyền truy cập ngay lập tức hoặc sau một khoảng thời gian ngắn quy định.
- [ ] Khi được cấp thêm quyền, các tính năng mới xuất hiện và hoạt động đúng mà không cần can thiệp kỹ thuật phức tạp.

## Output mong đợi (Expected Output)
- Ma trận kiểm thử phân quyền đã được xác minh.
- Danh sách các lỗ hổng bảo mật liên quan đến truy cập trái phép (nếu có).
- Báo cáo xác nhận hệ thống an toàn về mặt kiểm soát truy cập.

---

## From: 04-data-testing/04.01.database-testing.md

# Kiểm thử Cơ sở dữ liệu (Database Testing)

## Mục đích (Purpose)
Xác minh rằng dữ liệu được lưu trữ, truy xuất, cập nhật và xóa bỏ một cách chính xác trong cơ sở dữ liệu. Đảm bảo tính nhất quán, toàn vẹn và bảo mật của dữ liệu, đồng thời kiểm tra các ràng buộc kỹ thuật và hiệu suất của các câu lệnh truy vấn.

## Kiến thức cần có (Required Knowledge)
- Thành thạo ngôn ngữ truy vấn SQL (DML: Select, Insert, Update, Delete; DDL: Create, Alter, Drop).
- Hiểu về các thuộc tính ACID (Atomicity, Consistency, Isolation, Durability) trong giao dịch (Transactions).
- Nắm vững cấu trúc Schema, các bảng, quan hệ (Primary Key, Foreign Key) và các ràng buộc (Constraints).
- Hiểu về Indexing và cách tối ưu hóa truy vấn.
- Kiến thức về Store Procedures, Triggers và Views (nếu có).

## Quy trình thực hiện (Process)
1. **Kiểm tra cấu trúc (Schema Validation):** Xác minh tên bảng, tên cột, kiểu dữ liệu và độ dài của các trường dữ liệu đúng với thiết kế.
2. **Kiểm thử Ràng buộc (Constraint Testing):** Kiểm tra tính thực thi của các ràng buộc Primary Key, Unique, Not Null, Check constraints.
3. **Kiểm thử tính nhất quán dữ liệu (Data Integrity):** Thực hiện các thao tác trên UI/API và dùng SQL để truy vấn trực tiếp DB, đối chiếu kết quả để đảm bảo dữ liệu lưu xuống đúng và đủ.
4. **Kiểm thử Giao dịch (Transaction Testing):** Thực hiện các luồng nghiệp vụ phức tạp và giả lập lỗi giữa chừng để kiểm tra tính năng Rollback (quay lại trạng thái cũ) và Commit (lưu thay đổi).
5. **Kiểm thử Truy cập đồng thời (Concurrency Testing):** Kiểm tra các vấn đề Deadlock hoặc tranh chấp dữ liệu khi nhiều người dùng/tiến trình cùng truy cập một bản ghi.
6. **Kiểm tra Trigger và Store Procedure:** Xác minh các logic tự động hóa trong DB hoạt động đúng khi có sự kiện kích hoạt.

## Checklist
### Cấu trúc & Ràng buộc
- [ ] Kiểu dữ liệu và độ dài các trường trong DB khớp với tài liệu thiết kế.
- [ ] Ràng buộc NOT NULL hoạt động: Không thể lưu giá trị null vào trường bắt buộc.
- [ ] Ràng buộc UNIQUE hoạt động: Không thể lưu hai giá trị giống nhau vào trường duy nhất.
- [ ] Ràng buộc Foreign Key hoạt động: Không thể lưu giá trị không tồn tại trong bảng cha hoặc xóa bản ghi cha khi đang có bản ghi con tham chiếu.

### Dữ liệu & Thao tác
- [ ] Dữ liệu lưu trong DB không bị cắt xén (Truncation) nếu độ dài vượt quá giới hạn hiển thị trên UI.
- [ ] Các giá trị mặc định (Default values) được gán đúng khi không có dữ liệu nhập vào.
- [ ] Dữ liệu ngày tháng (Date/Time) được lưu đúng múi giờ và định dạng.
- [ ] Các ký tự đặc biệt và Unicode (Tiếng Việt) được lưu và hiển thị đúng (không bị lỗi font).

### Giao dịch & Hiệu năng
- [ ] Giao dịch thành công được lưu vĩnh viễn (Durability).
- [ ] Giao dịch thất bại được Rollback hoàn toàn, không để lại dữ liệu rác.
- [ ] Các câu lệnh truy vấn phức tạp trả về kết quả trong thời gian cho phép (Response time).
- [ ] Các Index được sử dụng hiệu quả để tăng tốc độ tìm kiếm.

## Output mong đợi (Expected Output)
- Danh sách các câu lệnh SQL (Scripts) dùng để xác minh dữ liệu.
- Kết quả đối chiếu dữ liệu giữa UI/API và Database.
- Báo cáo về các lỗi vi phạm ràng buộc hoặc lỗi nhất quán dữ liệu.

---

## From: 04-data-testing/04.04.duplicate-handling.md

# Kiểm thử Xử lý trùng lặp (Duplicate Handling)

## Mục đích (Purpose)
Đảm bảo hệ thống phát hiện và xử lý chính xác các trường hợp dữ liệu bị trùng lặp theo quy tắc nghiệp vụ. Kiểm thử này giúp duy trì sự "sạch sẽ" và duy nhất của các thực thể quan trọng (như Khách hàng, Sản phẩm, Tài khoản), ngăn chặn dữ liệu rác và các lỗi logic do trùng lặp gây ra.

## Kiến thức cần có (Required Knowledge)
- Hiểu về các trường dữ liệu duy nhất (Unique Fields) của từng thực thể.
- Nắm vững quy tắc chống trùng lặp: Trùng lặp tuyệt đối (Exact match) vs Trùng lặp tương đối (Fuzzy match).
- Phân biệt giữa Cảnh báo (Warning) và Chặn (Error) khi có trùng lặp.
- Hiểu về cơ chế gộp dữ liệu (Data Merging/Deduplication) nếu hệ thống hỗ trợ.
- Kiến thức về xử lý chuỗi (Case sensitivity, Whitespace, Accent marks).

## Quy trình thực hiện (Process)
1. **Xác định tiêu chí trùng lặp:** Liệt kê các trường hoặc tổ hợp các trường xác định một bản ghi là duy nhất (ví dụ: Email, hoặc Số CMND + Ngày cấp).
2. **Kiểm thử Trùng lặp khi tạo mới:** Thử tạo một bản ghi có thông tin giống hệt bản ghi đã tồn tại.
3. **Kiểm thử Trùng lặp khi cập nhật:** Thử sửa một bản ghi hiện có thành thông tin trùng với một bản ghi khác.
4. **Kiểm thử Xử lý chuỗi (String normalization):** Kiểm tra xem các trường hợp khác biệt về khoảng trắng, viết hoa/thường, hoặc dấu tiếng Việt có bị coi là trùng lặp không (ví dụ: `nguyen van a` vs `Nguyen Van A`).
5. **Kiểm thử Cảnh báo trùng lặp:** Nếu nghiệp vụ cho phép trùng nhưng cần cảnh báo, xác minh thông báo xuất hiện và cho phép người dùng xác nhận tiếp tục hoặc hủy bỏ.
6. **Kiểm thử Gộp dữ liệu (Merge):** Nếu có tính năng gộp, xác minh dữ liệu từ hai bản ghi trùng được tổng hợp lại chính xác và bản ghi cũ bị xóa/ẩn đúng cách.

## Checklist
### Phát hiện trùng lặp
- [ ] Hệ thống chặn và báo lỗi khi nhập trùng dữ liệu cho các trường Unique.
- [ ] Quy tắc trùng lặp áp dụng đúng cho cả trường hợp nhập tay trên UI và Import từ file.
- [ ] Các trường hợp trùng lặp do viết hoa/viết thường (Case-insensitive) được xử lý đúng theo yêu cầu.
- [ ] Khoảng trắng thừa ở đầu/cuối chuỗi không làm hệ thống hiểu nhầm là dữ liệu khác nhau.

### Thông báo & Trải nghiệm
- [ ] Thông báo lỗi trùng lặp hiển thị rõ ràng, chỉ ra trường nào bị trùng và (nếu có thể) bản ghi nào đang bị trùng.
- [ ] Người dùng không bị mất dữ liệu đã nhập khi gặp lỗi trùng lặp (hệ thống giữ lại thông tin trên form để sửa).

### Tính toàn vẹn khi Gộp/Xóa
- [ ] Khi gộp bản ghi, các dữ liệu lịch sử (Orders, Comments, Transactions) của bản ghi phụ được chuyển sang bản ghi chính đầy đủ.
- [ ] Bản ghi bị coi là trùng và bị xóa không còn xuất hiện trong các danh sách hiển thị và báo cáo.

## Output mong đợi (Expected Output)
- Danh sách các quy tắc chống trùng lặp (Deduplication Rules) đã được kiểm chứng.
- Bộ Test Scenarios bao phủ các kịch bản trùng lặp biên và xử lý chuỗi.
- Báo cáo về các lỗ hổng cho phép nhập trùng dữ liệu rác vào hệ thống.