Sử dụng kỹ thuật Đoán Lỗi trong Testing

Trong kiểm thử phần mềm, đoán lỗi - error guessing - là một phương pháp kiểm thử, trong đó các trường hợp kiểm thử - test case - được sử dụng để tìm lỗi trong các chương trình đã được phát triển - đã code - dựa vào kinh nghiệm trong các lần kiểm thử trước. Phạm vi của các trường hợp kiểm thử thường được dựa vào các kiểm thử viên - tester - có kiến thức liên quan, là những người đã có kinh nghiệm sử dụng và trực giác để xác định những tình huống thường gây ra lỗi trong phần mềm. Các lỗi điển hình như chia cho không, null pointer, hoặc các biến không hợp lệ.

Đoán Lỗi không có quy tắc rõ ràng để kiểm thử, test case có thể được thiết kế tùy thuộc vào tình hình, hoặc hoặc luồng công việc trong các tài liệu mô tả chức năng hoặc khi một lỗi không mong muốn / không được mô tả trong tài liệu được tìm thấy trong khi hoạt động kiểm thử.

1/ Kỹ thuật đoán lỗi là gì ?

Đây là một cách thiết kế kiểm thử dựa vào kinh nghiệm của một kiểm thử được sử dụng để tìm các thành phần của phần mềm mà các lỗi có thể xảy ra. Đây là cách thường được thực hiện bởi các Tester có kinh nghiệm, họ sử dụng kinh nghiệm trong quá khứ của họ để tìm lỗi trong phần mềm. Đoán Lỗi không có quy tắc, nó chỉ sử dụng các kỹ năng kiểm thử trước đó. Trong kiểm thử phần mềm, đoán lỗi có thể nghĩ đến các tình huống nơi mà phần mềm sẽ thất bại. Ví dụ:

• Chia cho không
• Nhấn nút gửi trên mẫu đơn mà không cần điền vào bất kỳ mục.
• Nhập các dữ liệu đặc biệt vào các ô nhập liệu và sau đó kiểm tra hành vi của phần mềm.

2/ Các tiếp cận kỹ thuật Đoán lỗi

a/ Cách tiếp cận

Nhóm khiếm khuyết là một khu vực trên hệ thống, nơi có khả năng xảy ra số lượng lỗi lớn nhất. Khi thực hiện Đoán lỗi . Có người có thể tìm ra nhóm khiếm khuyết bằng cách phân tích lịch sử kiểm thử bằng test case đã được thực hiện trước đó, cũng có người tìm ra bằng cách dự đoán nơi có khả năng xảy ra lỗi.

b/ Chú ý sự tác động qua lại giữa các bộ phận cấu thành.

Sự tác động qua lại, ảnh hưởng lẫn nhau giữa các chức năng con trên hệ thống là một kịch bản thường thấy khi có lỗi xảy ra. Khi thực hiện Đoán lỗi , tester có thể chỉ ra sự ảnh hưởng đó giữa các module với nhau, từ đó tìm ra những trạng thái bất bình thường của hệ thống.

c/ Suy nghĩ như một developer

Khi thực hiện Đoán lỗi , nếu suy nghĩ như một developer,nhìn vào hệ thống và thử nghĩ xem mình có thể làm gì, làm như thế nào khi phải phát triển chức năng này, và tester sẽ biết được liệu có phần nào của chức năng hoặc một yêu cầu nào đó đối với chức năng đó có bị thiếu không. Sau đó kiểm tra code và có thể sẽ tìm ra lỗi.

d/ Phải hiểu rõ về hệ thống

Trong Đoán lỗi , tester có kinh nghiệm bao giờ cũng tìm ra được nhiều lỗi hơn là người mới vì người đó đã từng test nhiều hệ thống khác nhau, cũng có thể là đã test những hệ thống tương tự nên thu thập được kinh nghiệm và sự hiểu biết để thực hiện Đoán lỗi Ghi chú, góp nhặt là phương pháp tốt để tích lũy kinh nghiệm

e/ Test theo session

Hãy kiểm thử ứng dụng hay một phần mềm theo từng phần, tức là mỗi lần chỉ test một chức năng, nó sẽ giúp cho tester có thể chú trọng và lý giải được những vấn đề xảy ra (nếu có).

f/ Ghi lại nhứng gì tìm được

Hãy ghi lại những lỗi, khiếm khuyết mà mình tìm ta được, ghi rõ cả chức năng, khi nào thì lỗi xảy ra…Những record này sẽ giúp cho developer và cả tester trong tương lai khi họ phát triển những hệ thống hoặc ứng dụng khác. Cũng nên ghi lại những lỗi do người khác tìm ra chứ không phải mình tìm ra, để có cơ sở tham khảo về sau.

g/ Một vài ví dụ

Đối với màn hình search: - Thường xảy ra lỗi search cả những record đã bị xóa (del_flg = 1) vì vậy khi viết test case và test màn hình search thì nên thêm vào test case này (gán del_flg = 1 cho một số record rồi thực hiện search, nếu những record này được hiển thị trên màn hình thì sai). - Tiếp theo, nhập điều kiện sao cho khi search được 0 record thì không hiển thị được màn hình mà lại báo lỗi “Null pointer” do trong code không xử lý khởi tạo list chứa danh sách các record search được. - Phần phân trang, thường thì mong muốn là: (giả sử phân trang là 20 records – một trang chỉ chứa được 20 dòng) - Search được 0 record thì chỉ hiển thị header (phần datagrid chỉ hiển thị header) - Search được 20 records thì hiển thị header và 20 dòng này trên 1 trang - Search được 21 records thì hiển thị header và 20 dòng này trên trang 1 và 1 dòng trên trang 2. - Search được 50 records thì hiển thị header và 20 dòng này trên 1 trang và 20 dòng trên trang 2 và 10 dòng trên trang 3

Nhiều khi DEV quên xử lý phân trang thì khi search được nhiều hơn số record chứa trong 1 trang thì bị lỗi hoặc hiển thị tất cả trên 1 trang. Trong trường hợp đang hiển thị nhiều trang thì click Next và Prev để kiểm tra xem có qua lại giữa các trang được không nhé vì cũng hay bị lỗi chỗ này nếu là control này do mình tự viết (thường thì dùng component của framework nhưng trong ADF thì thường tự viết bằng java để dễ kiểm soát)

Đối với màn hình Login: - Chú ý phần bảo mật: Đôi khi DEV code thì gán user name là “admin” và pass là rỗng hoặc là “123” vì vậy mình nên thử trường hợp này. - Thử thử các trường hợp SQL injection - Để user name và pass rỗng rồi enter. (nhiều khi DEV không xử lý action enter cho login mà phải click button login) - Bạn cũng có thể sử dụng việc copy paste nếu như Dev đã chặn việc nhập

Hi vọng bài viết này sẽ mang t ới cho các bạn một cách suy nghĩ để áp dụng cho cho kỹ thuật Đoán lỗi hiệu quả trong lĩnh vực kiểm thử phần mềm .