Test Cases

 

• Hay còn gọi là Trường hợp kiểm thử, là một tài liệu chi tiết, cụ thể, mô tả các bước thực hiện, dữ liệu đầu vào và kết quả mong đợi để kiểm tra một chức năng hoặc một tính năng cụ thể của phần mềm.

 

• Mục đích chính của việc tạo ra các Test Case là để đảm bảo quá trình kiểm thử được thực hiện một cách có hệ thống, minh bạch và có thể tái hiện. Nó giúp người kiểm thử (tester) biết chính xác mình cần làm gì, dữ liệu nào cần sử dụng, và kết quả mong đợi là gì để xác định xem phần mềm có hoạt động đúng hay không.

 

Vai trò của Test Cases

 

• Vai trò chính là đảm bảo tính năng hoặc giao diện của ứng dụng được thiết kế và hoạt động với kết quả đúng như mong đợi. Đây là bước đầu tiên trong quá trình test mà bất cứ tester nào cũng phải thực hiện. Nếu xây dựng Test Cases không chất lượng có thể gây sai sót, ảnh hưởng tới các bước tiếp theo.

 

Ngoài vai trò chính này, Test Cases còn có vai trò quan trọng trong việc:

 

• Đảm bảo phạm vi kiểm thử.
• Phát hiện các lỗi, bug, thiếu sót trong tính năng và giúp cải thiện chất lượng phần mềm. Quá trình vận hành, bảo trì và cập nhật cũng trở nên dễ dàng hơn.
• Giúp xác định liệu phần mềm đã đáp ứng đầy đủ mong muốn người dùng chưa. Nếu chưa thì lập trình viên cần xem xét và sửa lại trước khi công bố phần mềm ra thị trường.
• Tester có thể thực hiện nhiều test case cùng lúc để nhìn nhận phần mềm ở nhiều góc độ khác nhau.
• Test case có thể được tái sử dụng vô hạn trong tương lai, miễn là tester cảm thấy phù hợp.

 

Cấu trúc của một Test Cases

Cấu trúc của Test Cases sẽ khác nhau ở từng dự án, từng công ty. Sau đây là những thành phần chính bạn có thể bắt gặp khi xây dựng test case:

 

• Mã test case (ID test case): Giá trị cần để xác định thứ tự của test case. ID có thể bao gồm chữ và số được đánh dấu theo thứ tự tăng dần.
• Mục đích kiểm thử (Test case Description): Mô tả mục đích của test case là kiểm tra chức năng nào. Ở mục này, tester sẽ mô tả công việc thực hiện.
• Dữ liệu kiểm thử (Test Data): Dữ liệu cần chuẩn bị để thực hiện việc kiểm thử, có thể có hoặc không tùy từng quy mô dự án. Tester có thể để ở dạng tên data hoặc đường dẫn tới file.
• Các bước thực hiện (Test Steps): Mô tả chi tiết những bước thực hiện test. Tuy nhiên, tester nên mô tả một cách ngắn gọn và thật rõ ràng và không nên bỏ qua các sự kiện thiết yếu để có thể dễ dàng thực hiện lại khi có lỗi.
• Kết quả mong muốn (Expected Results): Hiển thị kết quả mong đợi từ những bước kiểm thử. Kết quả mong muốn thường dựa trên yêu cầu của khách hàng hoặc đánh giá theo tài liệu chuyên môn.
• Kết quả thực tế (Test Results): Hiển thị kết quả thực tế từ những bước thực hiện trên môi trường của hệ thống, thường sẽ là pass, fail hoặc pending.

 

Các nhóm chính của Test Cases

 

• GUI test case: Bao gồm tất cả những test case được xây dựng để kiểm tra giao diện người dùng đồ họa.
• Positive test case: Bao gồm những test case tích cực, hợp lệ, nhập dữ liệu đúng.
• Negative test case: Bao gồm những test case tiêu cực, không hợp lệ, nhập dữ liệu sai.
• Combination test case: Bao gồm những test case nằm giữa 2 loại positive và negative. Những test case này có nhiều bước đúng, sai đan xen những bước cuối cùng luôn đúng.

