Nhập môn Công nghệ phần mềm: Chương 3 - Lương Trần Hy Hiến

Kiểm thử Phần mềm – Software Testing

Chương 3:

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

Lương Trần Hy Hiến, Khoa CNTT, ĐH Sư phạm
TpHCM

1


Nội dung
• Kiểm tra mức đơn vị (Unit Testing)
• Kiểm tra tích hợp (Integration
Testing)
• Kiểm tra mức hệ thống (System
Testing)
• Kiểm tra chấp nhận sản phẩm
(Acceptance Testing)
• Kiểm tra hồi qui (Regression Testing)


3.1 Kiểm thử đơn vị Unit Test
Unit Test là gì?
Những Lợi ích từ UT
Assert, Mock Object, TDD
Cơng cụ cho Unit Test
Demo công cụ
3

Unit Test là gì?
• Unit Test là kỹ thuật kiểm nghiệm các hoạt
động của mọi đơn vị mã nguồn (unit of
code) với một quy trình tách biệt với quy
trình phát triển phần mềm, giúp phát hiện
sai sót kịp thời.
• Unit Test là một phần mã nguồn dùng để
kiểm tra một phần mã nguồn khác.
• Unit Test là kỹ thuật quan trọng trong Test
Driven Development.


Unit Test là gì?
• Unit Test là phương pháp bổ sung cho các
phương pháp kiểm thử khác, giúp phát hiện lỗi
từ sớm, ngay từ ý tưởng thiết kế (reviews code,
walkthroughs…)
• Unit Test được viết bởi Developers. Test “White
Box”, “Black-Box” trong quá trình PTPM.
Các Khái Niệm:
 Unit of Code : Mỗi đơn vị mã nguồn có thể là
individual program, function, Procedure, class, methods…
 White-Box, Black-Box :


Unit Test là gì?
Unit Test có 3 trạng thái:
 Fail (trạng thái lỗi)

 Ignore (tạm ngừng thực hiện)
 Pass (trạng thái làm việc đúng)


Thực hiện UT như thế
nào?
Mỗi Unit Test đều được tiết kế theo trình tự:
• Thiết lập các điều kiện cần thiết: khởi tạo các đối
tượng.
• Xác định tài nguyên cần thiết, xây dựng các dữ
liệu giả...
• Triệu gọi các phương thức cần kiểm tra.
• Kiểm tra sự hoạt động đúng đắn của các
phương thức.
• Dọn dẹp tài nguyên sau khi kết thúc kiểm tra.


How to write a Unit Test?


My Unit Test is good?








Tự động kiểm tra trạng thái (Pass/False/Ignore).

Đầy đủ (phủ hết các trường hợp).
Tái sử dụng được.
Tính độc lập (very important).
Theo chuẩn code.
Khả năng thực thi nhanh.
Đơn giản để thực hiện.

Unit Testing Still Not Mainstream
/>

Lợi ích từ Unit Test
Đảm bảo chất lượng từng Unit trong phần mềm.
Phát hiện lỗi sớm và chỉnh sửa kịp thời.
Giảm chi phí bảo trì và kiểm thử.
Dễ tích hợp.
Tài liệu hóa.
Giúp Thiết Kế.


Assert, Mock Object, TDD
• ASSERT
– là một macro dùng để phát hiện lỗi của phần
mềm trong quá trình phát triển bằng cách thực
thi biểu thức trong assert.

Dùng assert() để phát hiện ra những bugs do những người lập
trình vì vơ tình mà gây ra : gọi một hàm với những tham số
khơng hợp lệ, sử dụng sai thuật tốn, v.v…

Mock Object
• Là một đối tượng ảo mơ phỏng các tính chất và hành
vi giống hệt như đối tượng thực, được dùng để kiểm
tra tính đúng đắn của một đơn vị chương trình.
• Đơn giản hơn đối tượng thực nhưng vẫn giữ được sự
tương tác với các đối tượng khác.
–
–
–
–

Đảm bảo công việc kiểm nghiệm không bị gián đoạn .
Giúp tiếp cận hướng đối tượng tốt hơn
Giúp phát hiện interface cần tách ở một số lớp.
Dễ dàng cho việc kiểm nghiệm. Thay vì gọi các đối tượng
thực vận hành nặng nề, chúng ta có thể gọi các MO đơn
giản hơn để kiểm tra nhanh liên kết giữa các thủ tục, cơng
việc kiểm nghiệm có thể tiến hành nhanh hơn.


Test Driven Development
• TDD là một chiến lược phát
triển sử dụng kỹ thuật UT
theo nguyên tắc tạo ra các
công đoạn kiểm nghiệm
trước khi xây dựng mã.


Lợi ích Test Driven
Development

• Định hình ý tưởng thiết kế hơn là kiểm nghiệm
mã chương trình.
• Lập trình đơi.
• Định hướng cho nhóm thiết kế vận dụng tốt các
phương pháp hướng đối tượng.
 Loosely-Coupled.
 Highly-Cohesive.

• Mã chất lượng và an toàn, tập trung hơn, giảm
phân mảnh mã và giảm rủi ro xảy ra ngoài dự
kiến.


Công cụ cho Unit Test


3.2 Kiểm thử tích hợp
• Tồn hệ thống xem như là tập các hệ thống con
được xác định trong suốt q 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.
–
–
–
–
–

Tích hợp Big bang
Tích hợp từ dưới lên

Tích hợp từ trên xuống
Kiểm thử Sandwich
Biến dạng các cách trên

• Dùng cách phân rã hệ thống từ bản thiết kế


Dù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
hồn chỉnh, chưa biết hay khơng thể
xài suốt q trình kiểm.
VIP

Seat Interface
(in Vehicle Subsystem)

Stub Code

Seat Implementation

Simulated
Seat (SA/RT)

Real Seat

Ví dụ: Phân cấp 3 lớp
A

C

B

E

Layer I

F

D

Layer II

G

Layer III


3.2.1 Kiểm thử big bang
• 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 hồ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ỏ.


3.2.1 Kiểm thử Big-Bang
Unit Test
A

Đừng cố!

Unit Test
B
Unit Test
C
Unit Test
D
Unit Test
E
Unit Test
F

System Test


3.2.2 Kiểm thử dưới lên
• Là q 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


3.2.2 Kiểm thử dưới lên
• VD:

A

B

F

C

D
Nhóm chức năng

K

G

E

H

I

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

C

B

Test E

E

Layer I

F

Test B, E, F
Test F
Test C

Test D,G
Test G

Test
A, B, C, D,
E, F, G

D

G

Layer II

Layer III


3.2.2 Kiểm thử 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


Khi nào cần 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