KIỂM THỬ PHẦN MỀM - SOFTWARE TESTING

CÁC MỨC KIỂM THỬ PHẦN MỀM

(TEST LEVEL)

Đỗ Thị Thu Trang - FIT.UTEHY

1
NỘI DUNG

 Kiểm thử mức đơn vị - Unit testing

 Kiểm thử mức tích hợp - Integration testing
 Kiểm thử mức hệ thống - System Testing
 KT chấp nhận sản phẩm - Acceptance Testing

2
Các mức kiểm thử

3
Mô hình chữ V

4
NỘI DUNG

 Kiểm thử mức đơn vị - Unit test

 Kiểm thử mức tích hợp - Integration test
 Kiểm thử mức hệ thống - System Test
 KT chấp nhận sản phẩm - Acceptance Test

5
Unit Testing

6
Các mức kiểm thử là gì?

 Một nhóm các hoạt động kiểm thử được tổ chức và

quản lý cùng nhau.
 Mỗi mức kiểm thử cụ thể là tương ứng với một giai
đoạn phát triển phần mềm (mô hình chữ V).
 4 mức độ kiểm thử:
 Unit testing (Component testing)
 Integration testing (Combination testing)
 System testing
 Acceptance testing

7
UNIT TEST - What?

 Một đơn vị (unit) (thành phần phần mềm) là một phần nhỏ
nhất của chương trình phần mềm có thể kiểm thử được.
 CT hướng thủ tục: 1 chương trình độc lập, hàm (function), thủ
tục (procedure), module …

 CT hướng đối tượng: 1 phương thức (method)

 Unit test là kỹ thuật kiểm thử các hoạt động của các đơn vị
mã nguồn với quy trình tách biệt nhằm xác định xem nó có
hoạt động như mong đợi hay không

 Tập trung phát hiện lỗi liên quan đến chức năng và cấu trúc
nội tại của Unit
8
UNIT TEST - What?

 Unit test (Component test): Là hoạt động kiểm tra từng

đơn vị thành phần phần mềm riêng biệt của chương trình

 Cách gọi khác: module testing, component testing

9
Unit test - Why?

1 Để đảm bảo rằng code theo

đúng design

2 Các lỗi và các vấn đề sớm

Tại sao?
được tìm thấy => đảm bảo
chất lượng các Unit

3 Giảm chi phí, thời gian, công

sức cho việc sửa lỗi
10
 Unit test - Why?

$14,000

85% % Defects
Percentage of Bugs

Introduced in
this phase

% Defects
found in
in this phase
$1000
$ Cost to
$130 $250 repair defect
$25 in this phase

Coding Unit Funct Field Post

Test Test Test Release
Source: Applied Software Measurement,
Capers Jones, 1996

11
Unit test - When? Who?

When?
 Sau Coding

 Trước Integration Test

Who?
 Thông thường do đội phát triển phần mềm, lập trình
viên (Developer, coder) thực hiện

12
Unit test - Types/Technique

 Statement testing: thực thi tất cả các câu lệnh ít

nhất một lần.
 Decision/Branch testing: thực thi mỗi đường rẽ
nhánh ít nhất một lần.
 Condition testing: kiểm thử tất cả các điều kiện kết
hợp có thể.
 Path testing: thực thi tất cả các đường đi của
chương trình ít nhất một lần.

13
Unit test - Implementation

 Sử dụng một hoặc nhiều kiểu kiểm thử đơn vị theo

một trong các cách sau:
 Top-Down Unit Testing: sử dụng Stubs
 Bottom-up Unit Testing: sử dụng Drivers
 Khái niệm Stubs, Drivers thường được sử dụng
trong kiểm thử mức đơn vị để thay thế cho các
component, software còn thiếu.

14
Top-Down Unit Testing

 Stubs: được gọi bởi thành phần phần mềm cần

kiểm thử

15
Bottom-up Unit Testing

 Driver: gọi thành phần phần mềm cần kiểm thử

