Giới thiệu

Monkey Testing là khái niệm mới toanh với mình. Đã thực hiện kiểm thử khá nhiều ứng dụng và nhiều lần phải kiểm thử không có kịch bản mà giờ mới biết đến kiểm thử có tên như này. Sau đây mình sẽ chia sẻ những gì mình tìm hiểu được về Monkey Testing.

Monkey Testing là một kỹ thuật trong kiểm tra phần mềm khi đó, người dùng kiểm tra ứng dụng bằng cách đưa giá trị đầu vào bất kỳ và kiểm tra xem ứng dụng xử lý ra sao (hoặc cố gắng phá hủy chương trình).

Hầu hết kĩ thuật này được làm 1 cách tự động, người dùng nhập giá trị không hợp lệ bất kỳ và kiểm tra xử lý. Với monkey test, không có qui tắc, kĩ thuật này không theo testcase hay chiến lược xác định trước. Nó làm việc theo tâm trạng và cảm tính của người kiểm thử.

Kỹ thuật này được tự động hóa hay nói đúng hơn là bạn có thể viết chương trình/ kịch bản để tạo ra đầu vào ngẫu nhiên rồi đưa vào ứng dụng và phân tích xử lý. Kĩ thuật này làm việc khá tốt khi thực hiện load/stress testing hay khi bạn cố gắng phá hủy chương trình bằng cách đưa không ngừng giá trị ngẫu nhiên vào.

Trước khi nói về “Monkey”, tôi sẽ giới thiệu về “Horse”

Ở hình bên dưới, bạn nhìn thấy một chiếc dây hãm ở con ngựa đúng không? Cái này được dùng để chỉ dẫn và điều khiển con ngựa để nó không bị mất tập trung và chỉ tâp trung vào đường thẳng trên đường mà thôi.

Cũng giống như vậy, với test bằng tay hay test tự động thì chúng ta lúc này đều giống như con ngựa vậy. Bởi vì chúng ta bị chỉ đường và dẫn đi bằng testcase/ kế hoạch và chiến lược, bị kiểm soát bởi số liệu chất lượng.

Bởi vì chúng ta có 1 cái dây hãm quanh mình nên không muốn chuyển hướng tập trung, chỉ tập trung một cách nghiêm khắc vào bộ testcase và ngoan ngoãn thực hiện chúng.

Khá hoàn hảo khi là 1 con ngựa nhưng có đôi khi bạn muốn làm 1 con khỉ không?

Monkey test là tất cả những gì bạn muốn làm, một cách tự động

Kỹ thuật test này khá lộn xộn vì nó không theo mô hình đặc tả nào. Nhưng câu hỏi ở đây là

Tại sao?

Bất cứ khi nào bạn đưa một ứng dụng web lớn ra thế giới, bạn có thể tưởng tượng bạn phục vụ những loại người dùng nào không?

Có người dùng tốt, lành mạnh nhưng bạn không thể chắc chắn rằng sẽ không có người dùng xấu.

Có n số người xấu, những người cũng giống như khỉ, thích chơi xung quanh ứng dụng, đưa vào sự khác lạ, những đầu vào lớn hoặc cố tình làm hỏng ứng dụng.

Như vậy để kiểm thử được những tình thế đó, chúng ta, những tester cũng phải trở thành khỉ, nghĩ và thậm chí phải kiểm thử để ứng dụng của mình an toàn khỏi những con khỉ xấu tính.

Các loại Monkey

Có 2 loại Monkey:

1. Monkey mau lẹ

1 con khỉ mau lẹ được định nghĩa bởi các đặc tính bên dưới:

-Có ý tưởng ngắn gọn về ứng dụng

-Biết các trang của ứng dụng sẽ dẫn đến đâu

-Biết giá trị đầu vào là hợp lệ hay không hợp lệ

-Làm việc hoặc tập trung để phá hỏng hệ thống

-Khi tìm thấy 1 lỗi, chúng đủ thông minh để bắt lỗi

-Nhận thức được các menu và button

-Khá cừ với stress và load test

2. Monkey chậm chạp

1 con khỉ chậm chạp được định nghĩa bởi các đặc tính bên dưới:

-Không có ý tưởng gì về ứng dụng

-Không biết giá trị đầu vào là hợp lệ hay không hợp lệ

-Kiểm tra ứng dụng 1 cách ngẫu nhiên và không nhận thức được điểm bắt đầu của ứng dụng hay điểm kết thúc của luồng

-Mặc dù không nhận thức được ứng dụng nhưng chúng vẫn có thể định nghĩa lỗi như lỗi môi trường hay lỗi phần cứng

-Không có ý kiến gì nhiều về UI và chức năng

Kết quả

Lỗi báo cáo từ Monkey test đòi hỏi phân tích chi tiết. Vì không rõ các bước tái hiện lỗi (hầu như là vậy) nên việc khôi phục bug sẽ khó.

Tôi nghĩ kĩ thuật này nên làm ở giai đoạn sau của việc kiểm thử khi tất cả chức năng đã được kiểm thử và đã có một chút đang tin về hiệu quả của ứng dụng. Nếu làm nó ở giai đoạn đầu của kiểm thử, mức độ nguy hiểm sẽ cao hơn. Nếu chúng ta đang sử dụng 1 chương trình hay kịch bản để tạo ra đầu vào hợp lệ và không hợp lệ ngẫu nhiên thì phân tích sẽ trở lên dễ dàng hơn.

Lợi thế của Monkey Testing

-Dễ dàng cài đặt và thực hiện

-Có thể thực hiện bởi những người “không quá lão luyện”

-1 kĩ thuật tốt để kiểm tra độ tin tưởng của phần mềm

-Có thể phát hiện bug có ảnh hưởng lớn hơn

-Không tốn tiền

Bất lợi của Monkey Test

-Có thể phải mất nhiều ngày mới phát hiện ra 1 lỗi

-Số lượng lỗi ít hơn

-Việc tái hiện 1 lỗi(nếu xảy ra) trở thành 1 thử thách

-Một số lỗi có thể có đầu ra không mong muốn của kịch bản test, do vậy việc phân tích trở nên khó khăn và mất thời gian

Lời kết

Mặc dù nói Test Monkeys hay Monkey Testing là lộn xộn nhưng vẫn khuyến khích lên kế hoạch cho nó và tiến hành vào giai đoạn sau này. Mặc dù ở giai đoạn đầu của kĩ thuật này có thể không tìm được lỗi tốt nhưng nó thậm chí vẫn có thế phát hiện ra những lỗi thực sự tốt như rò rỉ bộ nhớ hay phá hỏng phần cứng.

Với kiến thức kiểm thử cơ bản, ta thường bỏ qua nhiều trường hợp do nghĩ rằng kịch bản này sẽ không bao giờ xảy ra tuy nhiên nếu xảy ra , chúng có thể dẫn đến ảnh hưởng nghiêm trọng (ví dụ bug độ ưu tiên thấp và mức độ nghiêm trọng cao ). Việc làm monkey test dĩ nhiên có thể tìm thấy những kịch bản này. Đôi khi do tình cờ mà ta lại gặp được tình huống như vậy và khi đó ta sẽ phân tích nó và cố gắng tìm ra giải pháp.

Theo quan điểm của tôi, cách tốt nhất là có cả “Horse” và “Monkey”. Với Horse, ta có thể đi theo phương pháp test với kế hoạch tốt, định nghĩa tốt và phương pháp tinh sảo. Với Monkey, ta bí mật bao quát được những tình huống thực tế khó chịu. Và nếu kết hợp với nhau, chúng sẽ góp phần tạo nên một phần mềm chất lượng và tin tưởng hơn.