Software Engineering

Software testing
 Topics covered
• System testing
• Component testing
• Test case design
• Test automation
 Program testing
• Có thể chỉ ra sự xuất hiện của lỗi
• Phần mềm phải được thực hiện để xem nó cư
xử như thế nào
• Nên được thực hiện kết hợp với static
verification
 Testing and debugging
• Verification & validation: chỉ ra sự tồn tại của lỗi.
• Debugging: tìm vị trí của lỗi trong mã và sửa lỗi.
 Các loại kiểm thử
• Black-box testing
• White-box testing
• Grey-box testing
 Các mức kiểm thử
• Component testing
– Kiểm thử các thành phần phần mềm riêng rẽ
– Nhiệm vụ của lập trình viên, người viết thành phần
• System testing
– Kiểm thử nhóm các thành phần phần mềm được tích
hợp với nhau tạo nên hệ con hoặc hệ thống hoàn
chỉnh
– Nhiệm vụ của nhóm kiểm thử
– Dựa trên tài liệu đặc tả hệ thống
 Testing phases

Component testing System testing

Software developer Independent testing team

 The V-model of development
Requirement
Service
specification

System Acceptance Acceptance

Specification test plan test

System System
System integration test integration
design plan
test

Syb-system Syb-system
Detail design integration test integration
plan
test

Module, unit code and test

 Mục tiêu của kiểm thử
• Validation testing
– Chỉ ra rằng phần mềm thỏa mãn yêu cầu
– Chỉ ra rằng hành vi của hệ thống là hành vi được
mong đợi
• Defect testing
– Phát hiện lỗi
• Ví dụ, cài đặt không nhất quán với đặc tả
– Ca kiểm thử thành công là ca kiểm thử trong đó hệ
thống hoạt động sai
• Lộ ra vấn đề của hệ thống
 The software testing process

Test Test
Test data
cases results

Thiết kế ca Chuẩn bị dữ Chạy chương So sánh

kiểm thử liệu kiểm thử trình kết quả

Test
reports
 Bao nhiêu ca kiểm thử là đủ?
• Một bộ kiểm thử đầy đủ có thể chỉ ra một hệ
thống không chứa lỗi
– Tuy nhiên, khó có thể thực hiện bộ kiểm thử đầy đủ
• Chúng ta có thể lựa chọn các ca kiểm thử theo
tiêu chí:
– Tất cả các chức năng được lựa chọn bằng thực đơn
đều được kiểm thử;
– Chuỗi các chức năng được truy cập bằng một thực
đơn nên được kiểm thử;
– Với những chức năng có yêu cầu đầu vào được đưa
vào bởi người dùng, chúng phải được kiểm thử với cả
dữ liệu hợp lệ và không hợp lệ.
 System testing
• Đòi hỏi tích hợp các thành phần để tạo nên hệ
thống hoặc hệ thống con
• Hai giai đoạn:
– Integration testing
– Release testing (acceptance testing)
 Integration testing
• Phát hiện các vấn đề nảy sinh từ sự tương tác
giữa các thành phần phần mềm
• Top-down integration:
– khung tổng thể của hệ thống được phát triển trước
– các thành phần được thêm vào dần.
• Bottom-up integration:
– tích hợp các thành phần cung cấp các dịch vụ chung
trước, e.g., dịch vụ mạng, cơ sở dữ liệu
– Tích hợp dần các thành phần chức năng
• Để đơn giản hóa việc xác định vị trí lỗi, hệ thống
nên được tích hợp dần dần.
Incremental integration testing

A T1

T1
A
T1 T2
A B
T2

T2 B T3

T3
B C
T3 T4
C
T4

D T5

Test sequence 1 Test sequence 2 Test sequence 3

 Release testing
• Kiểm thử phiên bản phần mềm mà sẽ được
bàn giao cho khách hàng
• Mục tiêu chính là tăng sự tin tưởng của khách
hàng với sản phẩm
• Thường là kiểm thử hộp đen hay kiểm thử
chức năng
– Người kiểm thử không cần biết về triển khai bên
trong
 Test case design
• Tạo ra bộ kiểm thử hiệu quả cho cả validation
testing và defect testing
• Các cách tiếp cận:
– Partition testing;
– Structural testing.
 Partition testing
• Dữ liệu vào, ra được phân chia theo
nhóm/lớp.
• Mỗi nhóm/lớp là một phân hoạch/miền tương
đương (equivalence partition) or domain
– Hành vi của hệ thống là như nhau khi sử dụng các
thành viên trong cùng nhóm.
• Các trường hợp kiểm thử nên được lựa chọn
từ các thành viên trong nhóm.
Equivalence partitioning