16
Unit Test - Tools

 Các công cụ Unit Test tham khảo:

 Java: TestNG, Junit (www.junit.org)
 C/C++: cppUnit (http://sourceforge.net/projects/cppunit/)
 Python: pyUnit (http://pyunit.sourceforge.net/)
 Perl: PerlUnit (http://perlunit.sourceforge.net/)
 Visual Basic: vbUnit (http://www.vbunit.com/)
 C#: csUnit (http://www.csunit.org/)
 .NET: Nunit (http://www.nunit.org/)

17
Unit test - Advantages?

 Mục đích của Unit Test là cô lập từng phần của chương trình
và đảm bảo những phần đó chạy đúng như yêu cầu
 Unit test giúp bảo đảm tính chính xác của chương trình, nó
giúp thiết lập những ràng buộc và những phần code phải
thực hiện chính xác những ràng buộc đó
 Unit test giúp phát hiện lỗi và những vấn đề liên quan ngay từ
những phase đầu tiên của quá trình phát triển phần mềm
 Unit test giúp tích hợp code dễ dàng

18
Unit test - Disadvantages?

 Unit Test khó có thể bắt tất cả các lỗi của chương trình
 Unit Test chỉ kiểm lỗi những unit nhỏ nhất của chương trình
do đó không thể nào lường trước những vấn đề có thể xảy ra
khi kết hợp các module với nhau
 Unit Test chỉ có thể kiểm tra được những lỗi đã biết chứ
không thể sử dụng nó để tìm ra các lỗi tiềm ẩn của chương
trình

19
NỘI DUNG

 Kiểm thử mức đơn vị - Unit test

 Kiểm thử mức tích hợp - Integration test
 Kiểm thử mức hệ thống - System Test
 KT chấp nhận sản phẩm - Acceptance Test

20
Integration test - What?

• Thực hiện hoạt động kiểm thử khi tích hợp các thành phần
phần mềm với nhau để tạo thành một hệ thống hoàn chỉnh.

• Tập trung kiểm tra giao diện giữa các thành phần, không tập
trung vào chức năng của từng thành phần cụ thể.

21
Integration test - What?

• Lỗi kiểm thử tích hợp là lỗi khi các thành phần/ đơn vị phần
mềm giao tiếp với nhau thực hiện không đúng.

• Thường kiểm thử theo hướng hộp đen

• Nên thực hiện trên những Unit đã được kiểm tra Unit Test,
và tất cả các lỗi mức Unit đã được sửa chữa

22
Integration test - Objectives

Kiểm thử tích hợp tập trung vào:

• Phát hiện lỗi giao tiếp xảy ra giữa các modules/ components

• Tính năng tích hợp

• Kiến trúc hệ thống

23
Integration test - Why?

 Kiểm thử mức Unit chỉ kiểm tra các đơn vị một cách độc lập.

 Có nhiều lỗi gây ra do sự tương tác của các hệ thống con.

 Hỗ trợ tích hợp chức năng/ modules theo thiết kế kiến trúc
hoặc thiết kế cấp cao (HLD).

 Đảm bảo sự giao tiếp giữa các chức năng/ modules làm việc
một cách đúng đắn.

25
Integration test - When? Who?

When:

 Phụ thuộc vào mức độ tích hợp

 Các thành phần/đơn vị phần mềm đã được kiểm thử mức

đơn vị và tích hợp một cách hoàn toàn

Who:

 Kiểm thử viên (Tester)

26
Integration test - Level of Integration

 Tích hợp thành phần  Tích hợp hệ thống

 Tích hợp giữa các thành  Tích hợp giữa các hệ thống
phần

27
 Integration test - Types of Integration

 Big-bang integration: tích hợp tất cả các thành phần, hệ thống

cùng một lúc.

 Incremental integration: tích hợp từng phần một.

28
Big Bang Integration

Big-bang integration: tích

hợp tất cả các thành phần,
hệ thống cùng một lúc.

29
 Big Bang Integration

 Ưu điểm:
 Mọi thứ đã hoàn thành trước khi bắt đầu kiểm thử tích hợp.

 Nhược điểm:
 Mất thời gian.

 Khó để tìm ra nguyên nhân gây lỗi.

 Chỉ hiệu quả khi phần mềm dự kiến không có khiếm khuyết.

30
 Incremental Integration

 Tích hợp từng thành phần một.

 Ưu điểm:
 Các lỗi được phát hiện sớm ở giai đoạn đầu của quá trình
tích hợp để dễ phát hiện nguyên nhân.

 Nhược điểm:
 Cần thời gian để tạo stubs và drivers.

31
Types of Incremental Integration

 Top-down: kiểm thử từ menu tới chức năng (sử dụng

stub)

 Bottom-up: kiểm thử từ chức năng chi tiết đến menu

(sử dụng driver)

 Functional incremental: kiểm thử mỗi chức năng

được tích hợp, kiểm tra từng cái một.

32
Top-down Integration Testing

33
Top-down Integration Testing

 Ưu điểm:
 Không cần tạo driver.
 Các test case có thể được định nghĩa về các tính năng của
hệ thống (yêu cầu chức năng)
 Nhược điểm:
 Có thể cần một số lượng lớn các stub, đặc biệt nếu mức
thấp nhất của hệ thống chứa nhiều phương pháp.
 Viết các stubs là khó khăn: stub phải cho phép kiểm tra tất
cả các điều kiện có thể.
 Một số giao diện không được kiểm tra riêng biệt.

34
Bottom-Up Integration Testing

35
Bottom-Up Integration Testing

 Ưu điểm:
 Không cần tạo stubs.
 Hữu ích cho việc kiểm thử các hệ thống:
 Hệ thống hướng đối tượng
 Hệ thống thời gian thực
 Hệ thống có yêu cầu về thực thi một cách nghiêm ngặt.
 Nhược điểm:
 Kiểm thử hệ thống con - hệ thống quan trọng nhất là cuối
cùng.
 Cần tạo driver.

36
Functional Incremental

 Ưu điểm:
 Các test case có thể được định nghĩa về các tính năng của
hệ thống (yêu cầu chức năng).
 Nhược điểm:
 Cần tạo driver và stub.
 Một số giao diện không được kiểm tra riêng biệt
 Khó khăn trong người tích hợp.

37
NỘI DUNG

 Kiểm thử mức đơn vị - Unit test

 Kiểm thử mức tích hợp - Integration test
 Kiểm thử mức hệ thống - System Test
 KT chấp nhận sản phẩm - Acceptance Test

38
System test - What?

 Kiểm thử mức hệ thống được

định nghĩa là kiểm tra hành vi
của hệ thống/ phần mềm theo
đặc tả yêu cầu phần mềm.

 Tập trung vào hành vi của toàn

bộ hệ thống/ sản phẩm được
xác định bởi phạm vi của dự án
hoặc sản phẩm phát triển.

39
System test - What?

Kiểm thử hệ thống dựa trên:

 Rủi ro

 SRS

 Quy trình nghiệp vụ, use case

 Tương tác với hệ điều hành, nguồn tài nguyên…

40
System test - Why?

Để xác định các Để kiểm tra trong Thực hiện các kiểm
yêu cầu chức một môi trường gần thử cuối cùng để xác
năng, phi chức giống với môi minh rằng hệ thống
năng, nghiệp vụ, trường sản xuất, nơi đủ điều kiện chuyển
yêu cầu kỹ thuật ứng dụng cuối cùng giao
của phần mềm. sẽ được triển khai.

41
System test - When?

 Khi hệ thống phần mềm đã được hoàn thiện

 Kiểm thử mức đơn vị đã được thực hiện hoàn thành

 Kiểm thử mức tích hợp đã được thực hiện hoàn thành

42
System Testing

 Kiểm thử mức hệ thống dựa trên đặc tả của sản phẩm,
bao gồm:
 Yêu cầu đặc tả

 Quy trình nghiệp vụ/ luồng nghiệp vụ

 Các trường hợp sử dụng

 Tương tác với các dịch vụ thứ ba hoặc một hệ thống khác

43
System Testing - Technique

 Kiểm thử hệ thống bao gồm:

 Kiểm thử chức năng: sử dụng phương pháp kiểm thử hộp
đen

 Kiểm thử phi chức năng: hiệu năng và độ tin cậy

 Kiểm thử liên quan đến các kiểu thay đổi.

 Người thực hiện: KTV

44
Black Box Test Method

 Tập trung vào Input/Output của phần mềm mà không

quan tâm đến mã lệnh bên trong của chương trình.

 Tập trung vào yêu cầu chức năng của phần mềm

 Thiết kế bộ điều kiện đầu vào sẽ thực hiện đầy đủ các

yêu cầu chức năng cho một chương trình.

45
System Testing - Environment

 Môi trường để kiểm thử gần giống với môi trường chạy
của sản phẩm để giảm thiểu rủi ro về lỗi môi trường.

 Nơi mà phần mềm / hệ thống / ứng dụng sẽ được triển

khai.

46
NỘI DUNG

 Kiểm thử mức đơn vị - Unit test

 Kiểm thử mức tích hợp - Integration test
 Kiểm thử mức hệ thống - System Test
 KT chấp nhận sản phẩm - Acceptance Test

47
 User Acceptance Test (UAT) - What?

 Được thực hiện bởi khách hàng

 Môi trường kiểm thử chấp nhận thông thường giống với
môi trường của sản phẩm

 Kiểm thử chấp nhận sản phẩm tập trung vào việc xác
nhận sản phẩm có đạt yêu cầu KH

 Kiểm thử chấp nhận sản phẩm có thể diễn ra trong mọi
cấp độ kiểm thử khác sau Unit test (Integration test,
System Test)

48
 User Acceptance Test- Why?

 Chấp nhận sản phẩm dựa trên tiêu chí chấp nhận.

 KH chấp thuận sản phẩm làm theo yêu cầu.

 Đảm bảo chức năng cần thiết và mong đợi của khách
hàng có trong sản phẩm phần mềm.

49
 UAT - When, Environment

 Sau khi sản phẩm được phát hành

 Kiểm thử hệ thống được thực hiện

 Môi trường giống như môi trường thực tế mà sản phẩm

được sử dụng

50
 UAT - Types

 User acceptance testing: kiểm thử chấp nhận người dùng

 Operational acceptance testing: kiểm thử nghiệm thu

 Compliance acceptance testing: kiểm thử chấp nhận tuân

thủ

 Alpha and beta testing: kiểm thử mức độ alpha, beta

51
 UAT - Types

 Operational acceptance testing - OAT: đảm bảo rằng tất

cả các khía cạnh phi chức năng của hệ thống được kiểm
tra để đảm bảo hệ thống nằm trong các thông số quy định.

 OAT có thể bao gồm các nội dung:

 Sao lưu/ phục hồi HT (Backup/ restore)

 Phục hồi dữ liệu

 Bảo trì

 Tính bảo mật

52
 UAT - Types

 Compliance acceptance testing: được thực hiện theo tiêu

chí chấp nhận của hợp đồng, chẳng hạn như các quy định
của chính phủ.

 Ví dụ: báo cáo kế toán có tuân thủ theo pháp luật không?

53
UAT - Types

Kiểm thử Alpha:

 Kiểm thử bởi người dùng cuối/ KH

 Được thực hiện tại nơi phát triển

sản phẩm.

 Phần mềm được sử dụng trong

môi trường tự nhiên với các nhà
phát triển quan sát cẩn thận (dưới
sự giám sát của nhà phát triển)

54
UAT - Types

Kiểm thử Beta:

 Kiểm thử bởi người dùng cuối/
KH

 Tiến hành tại các trang web

của người dùng cuối.

 Tiến hành sau kiểm thử Alpha.

 Người dùng cuối ghi lại tất cả
 Thường không có mặt của nhà các vấn đề gặp và báo cáo cho
phát triển. các nhà phát triển trong
khoảng thời gian đều đặn

55
CÁC CẤP ĐỘ KIỂM THỬ PHẦN MỀM

TÓM LẠI
Nội dung bài học gồm

1. Unit test 2. Integration 3.System test 4. UAT

Test
Kiểm thử mức Kiểm thử mức Kiểm thử chấp
Kiểm thử mức nhận người
đơn vị tích hợp hệ thống
dùng

56
Tài liệu tham khảo

 Bộ môn CNPM - Khoa CNTT, Đề cương Kiểm thử phần mềm, Đại
học Sư phạm Kỹ Thuật Hưng Yên.

 https://www.guru99.com/unit-testing-guide.html

 https://www.guru99.com/integration-testing.html

 https://www.guru99.com/system-testing.html

57
TỔNG KẾT

QUESTION/ ANSWER

58