Bài giảng kiểm chứng, thẩm định và kiểm thử

Mục đíchz Sau buổi học sinh viên phải nắm được: − Hiểu các khái niệm: verification, valdation, và testing − Nắm được các nguyên lý về kiểm thử − Hiểu khái niệm ca kiểm thử test case − Cá

Kiểm Chứng, Thẩm Định và Kiểm Thử (Verification, Validation, and Testing)

Mục đích

z Sau buổi học sinh viên phải nắm được:

− Hiểu các khái niệm: verification, valdation, và

testing

− Nắm được các nguyên lý về kiểm thử

− Hiểu khái niệm ca kiểm thử (test case)

− Các phương pháp thiết kế test case

− Làm thế nào để kiểm thử chương trình

Nội dung

z Giới thiệu

− Verification,Validation, và Testing

z Các nguyên lý về kiểm thử

z Ca kiểm thử (test case)

z Các kỹ thuật kiểm thử chương trình

− Kiểm thử chức năng

− Kiểm thử cấu trúc

z Các giai đoạn và chiến lược kiểm thử

Tài liệu

z Pressman, Software Engineering,

McGraw Hill (chapter 18 & 19)

z Sommerville, Software Engineering,

Addison-Wesley (chapter 22 & 23)

z Giáo trình kỹ nghệ phần mềm (chương 5)

z C ác tài liệu điện tử khác

− phát hiện lỗi phân tích, lỗi thiết kế (lỗi mức cao)

z V&V = Verification and Validation

− mục tiêu là phát hiện và sửa lỗi PM, đánh giá tính dùng

được của PM

Thứ tự thực hiện: Verification -> Validation

Kiểm chứng/Thẩm định tĩnh và động

z Kiểm chứng/Thẩm định tĩnh

− xét duyệt yêu cầu, thiết kế, mã nguồn

− tiến hành ở mọi công đoạn phát triển

z Kiểm chứng/Thẩm định động (kiểm thử - Testing)

Mô hình phát triển “V”

Đặc tả

yêu cầu

Đặc tả hệ thống

Thiết kế hệ thống

Thiết kế chi

tiết

Mã hóa mô đun & kiểm thử mô đun

Kiểm thử tích hợp các hệ thống con

Kiểm thử tích hợp hệ thống

Kiểm thử chấp nhận

Kế hoạch kiểm thử tích hợp

HT con

− sử dụng dữ liệu thực (dựa trên thống kê)

− số giao tác

− cơ sở dữ liệu lớn

Yêu cầu đối với kiểm thử

z Tính lặp lại

− kiểm thử phải lặp lại được (kiểm tra xem lỗi

đã được sửa hay chưa)

− dữ liệu/trạng thái phải mô tả được

z Tính hệ thống

− đảm bảo kiểm tra hết các trường hợp

(coverage)

Các nguyên lý kiểm thử PM

z Các phép kiểm thử phải tương ứng với các

yêu cầu của HT

z Mỗi phép kiểm thử nên được lập kế hoạch từ

rất sớm trước khi tiến hành kiểm thử

z Qui luật Pareto hay qui luật 80/20 (qui luật

thiểu số quan trọng và phân bố nhân tố)

ra

− “80% of all errors uncovered during testing will

likely be traceable to 20% of all program modules

or classes”

Ca kiểm thử (test case)

z Ca kiểm thử: dữ liệu để kiểm tra hoạt

Nôi dung của test case

z Tên mô đun/chức năng muốn kiểm thử

dữ liệu vào

− dữ liệu thông thường: số, xâu kí tự, file,

− môi trường thử nghiệm: phần cứng, OS,

− thứ tự thao tác (khi kiểm thử giao diện)

z Kết quả mong muốn

− thông thường: số, xâu kí tự, file,

− màn hình, thời gian phản hồi

z Kết quả thực tế

Các kỹ thuật kiểm thử chương trình

z Kiểm thử chức năng (functional testing)

− dựa trên đặc tả chức năng

− phát hiện các sai sót về chức năng

− không quan tâm đến cách cài đặt

