Edge Case Là Gì? - Testing VN

Có thể bạn quan tâm

🐞 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…)

Sử dụng non-printing character cũng là một cách tạo ra Edge case.

Kiểm thử chức năng giao hàng

Giả sử bạn đang kiểm thử chức năng đặt hàng và giao hàng trong một trang thương mại điện tử. Bây giờ bạn đang kiểm thử chức năng thay đổi địa chỉ giao hàng. Và bạn bám sát tài liệu mô tả yêu cầu và có các trường hợp sau:

Khách hàng muốn thay đổi địa chỉ giao hàng trong lúc thanh toán
Khách hàng muốn thay đổi địa chỉ giao hàng sau khi đã thanh toán (online) thành công
Khách hàng mua hàng muốn thay đổi địa chỉ giao hàng cho đơn hàng hôm qua
…

Trên đây là một số test case cơ bản nhằm để kiểm tra rằng chức năng này đã đáp ứng mô tả yêu cầu. Tuy nhiên, edge case có thể nghĩ đến là:

Chuyện gì sẽ xảy ra nếu khách hàng đổi địa chỉ sau khi Shipper đã lấy hàng và đang trên đường giao hàng?
Nếu cho phép thay đổi địa chỉ, thì khi mua hàng tôi chọn địa điểm gần (TP.HCM) để phí ship thấp, thanh toán xong tôi đổi địa điểm thực tế cần nhận hàng – ở khá xa địa chỉ cũ (HN)
Việc đổi địa chỉ giao hàng này, có cần kiểm tra lại phí giao hàng không? Nếu có, thì trong giỏ hàng có sản phẩm không giao được đến địa chỉ đó thì sao? Tách bill hay sẽ xử lý thế nào?

Đó là một số edge đơn giản có thể nghĩ ra nhanh được. Tuy nhiên để có thể nghĩ ra nhiều trường hợp nữa thì tester phải hiểu rõ nghiệp vụ giao hàng, đổi trả hàng,… Tài liệu mô tả yêu cầu thường chỉ mô tả “happy case” (những hướng dẫn mà phần mềm phải làm theo) chứ không mô tả chi tiết các trường hợp phần mềm sẽ không làm (should not do). Khi senior tester có kinh nghiệm thì sẽ đặt ra những câu hỏi (dựa vào các edge case mà họ nghĩ ra) thì PM, BA có thể giúp mô tả rõ hơn yêu cầu thông qua trả lời các câu hỏi này. Giúp tiết kiệm thời gian đi sửa lại nếu phát hiện trễ (thậm chí là sau khi chạy thiệt).

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.

Bên A: Đưa ra câu hỏi, trạng thái câu hỏi là “chờ trả lời”
Bên B: Trả lời câu hỏi, trạng thái câu hỏi là “đã trả lời”
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ước	Thao tác được thực hiện	Trạng thái câu hỏi
1	Bên A đặt một câu hỏi mới	Chờ trả lời
2	Bên B đang soạn thảo nội dung trả lời	Chờ trả lời
3	Bên A cập nhật nội dung câu hỏi	Chờ trả lời
4	Bên B trả lời câu hỏi (submit)	Đã trả lời

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

Bước	Thao tác được thực hiện	Trạng thái câu hỏi
1	Bên A đặt một câu hỏi mới	Chờ trả lời
2	Bên B đang soạn thảo nội dung trả lời	Chờ trả lời
3	Bên B trả lời câu hỏi (submit)	Đã trả lời
4	Bên A submit nội dung câu hỏi mới	Kế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ế.

Những câu hỏi thường gặp liên quan đến Edge case

Edge case nên được thực hiện khi nào?

Thường thì chúng ta nên bắt đầu từ những trường hợp happy case (positive case) trước, rồi mới đến những trường hợp unhappy case (negative case) bao gồm edge case. Nên có thể nói, edge case nên được thực hiện sau khi chạy xong các trường hợp positive case.

Tại sao nên có edge case?

Tuỳ vào hệ thống, chức năng bạn đang kiểm thử mà sẽ có nhiều hoặc ít edge case. Cũng ít trường hợp không thể nghĩ ra edge case nào. Khi nghĩ và thực hiện các edge case sẽ giúp bạn đánh giá được khả năng chịu đựng, độ tin cậy của chức năng/hệ thống đang được kiểm thử.

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

Thường thì mình sẽ dựa vào kinh nghiệm, hiểu biết về cách hệ thống hoạt động, cách nó được vận hành, và công nghệ đằng sau nó, v.v… Từ đó mình sẽ nghĩ ra được những trường hợp lắc léo để “phá” hoặc tìm cách làm cho hệ thống không hoạt động, đó là edge case.

Cố gắng học hỏi và liên tục cải tiến Học tester ở đâu?