Các loại Test Cases 

 

 

• Functionality Test Cases

 

 

• Test cases chức năng giúp xác định sự thành công hay thất bại của một chức năng phần mềm – cũng chính là giá trị kỳ vọng. Những case này yêu cầu phần mềm cho phép test mà không cần phải truy cập vào source code của phần mềm.

 

• Chúng có thể được viết và chạy sớm trong giai đoạn development ngay khi những chức năng đầu tiên hoàn thành. Chúng có thể được viết bằng code, nếu được yêu cầu. Functionality Test Cases nên được lặp lại bất cứ khi nào có thay đổi trong các chức năng của phần mềm.

 

 

• User Interface Test Cases

 

 

• Test cases giao diện người dùng được sử dụng để xác minh các thành phần của GUI (giao diện người dùng đồ họa) có đang hoạt động đúng mong đợi không. Loại test cases này giúp kiểm định về ngữ pháp, thẩm mỹ và lỗi dịch thuật, link hoặc bất cứ thành phần nào mà người dùng có thể thấy trên giao diện.

 

• Những case này thường được phối hợp xây dựng bởi nhóm designer và nhóm tester. Những test case này sẽ chạy tại giai đoạn hoàn thiện phần mềm, khi mà GUI đã được kết nối với cơ sở dữ liệu để kiểm tra xem phần mềm có tương thích và hoạt động tốt trên nhiều trình duyệt không.

 

 

• Performance Test Cases

 

 

• Test cases hiệu suất được sử dụng để kiểm tra hiệu năng phần mềm, cụ thể là thời gian phản hồi và hiệu suất hoạt động của ứng dụng. Test cases này sẽ cho phép kiểm tra thời gian cần thiết để hệ thống phản hồi một hoạt động theo bộ tiêu chí rõ ràng.

 

• Performance Test Cases thường được tester viết và cho phép chạy tự động liên tục trong suốt quá trình thiết kế phần mềm. Chúng sẽ giúp xác định xem ứng dụng hoạt động thực tế như thế nào, cũng như những trường hợp cụ thể mà ứng dụng hoạt động chưa hiệu quả. Từ đó lập trình viên có thể xem xét để cải thiện hiệu suất ứng dụng tối ưu hơn.

 

 

• Integration Test Cases

 

 

• Test cases tích hợp được sử dụng để xem xét sự tương tác giữa các module với nhau. Mục đích chính của test case này là đảm bảo giao diện giữa các module tương thích và hoạt động tốt nhất trong mọi điều kiện.

 

• Integration Test Cases thường được phối hợp xây dựng bởi nhóm tester và nhóm development. Tester sẽ xác định khu vực cần tiến hành test. Trong khi đó, developer cung cấp các dữ liệu đầu vào cho từng trường hợp kiểm thử. Cuối cùng, một trong 2 nhóm sẽ thực hiện xác định xem các module hoạt động độc lập có thể phối hợp làm việc cùng nhau không.

 

 

• Usability Test Cases

 

 

• Test cases tính khả dụng hay Task (nhiệm vụ) hoặc Scenarios (Kịch bản) cung cấp nhiệm vụ hoặc kịch bản yêu cầu tester phải hoàn thành. Test case này giúp tester trải nghiệm và xác định phương hướng tiếp cận, sử dụng sản phẩm, dịch vụ của người dùng theo cách tự nhiên nhất. Các trường hợp thử nghiệm được chuẩn bị bởi cả 2 nhóm designer – tester và phải được triển khai trước khi tiến hành User Acceptance Test Cases (Kiểm thử chấp nhận người dùng).

 

 

• Database Test Cases

 

 

• Test cases cơ sở dữ liệu được sử dụng để kiểm tra các luồng xử lý, hướng đi trong cơ sở dữ liệu của ứng dụng. Test case này được thực hiện để đảm bảo rằng lập trình viên xử lý và lưu trữ dữ liệu trong database một cách nhất quán, an toàn. Để xây dựng Database Test Case, tester cần hiểu rõ về ứng dụng, cơ sở dữ liệu ứng dụng cũng như các thủ tục cần thiết cho lưu trữ, quản trị dữ liệu. Thông thường, tester sẽ sử dụng truy vấn SQL để xây dựng những test case này.

 

 

