Thuật Ngữ Testing

Edge case là gì?

testing edge case
testing edge case

🐞 Trong kiểm thử phần mềm, khi bạn dựa vào tài liệu mô tả yêu cầu để thiết kế, nghĩ ra những trường hợp cần kiểm thử, thì đa phần những trường hợp: đó là positive case (còn gọi là happy case) – là những trường hợp nhập các giá trị đúng thì mong đợi phần mềm thực hiện đúng theo mô tả yêu cầu; Và các trường hợp negative case (nhập những giá trị sai và phần mềm sẽ báo lỗi tương ứng). Vậy còn edge case là gì? Nó cũng là một dạng negative case nhưng các thao tác thường phức tạp và lắc léo hơn.

Theo định nghĩa trên trang Cambridge

Edge case is a problem or situation, especially in computer programming, that only happens at the highest or lowest end of a range of possible values or in extreme situations.

Theo từ điển American English thì

Edge case is an unusual or unforeseen situation where something may fail to work properly or as expected.

Qua những định nghĩa trên cùng với kinh nghiệm kiểm thử phần mềm của mình thì 

Edge case là những trường hợp lắc léo, hóc búa mà khi chỉ dựa vào mô tả trong tài liệu yêu cầu bạn không xác định được nó. Thường những trường hợp này xảy ra khi môi trường và các tham số đầu vào không như mong đợi của ứng dụng hoặc tìm cách can thiệp làm thay đổi phá vỡ logic của quy trình nghiệp vụ bình thường. Corner case là một thuật ngữ tương tự với edge case.

Ví dụ một edge case: Trả lời một bình luận đã bị xoá trên facebook.

Dựa vào đâu để nghĩ ra edge case?

Để nghĩ ra được edge case thì chủ yếu là dựa vào kinh nghiệm bản thân, dựa vào kiến thức về những điểm yếu, lỗ hổng của công nghệ đang được sử dụng để thiết kế ra phần mềm mà bạn đang kiểm thử. Bên cạnh đó còn dựa vào nghiệp vụ và lĩnh vực mà phần mềm đó phục vụ.

Thường thì tài liệu yêu cầu chỉ mô tả những trường hợp “happy case.” Rất khó để có thể liệt kê các trường hợp mà mình không biết hoặc chưa biết. Nói cách khác, tài liệu thường mô tả các trường hợp mình muốn phần mềm thực hiện chứ không mô tả các trường hợp mình không muốn phần mềm thực hiện.

Xem thêm lớp Kiểm thử phần mềm dành cho người mới

Khi nào thì nên nghĩ về edge case?

Nói về thời điểm thì những trường hợp này nên được xác định (nghĩ ra) càng sớm càng tốt. Vì đa phần những trường hợp này rất khó hoặc rất tốn kém để sửa (fix). Trong thời gian làm tester, mình đã gặp những trường hợp edge case mà phải thiết kế lại workflow của nghiệp vụ để tránh xảy ra những lỗi đó chứ không đơn giản là chỉ cần fix là được.

Nhưng thường thì khi phân tích tài liệu yêu cầu bạn không nghĩ ra được nhiều edge case. Những trường hợp này thường chỉ xuất hiện trong đầu khi bạn đang thực hiện kiểm thử, đang sử dụng sản phẩm, và nhất là trong lúc bạn thực hiện exploratory testing (kiểm thử khám phá) hay ad hoc testing (kiểm thử ngẫu nhiên).

Trong lớp ISTQB CTFL mình có dạy thêm về Exploratory Testing và edge case.

Đây là những cái lỗi mà người ta hay nói vui rằng là:

Một trong những lý do tôi rất thích làm tester đó là chỉ mất 5 phút để tìm ra 1 lỗi nhưng developer phải mất 5 ngày để sửa. 

Một số ví dụ về edge case