Thuật Ngữ Testing 06-07-22 12-10-22
Non-printing character là gì?
Thuật Ngữ Testing 18-11-23 18-11-23
User story là gì? Ví dụ và mẫu user story
ISTQB Certificate 04-09-21 18-09-21
Luyện thi ISTQB Online hiệu quả
Thuật Ngữ Testing 02-03-23 04-05-25
Regression testing (kiểm thử hồi quy) là gì?

One comment

Sắp Khai Giảng

Bài viết mới nhất

Lịch thi ISTQB Online mới nhất
Playwright Là Gì? Trợ Thủ Đắc Lực Cho Kiểm Thử Tự Động
i18n là gì? Cách kiểm thử
Hướng dẫn đăng ký thi ISTQB online tại Đà Nẵng
Tester nên làm gì khi sót bug?
MFA là gì? Mọi thứ bạn cần biết
Outsource kiểu “điền vào chỗ trống”
Story là gì?
Tại sao tester nên biết SQL?
IT Comtor và khóa học Fresher Tester

Bài viết cũ hơn

Business Analyst (1)
Chứng chỉ ISTQB (20)
Công cụ kiểm thử (4)
Database (2)
Dzui cùng tester (1)
Đào tạo Tester (8)
Fresher Tester (1)
ISTQB Certificate (15)
JMeter (2)
Khuyến học (2)
Kiểm thử hiệu năng (1)
Kiểm thử hộp đen (1)
Kiểm thử hộp trắng (1)
Kiểm thử phần mềm (6)
Kiểm thử tự động (1)
Kiến thức chung (11)
Kinh nghiệm học tập (9)
Kinh nghiệm phỏng vấn Tester (13)
Kỹ năng mềm (10)
Kỹ thuật kiểm thử (3)
Người thật (9)
Post Bug (1)
Security Tester (1)
Tản mạn (4)
Test case (2)
Thông tin (6)
Thủ thuật (12)
Thuật Ngữ Testing (5)
Tư vấn khoá học (2)
Tuyển developers (1)
Tuyển Tester (3)
tuyển tester DN (1)
tuyển tester hcm (13)
tuyển tester HN (1)
TVNCLUB Offline (4)

Search for:

Liên kết

Search the site

× Manage Cookie Consent We use cookies to optimize our website and our service. Functional Functional Always active The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network. Preferences Preferences The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user. Statistics Statistics The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you. Marketing Marketing The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes. Manage options Manage services Manage vendors Read more about these purposes Accept Deny Preferences Save preferences Preferences {title} {title} {title} Manage consent

Công ty TNHH TESTING VIỆT NAM - MST: 0312579819 - Địa chỉ: 72/5A Bành Văn Trân, Phường Tân Sơn Nhất, TP.HCM - Do Sở KHĐT TP.HCM cấp ngày 09-12-2013

Từ khóa » Edge Case Là Gì

Edge Case Là Gì? - Testing VN

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

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

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

Kiểm thử chức năng giao hàng

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

Tóm lại

Những câu hỏi thường gặp liên quan đến Edge case

Post navigation

You Might Also Like

Non-printing character là gì?

User story là gì? Ví dụ và mẫu user story

Luyện thi ISTQB Online hiệu quả

Regression testing (kiểm thử hồi quy) là gì?

One comment

Leave a Reply Cancel reply

Sắp Khai Giảng

Bài viết mới nhất

Bài viết cũ hơn

Recent Posts

Recent Comments

Archives

Categories

Meta

Liên kết

Search the site

Công ty TNHH TESTING VIỆT NAM - MST: 0312579819 - Địa chỉ: 72/5A Bành Văn Trân, Phường Tân Sơn Nhất, TP.HCM - Do Sở KHĐT TP.HCM cấp ngày 09-12-2013

Testing VN - Edge Case Là Gì? Trong Kiểm Thử Phần Mềm,... | Facebook

4 Loại Mobile App Testing, QA Cần Phải Thực Hiện - Viblo

Ý Nghĩa Của Edge Case Trong Tiếng Anh - Cambridge Dictionary

Edge Case Là Gì? - Từ điển CNTT - Dictionary4it

"an Edge Case" Có Nghĩa Là Gì? - Câu Hỏi Về Tiếng Anh (Mỹ) | HiNative

What Are Edge Cases And Corner Cases | Testing For Them | Ignys Ltd

What Is An Edge Case? Definition And Examples In A Product

Samsung Galaxy Note 6 Edge Case?

Làm đồng Thời Manual Và Automation Tester Là Trải Nghiệm Thế Nào?

AN EDGE Tiếng Việt Là Gì - Trong Tiếng Việt Dịch - Tr-ex

About EDGE - EDGE Buildings

Liên Hệ