Toàn hệ thống xem như là tập các hệ thống con được xác định trong suốt quá trình thiết kế hệ thống và đối tượng. Chiến lược kiểm thử là thứ tự mà các hệ thống con được chọn để kiểm và tích hợp. Trong chương này chúng ta sẽ cùng tìm hiểu một số kiến thức về chiến lược kiểm thử phần mềm. Mời các bạn cùng tham khảo.
Trang 105/08/21 ThS Nguyễn Quốc Huy 1
Chiến lược kiểm thử
Khoa CNTT – ĐH Sài Gòn
Trang 2Chiến lược kiểm thử tích hợp
♦ Toàn hệ thống xem như là tập các hệ thống con được xác định trong suốt quá trình thiết kế hệ thống và đối tượng
♦ Chiến lược kiểm là thứ tự mà các hệ thống con được chọn để kiểm và tích hợp
Trang 3Dùng mẫu trung gian cho phép kiểm tích hợp sớm
♦ Dùng mẫu trung gian để cung cấp nhiều cách thực thi dưới 1 giao diện.
♦ Giao diện cho thành phần không hoàn chỉnh, chưa biết hay không thể xài suốt quá trình kiểm.
VIP Seat Interface
(in Vehicle Subsystem) Seat Implementation
Stub Code Seat (SA/RT) Simulated Real Seat
Trang 4Ví dụ: Phân cấp 3 lớp
A
G F
E
Layer I
Layer II
Layer III
Trang 5Kiểm tích hợp: Hướng Big-Bang
Trang 6Chiến lược từ dưới lên
♦ Hệ thống con ở lớp thấp nhất trong phân cấp được kiểm riêng lẻ.
♦ Sau đó các hệ thống con tiếp theo được kiểm thì gọi các hệ
thống con được kiểm trước đó.
♦ Việc này thực hiện lập đi lặp lại cho đến khi tất cả các hệ thống con được kiểm.
♦ Chương trình đặc biệt cần để kiểm, Test Driver:
Lộ trình gọi một hệ thống con và vượt qua test case của nó
SeatDriver
(simulates VIP) (in Vehicle Subsystem) Seat Interface Seat Implementation
Stub Code Seat (SA/RT) Simulated Real Seat
Trang 7Tích hợp từ dưới lên
A
G F
Trang 8Khi nào dùng chiến lược từ dưới lên
♦ Không tốt cho các hệ thống phân rã theo chức năng:
Kiểm thử hệ thống con quan trọng nhất sau cùng
♦ Hữu dụng để tích hợp cho các hệ thống sau:
Các hệ thống hướng đối tượng
Các hệ thống thời gian thực
Các hệ thống có yêu cầu việc thực thi nghiêm ngặt
Trang 9Chiến lược từ trên xuống
♦ Kiểm tầng trên cùng hay hay các hệ thống con quan trọng trước
♦ Rồi kết nối tất cả các hệ thống con đã được kiểm và kiểm tập kết quả các hệ thống con.
♦ Thực hiện cho đến khi kiểm tất cả các hệ thống con được kết hợp.
♦ Chương trình đặc biệt cần để kiểm, Test stub :
Chương trình hay là phương pháp giả lập hoạt động của hệ thống con bị thiếu bằng cách trả lời một loạt lời gọi hệ thống con và trả về
dữ liệu giả.
Trang 10Kiểm từ trên xuống
A
G F
Trang 11Khi nào dùng chiến lược từ trên xuống
♦ Test cases có thể được định nghĩa dưới dạng chức năng hệ
thống (yêu cầu chức năng)
♦ Viết stubs có thể khó: Stubs phải cho phép tất cả điều kiện có thể xảy ra được kiểm.
♦ Có thể cần số lượng rất lớn stubs, đặc biệt nếu lớp thấp nhất của hệ thống chứa nhiều phương pháp.
♦ Một giải pháp để tránh quá nhiều stubs: Điều chỉnh chiến lược
từ trên xuống.
Kiểm mỗi tầng của hệ thống trước khi trộn các tầng
Khuyết điểm của kiểm thử từ trên xuống có điều chỉnh:
Cả hai, stubs và drivers đều cần.
Trang 12Chiến lược Sandwich
♦ Kết hợp từ trên xuống và từ dưới lên
♦ Hệ thống xem như có 3 lớp:
Lớp mục tiêu ở giữa
Lớp trên
Lớp dưới
Kiểm thử tập trung vào lớp giữa
♦ Nếu có hơn 3 lớp thì lớp giữa là lớp nào?
Mẹo: Cố gắng cực tiểu hoá số stubs và drivers
Trang 13Chiến lược Sandwich A
G F
Trang 14Khi nào dùng Sandwich
♦ Thực hiện song song lớp Trên và Dưới.
♦ Không kiểm các lớp con riêng lẻ kỹ trước khi tích hợp.
♦ Giải pháp: Điều chỉnh chiến lược sandwich
Trang 15Điều chỉnh chiến lược Sandwich
♦ Kiểm song song:
Lớp giữa với drivers và stubs
Lớp trên với stubs
Lớp dưới với drivers
♦ Kiểm song song:
Tầng trên truy xuất tầng giữa (lớp trên thay drivers)
Tầng giữa truy xuất tầng dưới (lớp dưới thay stubs)
Trang 16Điều chỉnh chiến lược Sandwich
A
G F
Test A
Test C
Test B, E, F
Triple Test I
Triple Test I
Double Test II
Double Test I
Double Test I
Double Test I
Test A,C
Test
A, B, C, D,
E, F, G
Trang 17Lập lịch kiểm Sandwich: Ví dụ
Unit Tests Double Tests Triple Tests SystemTests
Trang 18sơ bộ cần thiết để kiểm thử tích
hợp chức năng (drivers, stubs)
3 Thực hiện kiểm thử chức năng:
Định nghĩa test cases thuộc tất cả
uses cases với thành phần được
sơ bộ cần thiết để kiểm thử tích
hợp chức năng (drivers, stubs)
3 Thực hiện kiểm thử chức năng:
Định nghĩa test cases thuộc tất cả
uses cases với thành phần được
chọn
4 Thực hiện kiểm cấu trúc: Định
nghĩa test cases thuộc thành phần được chọn
5 Thi hành kiểm thử công suất.
6 Giữ các hồ sơ của test cases và các
hoạt động kiểm thử
7 Lặp các bước 1 đến 7 cho đến khi toàn hệ thống được kiểm
Mục tiêu nguyên thuỷ của kiểm tích
hợp là xác định lỗi trong cấu hình thành phần hiện hành.
4 Thực hiện kiểm cấu trúc: Định
nghĩa test cases thuộc thành phần được chọn
5 Thi hành kiểm thử công suất.
6 Giữ các hồ sơ của test cases và các
hoạt động kiểm thử
7 Lặp các bước 1 đến 7 cho đến khi toàn hệ thống được kiểm
Mục tiêu nguyên thuỷ của kiểm tích
hợp là xác định lỗi trong cấu hình thành phần hiện hành.
Trang 19Chiến lược tích hợp nào nên dùng?
Sắp xếp các mối quan tâm
♦ Hướng từ dưới lên
Phù hợp cho các phương
pháp thiết kế hướng đối
tượng.
Các giao diện driver kiểm
thử phải khớp các giao diện
Sắp xếp các mối quan tâm
♦ Hướng từ dưới lên
Phù hợp cho các phương
pháp thiết kế hướng đối
tượng.
Các giao diện driver kiểm
thử phải khớp các giao diện
Dò tìm các lỗi thiết kế được
hoãn lại ở cuối giai đoạn kiểm thử.
♦ Hướng từ trên xuống
Test cases có thể được định
nghĩa theo các chức năng đang xét.
Cần duy trì tính đúng đắn
của test stubs
Viết stubs có thể khó khăn.
Các thành phần ở tầng
trên thường quan trọng và không thể xem thường vào giai đoạn cuối của việc kiểm thử.
Dò tìm các lỗi thiết kế được
hoãn lại ở cuối giai đoạn kiểm thử.
♦ Hướng từ trên xuống
Test cases có thể được định
nghĩa theo các chức năng đang xét.
Cần duy trì tính đúng đắn
của test stubs
Viết stubs có thể khó khăn.
Trang 20Ảnh hưởng của yêu cầu đối với kiểm thử hệ thống:
Yêu cầu càng tường minh, càng dễ kiểm thử.
Chất lượng use cases xác định độ dễ của kiểm thử chức năng.
Chất lượng việc phân rã các hệ thống con xác định độ dễ của kiểm
cấu trúc.
Chất lượng các yêu cầu phi chức năng và các ràng buộc xác định độ
dễ của kiểm thử hiệu suất:
Trang 21Kiểm thử cấu trúc
♦ Giống với kiểm hộp trắng.
♦ Mục tiêu: Phủ tất cả các đường trong thiết kế hệ thống
Thử tất cả các tham số đầu vào và đầu ra của thành phần.
Thử tất cả các thành phần và tất cả lời gọi hàm (mỗi thành phần
được gọi ít nhất 1 lần và mọi thành phần được gọi bởi tất cả các nơi
có thể gọi.)
Dùng kiểm thử điều kiện và lặp như trong unit testing.
Trang 22Kiểm chức năng
.
Giống như kiểm hộp đen
♦ Mục tiêu: Kiểm chức năng của hệ thống
♦ Test cases được thiết kế từ tài liệu phân tích yêu cầu (tốt hơn là: tài liệu hướng dẫn sử dụng) và tập trung vào các yêu cầu xung quanh và các chức năng cơ bản (use cases)
♦ Hệ thống được xử lý như hộp đen.
♦ Unit test cases có thể tái sử dụng, nhưng người dùng cuối hướng đến test cases mới cũng được.
Trang 23Kiểm thử năng suất
♦ Stress Testing
Stress limits of system (maximum # of
users, peak demands, extended
operation )
♦ Volume testing
Test what happens if large amounts of
data are handled
Evaluate response times and
time to perform a function
♦ Environmental test
Test tolerances for heat,
humidity, motion, portability
♦ Quality testing
Test reliability, maintain- ability
& availability of the system
♦ Recovery testing
Tests system’s response to
presence of errors or loss of data.
♦ Human factors testing
Tests user interface with user
Trang 24Test Cases cho kiểm thử năng suất
♦ Đưa hệ thống đã tích hợp vào đúng giới hạn.
♦ Mục tiêu: Cố gắng phá hệ thống con
♦ Kiểm tra hệ thống xử lý thế nào khi quá tải
♦ Thử thứ tự thi hành khác thường
Gọi receive() trước send()
♦ Kiểm tra phản ứng của hệ thống trước khối lượng dữ liệu lớn
Nếu hệ thống có thể kiểm soát 1000 mục, thử 1001 mục.
♦ Xét thời gian thực hiện trong các use case khác nhau
Trang 25 Lập trình viên không kiểm
thử ở giai đoạn này.
♦ Phần lớn các bugs trong phần mềm
do khách hàng tìm thấy sau khi hệ
thống đưa vào sử dụng Vì vậy có
2 loại kiểm ở giai đoạn này:
Lập trình viên không kiểm
thử ở giai đoạn này.
♦ Phần lớn các bugs trong phần mềm
do khách hàng tìm thấy sau khi hệ
thống đưa vào sử dụng Vì vậy có
2 loại kiểm ở giai đoạn này:
Trang 26Kiểm thử có chu kì sống riêng của nó
Thiết lập các mục tiêu kiểm Thiết kế test cases
Viết test cases Kiểm test cases Thực thi the tests Đánh giá các kết quả kiểm Thay đổi hệ thống
Thực hiện kiểm hồi qui
Trang 27Professional Tester
Configuration Management Specialist
System Designer