Xác định nội dung cần kiểm thử, xác định các trường hợp kiểm thử và mức độ ưu tiên.
Trong bài đăng trước, bạn đã tìm hiểu về các chiến lược kiểm thử, số lượng bài kiểm thử cần thiết để kiểm thử một ứng dụng cũng như cách tìm ứng dụng phù hợp nhất để có được kết quả tự tin nhất trong khi vẫn lưu ý đến tài nguyên của mình. Tuy nhiên, điều này chỉ cho chúng ta ý tưởng về lượng nội dung cần kiểm thử. Bạn vẫn cần xác định chính xác nội dung cần kiểm thử. Ba tiêu chí sau đây có thể giúp bạn hiểu rõ những điều có thể mong đợi trong một chương trình kiểm thử, cũng như giúp bạn biết được loại kiểm thử nào cũng như mức độ chi tiết phù hợp nhất:
- Chăm sóc con đường hạnh phúc của bạn. Đây là câu chuyện chung nhất hoặc chính về ứng dụng của người dùng chính, trong đó người dùng sẽ nhanh chóng nhận thấy lỗi.
- Quyết định kỹ về mức độ chi tiết. Hãy tìm hiểu chi tiết hơn xem trường hợp sử dụng của bạn dễ bị tấn công hoặc có lỗi gây ra thiệt hại lớn.
- Ưu tiên kiểm thử cấp thấp hơn (ví dụ: kiểm thử đơn vị và kiểm thử tích hợp) thay vì kiểm thử toàn diện cấp cao hơn bất cứ khi nào có thể.
Phần còn lại của bài viết này sẽ khám phá những tiêu chí này và cách chúng áp dụng khi bạn xác định các trường hợp kiểm thử.
Trường hợp kiểm thử là gì?
Trong quá trình phát triển phần mềm, trường hợp kiểm thử là một chuỗi các hành động hoặc tình huống được thiết kế để xác nhận tính hiệu quả của một chương trình hoặc ứng dụng phần mềm. Trường hợp kiểm thử nhằm đảm bảo rằng phần mềm hoạt động theo đúng kế hoạch và tất cả tính năng cũng như chức năng của phần mềm đó hoạt động đúng cách. Nhân viên kiểm thử hoặc nhà phát triển phần mềm thường tạo các trường hợp kiểm thử này để đảm bảo rằng phần mềm đáp ứng các yêu cầu và thông số kỹ thuật đã chỉ định.
Khi chạy một trường hợp kiểm thử, phần mềm sẽ thực hiện một loạt các bước kiểm tra để đảm bảo cho ra kết quả mong muốn. Trong khi làm như vậy, kiểm thử sẽ hoàn thành các nhiệm vụ sau:
- Xác minh. Quá trình kiểm tra kỹ lưỡng phần mềm để đảm bảo phần mềm hoạt động không có lỗi. Việc xác định xem sản phẩm tạo ra có đáp ứng tất cả những yêu cầu cần thiết về chức năng và đạt được mục đích mong muốn hay không là một bước rất quan trọng. Câu hỏi mà công cụ này trả lời là: "Chúng ta có đang xây dựng sản phẩm đúng cách không?"
- Xác thực. Quy trình đảm bảo rằng sản phẩm phần mềm đáp ứng các tiêu chuẩn cần thiết hoặc các yêu cầu cấp cao. Quy trình này bao gồm cả việc kiểm tra xem sản phẩm thực tế có phù hợp với sản phẩm dự kiến hay không. Về cơ bản, chúng ta sẽ trả lời câu hỏi: “Chúng ta có đang xây dựng sản phẩm phù hợp với yêu cầu của người dùng không?”
Giả sử chương trình không mang lại kết quả như mong đợi. Trong trường hợp đó, trường hợp kiểm thử sẽ là thông báo — tức là báo cáo kết quả không thành công, và nhà phát triển hoặc người kiểm thử sẽ cần điều tra vấn đề và tìm ra giải pháp. Hãy coi các bước kiểm tra và hành động là đường dẫn mà máy tính tuân theo, bất kể loại hình kiểm thử là gì. Các nhóm dữ liệu hoặc điều kiện đầu vào dùng để kiểm tra được gọi là "lớp tương đương". Chúng sẽ nhận được hành vi hoặc kết quả tương tự từ hệ thống đang kiểm thử. Các đường dẫn cụ thể được thực thi trong kiểm thử có thể khác nhau nhưng phải khớp với các hoạt động và câu nhận định được thực hiện trong kiểm thử.
Lộ trình kiểm thử: Các loại trường hợp kiểm thử điển hình
Trong hoạt động phát triển phần mềm, trường hợp kiểm thử là tình huống thực thi mã mà từ đó, một hành vi nhất định được dự kiến và kiểm thử. Thông thường, sẽ có 3 trường hợp để hình thành các trường hợp kiểm thử.
Danh sách đầu tiên là cái được biết đến nhiều nhất mà có thể bạn đang sử dụng. Đó là con đường hạnh phúc, còn gọi là “tình huống trong ngày vui vẻ” hoặc “con đường vàng”. Con đường này xác định trường hợp sử dụng phổ biến nhất của tính năng, ứng dụng hoặc sự thay đổi của bạn — cách mà khách hàng sẽ nhận được.
Lộ trình kiểm thử quan trọng thứ hai cần đưa vào trong các trường hợp kiểm thử thường bị bỏ qua vì không thoải mái — đúng như tên gọi của nó. Đó là “đường dẫn đáng sợ” hay nói cách khác là quy trình kiểm thử phủ định. Đường dẫn này nhắm đến các trường hợp khiến mã hoạt động không đúng cách hoặc chuyển sang trạng thái lỗi. Việc kiểm thử các tình huống này đặc biệt quan trọng nếu bạn có những trường hợp sử dụng dễ bị tấn công và có nguy cơ gây rủi ro cao cho các bên liên quan hoặc người dùng.
Ngoài ra, còn có một số đường dẫn khác mà bạn nên tìm hiểu và cân nhắc sử dụng, nhưng thường thì những đường dẫn đó sẽ ít được sử dụng. Bảng sau đây tóm tắt các nội dung này:
| Kiểm thử đường dẫn | Giải thích |
|---|---|
| Con đường tức giận | Điều này dẫn đến lỗi, nhưng là lỗi dự kiến; ví dụ: nếu bạn muốn đảm bảo việc xử lý lỗi diễn ra đúng cách. |
| Đường dẫn quá hạn | Đường dẫn này giải quyết mọi tình huống liên quan đến bảo mật mà ứng dụng của bạn cần đáp ứng. |
| Tách biệt đường dẫn | Tình huống kiểm thử đường dẫn trong ứng dụng của bạn không có đủ dữ liệu để hoạt động, chẳng hạn như kiểm thử các giá trị rỗng. |
| Đường dẫn đã quên | Kiểm thử hành vi của ứng dụng khi không có đủ tài nguyên, ví dụ: kích hoạt việc mất dữ liệu. |
| Lộ trình không rõ ràng | Thử nghiệm với một người dùng đang cố gắng thực hiện các thao tác hoặc theo dõi câu chuyện của người dùng trong ứng dụng của bạn nhưng chưa hoàn thành các quy trình làm việc đó. Trường hợp này có thể xảy ra, chẳng hạn như khi người dùng làm gián đoạn quy trình làm việc của họ. |
| Con đường tham lam | Cố gắng kiểm thử bằng cách sử dụng một lượng lớn dữ liệu đầu vào hoặc dữ liệu. |
| Con đường căng thẳng | Cố gắng làm cho ứng dụng của bạn chịu tải bằng bất kỳ phương tiện nào cần thiết cho đến khi ứng dụng không còn hoạt động (tương tự như kiểm thử tải). |
Có một số phương pháp để phân loại các đường dẫn đó. Hai phương pháp phổ biến là:
- Phân vùng tương đương. Phương pháp kiểm thử giúp phân loại các trường hợp kiểm thử thành nhóm hoặc phân vùng, nhờ đó giúp tạo các lớp tương đương. Điều này dựa trên ý tưởng rằng nếu một trường hợp kiểm thử trong một phân vùng phát hiện ra lỗi, thì các trường hợp kiểm thử khác trong cùng một phân vùng có khả năng sẽ cho thấy các khiếm khuyết tương tự. Vì tất cả dữ liệu đầu vào trong một lớp tương đương cụ thể sẽ biểu hiện hành vi giống nhau, nên bạn có thể giảm số lượng trường hợp kiểm thử. Tìm hiểu thêm về việc phân vùng tương đương.
- Giới hạn việc phân tích. Phương pháp kiểm thử, còn gọi là phân tích giá trị giới hạn, kiểm tra các giới hạn hoặc quá mức của giá trị đầu vào để tìm mọi vấn đề hoặc lỗi tiềm ẩn có thể phát sinh trong giới hạn về khả năng hoặc hạn chế của hệ thống.
Phương pháp hay nhất: Viết các trường hợp kiểm thử
Trường hợp kiểm thử cổ điển do người kiểm thử viết sẽ chứa dữ liệu cụ thể giúp bạn nắm được nội dung kiểm thử mà bạn muốn tiến hành và tất nhiên là thực thi kiểm thử. Một người kiểm thử thông thường sẽ ghi lại các hoạt động kiểm thử của họ trong một bảng. Có hai mẫu mà chúng ta có thể sử dụng ở giai đoạn này, giúp chúng ta cấu trúc các trường hợp kiểm thử và sau đó là chính các kiểm thử của mình:
- Mẫu Sắp xếp, hành động, xác nhận. Mẫu thử nghiệm "sắp xếp, hành động, xác nhận" (còn được gọi là "AAA" hoặc "Triple A") là cách sắp xếp thử nghiệm thành ba bước riêng biệt: sắp xếp thử nghiệm, sau đó thực hiện thử nghiệm và cuối cùng nhưng không kém phần quan trọng là rút ra kết luận.
- Mẫu given, when, then. Mẫu này tương tự như mẫu AAA nhưng có một số gốc rễ trong quá trình phát triển theo hành vi.
Các bài viết trong tương lai sẽ đi sâu hơn về các mẫu này, ngay khi chúng ta đề cập đến cấu trúc của kiểm thử. Nếu bạn muốn tìm hiểu sâu hơn về các mẫu này ở giai đoạn này, hãy tham khảo hai bài viết sau: Arrange-Act-Assert: A case for write Good test và given- when- then.
Theo tất cả tìm hiểu từ bài viết này, bảng sau đây tóm tắt một ví dụ kinh điển:
| Thông tin | Giải thích |
|---|---|
| Điều kiện tiên quyết | Mọi việc cần làm trước khi viết chương trình kiểm thử. |
| Đối tượng đang được kiểm thử | Những thông tin nào cần được xác minh? |
| Dữ liệu đầu vào | Biến và giá trị của chúng. |
| Các bước cần thực thi | Tất cả những việc bạn sẽ làm để hiện thực hoá chương trình kiểm thử: mọi hành động hoặc hành động tương tác bạn thực hiện trong chương trình kiểm thử. |
| Kết quả dự kiến | Điều gì nên xảy ra và những kỳ vọng cần được đáp ứng. |
| Kết quả thực tế | Điều gì thực sự đang xảy ra. |
Trong kiểm thử tự động, bạn không cần phải ghi lại tất cả các trường hợp kiểm thử này theo cách người kiểm thử cần, mặc dù chắc chắn việc này sẽ rất hữu ích. Bạn có thể tìm thấy tất cả thông tin này trong kiểm thử của mình nếu chú ý. Vì vậy, hãy chuyển trường hợp kiểm thử cổ điển này thành kiểm thử tự động.
| Thông tin | Chuyển đổi thành tự động kiểm thử |
|---|---|
| Điều kiện tiên quyết | Tất cả những thứ bạn cần, sắp xếp bài kiểm thử và nghĩ về những gì được đưa ra để biến tình huống của bài kiểm thử thành hiện thực. |
| Đối tượng đang được kiểm thử | “Đối tượng” này có thể là nhiều đối tượng: một ứng dụng, luồng, đơn vị hoặc thành phần đang được kiểm thử. |
| Dữ liệu đầu vào | Giá trị thông số. |
| Các bước cần thực thi | Tất cả các hành động và lệnh được thực thi trong bài kiểm thử của bạn, những điều bạn thực hiện và tìm hiểu điều gì xảy ra khi bạn thực hiện một số việc nhất định. |
| Kết quả dự kiến | Câu nhận định mà bạn dùng để xác thực ứng dụng, những điều bạn xác nhận trong ứng dụng. |
| Kết quả thực tế | Kết quả kiểm tra tự động của bạn. |