• Security Test Cases

 

 

• Test cases bảo mật được sử dụng để đảm bảo ứng dụng được phân quyền dữ liệu và hạn chế xâm nhập ở những nơi cần thiết. Từ đó giúp bảo vệ dữ liệu ở những khu vực cần thiết. Security Test Case sẽ được xây dựng để kiểm tra thâm nhập và mức độ xác thực, mã hóa dữ liệu của ứng dụng. Nhóm Security sẽ là người chịu trách nhiệm chính cho loại test case này.

 

 

• User Acceptance Test Cases

 

 

• Test cases chấp nhận người dùng được sử dụng để kiểm tra môi trường sử dụng của người dùng. Mục đích của những test case là xác minh rằng ứng dụng có thể đáp ứng được nhu cầu người dùng ở tất cả các lĩnh vực. Chính vì vậy, test case này cần được xây dựng đa dạng lĩnh vực, ngành nghề và bám sát vào thực tế nhất. Những người xây dựng User Acceptance Test Cases chủ yếu là quản lý dự án hoặc nhóm tester. Đây là bước kiểm thử cuối cùng và quan trọng nhất trước khi công bố sản phẩm và đưa vào sản xuất thực tế.

 

Những kỹ thuật Test Cases

 

 

• Kỹ thuật Test Cases tĩnh

 

 

Hay Static Testing Technique là phương pháp kiểm thử thủ công thông qua giấy bút mà không cần chạy phần mềm trực tiếp. Kiểm thử tĩnh thường được thực hiện bằng tay hoặc các phần mềm, công cụ kiểm thử. Quá trình này sẽ do lập trình viên hoặc người review code thực hiện nhằm kiểm tra code, yêu cầu kỹ thuật, tài liệu thiết kế, mã nguồn, kịch bản thử nghiệm,… có chính xác và khả thi không.

 

Các loại kiểm thử tĩnh thường bao gồm:

 

• Informal Review: Là quá trình kiểm thử không chính thức, trong đó các tài liệu kỹ thuật sẽ được xem xét và nhận xét.
• Walk-through: Là phương pháp chia sẻ thông tin, hướng dẫn, giải thích, chuyển giao thông tin để giúp những người tham gia kiểm thử hiểu rõ về phần mềm, ứng dụng. Từ đó họ có thể nhận biết và phát hiện những lỗi tồn tại trong phần mềm. Test case này thường được tổ chức thành một buổi họp và được ghi chép, lưu trữ thông tin lại.
• Technical review: Là phương pháp kiểm thử tập trung vào việc đánh giá và thảo luận về phần kỹ thuật của ứng dụng, phần mềm. Từ đó đưa ra phương hướng giải quyết, thay thế kỹ thuật, sửa đổi lỗi,… để tối ưu ứng dụng.
• Inspection: Là phương pháp kiểm thử giúp xác định những khiếm khuyết còn tồn tại. Người kiểm duyệt sẽ thực hiện kiểm tra xem các tài liệu công việc đã được hoàn thành tới đâu.

 

 

• Kỹ thuật test case động

 

 

Hay Dynamic Testing Technique là phương pháp kiểm thử thông qua việc sử dụng máy chạy chương trình. Lúc này, code đã được vận hành, đầu vào đã được cung cấp giá trị và cho kết quả (đầu ra). Kiểm thử động sẽ so sánh kết quả thực tế này với kết quả mong đợi ban đầu để xác định rằng phần mềm đã đáp ứng nhu cầu hay chưa. Các kỹ thuật test case động bao gồm 3 nhóm chính sau:

 

 

• Kỹ thuật Specification-based

 

 

Đây là nhóm kỹ thuật kiểm thử tập trung vào những yếu tố bên ngoài như cách thiết kế, cách vận hành bên ngoài,… Tester có thể kiểm tra mà không tác động làm thay đổi cấu trúc bên trong phần mềm. Các kỹ thuật cụ thể thuộc nhóm này bao gồm:

 