Dưới đây là một số trường hợp edge thường gặp trong kiểm thử ứng dụng web và mobile app.

  • Nhập số lượng sản phẩm cần mua = 0 
  • Chuyển tiền với số tiền là âm
  • Đồng thời cùng thay đổi nội dung của 1 đối tượng (như bài post hoặc user)
  • Cập nhật thông tin của một user không tồn tại
  • Truy cập một nội dung không tồn tại từ hộp thông báo
  • Tìm cách tạo ra lỗi ​​414 (too long request) khi test api (get hoặc post) với giá trị của tham số được gắn vào url như /v2/getTicket?Id=12,13,14,…
  • Khi kiểm thử trên mobile thì thử đồng thời thực hiện thao tác và xoay điện thoại
  • Chuyển mạng giữa 4G và wifi trong lúc thực hiện giao dịch (chuyển khoản, thanh toán online, upload/download, v.v…)

Ví dụ một kịch bản về hệ thống hỏi đáp

Dưới đây là các bước tái hiện một lỗi được tester báo cáo. Tester cho rằng đây là lỗi nghiêm trọng vì có thể làm thay đổi bản chất vấn đề, và việc thay đổi nội dung câu hỏi sau khi đã được trả lời là không thể chấp nhận được. Nhưng DEV thì cho rằng đây không phải là bug, vì trong tài liệu không mô tả cách xử lý cho trường hợp này. Và nếu đây là một đề xuất cải tiết (improvement hoặc enhancement ticket) thì được, nhưng nên xác nhận với PM hoặc khách hàng.

  1. Bên A: Đưa ra câu hỏi, trạng thái câu hỏi là “chờ trả lời”
  2. Bên B: Trả lời câu hỏi, trạng thái câu hỏi là “đã trả lời”
  3. Bên A: Vẫn được phép thay đổi/cập nhật nội dung câu hỏi

Bạn nghĩ gì về trường hợp này? Bạn thích cách xử lý nào trong những cách sau:

Khi câu hỏi đang ở trạng thái “đã trả lời” thì sẽ:

  • KHÔNG cho phép thay đổi nội dung
  • Vẫn cho phép thay đổi nhưng sau khi cập nhật nội dung câu hỏi, thì trạng thái câu hỏi sẽ tự động chuyển sang “chờ trả lời”

Một trong những edge case cho trường hợp này là:

Các thao tác bên dưới được liệt kê theo thứ tự thời gian thực hiện.

BướcThao tác được thực hiệnTrạng thái câu hỏi
1Bên A đặt một câu hỏi mớiChờ trả lời
2Bên B đang soạn thảo nội dung trả lờiChờ trả lời
3Bên A cập nhật nội dung câu hỏiChờ trả lời
4Bên B trả lời câu hỏi (submit)Đã trả lời

Hoặc Bên B nhanh tay hơn thì.

BướcThao tác được thực hiệnTrạng thái câu hỏi
1Bên A đặt một câu hỏi mớiChờ trả lời
2Bên B đang soạn thảo nội dung trả lờiChờ trả lời
3Bên B trả lời câu hỏi (submit)Đã trả lời
4Bên A submit nội dung câu hỏi mớiKết quả: Chưa xác định được

Tóm lại

Để có thể nghĩ ra được những trường hợp lắc léo và hóc búa này thì bạn cần phải hiểu rõ về cơ chế hoạt động của chức năng mà bạn đang kiểm thử. Bên cạnh đó bạn phải nắm vững nghiệp vụ của nó thì mới có thể nghĩ ra trường hợp tương ứng mà thường trong tài liệu yêu cầu không mô tả.

Những lỗi do edge case phát hiện được thường khó để sửa. Đôi khi phải thay đổi luồng nghiệp vụ để ngăn ngừa nó xảy ra. Tuy nhiên cũng chính vì không được mô tả trong yêu cầu nên nhiều lập trình viên cũng sẽ từ chối fix lỗi này, và họ không đồng ý đó là bug bởi vì 1) trong tài liệu không mô tả phải xử lý trường hợp đó và 2) không người dùng (user) nào lại đi làm cái trò điên khùng như vậy. Trong trường hợp đó, bạn phải chứng minh trường hợp tương tự có thể xảy ra trong thực tế.

You Might Also Like

Leave a Reply

Your email address will not be published. Required fields are marked *