Chương 5: Kiểm thử phần mềm (Software...
61
Transcript of Chương 5: Kiểm thử phần mềm (Software...
Nội dung
1. Kiểm thử là gì
2. Mục đích (Testing objectives)
3. Nguyên tắc kiểm thử (Testing principles)
4. Các kỹ thuật kiểm thử
5. Các phương pháp thiết kế test case
– Kiểm thử theo phân vùng tương đương (Equivalence
partitioning)
– Kiểm thử theo đường cơ bản (Basic path)
– Kiểm thử theo giá trị biên (Boundary value analysis)
6. Các mức độ (giai đoạn) kiểm thử
205/10/2018
1. Kiểm thử là gì
• “Test chứng tỏ sự có mặt của lỗi, không chứng
tỏ rằng không có lỗi.” —Edsger W. Dijkstra
• Một lỗi (fault, “defect”, “bug,”) là một phần tử
phần cứng hoặc phần mềm có sai sót mà có thể
gây sự cố hệ thống
• Mục tiêu: Tìm lỗi
305/10/2018
“Program testing can
be used to show the
presence of bugs, but
never to show their
absence!” Edsgar Dijkstra Notes on Structured
Programming, 1970
405/10/2018
2. Mục đích của kiểm thử
(Verification,Validation và Testing)• Kiểm chứng (Verification)
– có đúng đặc tả không, có đúng thiết kế không
– phát hiện lỗi lập trình
– Một test thành công là test cho thấy hệ thống hoạt động không
đúng
• Thẩm định (Validation)
– có đáp ứng nhu cầu người dùng không
– có hoạt động hiệu quả không
– phát hiện lỗi phân tích, lỗi thiết kế (lỗi mức cao)
• Test = Verification and Validation
– Mục tiêu là phát hiện lỗi PM, đánh giá tính dùng được của PM
– Thứ tự thực hiện: Verification -> Validation
505/10/2018
3. Các nguyên tắc kiểm thử
• Kiểm thử không phải là gỡ rối (Debugging)
• Kiểm thử không bao giờ có thể phát hiện
hoàn toàn 100% lỗi
• Các phép kiểm thử phải tương ứng với
các yêu cầu hệ thống
• 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ử
605/10/2018
Yêu cầu kiểm thử
• 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
• Tính hệ thống
– đảm bảo kiểm tra hết các trường hợp
(coverage)
• Được lập tài liệu
705/10/2018
Ca kiểm thử (test case)
• Một test case (ca kiểm thử) là một lựa chọn cụ
thể về input được dùng khi kiểm thử hoạt động
của chương trình
• Ca kiểm thử tốt
• được thiết kế để phát hiện một lỗi của chương
trình
• Kiểm thử thành công: phát hiện ra lỗi
• Mục đích:
• − Chứng minh được sự tồn tại của lỗi
• − Không chứng minh được sự không có lỗi
805/10/2018
Nôi dung của test case
905/10/2018
10
Quy trình kiểm thử phần mềm
Thiết kế các
test case
Chuẩn bị
dữ liệu test
Chạy
chương trình
với dữ liệu test
So sánh
kết quả với
các test case
Test caseDữ liệu
test
Kết quả
test
Báo cáo
kiểm thử
(test report)
05/10/2018
11
Testing policies
Chính sách kiểm thử
• Chỉ có kiểm thử toàn diện vét cạn tất cả các trường hợp thực
thi (exhaustive testing) mới có thể chứng tỏ rằng một chương
trình không có lỗi
– Kiểm thử toàn diện là bất khả thi
• Thực tế, việc kiểm thử chỉ thực hiện với một tập con của tập
tất cả các trường hợp có thể xảy ra.
• Chính sách kiểm thử xác định phương pháp chọn các test hệ
thống. Ví dụ
– Test tất cả các chức năng truy nhập được từ các menu;
– Test các tổ hợp chức năng truy nhập được từ cùng một menu;
– Ở đầu cần đến input của người dùng, test tất cả các chức năng
với cả input sai và input đúng.
05/10/2018
4. Các kỹ thuật kiểm thử chương trình
• 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
• 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
1205/10/2018
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,…
1305/10/2018
Kiểm thử cấu trúc
• Structural testing / White box testing
– 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
1405/10/2018
5. Các phương pháp thiết kế test case
1505/10/2018
5.1. Phân hoạch tương đương
• Equivalence partitioning
– 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
1605/10/2018
Partition testing
• Input và output thường tập
trung thành các nhóm,
mỗi nhóm chứa các thành viên
có tính chất giống nhau.
• Mỗi nhóm đó là một phân
hoạch tương đương
(equivalence partition) hoặc
miền (domain)
mà với mỗi điểm trong đó
chương trình hoạt động gần
như nhau
• Cần chọn test case cho từng
phân hoạch
17
equivalence partition05/10/2018
18
Binary search equiv. partitions
05/10/2018
Phân hoạch tương đương - Ví dụ
1905/10/2018
Mở rộng các test case
• Tạo test case cho các trường hợp đặc biệt
– biên của số trong máy tính
• (vd. 32767, -32768)
– -số không (0)
– số âm, số thập phân
– dữ liệu sai kiểu
– dữ liệu ngẫu nhiên
2005/10/2018
5.2. Đường đi trong mô đun
• Áp dụng cho kiểm thử cấu trúc
• 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ểm bắ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
2105/10/2018
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
• Rút gọn flow chart (đồ thị)
– các khối tuần tự được tích hợp thành một
khối
– tích hợp khối tuần tự vào câu lệnh điều kiện
kế tiếp
2205/10/2018
2305/10/2018
2405/10/2018
Đường đi độc lập
• Không thể chọn mọi đường đi
– chọn các đường đi độc lập
• Đường đi độc lập
– có ít nhất một cặp khối lệnh (một cạnh của đồ thị)
– chưa xuất hiện trong các đường đi đã có
• 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
– mọi điều kiện đều được kiểm thử với hai trường
hợp true và false
2505/10/2018
Đường đi độc lập
2605/10/2018
Đườ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
2705/10/2018
Độ phức tạp thuật toán
• Độ phức tạp V(G) của flow chart G:
1. Số miền của đồ thị G
2. V(G) = E - N + 2
E: số cạnh
N: số đỉnh
3. V(G) = P + 1
• P: số các nút điều kiện
2805/10/2018
Độ phức tạp thuật toán
2905/10/2018
Độ phức tạp thuật toán
3005/10/2018
5.3. Kiểm thử theo giá trị biên
(Boundary value analysis)
• Đây là một trong những kỹ thuật kiểm thử
phần mềm, trong đó các testcase được
thiết kế bao gồm các giá trị tại các biên.
3105/10/2018
Ví dụ
3205/10/2018
Áp dụng kỹ thuật phân tích giá trị biên
ta chọn được các case sau:
• Case 1: Nhập giá trị là -1 => hiển thị lỗi
• Case 2: Nhập giá trị là 0 => pass
• Case 3: Nhập giá trị với 10 => pass
• Case 4: Nhập giá trị với 11 => hiển thị lỗi
• Case 5: Để trống không nhập gì hay nhập
ký tự không phải dạng chữ => hiển thị lỗi
3305/10/2018
Ưu điểm của kiểm thử theo giá trị biên
• Thay vì phải test hết toàn bộ các giá trị
trong từng vùng tương đương, kỹ thuật
phân tích giá trị biên tập trung vào việc
kiểm thử các giá trị biên của miền giá trị
inputs để thiết kế test case do “lỗi thường
tiềm ẩn tại các ngõ ngách và tập hợp tại
biên”.
• Tiết kiệm thời gian thiết kế test case và
thực hiện test.
3405/10/2018
Nhược điểm của kiểm thử theo giá trị
biên
• Phương pháp này chỉ hiệu quả trong
trường hợp các đối số đầu vào (input
variables) độc lập với nhau và mỗi đối số
đều có một miền giá trị hữu hạn.
3505/10/2018
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
– hiệu quả với các mô đun nhỏ, đơn lẻ
3605/10/2018
Ví dụ tạo test case
• 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ó
3705/10/2018
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 1
• Khóa tìm kiếm:
– không có trong mảng
• nhỏ hơn, lớn hơn
• xen kẽ
– có trong mảng
• phần tử đầu tiên, cuối cùng
• phần tử ở vị trí bất kỳ 3805/10/2018
Tạo test cases cho hàm tìm kiếm nhị
phân
3905/10/2018
6. Các giai đoạn kiểm thử
• Unit Testing
– Kiểm tra mỗi method/class/interface có hoạt động
đúng không?
• Integration Testing
– Kiểm tra xem các phần khi làm việc cùng nhau có đạt
được kết quả như mong đợi không?
• Validation Testing
– Chương trình có thõa mãn với yêu cầu?
• System Testing
– Kiểm tra sự hoạt động của chương trình trên
toàn hệ thống4005/10/2018
Kiểm thử đơn vị
• 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
• Sử dụng các stubs và drivers
• Phối hợp giữa kiểm thử cấu trúc và kiểm thử
chức năng
– kiểm tra câu lệnh điều kiện, cấu trúc dữ liệu điều kiện
biên,...
• Tài liệu thường sơ sài
4105/10/2018
Kiểm thử đơn vị
4205/10/2018
Kiểm thử tích hợp
Intergration testing
• Kiểm thử tích hợp các unit
• Người tiến hành: người lập trình, người thiết kế...
• Các unit được thêm vào theo một trong 2 chiến lược top-down hoặc
bottom-up
• Mục đích:
– kiểm tra giao diện giữa các unit
– kiểm tra tính đúng đắn so với đặc tả
– kiểm tra tính hiệu quả
• Thường sử dụng kiểm thử chức năng
• Được lập tài liệu
4305/10/2018
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)
4405/10/2018
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
– trả lại kết quả với một hoặc một vài bộ dữ liệu chuẩn
4505/10/2018
Kiểm thử trên xuống
4605/10/2018
Ưu nhược điểm của top-down
• Ưu điểm:
• 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
• Nhược điểm
– Nhiều mô đun cấp thấp rất khó mô phỏng
– thao tác với cấu trúc dữ liệu phức tạp
– trả lại kết quả phức tạp (con trỏ, ảnh, ...)
4705/10/2018
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
4805/10/2018
Kiểm thử dưới lên
4905/10/2018
Ưu nhược điểm của bottom up
• Ưu điểm:
– 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ừ
bàn phím)
– Thuận tiện cho phát triển các mô đun để
dùng lại
• Nhược điểm:
– Chậm phát hiện các lỗi kiến trúc
– - Chậm có phiên bản thực hiện5005/10/2018
51
System testing – kiểm thử hệ thống
• Tích hợp các thành phần để tạo một hệ thống hoặc hệ
thống con rồi test hệ thống đó
• Trong quy trình phát triển lặp, test hệ thống là test từng
bản increment để giao cho khách hàng. Trong quy trình
thác nước, kiểm thử hệ thống là test toàn bộ hệ thống.
• Hai pha của kiểm thử hệ thống:
– Integration testing – kiểm thử tích hợp. Đội kiểm thử có thể truy
nhập mã nguồn. Còn hệ thống được test khi bổ sung các thành
phần. Đội tích hợp xác định lỗi thuộc thành phần nào để debug.
– Release testing – kiểm thử bản release. Đội kiểm thử test hệ
thống chuẩn bị giao cho khách hàng, test để kiểm tra xem có
thỏa mãn yêu cầu không, thực hiện theo kiểu black-box
05/10/2018
52
Integration testing
• Xây dựng một hệ thống từ các thành phần của nó
và test xem có vấn đề nào nảy sinh khi các thành
phần tương tác với nhau hay không
• Top-down integration
– Phát triển khung hệ thống rồi lắp các thành phần vào
• Bottom-up integration
– Tích hợp các thành phần cơ sở hạ tầng (mạng, cơ sở dữ
liệu...) rồi thêm các thành phần chức năng
• Để đơn giản hóa việc định vị lỗi, cần tích hợp hệ
thống một cách tăng dần
05/10/2018
53
Incremental integration testing
kiểm thử tích hợp tăng dần
T3
T2
T1
T4
T5
A
B
C
D
T2
T1
T3
T4
A
B
C
T1
T2
T3
A
B
Test sequence 1 Test sequence 2 Test sequence 3
05/10/2018
54
Release testing
• Kiểm thử một bản release của một hệ thống mà sẽ được
giao cho khách hàng
• Mục đích là để chắc chắn hơn rằng hệ thống thỏa mãn
các yêu cầu
• Release testing thường là kiểm thử hộp đen
– Chỉ dựa vào đặc tả hệ thống
– Người test không biết gì về cài đặt hệ thống
• Còn gọi là kiểm thử chức năng vì chỉ liên quan đến các
chức hăng của hệ thống
• Nếu có khách hàng tham gia kiểm thử thì còn gọi là
acceptance test
05/10/2018
55
Các hướng dẫn kiểm thử
• Làm cách nào để các khiếm khuyết lộ ra?
– Chọn các input nhằm buộc hệ thống phải sinh
tất cả các thông báo lỗi
– Thiết kế các input gây tràn bộ đệm dành cho
input
– Lặp một input hoặc một chuỗi input nhiều lần
– Buộc hệ thống sinh output không hợp lệ
– Buộc kết quả tính toán trở thành quá lớn hoặc
quá nhỏ
05/10/2018
56
Testing scenario – kịch bản test
Một sinh viên ở Scotland đang học lịch sử Mỹ và cần phải viết một
báo cáo về ‘Tâm lý tiền phương ở vùng viễn Tây Mỹ trong giai
đoạn 1840-1880’. Để làm việc này, cô cần tìm tài liệu ở một loạt
các thư viện. Cô log vào hệ thống LIBSYS và dùng tiện ích tìm
kiếm để xem mình có thể truy cập các tài liệu nguyên gốc từ thời
đó hay không. Cô tìm thấy nguồn ở nhiều thư viện đại học Mỹ và
download bản sao của một số tài liệu. Tuy nhiên, có một tài liệu mà
cô cần phải xin chứng nhận của trường đại học cô đang học rằng
cô là sinh viên và sẽ không sử dụng cho mục đích thương mại. Cô
sinh viên dùng tiện ích của LIBSYS để yêu cầu chứng nhận đó và
đăng kí yêu cầu của mình. Nếu được chấp nhận, tài liệu sẽ được
download về server của thư viện đã đăng ký rồi in tại đó cho cô. Cô
nhận được một thông điệp từ LIBSYS nói rằng cô sẽ nhận được
một email khi cô có thể đến nhận bản in tài liệu đó.
05/10/2018
57
System tests – các test hệ thống
1. Test cơ chế đăng nhập bằng các lần đăng nhập đúng và
sai để kiểm tra việc người dùng hợp lệ được chấp nhận
và người dùng không hợp lệ bị từ chối.
2. Test tiện ích tìm kiếm bằng các truy vấn khác nhau về các
nguồn đã biết để kiểm tra xem cơ chế tìm kiếm có thực
sự tìm thấy tài liệu không.
3. Test chức năng trình bày của hệ thống để kiểm tra xem
thông tin về các tài liệu có được hiển thị đúng đắn không.
4. Test cơ chế xin phép tải xuống.
5. Test phản ứng bằng e-mail khi thông báo rằng tài liệu
được download đã sẵn sàng để dùng.
05/10/2018
58
7. Tự động hóa test
• Kiểm thử là một bước quy trình tốn kém.
• Các Testing workbench cung cấp nhiều công cụ để giảm
thời gian và chi phí kiểm thử.
• Các hệ thống như Junit hỗ trợ tự động hóa việc chạy
test.
• Nhiều testing workbench là các hệ thống mở vì các nhu
cầu kiểm thử có tính đặc thù đối với từng tổ chức.
Java PathFinder05/10/2018
59
Tóm tắt
• Việc kiểm thử (testing) có thể cho thấy lỗi trong hệ
thống; nó không thể chứng minh hệ thống không
còn lỗi nào.
• Những người phát triển component có trách nhiệm
thực hiện component testing; system testing là trách
nhiệm của một đội khác.
• Integration testing là kiểm thử các bản tăng dần
(increment) của hệ thống; release testing kiểm thử
hệ thống trước khi trao cho khách hàng.
• Dùng kinh nghiệm và hướng dẫn để thiết kế các test
case cho defect testing.
05/10/2018
60
Question?
05/10/2018
Câu hỏi và bài tập chương 5
1. Trình bày các khái niệm cơ bản trong kiểm thử.
2. Trong quá trình kiểm thử hệ thống, người ta có thể sử
dụng các hình thức kiểm thử nào?
3. Trình bày phương pháp kiểm thử theo giá trị biên
4. Trình bày phương pháp kiểm thử theo phân vùng
tương đương
5. Trình bày phương pháp kiểm thử theo đường cơ bản
6. Hãy xây dựng các kịch bản kiểm thử cho chức năng rút
tiền từ một máy ATM của hệ thống ngân hàng.
7. Xây dựng kịch bản kiểm thử đường cho chương trình
giải phương trình bậc hai: ax2 + bx + c = 0
6105/10/2018
