Git - Xóa remote repository 
Kỹ thuật Phân tích giá trị biên và phân vùng tương đương 
Git - thao tác thư mục 
Git - Lệnh merge branch - Xử lý conflict 
Git - Cấu hình username và email 
Git - Lệnh tạo Branch 
Git - Amend, thay đổi commit cuối cùng 
Cách khai báo biến trong PHP, các loại biến thường gặp 
Download và cài đặt Vertrigo Server 
Thẻ li trong HTML 
Thẻ article trong HTML5 
Cấu trúc HTML5: Cách tạo template HTML5 đầu tiên 
Cách dùng thẻ img trong HTML và các thuộc tính của img 
Thẻ a trong HTML và các thuộc tính của thẻ a thường dùng Các tài liệu kiểm thử
Tài liệu kiểm thử bao gồm các tài liệu cần được xây dựng trước hoặc trong quá trình kiểm thử phần mềm. Tài liệu kiểm thử phần mềm giúp ước lượng được lượng nguồn lực cần thiết (effort), phạm vi kiểm thử, theo dõi yêu cầu, v.v. Bài viết này sẽ mô tả một số các tài liệu được sử dụng liên quan đến kiểm thử phần mềm.
Dưới đây là một số các tài liệu được sử dụng trong kiểm thử phần mềm:
- Kế hoạch kiểm thử (Test Plan)
- Kịch bản kiểm thử (Test Scenario)
- Trường hợp kiểm thử (Test Case)
- Ma trận nhập xuất (Traceability Matrix)
1. Test Plan
Kế hoạch kiểm thử sẽ vạch ra chiến lược được sử dụng để kiểm thử một ứng dụng phần mềm, các tài nguyên sẽ được sử dụng, môi trường kiểm thử ,trong đó các trường hợp sẽ được kiểm thử, các giới hạn của kiểm thử và lên lịch kiểm thử. Thông thường trưởng nhóm QA sẽ chịu trách nhiệm viết một kế hoạch kiểm thử.
Một kế hoạch kiểm thử bao gồm:
- Giới thiệu về tài liệu kế hoạch kiểm thử phần mềm
- Các giả định trong kiểm thử phần mềm
- Danh sách các trường hợp kiểm thử có trong kiểm thử phần mềm
- Danh sách tính năng cần kiểm thử
- Những phương pháp cần sử dụng trong kiểm thử phần mềm
- Danh sách các trường hợp đặc biệt cần được kiểm thử
- Các nguồn lực được phân bổ để kiểm thử phần mềm
- Những rủi ro liên quan trong quá trình kiểm thử
- Lịch trình cụ thể cho các task, các mốc cần đạt được
2. Test Scenario
Test Scanario là một chuỗi các lưu ý phần nào của phần mềm sẽ được kiểm thử. Các kịch bản kiểm thử được sử dụng để đảm bảo tất cả luồng xử lý được kiểm thử đầu tới cuối. Một chúc năng cụ thể của phần mềm có thể có ít nhất một kịch bản kiểm thử có đến hàng trăm trường hợp kiểm thử tùy thuộc vào độ phức tạp của phần mềm.
Thuật ngữ "kịch bản kiểm thử" và "các trường hợp kiểm thử" được sử dụng thay thế cho nhau, tuy nhiên một kịch bản kiểm thử có nhiều bước, trong khi trường hợp kiểm thử có một bước duy nhất. Từ những quan điểm này, các kịch bản kiểm thử là các trường hợp kiểm thử, nhưng chúng bao gồm một số trường hợp kiểm thử và trình tự mà chúng phải được thực thi.
3. Test Case
Các test cases bao gồm một tập hợp các bước, điều kiện và đầu vào có thể được sử dụng trong khi thực hiện kiểm thử các tác vụ. Mục đích chính là để đảm bảo liệu một phần mềm có thể đúng hoặc sai về chức năng hoặc các khía cạnh khác hay không. Có nhiều loại kiểm thử như kiểm thử chức năng, phủ định, lỗi, trường hợp kiểm tra vật lý, trường hợp kiểm tra logic, trường hợp kiểm tra giao diện người dùng,…
Hơn nữa, các test cases được viết để theo dõi phạm vi kiểm thử của phần mềm. Nói chung, không có mẫu chính thức nào có thể được sử dụng trong khi viết các test cases. Tuy nhiên, các thành phần sau luôn có sẵn và được thêm vào mọi test cases:
- Test case ID
- Module sản phẩm
- Phiên bản sản phẩm
- Lịch sử sửa đổi
- Mục đích
- Giả định
- Điều kiện tiền đề
- Các bước thực hiện
- Kết quả thực tế
- Kết quả dự kiến
- Điều kiên sau
Nhiều trường hợp kiểm thử có thể bắt nguồn từ một kịch bản thử nghiệm duy nhất. Ngoài ra, đôi khi nhiều test cases được viết cho một phần mềm đơn lẻ được gọi chung là bộ kiểm thử (test suites).
4. Traceability Matrix
Traceability Matrix (hay Requirement Traceability Matrix - RTM) là một bảng được sử dụng để theo dõi các yêu cầu trong vòng đời phát triển phần mềm. Nó có thể được sử dụng để tìm nhữngthay đổi trước đó (như các yêu cầu tới thiết kế hoặc viết code) hoặc ngược lại (từ viết code tới các yêu cầu). Có nhiều mẫu do người dùng xác định cho RTM.
Mỗi yêu cầu trong tài liệu RTM được liên kết với trường hợp kiểm thử liên quan để kiểm tra có thể thực hiện theo các yêu cầu đã để ra. Hơn nữa Bug ID cũng được thêm vào và được liên kết với các yêu cầu liên quan và các testcases. Mục tiêu chính của ma trận này là:
- Đảm bảo phần mềm được phát triển theo các yêu cầu đã đề ra.
- Giúp tìm ra nguyên nhân gốc rễ của lỗi.
- Giúp theo dõi các tài nguyên được phát triển trong các giai đoạn khác nhau của vòng đời phát triển phần mềm.