Invalid inputs Valid inputs

System

Outputs
 Equivalence partitions
3 11
4 7 10

Less than 4 Betw een 4 and 1 0 More than 1 0

Number of input v alues

9999 100000
10000 50000 99999

Less than 1 0000 Betw een 1 0000 and 99999 More than 99999

Input v alues
 Search routine specification

procedure Search (Key : ELEM ; T: SEQ of ELEM;

Found : in out BOOLEAN; L: in out ELEM_INDEX) ;

Pre-condition
-- the sequence has at least one element
T’FIRST <= T’LAST
Post-condition
-- the element is found and is referenced by L
( Found and T (L) = Key)
or
-- the element is not in the array
( not Found and
not (exists i, T’FIRST >= i <= T’LAST, T (i) = Key ))
 Search routine –
Phân chia các miền đầu vào
• Dữ liệu vào sao cho pre-condition thỏa mãn
• Dữ liệu vào sao cho pre-condition không thỏa
mãn
• Dữ liệu vào sao cho phần tử cần tìm nằm
trong mảng
• Dữ liệu vào sao cho phần tử cần tìm không có
trong mảng
Hướng dẫn thiết kế kiểm thử với chuỗi
(sequences)
• Trường hợp kiểm thử mà chuỗi có duy nhất
một phần tử
• Các trường hợp kiểm thử khác nhau với các
kich cỡ chuỗi khác nhau
• Các trường hợp kiểm thử trong đó phần từ
đầu, giữa và cuối của chuỗi được truy nhập
• Trường hợp kiểm thử với chuỗi rỗng
 Search routine - input partitions
Sequence Element
Single value In sequence
Single value Not in sequence
More than 1 value First element in sequence
More than 1 value Last element in sequence
More than 1 value Middle element in sequence
More than 1 value Not in sequence

Input sequence (T) Key (Key) Output (Found, L)

17 17 true, 1
17 0 false, ??
17, 29, 21, 23 17 true, 1
41, 18, 9, 31, 30, 16, 45 45 true, 7
17, 18, 21, 23, 29, 41, 38 23 true, 4
21, 23, 29, 33, 38 25 false, ??
 Structural testing
• Kiểm thử hộp trắng
• Thiết kế các trường hợp kiểm thử dựa trên
cấu trúc chương trình
• Tập dượt (kiểm tra việc thực thi) tất cả các câu
lệnh của chương trình.
 Path testing
• Là một cách tiếp cận của structural testing
• Mọi đường thực hiện của chương trình được
kiểm thử ít nhất một lần
• Đồ thị luồng chương trình (program flow
graph)
– Nodes: các quyết định, rẽ nhánh
– Arcs: các luồng điều khiển.
Binary search flow graph
1

bottom > top while bottom <= top

5

elemArray [mid] != key

7 11
elemArray
elemArray [mid] > key elemArray [mid] < key
[mid] = key

8
12 13

14 10
Các đường đi trong chương trình được
kiểm thử
• 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14
• 1, 2, 3, 4, 5, 14
• 1, 2, 3, 4, 5, 6, 7, 11, 12, 5, …
• 1, 2, 3, 4, 6, 7, 2, 11, 13, 5, …
• Các ca kiểm thử nên chứa tất cả các đường đi
cần kiểm thử
• Công cụ hỗ trợ: dynamic program analyser
 Test coverage & test criteria
• Test coverage (độ bao phủ
– Node-coverage
– Arc-coverage
– Path-coverage
–…
• Test criteria (tiêu chuẩn lựa chọn ca kiểm thử)
 Test automation
Giảm chi phí kiểm thử:
•Sinh tự động các ca kiểm thử
•Sinh tự động dữ liệu kiểm thử
•Hệ thống thực hiện kiểm thử

Nguồn để sinh tự động:

-Đặc tả yêu cầu,
-Thiết kế,
-Mã nguồn,
-Tài liệu chương trình, …

Java PathFinder
 Cùng nhìn lại
• Testing có thể chỉ ra lỗi tồn tại trong hệ thông;
không thể chỉ ra rằng hệ thống không lỗi
• Unit testing, component testing, interface
testing, system testing, release testing
(acceptance tesing)
• Black-box, grey-box, white-box testing
 Cùng nhìn lại
• Đội phát triển thực hiện component testing;
system testing nên được thực hiện bởi nhóm
thành viên khác.
• Integration testing nên được thực hiện dần
từng bước; release testing là việc kiểm thử
phiển bản bàn giao cho khách hàng, có sự
tham gia của khách hàng.
 Key points
• Các kỹ thuật thiết kế ca kiểm thử:
– Equivalence partitioning
– Structural analysis (path testing)
• Test automation