• Phân vùng tương đương (Equivalence Partitioning): Đầu vào sẽ được phân chia thành các lớp dữ liệu với điều kiện tương đương để thực hiện các ca kiểm thử.
• Phân tích giá trị biên (Boundary Value Analysis): Tester sẽ thực hiện kiểm thử giá trị biên của dữ liệu vào và ra theo 2 cách chính là: Kiểm tra 2 giá trị (với 4 test case là nhỏ nhất, sát dưới mức nhỏ nhất, lớn nhất, sát trên mức lớn nhất) và kiểm tra 3 giá trị (với 6 test case là nhỏ nhất, sát dưới mức nhỏ nhất, sát trên mức nhỏ nhất, lớn nhất, sát dưới mức lớn nhất, sát trên mức lớn nhất).
• Bảng quyết định (Decision Table Testing): Được thực hiện khi đầu vào chứa nhiều điều kiện và đầu ra chứa nhiều hành động. Kỹ thuật này giúp tiết kiệm thời gian chạy thử chương trình nhưng vẫn bao quát toàn bộ đầu ra và đầu vào.
• Chuyển đổi trạng thái (State Transition Testing): Là phương pháp kiểm thử bằng cách thay đổi điều kiện đầu vào dẫn tới sự thay đổi trạng thái của phần mềm, ứng dụng. Cụ thể, tester sẽ cung cấp dữ liệu đầu vào hợp lệ và không hợp lệ để xem xét cách thức phản hồi của hệ thống cho từng trường hợp.
• Trường hợp sử dụng (Use cases Testing): Là phương pháp kiểm thử giúp xác định toàn bộ test case đang được thực hiện trên toàn bộ hệ thống, từ đó giúp tìm kiếm và khắc phục những lỗi từ kiểm thử tích hợp.

 

 

• Kỹ thuật Structure-based

 

 

Đây là nhóm kỹ thuật được sử dụng để kiểm thử cấu trúc và cách vận hành của phần mềm, ứng dụng. Để thực hiện được kỹ thuật này, tester phải am hiểu về lập trình thì mới có thể nạp input và kiểm thử output chính xác. Những kỹ thuật cụ thể thuộc nhóm này bao gồm:

 

• Kiểm thử câu lệnh (Statement testing): Tester kiểm tra cách vận hành của mã nguồn bằng cách thực thi mọi câu lệnh ít nhất một lần theo các điều kiện đúng.
• Kiểm thử quyết định (Decision testing): Được sử dụng để kiểm tra xem trong chương trình có câu lệnh nào không thể truy cập hoặc gây bất thường không. Trong đó, tester sẽ bắt đầu từ điểm quyết định (decision point) và đi theo control flow để kiểm tra kết quả quyết định (decision result).
• Kiểm thử điều kiện (Condition testing): Được sử dụng để kiểm tra các biểu thức Boolean bằng cách thực thi chúng ít nhất một lần bằng cả giá trị đúng và sai.
• Kiểm thử đa điều kiện (Multiple condition testing): Được sử dụng để kiểm thử toàn bộ tổ hợp điều kiện có thể của quyết định. Trong đó, số lượng tổ hợp chính là số test case phải thực hiện và bằng 2 lũy thừa bậc N (N là số điều kiện).

 

 

• Kỹ thuật Experience-based

 

 

Nhóm kỹ thuật experience-based được thiết kế dựa trên kiến thức, kinh nghiệm, năng lực chuyên môn của tester. Những kỹ thuật cụ thể của nhóm này bao gồm:

 

• Kiểm thử thăm dò (Exploratory testing): Tester sẽ vừa thăm dò phần mềm, vừa thiết kế và thiện hiện quá trình kiểm thử. Quá trình này không diễn ra theo lịch trình hay các bước cụ thể mà thay đổi linh hoạt theo kinh nghiệm của từng tester.
• Phỏng đoán lỗi (Error guessing): Tester sẽ phỏng đoán các lỗi tiềm ẩn có thể tồn tại trong phần mềm dựa trên vốn kinh nghiệm có sẵn.

 

Cách viết Test Cases chất lượng

 

