Ằ- y.cau kế hóa thử tíchhợp sử dụng Mức chỉ phí phải trả do sót lỗi qua các giai đoan 5/57 È 4 Mục tiêu của kiểm thử PM 3; Kiểm thử PM là : œ Hoạt động thực thi chương trinh với mụ
Trang 1SF
TT FACULTY:
PGS.TS Phan Huy Khanh
29@gmail.com, phkhanh@dut.udu.vn
Công nghệ Phần mêm
oftware Engineering
$8 Khai niém kiém thtr PM (Software Testing)
$8 Cac nguyén ly kiém thử PM
‡§ Các chiến lược kiểm thử PM
3$ Nghệ thuật gỡ rối
“to bo
2/57
SG Thế nào là kiểm thử PM
3 Kiểm thử PM là
œ Thực hiện (chạy) phần mêm trong một môi trường mồ phỏng hay thực tế, theo cách nào đó
3 What is Software Testing?
® using inputs selected somehow
e bằng cách sử dụng các yếu tố đầu vào được lựa chọn
œ Executing software in a simulated or real environment,
È 4 Tai sao phải kiểm thử PM
3§ Trong tiến trình PM :
œ Mặc dù được tự động hoá một phần bởi các công cụ CASE, rất nhiêu công đoạn vân được thực hiện thủ công
e Sản phẩm PM vẫn có khả năng xảy ra sai sót, phạm lỗi
œ Lỗi có thể xảy ra trong tất cả các giai đoạn,
từ phân tích yêu cầu, thiết kế, mã hoá
đến đóng gói sản phẩm
$8 Do đó phải kiểm thử PM trước khi chính thức sử dụng
4/57
3/57
Giá phải trả cho việc tìm và sửa lôi
⁄
100
mức chỉ phí
(lan)
10-
4=
= ma Ằ-
y.cau kế hóa thử tíchhợp sử dụng
Mức chỉ phí phải trả do sót lỗi qua các giai đoan
5/57
È 4 Mục tiêu của kiểm thử PM
3; Kiểm thử PM là :
œ Hoạt động thực thi chương trinh với mục địch tìm ra lồi và phê phan
ø Không mang tính xây dựng, phát triển hay thay đổi PM
Có chi phí hợp lý (do thường có chỉ phí cao)
$8 Kiém thử PM giúp
œ Phát hiện được lỗi, thiếu sót trong chương trình (nếu có)
œ Chứng minh PM được viết đúng
œ Chứng minh được PM hoạt động đúng như đã thiết kế
œ Chứng minh được PM đáp ứng những yêu cầu của NSD
‡§ Kiểm thử PM góp phần chứng minh chất lượng của PM
6/57
Nhap môn CNPM Ch.4 Kiểm thử
Trang 2
a Who Tests the Software?
Developer Independent Tester Understands the system Must learn about the system, but, will test “gently"and, but, will attempt to break it
is driven by "delivery’ and, is driven by guality
7/57
Kiểm thử PM = Xác minh + Thẩm định
Software Testing = Verification and Validation (V&V)
ठXac minh (Verification:
Are we building the Product Right?) :
œ Quá trình xem xét PM có thực hiện đúng đặc tả không,
có đúng thiết kế không ?
3; Thẩm định, hay hợp thức hóa (Validation:
Are we building the Right Product?) :
œ Quá trình xem xét PM có được xây dựng theo đúng yêu câu của khách hàng hay không ?
œ Phát hiện lỗi phân tích, lỗi thiết kế (lỗi ở mức cao)
a Mot so khai niem
$8 MOt Kiém thi’:
e Là cho chạy (Run), hay thực hiện (Execution) một chương trình
từ những dữ liệu được lựa chọn đặc biệt
$8 Mot tap đữ iiệu thử:
e Là tập hợp hữu hạn dữ liệu phục vụ cho một kiểm thử
% Mỗi ép kiểm thử:
e Là hoạt động gồm xây dựng tập dữ liệu thử, tiến hành phép kiểm thử và đánh giá kết quả
‡ÿ VWgườiï kim thử(hay nhớm kiểm thu) :
e Là những chuyên gia có nhiệm vụ tiễn hành phép kiểm thử 3§ Một “/⁄m Khuyet (Failure) :
œ Xảy ra khi thực hiện chương trình cho kết quả không tương hợp với đặc tả của chương trình
38 MOt /6/ sa/ (Error) :
e Là một phần chương trình (lệnh) đã gây ra khiếm khuyết
Ed Hoạt động xác minh và thẩm định
$8 Xac minh và thẩm định cho mọi sản phẩm khác nhau :
ø Thực hiện ở mọi giai đoạn phát triển PM,
do các đổi tượng khác nhau thực hiện
Bản chất của xác minh và thẩm định
Có hai dạng tính và động
‡ÿ Xác minh/thẩm định tĩnh,
còn đgl thanh tra hay kiểm tra (Software Inspection)
œ Không thực hiện chương trinh
œ Chi xem xé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
ø Hạn chế : khó đánh giá tính hiệu quả của sản phẩm
‡§ÿ Xác minh/thẩm định động,
là giai đoạn kiểm thử (Software Testing)
œ Thực hiện (chạy) chương trình để tìm lỗi lập trình
œ Cân có mã nguồn
ø Để đánh giá tính hiệu quả, hay chất lượng phần mềm
11/57
Nhap môn CNPM Ch.4 Kiểm thử
Phân
Đặc tả cầu | nhu |
phan | KO Xac minh 1 chất |
10/57
FF Dac diem cua kiem thu PM
3§ Trong hâu hết tiến trinh PM :
ø Kiểm thử PM không khẳng định được
PM không còn khiếm khuyết
œ Chỉ khẳng định được PM có lỗi và giúp giảm thiểu lỗi 3; Quá trình kiểm thử PM là tốt khi :
œ Có khả năng tìm ra lỗi cao
œ Không dư thừa các hoạt động vô ích, hay có tác dụng ngược
œ Biết cách chọn loc :
Chỉ kiểm thử những phần nào
có khả nẵng tim ra lỗi đặc trưng
œ Không quá phức tạp, cũng không quá đơn giản
Trang 3
Một số công cu trợ giúp kiểm thử
‡§ Hiện nay có nhiều công cụ trợ giúp kiểm thử PM,
thường gặp là :
e TestTrack Pro
DMS for Defect Management
®
e Rational Robot Functional Test Tool
e Rational Performance Test Tool
® Virtual Ruler and Eye Dropper for Graphic Test
È Ả Các nguyên lý kiểm thử PM
$8 Không thể kiểm thử triệt để một PM
‡§; Việc kiểm thử nên :
ø Do những người không tham gia phát triển PM thực hiện
ø Được lập kế hoạch trước khi phát triển PM một thời gian dài Hướng về yêu cầu của khách hàng
œ Nên tiến hành từ nhỏ đến lớn :
Bắt đầu từ những đơn thể riêng biệt
rồi sau đó tích hợp các đơn thể lại
38 Ap dung nguyén ly Pareto (80-20) :
œ 80% lỗi có nguyên nhân từ 20% các đơn thể cô lập
ø Chỉ kiểm tra những đơn thể khả nghi nhất
14/57
13/57
Ed Cac hoat dong kiem thu’
3$ Các bước chính Bắt đầu
Lập kế - | Lập kế hoạch Test |
— | Thiết kế Test |
|
Chuan bi Cai dat va chuan bi Test
Xem xet va danh gia Test Test hé théng két qua test
- —_ œéế¬"¬ ma Phân tích
| Tổng hợp, báo cáo |
J
bed Sản phẩm chính
Bắt đầu
À | Lập kế hoạch Test ot [ mteenee ||
Test case t |
Test data
|
| Tổng hợp, báo cáo =
— XN ƠI `
Gd Chiến thuật kiểm thử PM
3; Chiến thuật kiểm thử PM :
ø Tích hợp các phương pháp tạo ra các ca kiểm thử (Test Case)
œ Xây dựng chuỗi các công việc có thứ tự
để có thể kiểm thử PM thành công với chi phí thấp 3§ Bao gồm các công việc
s Lập kế hoạch kiểm thử
s Xây dựng các ca (trường hợp) kiểm thử
‡§ Một số chiến thuật kiểm thử (Testing) :
ø Kiểm thử đơn thể/đơn vi (Unit Testing)
ø Kiểm thử (Integration Testing)
Đ
Đ
kiểm thử hướng đối tượng (OO Testing)
Kỹ thuật gỡ rối (Debugging)
Nhap môn CNPM Ch.4 Kiểm thử
FF! _ Chiến thuật kiểm thử hình chữ V
Phân tích toàn bộ hệ thống kiểm thử toàn bộ hệ thống
Phân tích yêu câu = = = =~= kiểm thử tính năng
Thiết kế kiểm thử tích hợp
Mã hóa —= kiểm thử đơn thể
Phát triển kểmthử _ 18/57
Trang 4
ba Một số kinh nghiệm
3‡§ Sau giai đoạn thiết kế, mã hoá vả biên dịch hoàn tất :
s Người phát triển PM có thể tự kiểm thử PM của mình
œ Nhưng với các dự án lớn, cân phải do một nhóm chuyên gia độc lập tiến hành
‡§ Dưới đây là một số kinh nghiệm trong kiểm thử
ø Kiểm thử bắt đầu tại từng đơn thể
rồi tích hợp lớn dân đến toàn bộ hệ thống
œ Mỗi giai đoạn sử dụng một kỹ thuật kKiểm thử thích hợp
œ kiểm thử hoạt động độc lập với sửa lỗi, nhưng sửa lỗi phải phù hợp với chiến thuật kiểm thử
E2 Kiểm thử từng đơn thể
‡§ Trong kiểm thử đơn thể, người kiểm thử tiến hành :
ø Kiểm thử từng đơn vị nhỏ nhất của mã nguồn, là các đơn thể
ø Có thể tiến hành kiểm thử cùng lúc nhiều đơn thể
œ Thường được sử dụng trong lập trình cấu trúc (Top-Down Programing)
$8 Goi M là đơn thể cần kiểm thử, có hai khả năng hay gặp :
ø Sử dụng "cuống” (Stubs) khi những đơn thể do M gọi tới không có mặt lúc kiểm thử
ø Sử dụng *trình gọi” (Driver) khi những đơn thể gọi tới M không có mặt lúc kiểm thử
$8 Tuy trường hợp có thể sử dụng một hoặc cả hai khả năng
20/57
Ga Trường hợp sử dụng Stubs
‡§ Những đơn thể do M gọi tới không có mặt lúc kiểm thử
œ Khi đó, những đơn thể vắng mặt phải được thay thế bởi
các trình đgl "cuống" (Stubs) có củng giao diện với M
e Các trình "cuống" thực hiện đúng chức năng
mà chúng đại diện cho đơn thể vắng mặt
E2 Vi du su dung Stubs
$8 Gia sử đơn thể kiểm thử M gọi thủ tục sắp xếp :
Procedure Sort (T: Array ; n: Integer ) ;
tuy nhiên thu tuc Sort vang mat
‡§ Người ta có thể sử dụng trình Stub thay thé :
Procedure Sort (T: Array ; n: Integer ) ;
Writeln (‘Day can sap xép là : `) ;
For i:= 1 To n Do writeln (T[i]) ;
For i:= 1 To n Do readin (T[i}) ;
‡§ Tiếp theo, người kiểm thử sẽ sắp xếp dãy đã nhập
bang tay dé thay thế cho thủ tục sắp xếp vắng mặt
22/57
s Trường hợp sử dụng Drive
3; Những đơn thể gọi tới M không có mặt lúc kiểm thử
ø Khi đó, đơn thể gọi tới M nhưng vắng mặt
phải được thay thể bởi một "trinh gọi” (Driver)
® Trinh Driver goi M để M thực hiện trên tập dữ liệu thử,
sau đó so sánh kết quả tính được với các kết quả chờ đợi
Các đơn thể văng mặt
Trinh gọi
E2 Kiểm thử tích hợp
$8 Mục đích kiểm thử tích hợp :
e Dé tạo mối liên kết giữa các đơn thé
e _ Vừa kiểm thử những đơn thể lớn
hình thành hệ thống chương trình hoàn chỉnh
‡ÿ Có nhiều phương pháp kiểm thử tích hợp :
e Phuong phap “big bang”
e Phương pháp kiểm thử từ trên xuống
(Descendant, hay Top-down Testing Method)
e Phương pháp kiểm thử từ dưới lên
(Ascendant, hay Bottom-Up Testing Method)
e kiểm thử hệ thống
e kiểm thử hồi quy
24/57
Nhap môn CNPM Ch.4 Kiểm thử
Trang 5
Phương pháp “big bang”
‡§ Nội dung phương pháp :
œ Xây dựng một phiên bản hệ thống hoàn chỉnh
gồm tất cả đơn thể để tiến hành kiểm thử
e Mỗi đơn thể của hệ thống đều sử dụng một trình Drivers
và một trình Stubs, trừ đơn thể chính phải được kiểm thử bằng phương pháp kiểm thử đơn vị
‡§ Phương pháp `big bang” nguy hiểm :
e Mọi sai sót có thể đồng thời xuất hiện, nhưng khó xác din
eœ Đòi hỏi một lượng tối đa các trình Drivers và các trình Stu
3 Thực tế, người ta ít sử dụng phương phap “big bang”
mà sử dụng tích hợp từ trên xuống, hay từ dưới lên
h
bs
SF Ví dụ kiểm thử từ trên xuống
Giả sử A là đơn thể chính kiểm thử đầu tiên với 1 Drive
A, stub(B), stub(C)
A, B, stub(C), stub(D), stub(E), stub(F)
A, B, C, stub(G), stub(D), stub(E), stub(F)
A, B, C, D, stub(G), stub(E), s
A, B, C, D, E, stub(G), stub(F?
A, B, C, D, E, F, stub(G), stub
A, B, C, D, E, F, G, stub(H)
FF Ví dụ kiểm thử từ dưới lên
$8 Bắt đầu kiểm thử từ đơn thể D ở mức thấp nhất
D, driver(D)
E, driver(E)
H, driver(H)
G, driver(G)
H, F, driver(F)
D, E, F,B, driver(B), driver(F)
H, F, G, C, driver(C), driver(F)
D, E, H, G, F, B, C, A |
re] (FJ [6]
ba Kiem thu tu tren xuong
3§°Hay còn đgl phương pháp lùi Nội dung phương pháp :
e Bắt đầu kiểm thử đơn thể chính
e Sau đó kiểm thử các đơn thé do đơn thể chính gọi đến, v.v
e Chỉ dùng một trình Driver duy nhất cho đơn thể chính, nhưng mồi đơn thể còn lại đều cần một trình Stubs
Dãy các |
kiểm thử |
È 4 Kiểm thử từ dưới lên
‡$ Hay còn đgl phương pháp tiến Nội dung phương pháp :
e kiểm thử các đơn thể không gọi đến các đơn thể khác e_ Tiếp tục các đơn thể gọi đến các đơn thể đã kiểm thử
e Đòi hỏi mỗi đơn thể một Driver, không cần Stub
Đánh giá PP kiểm thử từ dưới lên
‡§ Phương pháp tiến tỏ ra ưu điểm hơn phương pháp lùi :
e Do các trình Driver sử dụng đến dễ viết hơn các trình Stubs
œ Thường có công cụ để tạo sinh tự động các trình Drivers
œ Thứ tự tích hợp thường bị ràng buộc bởi thứ tự có mặt
của các đơn thể
Nhap môn CNPM Ch.4 Kiểm thử
Trang 6
3 Sandwich testing:
e A, stub(B), stub(C)
e A,B, stub(C), stub(D), stub(E), stub(F)
A, B, C, stub(G), stub(D), stub(E), stub(F)
D, driver(D)
A
H, driver(H)
G, driver(G)
A, B, C, D, E, F, G, H
31/57
SG Kiểm thử hệ thống
‡£ Nội dụng phương pháp :
e Tiến hành kiểm thử hoàn chỉnh toàn bộ phần mềm
và sự tương hợp với phần cứng
e Đánh giá hiệu năng, độ an toàn, tính tương hợp với các đặc tả yêu cầu, v.v
3; Đặc điểm kiểm thử hệ thống :
œ Đi hỏi nhiêu thời gian, công sức
e Trong nhiêu trường hợp, PP nay con dgl
kiểm thử chap nhan (Acceptance Testing),
SF Một PP kiểm thử khác (2)
3 Build testing:
e A, stub(B), stub(C)
A, B, stub(C), stub(D), stub(E), stub(F)
A, B, F, stub(H), stub(D), stub(E), stub(C)
A, B, F, H, stub(D), stub(E), stub(C)
A, B, F, H, D, E, stub(C)
A, B, F, H, D, E, C, stub(G)
A, B, F, H, D, E, C, G ~
(o] Ce rT (a
ce-
Một số dạng kiểm thử hệ thống khác
$8 Ki€m thu’ cai dat (Setup Testing) :
e kiểm thử sản phẩm cuối cùng
e Tiến hành tại vị trí của khách hàng (với các máy tính và hệ điêu hành họ đang sử dụng)
3‡§ Do tính phức tạp của phần mềm, người ta thường kiểm thử hệ thống dưới dạng :
e kiểm thử Alpha
se kiểm tht Beta
3§ Được tiến hành ngay tại nơi sản xuất PM
‡§ Có thể do khách hàng, NSD tiến hành kiểm thử
trên sản phẩm
3§ Nội dung :
œ Kiểm tra sản phẩm có phù hợp với hợp đồng
đã ký với khách hàng hay chưa
ø Người phát triển PM quan sát NSD dùng sản phẩm
và ghi nhận lại những lỗi phát sinh để sửa chữa
35/57
Nhap môn CNPM Ch.4 Kiểm thử
3§PM được kiểm tra bên ngoài phạm vi của đơn vị sản xuất
3 Nội dung
e kiểm thử cho phiên bản (Version/Release) đầu tiên của PM
e Lựa chọn khách hàng nào được tham gia kiểm thử,
ví dụ các trường đại học, viện nghiên cứu
œ Khách hành trực tiếp sử dụng và ghi nhận lỗi
để báo lại cho nhà phát triển sửa chữa
Trang 7
SP Kiểm thử hồi quy
$8 Con dal kiém thu thoai lui (Regresgion Testing) :
œ Tiến hành sau khi sửa lỗi, thường ở giai đoạn bao tri PM
ø Xác định các sai sót chưa được xử lý sau giai đoạn kiểm thử
ø Lưu giữ những kết quả kiểm thử
đã tiến hành trong quá trinh sản xuất PM
3§ Khó khăn của phương pháp :
ø Chọn những kiểm thử nào cho kiểm thử thoái lui ?
® Số lượng các kiểm thử đã triển khai thường rất lớn,
dễ thay đổi
s Kiểm thử hôp đen (BlackBox)
3$ Thường áp dụng cho những PM lớn
#€ Nội dung phương pháp :
ø Kiểm tra các chức năng cụ thể của PM
œ Không quan tâm cấu trúc bên trong
ba Kiểm thử hộp trắng (WhiteBox)
3§ Thường dùng cho những những PM nhỏ
‡§ Nội dung phương pháp là kiểm tra cấu trúc điều khiển bên
trong chương trinh với tiêu chí :
ø Kiểm thử các đường độc lập trong dòng chảy của thuật giải
œ Bảo đảm số phép thử là ít nhất đủ để phát hiện các lỗi
œ Thử các điều kiện rẽ nhánh True va False
œ Thử vòng lặp tại biên cũng như bên trong
s Thử cấu trúc dữ liệu để đảm bảo tính toàn vẹn của nó
‡§; Kiểm thử hộp đen và kiểm thử hộp trẳng
đều có khả năng tìm ra những nhóm lỗi khác nhau,
trong thực tế nên kết hợp cả hai
38/57
ba Ví dụ đồ thi dòng chảy
3§ Cách xây dựng :
œ Mỗi node hình tròn biểu diễn một hoặc một vài tác vụ
(hơi khác so với lưu đồ thuật toán)
œ Cạnh có hướng miêu tả đường thực thi
‡§ Đồ thị dòng chảy được xây dựng từ lưu đồ thuật toán
Sequence Tí Until While Case
40/57
SP Vi du xay dung do thi dong chay
$8 Tu’ so do khoi :
41/57
3§ Từ chương trình : (1)
Procedure: DoSomething
if y=0 then
elseif k=0 then
N II
©
42/57
Nhap mé6n CNPM Ch.4 Kiém tht
Trang 8
a Ky thuat go roi (Debugging) Ga Phuong phap Brute Force
+ Do timeout 38 Ap dung phương pháp này khi tất cả các phương pháp khác + Do độ chính xác đều thất bại
+ Do chủ quan khi lập trình 3; Có 3 cách thực hiện :
3 Có nhiều phương pháp gỡ rồi : s Dùng lệnh Write để in ra màn hình dữ liệu cần kiểm tra
œ Brute Force Loại trừ nguyên nhân
øœ Theo vết
ba Loại trừ nguyên nhân ba Theo vết
3g Phương pháp này dựa trên nguyên tắc phân chia nhị phân 3 Là phương pháp gỡ lỗi khá phổ biến
3§ Cách thực hiện; ø Có thể dùng thành công trong các chương trình nhỏ
œ Khi một lỗi được phát hiện, cố gắng đưa ra một danh sách œ Khó áp dụng cho các chương trinh rất lớn
s Danh sách này được kiểm nghiệm lại để loại bỏ dần
các nguyên nhân không đúng cho đến khi tim thấy một nguyên nhân khả nghỉ nhất
œ Khi đó dữ liệu kiểm nghiệm sẽ được tinh chế lại
để tiếp tục tìm lỗi
œ Bắt đầu tại dòng mã nguồn có triệu chứng lỗi
thực hiện lần ngược trở lại từng dòng mã nguồn
cho đến khi tìm thấy dòng gây ra lỗi
# Testing is still a black art,
but many rules and heuristics are available A failure?
3$ Testing consists of component-testing
(unit testing, integration testing) An error?
and system testing, and
$€ OOT and architectural testing, still challenging A fault?
€ User-oriented reliability modeling Need t fy
eed to speci | z and evaluation not adequate the desired behavior first! ` SZ Â 3$ Testing has its own lifecycle
Nhap mé6n CNPM Ch.4 Kiém tht
Trang 9
Alqorithmic Fault
50/57
Erroneous State (“Error”)
49/57
How do we deal with Errors and Faults?
52/57
Mechanical Fault
51/57
Modular Redundancy?
54/57
Verification?
53/57
U
>
Nhap môn CNPM Ch.4 Kiêm th
Trang 10
oo A)
+
Declaring the Bug
as a Feature?
tee
Patching?
Testing?