# Gate 3 — Kỹ thuật thiết kế TC cơ bản, luôn áp dụng (Test Design) > **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: 01-test-design/01.01.boundary-value-analysis.md # 01.01. Boundary Value Analysis (Phân tích giá trị biên) ## Mục đích Đảm bảo kiểm tra các điểm tới hạn (ranh giới) nơi lỗi thường xảy ra nhất. Kỹ thuật này giúp tối ưu hóa số lượng test case bằng cách tập trung vào các giá trị tại biên của các phân vùng tương đương, thay vì kiểm tra mọi giá trị trong dải. ## Kiến thức cần có - Khái niệm về Phân vùng tương đương (Equivalence Partitioning). - Hiểu biết về dải giá trị (range), độ dài (length) và các kiểu dữ liệu (data types). - Logic nghiệp vụ và các điều kiện ràng buộc của hệ thống. ## Quy trình thực hiện 1. **Xác định tham số:** Liệt kê các tham số đầu vào hoặc điều kiện cần kiểm tra. 2. **Xác định dải giá trị:** Xác định dải giá trị hợp lệ cho từng tham số (Ví dụ: Tuổi từ 18 đến 60). 3. **Xác định các giá trị biên:** Tìm các giá trị tối thiểu (Min) và tối đa (Max). 4. **Chọn các giá trị kiểm thử:** - Tại biên: Min, Max. - Sát biên (hợp lệ): Min+1, Max-1. - Ngoài biên (không hợp lệ): Min-1, Max+1. 5. **Kiểm tra độ dài:** Đối với chuỗi, kiểm tra độ dài 0 (rỗng), 1, Max, Max+1. ## Checklist - [ ] Đã xác định đúng giá trị Min và Max dựa trên yêu cầu (SRS)? - [ ] Đã bao gồm các giá trị biên hợp lệ (Min, Max)? - [ ] Đã bao gồm các giá trị biên không hợp lệ (Min-1, Max+1)? - [ ] Đã xem xét các trường hợp đặc biệt như rỗng (empty), null, hoặc khoảng trắng (space)? - [ ] Đã kiểm tra giới hạn vật lý của kiểu dữ liệu (ví dụ: giá trị lớn nhất của Integer)? ## Output mong đợi - Danh sách các giá trị biên cụ thể cho từng tham số. - Các Test case bao phủ đầy đủ các kịch bản tại ranh giới (hợp lệ và không hợp lệ). --- ## From: 01-test-design/01.02.equivalence.partitioning.md # 01.02. Equivalence Partitioning (Phân vùng tương đương) ## Mục đích Chia dữ liệu đầu vào thành các nhóm (phân vùng) mà hệ thống xử lý theo cách tương tự nhau. Kỹ thuật này giúp giảm số lượng test case cần thực thi mà vẫn đảm bảo độ bao phủ tối đa bằng cách chỉ cần kiểm tra một giá trị đại diện cho mỗi vùng. ## Kiến thức cần có - Hiểu về các loại dữ liệu đầu vào (String, Number, Date, v.v.). - Hiểu biết về logic nghiệp vụ và các quy tắc xử lý của ứng dụng. - Khả năng phân loại dữ liệu thành các nhóm hợp lệ và không hợp lệ. ## Quy trình thực hiện 1. **Xác định đầu vào:** Liệt kê tất cả các trường dữ liệu hoặc điều kiện đầu vào của tính năng. 2. **Chia phân vùng:** - **Vùng hợp lệ (Valid):** Các giá trị mà hệ thống phải chấp nhận và xử lý đúng. - **Vùng không hợp lệ (Invalid):** Các giá trị mà hệ thống phải từ chối hoặc báo lỗi. 3. **Chọn giá trị đại diện:** Chọn ít nhất một giá trị tiêu biểu từ mỗi phân vùng để đưa vào test case. 4. **Thiết kế test case:** Mỗi test case nên bao phủ một hoặc nhiều vùng hợp lệ, nhưng mỗi vùng không hợp lệ nên được kiểm tra bởi một test case riêng biệt để tránh lỗi bị che lấp. ## Checklist - [ ] Đã xác định đầy đủ các vùng hợp lệ dựa trên đặc tả? - [ ] Đã xác định đầy đủ các vùng không hợp lệ (sai kiểu dữ liệu, ngoài dải)? - [ ] Có vùng nào bị chồng chéo (overlapping) hoặc bị bỏ sót không? - [ ] Mỗi phân vùng đã có ít nhất một giá trị đại diện cụ thể? ## Output mong đợi - Bảng phân vùng tương đương (Equivalence Class Table). - Danh sách các Test case đại diện cho tất cả các phân vùng đã xác định. --- ## From: 01-test-design/01.03.decision-table.md # 01.03. Decision Table (Bảng quyết định) ## Mục đích Hệ thống hóa việc kiểm thử các quy tắc nghiệp vụ phức tạp, nơi kết quả phụ thuộc vào sự kết hợp của nhiều điều kiện đầu vào khác nhau. Kỹ thuật này đảm bảo mọi tổ hợp logic đều được xem xét và không có kịch bản nào bị bỏ sót. ## Kiến thức cần có - Logic Boolean (AND, OR, NOT). - Hiểu sâu về các quy tắc nghiệp vụ (Business Rules) và sự phụ thuộc giữa các điều kiện. - Khả năng phân tích hệ quả (Actions) từ các nguyên nhân (Conditions). ## Quy trình thực hiện 1. **Liệt kê Điều kiện (Conditions):** Xác định tất cả các yếu tố đầu vào ảnh hưởng đến kết quả. 2. **Liệt kê Hành động (Actions):** Xác định tất cả các kết quả hoặc phản ứng có thể xảy ra của hệ thống. 3. **Xây dựng ma trận tổ hợp:** Tạo các cột tương ứng với tất cả các kết hợp của điều kiện (T/F hoặc Yes/No). 4. **Xác định hành động cho từng cột:** Điền kết quả mong đợi cho mỗi tổ hợp điều kiện. 5. **Tối ưu hóa bảng:** Loại bỏ các cột không thể xảy ra trong thực tế hoặc gộp các cột có cùng hành động nếu có điều kiện không ảnh hưởng (Don't care). ## Checklist - [ ] Đã liệt kê đầy đủ tất cả các điều kiện đầu vào? - [ ] Đã xác định chính xác các hành động đầu ra tương ứng? - [ ] Các tổ hợp logic đã bao quát toàn bộ các trường hợp có thể xảy ra? - [ ] Đã xử lý hoặc loại bỏ các kịch bản "bất khả thi" một cách hợp lý? ## Output mong đợi - Bảng quyết định (Decision Table) hoàn chỉnh. - Tập hợp các Test case được trích xuất trực tiếp từ các quy tắc (Rules) trong bảng. --- ## From: 01-test-design/01.06.error-guessing.md # 01.06. Error Guessing (Đoán lỗi) ## Mục đích Sử dụng kinh nghiệm, trực giác và kiến thức chuyên sâu về hệ thống của tester để tìm ra các lỗi mà các phương pháp có cấu trúc có thể bỏ sót. Kỹ thuật này tập trung vào các tình huống "ngoại lệ" và các điểm yếu thường gặp của phần mềm. ## Kiến thức cần có - Kinh nghiệm thực tế về các loại lỗi phổ biến trong phát triển phần mềm. - Hiểu biết về công nghệ, kiến trúc và các lỗi lịch sử của dự án. - Tư duy "phá hoại" (Ad-hoc testing mindset). ## Quy trình thực hiện 1. **Phân tích rủi ro:** Xác định các khu vực nhạy cảm hoặc phức tạp trong mã nguồn. 2. **Liệt kê kịch bản lỗi:** Dự đoán các sai sót của người dùng hoặc các điều kiện hệ thống bất thường. 3. **Thiết kế kịch bản đặc biệt:** - Dữ liệu rỗng, ký tự lạ, SQL Injection/XSS đơn giản. - Thao tác nhanh, nhấn nút nhiều lần (Double click). - Ngắt kết nối mạng giữa chừng, hết bộ nhớ, timeout. 4. **Thực thi và điều chỉnh:** Thử nghiệm các kịch bản và mở rộng dựa trên phản hồi của hệ thống. ## Checklist - [ ] Đã liệt kê các trường hợp đầu vào "cực đoan" (Special characters, zero, null)? - [ ] Đã kiểm tra các kịch bản về hiệu năng hoặc tài nguyên (Low memory, slow network)? - [ ] Đã thử các hành động không theo trình tự logic của người dùng? - [ ] Đã dựa trên các lỗi thực tế từng xảy ra trong quá khứ của hệ thống? ## Output mong đợi - Danh sách các Test Scenarios ngoại lệ (Edge cases). - Các lỗi tiềm ẩn hoặc rủi ro được phát hiện thông qua kinh nghiệm.