TESTER CẦN HỌC NHỮNG GÌ TỪ BUG

Cập nhật ngày: 27/10/2021 - Đã có 655 lượt xem bài viết này!
TESTER CẦN HỌC NHỮNG GÌ TỪ BUG
Có những bug rõ ràng nên được “khui” ra ngay trong quá trình test. Nếu vậy, phần test nào đã thiếu sót – unit, functional, hay system? Test case nào đã bị thiếu?

TESTER CẦN HỌC NHỮNG GÌ TỪ BUG

0 và null.

-  Luôn chắc chắn kiểm tra với giá trị 0 và null (nếu có thể). Đối với chuỗi, cần lưu ý chuỗi rỗng, và chuỗi là null.
-  Một ví dụ khác: kiểm tra trường hợp đứt kết nối TCP trước khi bất cứ dữ liệu (zero bytes) nào được gửi.
-  Bỏ qua việc kiểm tra các trường hợp trên là lý do số một làm cho bug lọt khỏi phần test của tôi.

Thêm vào và xóa đi.

-  Thường các tính năng mới sẽ dính tới chuyện thêm các thiết lập mới vào hệ thống, chẳng hạn như một kiểu định dạng mới số điện thoại.
-  Thường thì bạn sẽ kiểm tra xem có thể thêm định dạng mới hay không, nhưng tôi thấy là rất dễ quên kiểm tra trường hợp xóa định dạng cũ.

Xử lý lỗi.

-  Phần code dùng để xử lý lỗi thường rất khó kiểm tra. Tốt nhất là nên có các test tự động để kiểm tra phần này, nhưng đôi khi việc này trở nên bất khả.
-  Một mẹo tôi hay dùng là sửa code tạm thời để kích hoạt phần xử lý lỗi. Dễ nhất là lật ngược điều kiện if lại, chẳng hạn như chuyển if error_count > 0 thành if error_count == 0.
-  Một ví dụ khác là giả vờ viết sai tên một column trong database để kích hoạt lỗi.

Sử dụng dữ liệu đầu vào ngẫu nhiên.

-  Một cách kiểm tra khác có thể dùng để phát hiện bug là sử dụng dữ liệu đầu vào ngẫu nhiên.
-  Chẳng hạn như, phần giải mã ASN.1 của giao thức H.323 hoạt động trên dữ liệu nhị phân. Bằng cách gửi các bytes ngẫu nhiên để giải mã, chúng tôi đã tìm ra rất nhiều lỗi trong phần này.
-  Một ví dụ khác là tạo ra những cuộc gọi thử nghiệm, với thời gian gọi, độ trễ khi trả lời, bên nào ngắt máy trước, v.v.. được tạo ra ngẫu nhiên. Những cuộc gọi này làm lộ ra một đống bug, đặt biệt là khi chúng xen vào những sự kiện xảy ra gần như cùng lúc.

Kiểm tra hành động không mong muốn có thật sự KHÔNG diễn ra.

-  Thường testing liên quan đến xem thử hành động mong muốn có xảy ra không. Nhưng lại rất dễ bỏ qua trường hợp ngược lại – kiểm tra hành động không mong muốn thật sự không diễn ra.

Tự làm tool.

-  Tôi thường tự làm các tool nhỏ để test dễ hơn.
-  Ví dụ, khi khi tôi làm việc với giao thức SIP cho VoIP, tôi viết một đoạn mã nhỏ có thể trả lời với headers và giá trị tôi mong muốn. Đoạn mã này giúp tôi kiểm tra những trường hợp đặc biệt dễ dàng hơn.
-  Một ví dụ khác là một chương trình dòng lệnh chuyên dùng để gọi API.
-  Bằng cách bắt đầu nhỏ, và dần dần phát triển thêm tính năng cho nó, cuối cùng tôi có trong nay những công cụ rất hữu dụng. Lợi ích của việc này là tôi có những công cụ đúng như tôi mong muốn.
 

BTV.Trần Thị Thu Huyền
Phòng Truyền Thông IMicroSoft Việt Nam
Hotline: 0916 878 224
Email: huyenttt@imicrosoft.edu.vn

Xem khóa đào tạo nhân sự theo danh mục!

Xem các khóa đào tạo nhân sự