z Kiểm thử cấu trúc (structured testing)

− kiểm thử có nghiên cứu mã nguồn

phân tích thứ tự thực hiện các lệnh

Kiểm thử chức năng

Functional testing / Black box testing

Dựa trên đặc tả chức năng

• Test case được thiết kế để kiểm tra chức năng

• Phát hiện các khiếm khuyết so với đặc tả

• Không quan tâm đến cách cài đặt (mã nguồn)

- Phát hiện sai sót, thiếu sót chức năng

- Sai sót về giao diện của mô đun

- Kiểm tra tính hiệu quả

- Phát hiện lỗi khởi tạo, lỗi kết thúc,…

Phân hoạch tương đương

• Không thể kiểm thử mọi trường hợp

• Chia dữ liệu thành các miền có cùng hành vi

• Tạo một test case cho từng miền

• Tạo test case cho biên của các miền

- nhiều lỗi xuất hiện với giá trị biên

Equivalence partitioning

Phân hoạch tương đương - Ví dụ

Hàm tính trị tuyệt đối

- miền dữ liệu ≥ 0

- miền dữ liệu < 0

100 20

0

100 -20

0

Expected Output Input

Tạo test case cho các trường hợpđặc biệt

- biên của số trong máy tính

Kiểm thử cấu trúc

• Xây dựng ca kiểm thử dựa trên phân tích mã nguồn

• Xây dựng bộ test case để kiểm tra mọi dòng lệnh

• Phân tích các lệnh rẽ nhánh, vòng lặp

• Phù hợp với các mô đun nhỏ

• Là sự bổ sung cho kiểm thử chức năng

Structural testing / White box testing

Đường đi trong mô đun

• Phân tích mô đun để xác định đường đi

• Đường đi là thứ tự thực hiện các lệnh từ điểmbắt đầu đến điểm kết thúc của mô đun

• Thiết kế các test case để kiểm thử mọi đường đi

Xác định đường đi

• Đánh số các khối lệnh

- đánh số các khối lệnh, câu lệnh điều kiện

- đánh số các hợp điểm của luồng lệnh

3

46

11

Start

End

0

24

65

7

8

39

đường đi:

1-2-3-8-1-91-2-4-6-7-8-1-9

• Bộ các đường đi độc lập là một tập hợp thỏa mãn

- mọi khối lệnh đều được thực hiện ít nhất một lần

24

65

Đường đi độc lập

có thể tồn tại nhiều bộ đường đi độc lập

số đường đi tối thiểu cần kiểm tra

= độ phức tạp thuật toán

3 V(G) = P + 1

P: số các nút điều kiện

24

65

Độ phức tạp thuật toán

không nên tạo các mô đun có độ phức tạp >

10 phân rã mô đun (tạo các mô đun thứ cấp

để giảm độ phức tạp)

Độ phức tạp lớn thì xác suất xuất hiện lỗi cao

Chức năng vs Cấu trúc

• Kiểm thử chức năng

- kiểm tra tính hiệu quả của phần mềm

- thuận tiện với các mô đun lớn, tích hợp

• Kiểm thử cấu trúc

- đảm bảo mọi lệnh đều được kiểm tra

Kiểm thử và gỡ rối

z Kiểm thử và gỡ rối là hai công việc phân biệt

z Kiểm thử nhằm phát hiện sự tồn tại của lỗi

z Gỡ rối nhằm định vị và sửa chữa mã gây lỗi

z Gỡ rối bao gồm việc sinh ra các giả thiết về hoạt động của chương trình và kiểm thử

chương trình để tìm lỗi

Tiến trình gỡ rối

Locate

error

Design error repair

Repair error

Re-test program

Test

results Specification

Test cases

Mini test

Tạo test case (dựa trên phân hoạch tương đương)cho hàm tìm kiếm sau:

input: - mảng số nguyên a[] đã sắp xếp

- khóa tìm kiếm k (số nguyên)output: vị trí của k trong mảng a[] nếu có, -1 nếu

không có

Tạo test cases cho hàm tìm kiếm nhị phân

