Chiến lược kiểm thử

Quá trình kiểm thử có thể chia làm các giai đoạn :

• Kiểm thử mô đun
• Kiểm thử tích hợp
• Kiểm thử hệ con
• Kiểm thử hệ thống
• Kiểm thử big bang
• Kiểm thử nghiệm thu
• Kiểm thử Alpha
• Kiểm thử Beta

• Kiểm tra một đơn vị thiết kế nhỏ nhất – một mô đun – của phần mềm.
• Người tiến hành kiểm thử thông thường là người lập trình mô đun đó hoặc lập trình viên cùng nhóm.
• Các mô đun thứ cấp của mô đun được kiểm thử nếu chưa được phát triển sẽ được thay bằng các chương trình tạm thời gọi là các stub.
• Mô đun thượng cấp được thay bằng một trình điều khiển kiểm thử gọi là test driver.
• Ví dụ:

Ví dụ về kiểm thử module

• Ví dụ:

String calc_day(Date d)

{

return "Sunday";

}

hoặc:

String calc_day(Date d)

{

String s;

cout << ”Enter day_of_week of ”<< d;

cin >> s;

return s;

}

• VD: Dưới đây là một ví dụ đơn giản về test driver của nó:

void calc_day_test_drive()

{

Date d;

String s;

while (1) {

cout << ”Enter date: ”);

cin >> d;

s = calc_day(d);

cout << s << endl;

}

}

• Tích hợp các mô đun và kiểm thử chúng dưới một thể thống nhất.
• Các đơn vị phần mềm (unit) được tích hợp dần thành các mô đun, hệ con, và cuối cùng là thành hệ thống hoàn chỉnh.
• Một số lỗi giao diện (mô đun) điển hình:

• Sử dụng sai giao diện
• Hiểu nhầm về giao diện
• Xung đột

• Các chiến lược kiểm thử tích hợp:

• Kiểm thử dưới lên (bottom-up testing)

• Là quá trình tích hợp và kiểm thử với các mô đun ở mức độ thấp trước.
• Thông thường người ta không thuần túy kiểm thử tất cả các mô đun ở tầng dưới cùng mà nhóm các mô đun này thành các nhóm chức năng, tích hợp và kiểm thử chúng theo từng nhóm.
• Tiến hành tích hợp và kiểm thử một số mô đun cấp trên trước

Kiểm thử từ dưới lên

• Kiểm thử dưới lên có một số ưu điểm:

• Tránh phải tạo các stub phức tạp hay tạo các kết quả nhân tạo
• Thuận tiện cho phát triển các mô đun thứ cấp dùng lại được

• Nhược điểm của phương pháp bottom-up:

• Phát hiện chậm các lỗi thiết kế
• Chậm có phiên bản thực hiện được của hệ thống

• Kiểm thử trên xuống (top-down testing)

• Kiểm thử trên xuống tiến hành kiểm thử với các mô đun ở mức cao trước, các mô đun mức thấp được tạm thời phát triển với các chức năng hạn chế.
• Thông thường, để sớm có một phiên bản thực hiện người ta thường tích hợp theo một nhánh cho đến các mô đun cấp thấp nhất.

Ví dụ Kiểm thử trên xuống

• Ưu điểm của kiểm thử trên xuống

• Phát hiện sớm các lỗi thiết kế
• Có phiên bản hoạt động sớm

• Nhược điểm của kiểm thử trên xuống

• Khó có thể mô phỏng được các chức năng của mô đun cấp thấp phức tạp
• Không kiểm thử đầy đủ các chức năng

• Trên thực tế người ta thường tìm cách phối hợp hai chiến lược này, gọi là sandwich testing

• Kiểm thử hồi qui (regression testing)

• Là tiến hành lại các phép thử đã thành công mỗi khi tích hợp thêm mô đun hoặc khi cập nhật mã nguồn chương trình
• Khi chúng ta tích hợp thêm mô đun vào hệ thống hoặc khi tiến hành nâng cấp chương trình thì sẽ tạo ra một số tổ hợp trạng thái mới dẫn đến:

• Xuất hiện lỗi ở mô đun trước đây chưa gây lỗi
• Khắc phục một lỗi mới có thể sẽ làm ảnh hưởng tới một lỗi chúng ta đã sửa
• Sinh ra lỗi mới mà trước đây chưa có

• Kiểm thử khả năng hoạt động của hệ thống
• Kiểm tra các vấn đề về hiệu năng của hệ thống, khả năng phục hồi khi gặp sự cố,…
• Một số các dạng kiểm thử hệ thống chính

• Kiểm thử phục hồi (recovery testing)

• Là các kiểm thử được tiến hành nhằm làm hệ thống ngừng hoạt động và đánh giá khả năng phục hồi sau đó
• Với các hệ thống có khả năng phục hồi tự động, chúng ta cần đánh giá các công đoạn tái thiết lập thông số, khả năng khôi phục dữ liệu và tái khởi động
• Với các trường hợp đòi hỏi khởi động lại thủ công, chúng ta cần đánh giá thời gian ngừng để sửa chữa (MTTR – Mean Time To Repair) và trong một số trường hợp đánh giá cả chi phí cho việc khôi phục.

• Kiểm thử gây áp lực (stress testing)

• Đây là loại (bước) kiểm thử được tiến hành khi đã có phiên bản làm việc, nhằm tìm hiểu hoạt động của hệ thống trong các trường hợp tải trọng lớn (dữ liệu lớn, số người sử dụng lớn, tài nguyên hạn chế...)
• Mục đích của kiểm thử áp lực là:

• Tìm hiểu giới hạn chịu tải của hệ thống
• Tìm hiểu về đặc trưng của hệ thống khi đạt và vượt giới hạn chịu tải (khi bị sụp đổ)
• Ngoài ra kiểm thử áp lực còn nhằm xác định các trạng thái đặc biệt như tổ hợp một số điều kiện dẫn đến sự sụp đổ của hệ thống; tính an toàn của dữ liệu, của dịch vụ khi hệ thống sụp đổ

• Kiểm thử hiệu suất (performance testing)

• Kiểm thử hiệu suất (performance testing) được thiết kế để đánh giá hiệu suất hoạt động của phần mềm trong một ngữ cảnh cho trước, thông thường là trong một môi trường tích hợp các phần mềm và phần cứng cụ thể
• Được tiến hành ở tất cả các công đoạn kiểm thử
• Kiểm thử hiệu suất liên quan chặt chẽ đến ngữ cảnh sử dụng bao gồm cả các phần mềm khác (hệ điều hành, CSDL,…) và môi trường phần cứng (CPU, bộ nhớ, mạng)
• Kiểm thử hiệu suất thường được tiến hành cùng với kiểm thử áp lực

• Kiểm thử big bang (big bang testing) là một chiến lược kiểm thử hệ thống tiến hành một lần duy nhất khi đã phát triển toàn bộ các mô đun và tích hợp thành một phần mềm hoàn chỉnh
• Phương pháp này vẫn thường được tiến hành khi phát triển các phần mềm có kích thước nhỏ