• Xác định mục đích: Ở bước này, tester cần tìm hiểu nhu cầu và mong muốn của khách hàng. Sau đó, họ sẽ đặt ra những mục tiêu, tiêu chuẩn cụ thể cho test case để giúp phần mềm, ứng dụng có thể đáp ứng những nhu cầu này.
• Xác định hiệu suất: Bước này yêu cầu tester phải am hiểu về lập trình. Trong đó, họ sẽ phải xác định xem module đang test có chức năng gì, dữ liệu, thành phần trong module sẽ tương tác với nhau như thế nào,… từ đó tính toán được hiệu suất kiểm thử.
• Xác định yêu cầu phi chức năng: Bên cạnh yêu cầu về phần cứng, cấu trúc hệ thống hay bảo mật dữ liệu thì các yêu cầu phi chức năng cũng rất quan trọng với một ứng dụng, phần mềm. Vì vậy ở bước này, tester cần liệt kê toàn bộ những yêu cầu phi chức năng có thể xuất hiện và tiến hành kiểm thử.
• Xác định biểu mẫu: Mỗi phần mềm, ứng dụng sẽ có những biểu mẫu testing khác nhau. Tuy nhiên, nhìn chung trong quá trình viết test case, tester cần đảm biểu mẫu chứa các yếu tố gồm giao diện người dùng (UI), chức năng, khả năng tương thích, hiệu suất phần mềm.
• Xác định tương tác giữa module: Cuối cùng để viết test case chất lượng, tester cần hiểu rõ cách các module đang tương tác với nhau. Điều này giúp tối ưu quá trình test cũng như đảm bảo test case bao phủ toàn bộ các module có liên kết.

 

Test Scenarios

 

• Hay còn gọi là Kịch bản kiểm thử, là một tập hợp các bước, điều kiện và dữ liệu đầu vào cụ thể được sử dụng để kiểm tra một tính năng hoặc yêu cầu nhất định của phần mềm. Nó mô tả một trường hợp sử dụng cụ thể và các bước cần thực hiện để kiểm tra trường hợp đó. Test Scenario giúp các kiểm thử viên có một cách tiếp cận có hệ thống trong việc kiểm tra phần mềm và đảm bảo rằng tất cả các trường hợp quan trọng đều được kiểm tra.

 

Vai trò quan trọng của Test Scenario trong kiểm thử

 

Test Scenario đóng một vai trò quan trọng trong quá trình kiểm thử phần mềm bởi một số lý do sau:

 

• Giúp xác định phạm vi kiểm thử: Bằng cách xác định các kịch bản kiểm thử, đội ngũ kiểm thử có thể hiểu rõ phạm vi kiểm thử và đảm bảo rằng tất cả các tính năng quan trọng đều được kiểm tra.
• Cung cấp một cách tiếp cận có hệ thống: Test Scenario cung cấp một khuôn khổ có hệ thống để thực hiện kiểm thử, giúp các kiểm thử viên không bỏ sót bất kỳ trường hợp nào.
• Tăng độ lặp lại và tính nhất quán: Với các kịch bản kiểm thử được định nghĩa rõ ràng, việc kiểm tra có thể được lặp lại và đảm bảo tính nhất quán trong quá trình kiểm thử.
• Hỗ trợ ghi lại và báo cáo kết quả: Test Scenario giúp ghi lại và báo cáo kết quả kiểm thử một cách dễ dàng hơn, cung cấp thông tin chi tiết về các trường hợp đã được kiểm tra và kết quả tương ứng.

 

Cách viết Test Scenario 

 

Bước 1: Đọc kỹ các tài liệu yêu cầu như BRS (Business Requirement Specification), SRS (Software Requirement Specification), FRS (Functional Requirement Specification) của hệ thống cần kiểm thử (System Under Test – SUT). Ngoài ra, cũng nên tham khảo các use cases, sách hướng dẫn sử dụng ứng dụng để hiểu rõ hơn về chức năng và cách sử dụng.

 

Bước 2: Đối với mỗi yêu cầu được liệt kê trong tài liệu, cần xác định:

 