Số phần tử của mảng:

- 0, 1

- lớn hơn 1Khóa tìm kiếm:

- không có trong mảng

+ nhỏ hơn, lớn hơn+ xen kẽ

Tạo test cases cho hàm tìm kiếm nhị phân

-1 -1 -1 0 -1 -1 -1 0 3

7 20 3 10 1 30 8 3 20

10 10 10

Mảng

Số p.tử

Nội dung

z Giới thiệu

− Verification,Validation, và Testing

z Các nguyên lý về kiểm thử

z Ca kiểm thử (test case)

z Các kỹ thuật kiểm thử chương trình

− Kiểm thử chức năng

− Kiểm thử cấu trúc

Các giai đoạn kiểm thử

Kiểm thử đơn vị

Unit testing

• Kiểm thử các mô đun, chương trình riêng lẻ

• Người tiến hành: thường là người lập trình

Ví dụ sử dụng stub

• Kiểm thử mô đun calender() có gọi đến mô

đun tính ngày

• trong tuần calc_day()chưa được phát triển

calender() đã phát triển, cần kiểm thử

Mô đun tính ngày trong tuần calc_day():

- input: ngày, tháng, năm

- output: trả xâu kí tự là thứ của ngày đã cho

Để tăng độ thích nghi, có thể thay thế dữ liệu cố

- kiểm tra giao diện giữa các unit

- kiểm tra tính đúng đắn so với đặc tả

Các chiến lược tích hợp

Kiểm thử trên xuống (top-down)Kiểm thử dưới lên (bottom-up)Kiểm thử quay lui (regression)

Kiểm thử trên xuống

Top-down testing

Các mô đun mức trên được kiểm thử trước

Các mô đun thuộc cấp được thay bằng bằng các

mô đun tạm thời (stub function)

- có cùng tên với mô đun thật

- có cùng giao diện

Kiểm thử trên xuống

Ưu nhược điểm của top-down

Phát hiện sớm các lỗi thiết kế (lỗi cấu trúc)

- kiểm thử trên xuống kết hợp với phát triển trên

xuống sẽ giúp phát hiện sớm các lỗi thiết kế và

làm giảm giá thành sửa đổi

Có sớm phiên bản thực hiện được

- phiên bản thực hiện với các chức năng chính có sớm

- có thể thẩm định tính dùng được của sản phẩm sớm

Ưu điểm:

Nhược điểm

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

Các mô đun cấp thấp được kiểm thử trước

Mô đun mức trên được thay thế bằng mô đun

điều khiển (test driver), có chức năng

- gọi mô đun cần thử nghiệm

- truyền dữ liệu

- hiển thị kết quảThay thế dần các drive

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

Ưu nhược điểm của bottom up

- Tránh xây dựng các mô đun tạm thời (stub) phức tạp

- Tránh sinh các kết quả nhân tạo (nhập từ

Top down vs Bottom up

z Mỗi chiến lược đều có ưu nhược điểm riêng

z Chiến lược kiểm thử phải phù hợp với

chiến lược phát triển

− phát triển top-down = top-down testing

− phát triển bottom-up = bottom-up testing

Có thể phối hợp các chiến lược:

• Sử dụng các dữ liệu thực do user cung cấp

• Kiểm thử chấp nhận tiến hành ở môi trườngkhách hàng được gọi là alpha testing

Kiểm thử beta

• Mở rộng của alpha testing

• Được tiến hành với một lượng lớn users

• User tiến hành kiểm thử không có sự hướng

dẫn của người phát triển; thông báo lại kết quảcho người phát triển

Kiểm thử hệ thống

z Mở rộng phạm vi kiểm thử, nhìn nhận

phần mềm là một yếu tố trong một HTTT phức tạp

z Kiểm tra các yếu tố

− khả năng phục hồi sau lỗi

− độ an toàn

− hiệu năng và giới hạn của phần mềm

Kiểm thử gây áp lực - Stress Testing

ƒ phản ứng của hệ thống khi đạt mức tới hạn

+ biến thiên của thời gian phản hồi

• Nghiên cứu: