Kỹ thuật test black-box

[đặng thu thảo]

Hello everyone,

Mình là dân tester kinh nghiệm mới 1 năm. Hiện tại đang ngồi test một tính năng cho công ty mà chưa biết áp dụng kỹ thuật test nào để có thể giảm thiểu số test case cần thực hiện. Nhờ các cao nhân vào chỉ giáo giúp ạ.

Tính năng mình đang viết test case bao gồm 12 điều kiện, mỗi điều kiện sẽ có 2 giá trị là True/False. Nếu thỏa mãn tất cả các điều kiện thì kết quả nhận được là A; thiếu 1 trong 12 điều kiện thì kết quả trả về là B.

Vậy giờ mình cần test như thế nào để đảm bảo cover được hết 12 điều kiện mà không mất quá nhiều thời gian. Chứ mình ngồi tính ra test normal cả 12 điều kiện thì không biết khi nào mới xong nữa.

Rất mong nhận được sự trợ giúp của cả nhà ạ!!!

[meomap]

Giờ sau 1 tháng chắc bạn test xong rồi

Với mình, nếu trường hợp này mà test tay (manual) thì test ba trường hợp cơ bản sau:

1. Tất cả đều là true;

• rồi thử lần lượt mỗi điều kiện là False;

• Sau đó là tất cả đều False.

Chấp nhận có thể thiếu sót một số trường hợp. Tuy nhiên, các trường hợp này phải được bảo đảm nhờ việc review code của đội dev.

Còn không thì phải dùng test tự động (vẫn mất nhiều thời gian để máy chạy, trừ khi bạn biết cách test phân tải).

Chứ ~4000 test cases (2 mũ 12) mà test tay thì chắc đến case tầm thứ 1000 thì mình cũng chẳng tin tưởng kết quả test lắm, chưa kể nhiều khi thời gian không cho phép, chưa kể sau fix bug còn phải test lại.

[tvn]

Cám ơn meomap đã trả lời. Sau tết nhiều việc quá mình chưa có thời gian online thường xuyên nên có thiếu sót trong việc trả lời các bạn.

Mình đồng ý với cách làm của bạn. Sau ba test cases cơ bản đó, mình sẽ kiểm thử ngẫu nhiên vài trường hợp để bảo đảm là chương trình tính đúng.

Bên dưới là hình mô tả lý do tại sao có ~4000 test cases.

[tvn]

Điểm yếu của kỹ thuật kiểm thử hộp đen (blackbox testing) là tập giá trị cần nhập để kiểm thử rất lớn vì mình không biết nó được lập trình như thế nào bên trong.

Nếu khi mình rà soát (review) lại code (white box testing) thì mình sẽ dễ dàng loại bỏ nhiều tổ hợp không cần thiết phải kiểm thử.

[meomap]

Hi tvn,

Việc test ngẫu nhiên, mình nghĩ tác dụng lớn nhất là tạo thêm cảm giác yên tâm cho người test. Việc thực hiện kiểm thử full case dựa trên tính toán chi phí với điều kiện hiện tại của đội kiểm thử.
Trong một số trường hợp, yêu cầu kiểm thử đầy đủ có thể cao hơn. Ví dụ như với chức năng rất quan trọng hoặc case test chứa 12 điều kiện trên thuộc 12 chức năng chạy liên tiếp khác nhau (chứ không phải trong một đoạn lệnh), thì dù có việc review của dev, xác suất sai ở đoạn nào đó cao hơn việc tập trung trong 1 đoạn lệnh. Một ví dụ đơn giản của việc này là test luồng nghiệp vụ.

Trong trường hợp bắt buộc phải test full như trên, mình nghĩ Thảo BẮT BUỘC tìm hiểu automation test và viết script.
Về mặt thời gian thực hiện, ví dụ như với test web dùng selenium, trung bình 1 máy PC cấu hình bình thường chịu được 5 tải (tùy thuộc thời gian xử lý phía server nữa). Nếu phân tải được (thường công ty nhỏ cũng phải được 20 máy), thì vấn đề thời gian cũng không còn là rào cản nữa.

Về việc review code, tùy công ty, mình gặp cả 3 trường hợp sau:
1. dev review.
2. test review.
3. Không review.

Minh nghĩ dev review nên là bắt buộc với đội dev, tester review cực kỳ nên với tester sau khi dev fixbug hoặc nâng cấp nhỏ một chức năng nào đó.
Không biết ở công ty các bạn thì thế nào?

[tvn]

> Trong trường hợp bắt buộc phải test full như trên, mình nghĩ Thảo BẮT BUỘC tìm hiểu automation test và viết script.

Trong trường hợp nào thì nên/sẽ bắt buộc test đầy đủ mọi trường hợp (vét cạn)?
Mình nghĩ, không có lý do gì mà True sẽ chạy đúng, và False thì có thể bị bug.

Nên nếu có nghiệp vụ yêu cầu, giả sử như nếu DK1 = True, DK2 = false và ít nhất 1 DK khác là true, thì kết quả sẽ là ABC. Và,... thì kết quả sẽ là XYZ
Trong trường hợp này bắt buộc tất cả yêu cầu phải được kiểm thử ít nhất là 1 test case. Nên lúc đó mới cần những kết hợp để phản ánh hết mọi yêu cầu. Còn không thì không phải tổ hợp làm gì.

Còn nếu thật sự phải cần test hết những kết hợp này, thì DEV nên viết unit test để chạy hết tổ hợp này, chứ không nên áp dụng kiểm thử tự động ở mức UI (mức system, hoặc acceptance test)