• Hành động và mục tiêu có thể của người dùng khi sử dụng tính năng đó.
• Các khía cạnh kỹ thuật liên quan đến yêu cầu, như đầu vào, đầu ra, xử lý dữ liệu, tích hợp với hệ thống khác,…
• Các tình huống lạm dụng hệ thống có thể xảy ra, như nhập dữ liệu không hợp lệ, truy cập trái phép, tấn công bảo mật,… Cần đánh giá với góc nhìn của một hacker.

 

Bước 3: Sau khi đọc và phân tích các tài liệu yêu cầu, liệt kê các kịch bản kiểm thử nhằm xác minh từng tính năng của phần mềm. Mỗi kịch bản kiểm thử cần bao gồm:

 

• Mô tả kịch bản
• Điều kiện tiên quyết (nếu có)
• Các bước thực hiện kiểm thử chi tiết
• Dữ liệu đầu vào
• Kết quả mong đợi

 

Bước 4: Khi đã liệt kê đầy đủ các kịch bản kiểm thử, tạo ma trận truy xuất nguồn gốc (Traceability Matrix) để đảm bảo rằng tất cả các yêu cầu đều có ít nhất một kịch bản kiểm thử tương ứng để xác minh.

 

Bước 5: Các kịch bản kiểm thử được tạo ra cần được xem xét và phê duyệt bởi người giám sát dự án, người quản lý kiểm thử và các bên liên quan khác trong dự án để đảm bảo tính đầy đủ, chính xác và khả thi.

 

Phân biệt Test Case và Test Scenario

 

Test Case	Test Scenario
Bao gồm tên Test Case, điều kiện tiên quyết, các bước thực hiện hoặc dữ liệu đầu vào và kết quả mong đợi.	Bao gồm một quy trình tiêu chuẩn thực hiện kiểm thử chi tiết. Một Test Scenario bao gồm nhiều Test Case liên quan.
Thuộc cấp độ hành động thấp hơn và có thể bắt nguồn từ Test Scenario.	Được phân cấp cao hơn trong nhóm điều kiện kiểm thử dựa trên tính năng của các module và bắt nguồn từ việc sử dụng trong trường hợp nhất định.
Đưa ra thông tin chi tiết về điều kiện tiên quyết (nếu có), cách kiểm thử và kết quả mong đợi.	Mô tả ngắn gọn và súc tích cho biết cái cần được kiểm thử.
Trở nên quan trọng hơn khi việc phát triển được thực hiện tại chỗ (onsite) và việc quản lý chất lượng được tiến hành từ xa (offshore). Nó giúp các bên hiểu và làm việc đồng bộ.	Trở nên quan trọng khi không đủ thời gian với Test Case; các thành viên nhóm đều tán thành mô tả ngắn gọn nhưng chi tiết về kịch bản kiểm thử.
Viết Test Case chỉ tốn công một lần và có khả năng được dùng trong tương lai khi thực hiện kiểm thử hồi quy. Khi báo lỗi, nó giúp tester liên kết giữa số liệu Test Case (ID) và lỗi được phát hiện.	Trong bối cảnh kiểm thử phần mềm kiểu mới, Test Scenario là một ý tưởng đột phá và tiết kiệm thời gian. Việc sửa chữa và thêm không quá khó khăn và không phụ thuộc vào đối tượng đặc biệt nào.
Đối với một tester mới, tài liệu chi tiết về Test Case là một tập hợp bằng chứng quan trọng. Trong trường hợp developer bỏ lỡ điều gì đó thì tester cũng có thể nắm bắt được khi thực hiện kiểm thử bằng Test Case.	Một trong những ưu điểm nổi bật nhất về Test Scenario là sẽ giảm được sự phức tạp cũng như là tính lặp lại của sản phẩm.
Cần nhiều thời gian cũng như nguồn lực để tiến hành Test Case chi tiết khi bàn luận về việc kiểm thử như thế nào và kiểm thử điều gì.	Trường hợp Test Scenario không có đủ sự chi tiết, nó cần ít thời gian để bàn luận và trao đổi về Test Scenario chính xác đang nói về điều gì.