Kiểm thử đơn vị cho hệ thống

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ






LUYỆN THỊ LAN HƢƠNG




KIỂM THỬ ĐƠN VỊ CHO HỆ THỐNG




LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN









Hà Nội - 2014

1

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ




LUYỆN THỊ LAN HƢƠNG




KIỂM THỬ ĐƠN VỊ CHO HỆ THỐNG


Ngành: Công nghệ thông tin
Chuyên ngành: Kỹ thuật phần mềm
Mã số: 60480103


LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

NGƢỜI HƢỚNG DẪN KHOA HỌC: TS. TRẦN THỊ MINH CHÂU





Hà Nội – 2014

2

Lời cam đoan
Tôi xin cam đoan rằng luận văn cao học này do chính tôi thực hiện. Những kết
quả được tổng hợp và nghiên cứu từ các tài liệu tham khảo sử dụng trong luận văn này
được thu thập từ các nguồn thông tin được công bố trên các sách báo, tạp chí khoa học
chuyên ngành đáng tin cậy và kiến thức, kinh nghiệm của bản thân. Tôi hoàn toàn chịu
trách nhiệm trước nhà trường về sự cam đoan này.
Hà Nội, ngày 31 tháng 10 năm 2014
Học viên


Luyện thị Lan Hương

3

Lời cảm ơn
Em xin gửi lời cảm ơn chân thành tới các thầy cô giảng viên trong bộ môn Kỹ
thuật phần mềm, khoa Công nghệ thông tin, trường Đại học Công nghệ đã tận tình
giảng dạy và truyền đạt kiến thức, kinh nghiệm cho em trong suốt thời gian em học tập
tại trường.
Em xin được gửi lời cảm ơn sâu sắc nhất tới cô giáo TS. Trần Thị Minh Châu, cô
đã luôn giúp đỡ, hướng dẫn và chỉ bảo cho em trong suốt quá trình học tập và thực
hiện đề tài luận văn.
Bên cạnh những kết quả em đạt được vẫn còn những vấn đề mà em cũng không
tránh khỏi những thiếu sót trong quá trình thực hiện luận văn, em kính mong các thầy
cô thông cảm cho em. Em mong nhận được sự góp ý, chia sẻ, đánh giá của các thầy
cô. Đó là những kinh nghiệm quý báu cho quá trình học tập và làm việc của em sau
này.

Em xin cảm ơn chân thành cảm ơn.
Hà Nội, ngày 31 tháng 10 năm 2014
Học viên


Luyện Thị Lan Hương




4

Mục lục

Lời cam đoan 2
Lời cảm ơn 3
Mục lục 4
Bảng các từ viết tắt 6
Danh mục hình vẽ 7
Danh mục bảng biểu 8
Chương 1. Giới thiệu 10
1.1 Đặt vấn đề 10
1.2 Nội dung nghiên cứu 10
1.3 Cấu trúc luận văn 11
Chương 2.Tổng quan về kiểm thử phần mềm 12
2.1 Chất lượng phần mềm 12
2.2 Kiểm thử và vai trò của kiểm thử 12
2.3 Các mục tiêu của kiểm thử 13
2.4 Các hoạt động kiểm thử 14
2.5 Các mức độ kiểm thử 14

Kiểm thử đơn vị 15
Kiểm thử tích hợp, 17
Kiểm thử hệ thống 18
Kiểm thử chấp nhận. 20
Kiểm thử hồi quy 20
Chương 3.Các kỹ thuật kiểm thử phần mềm 22
3.1 Kiểm thử hộp đen 22
3.1.1. Kỹ thuật phân lớp tương đương(Equivalence Class Testing) 22
3.1.2. Kỹ thuật phân tích giá trị biên (Boundary Value Testing) 25
3.1.3. Kỹ thuật bảng quyết định (Descision Table Testing) 29
3.2 Kiểm thử hộp trắng 31
3.2.1. Kỹ thuật dòng điều khiển (Control Flow Testing) 31
3.2.2. Kỹ thuật dòng dữ liệu (Data Flow Testing) 34

5
Chương 4.Bài toán áp dụng 37
4.1. Bài toán 1 37
4.1.1. Áp dụng kỹ thuật phân lớp tương đương 38
4.1.2. Áp dụng kỹ thuật Bảng quyết định 38
4.1.3. Áp dụng kỹ thuật kiểm thử dòng điều khiển 39
4.1.4. Áp dụng kỹ thuật kiểm thử dòng dữ liệu 45
4.1.5. Kết luận 48
4.2. Bài toán 2 51
4.2.1. Áp dụng kỹ thuật phân lớp tương đương 52
4.2.2. Áp dụng kỹ thuật bảng quyết định 54
4.2.3. Áp dụng kỹ thuật dòng điều khiển 54
4.2.4. Áp dụng kỹ thuật dòng dữ liệu 61
4.2.5. Kết luận 66
4.3. Bài toán 3 68
4.3.1. Áp dụng kỹ thuật Domain testing 69

4.3.2. Áp dụng kỹ thuật Bảng quyết định 69
4.3.3. Áp dụng kỹ thuật dòng điều khiển 74
4.3.4. Áp dụng kỹ thuật dòng dữ liệu 79
4.3.5. Kết luận 80
Chương 5.Kết luận 83
5.1. Kết quả của luận văn 83
5.2. Hướng nghiên cứu tiếp theo 83
Tài liệu tham khảo 84



6

Bảng các từ viết tắt
Viết tắt
Tên đầy đủ
Ghi chú
UT
Unit Test
Kiểm thử đơn vị
ST
System test
Kiểm thử hệ thống
AT
acceptance test
Kiểm thử chấp nhận
EP
Equivalence partitioning
Phân lớp tương đương
ĐK

Điều kiện

Eff
Effects
Hành động
CS
Checksum

CFG
Control flow graph
Đồ thị dòng điều khiển
DFG
Data flow graph
Đồ thị dòng dữ liệu
EO
Expected output
Kết quả mong đợi


7
Danh mục hình vẽ
Hình 2.1 Mô hình phát triền phầm mềm chữ V 15
Hình 2.2 Kỹ thuật bộ cuống và bộ lái trong chiến lươc tích hợp dần 18
Hình 3.1 Trực quan mô tả phân lớp tương đương. 22
Hình 3.2 Kỹ thuật kiểm thử biên mở rộng 26
Hình 3.3 Các biên kiểm thử trong trường hợp xấu nhất. 27
Hình 3.4 Kết hợp kiểm thử biên rường hợp xấu nhẩt & kiểm thử biên mở rộng. 28
Hình 3.6 So sánh các kỹ thuật kiểm thử biên. 28
Hình 3.7 Sơ đồ dòng điều khiển 32
Hình 3.8 Các ký hiệu sử dụng trong đồ thị 32

Hình 3.9 Mối quan hệ giữa các độ đo kiểm thử dòng dữ liệu. 36
Hình 4.1Sơ đồ dòng điều khiền cho bài toán 1 – mã nguồn 1 42
Hình 4.2 Sơ đồ dòng điều khiền cho bài toán 1 – mã nguồn 2 44
Hình 4.3 Sơ đồ dòng dữ liệu cho bài toán 1 – mã nguồn 1 46
Hình 4.4 Sơ đồ dòng dữ liệu cho bài toán 1 – mã nguồn 2 48
Hình 4.5 Sơ đồ dòng điều khiển cho bài toán 2 – mã nguồn 1 58
Hình 4.6 Sơ đồ dòng điều khiển cho bài toán 2 – mã nguồn 2 60
Hình 4.7 Sơ đồ dòng dữ liệu cho bài toán 2 – mã nguồn 1 63
Hình 4.8 Sơ đồ dòng dữ liệu cho bài toán 2 – mã nguồn 2 65
Hình 4.9 Sơ đồ dòng điều khiển cho bài toán 3 76
Hình 4.10 Sơ đồ dòng dữ liệu cho bài toán 3 79


8

Danh mục bảng biểu
Bảng 3.1 Cấu trúc bảng quyết định 29
Bảng 4.2 Các ca kiểm thử sinh ra theo kỹ thuật phân lớp tương đương 38
Bảng 4.3 Bảng quyết định cho bài toán 1. 39
Bảng 4.4 Các ca kiểm thử sinh ra theo kỹ thuật bảng quyết định 39
Bảng 4.5 Quy ước các điều kiện, hành động trong sơ đồ CFG của bài toán 1 41
Bảng 4.6 Các ca kiểm thử sinh ra theo kỹ thuật dòng điều khiển với mã nguồn 1 43
Bảng 4.7 Các ca kiểm thử sinh ra theo kỹ thuật dòng điều khiển với mã nguồn 2 45
Bảng 4.8 Quy ước ký hiệu của các điều kiện trong sơ đồ DFG của bài toán 1 45
Bảng 4.9 Các ca kiểm thử sinh ra theo kỹ thuật dòng dữ liệu với mã nguồn 1 47
Bảng 4.10 Các ca kiểm thử sinh ra theo kỹ thuật dòng dữ liệu với mã nguồn 2 48
Bảng 4.11 So sánh độ bao phủ của các kỹ thuật kiểm thử với mã nguồn 1 48
Bảng 4.12 So sánh độ bao phủ của các kỹ thuật kiểm thử với mã nguồn 2 49
Bảng 4.13 Thống kê số lỗi phát hiện được khi thực thi hai mã nguồn – bài toán 1 49
Bảng 4.14 Bảng hệ số tỷ lệ free float của chỉ số HNX 52

Bảng 4.15 Các ca kiểm thử sinh ra theo kỹ thuật phân lớp tương đương 53
Bảng 4.16 Các ca kiểm thử sinh ra theo kỹ thuật bảng quyết định 54
Bảng 4.17 Quy ước các điều kiện, hành động trong sơ đồ CFG của bài toán 2 – mã
nguồn 1 57
Bảng 4.18 Các ca kiểm thử sinh ra bởi kỹ thuật dòng điều khiển – mã nguồn 1 59
Bảng 4.19 Quy ước các điều kiện, hành động trong sơ đồ CFG của bài toán 2 – mã
nguồn 2 59
Bảng 4.20 Các ca kiểm thử sinh ra bởi kỹ thuật dòng điều khiển – mã nguồn 2 61
Bảng 4.21 Quy ước, ký hiệu các điều kiện của sơ đồ DFG của bài toán 2 – mã nguồn 1
61
Bảng 4.22 Quy ước, ký hiệu các điều kiện của sơ đồ DFG của bài toán 2 – mã nguồn 1
62
Bảng 4.23 Các ca kiểm thử sinh ra bởi kỹ thuật dòng dữ liệu – mã nguồn 1 63
Bảng 4.24 Quy ước, ký hiệu các điều kiện của sơ đồ DFG của bài toán 2 – mã nguồn 2
64
Bảng 4.254 Các ca kiểm thử sinh ra bởi kỹ thuật dòng dữ liệu – mã nguồn 2 66
Bảng 4.265 So sánh độ bao phủ của các kỹ thuật kiểm thử với mã nguồn 1 66
Bảng 4.27 So sánh độ bao phủ của các kỹ thuật kiểm thử với mã nguồn 2 67
Bảng 4.28 Thống kê số lỗi phát hiện được khi thực thi hai mã nguồn – bài toán 2 67
Bảng 4.29 Quy ước các điều kiện, hành động trong sơ đồ CFG của bài toán 3 75

9
Bảng 4.30 So sánh độ phủ của các kỹ thuật kiểm thử 80
Bảng 4.31 Thống kê số lỗi phát hiện được khi thực thi hai mã nguồn – bài toán 3 81

10
Chƣơng 1. Giới thiệu
Chương 1 đặt vấn đề đưa ra nội dung cần nghiên cứu, cấu trúc của luận văn.
1.1 Đặt vấn đề

Hiện nay, khi các sản phẩm phần mềm ngày càng mang lại những lợi ích quan
trọng cho cuộc sống, thì việc đánh giá, kiểm thử để chứng minh giá trị của các sản
phẩm phần mềm ngày càng trở nên quan trọng. Hầu hết các dự án phát triển phần mềm
hiện nay đều sử dụng mô hình phát triển chữ V đế tiến hành xây dựng và phát triển dự
án phần mềm. Ở mô hình này, ta có thể dễ nhận thấy vai trò quan trọng của kiểm thử,
cũng như việc xác định các chiến lược kiểm thử tương ứng với từng mức độ phát triển
trong từng giai đoạn triển khai dự án.
Trong ngành phần mềm, việc tiến hành kiểm thử đơn vị là phương pháp xác định
tính đúng đắn của một đơn vị mã nguồn đã ngày càng trở nên quan trọng. Tuy nhiên,
hầu hết các lập trình viên hiện nay đều không sử dụng một công cụ sinh ca kiểm thử tự
động nào mà vẫn viết ca kiểm thử thủ công, sau đó tiến hành chạy ca kiểm thử trong
môi trường lập trình.
Mặt khác, có rất nhiều kỹ thuật, phương pháp kiểm thử có thể áp dụng để tiến
hành kiểm thử cho đơn vị/chương trình như:
Đối với chiến lược kiểm thử dựa trên đặc tả bài toán (black box): Ta có kỹ thuật
kiểm thử sử dụng phân lớp tương đương (Equivalence class partitioning), kỹ thuật
phân tích giá trị biên (Boundary value analysis), kỹ thuật kiểm thử cặp (Pairwise
Tesing), kỹ thuật sử dụng bảng quyết định (Decision tables).
Đối với chiến lược kiểm thử cấu trúc (white box): Ta có kỹ thuật kiểm thử dòng
điều khiển (Control flow testing), kỹ thuật kiểm thử dòng dữ liệu (Data flow testing).
Vấn đề đặt ra là: Lập trình viên nên xây dựng chiến lược kiểm thử như thế nào
để việc kiểm thử đơn vị đạt được hiệu quả tốt nhất, số lượng ca kiểm thử sinh ra không
quá nhiều, mà việc hạn chế lỗi phát sinh là tốt nhất.
Từ vấn đề đặt ra đó, luận văn đã tiến hành thử nghiệm các kỹ thuật kiểm thử khác
nhau áp dụng cho bài toán thực tế trong dự án phần mềm để sinh ra các ca kiểm thử.
Từ đó, phân tích và đưa ra kết luận về chiến lược kiểm thử phù hợp sẽ áp dụng cho bài
toán/ hàm thuộc chương trình.
1.2 Nội dung nghiên cứu
Luận văn tập trung nghiên cứu và khảo sát tổng quan về kiểm thử phần mềm và
các kỹ thuật kiểm thử phần mềm. Trong đó, tìm hiểu và phân tích các kỹ thuật kiểm

thử áp dụng cho mức độ kiểm thử đơn vị, các ưu, nhược điểm của từng kỹ thuật và các
bài toán sẽ áp dụng cho từng kỹ thuật kiểm thử.
Từ những tìm hiều về các kỹ thuật kiểm thử, tiến hành áp dụng thử nghiệm các
kỹ thuật kiểm thử để sinh ca kiểm thử cho bài toán thực tế. Dựa trên các kết quả đó,
tiến hành tổng hợp phân tích để đưa ra chiến lược kiểm thử sẽ áp dụng cho hàm/ đơn

11
vị cần tiến hành kiểm thử đơn vị nhằm đảm bảo số ca kiểm thử ít nhưng độ bao phủ là
cao nhất. Đưa ra kết luận về các chiến lược kiểm thử sẽ áp dụng khi lập trình viên xây
dựng kiểm thử cho mức độ kiểm thử đơn vị.
1.3 Cấu trúc luận văn
Luận văn có cấu trúc gồm năm phần như sau:
Chương 1: Đưa ra vấn đế nghiên cứu của luận văn. Từ đó, mô tả khái quát nội
dụng nghiên cứu của luận văn.
Chương 2: Trình bày kiến thức tổng quan về kiểm thử phần mềm.
Chương 3: Trình bày các kỹ thuật kiểm thử phần mềm áp dụng cho mức độ kiểm
thử đơn vị.
Chương 4: Đưa bài toán thực tế, tiến hành phân tích, đánh giá, nhận xét và đưa ra
chiến lược kiểm thử áp dụng cho bài toán.
Chương 5: Kết luận đưa ra kết quả đạt được của luận văn và hướng nghiên cứu
tiếp theo của luận văn .


12
Chƣơng 2.Tổng quan về kiểm thử phần mềm
Chương 2 trình bày tổng quan về kiểm thử phần mềm.
2.1 Chất lƣợng phần mềm
Chất lượng của phần mềm được nhìn theo những hướng khách nhau, khi đứng ở
những vai trò khác nhau. Theo [2] thì chất lượng phần mềm được đánh giá theo năm
góc nhìn như sau:

1. Góc nhìn tiên nhiệm (Transcendental View): Chất lượng là một thứ gì đó dễ
dàng thừa nhận qua kinh nghiệm, nhưng khó được định nghĩa. Góc nhìn tiên
nhiệm không đặc tả riêng rẽ được chất lượng phần mềm, nhờ vào kinh nghiệm
người ta có thể đưa ra chất lượng phần mềm là tốt và dễ được công nhận.
2. Góc nhìn người dùng (User View): Chất lượng liên quan đến mức độ mà sản
phẩm đáp ứng được nhu cầu, kỳ vọng của người dung, phù hợp cho việc sử
dụng. Quan điểm này đánh giá cao cá nhân. Một sản phẩm được coi là chất
lượng tốt nếu có đủ một số lượng lớn người dùng. Quan điểm này rất hữu ích để
xác định các thuộc tính sản phẩm mà người dùng cho là quan trọng bao gồm
nhiều yêu tố như khả năng sử dụng, độ tin cậy và hiệu quả.
3. Góc nhìn sản xuất (Manufacturing View): Ý tưởng chính của quan điểm này là
sự đáp ứng được đặc tả yêu cầu. Chất lượng ở mức độ sản phẩm được xác định
bởi việc là sản phẩm có gặp được đặc tả của nó hay không. Bất kỳ một sai lệch
nào với yêu cầu đặc tả cũng làm giảm chất lượng sản phẩm. Việc phù hợp với
yêu cầu dẫn đến sự thống nhất của sản phẩm.
4. Góc nhìn sản phẩm (Product View): Giả thuyết đặt ra là:”Nếu một sản phẩm
được sản xuất với tính chất nội bộ tốt, thì nó sẽ có các thuộc tính bên ngoài tốt”.
Người ta có thể khám phá những mối quan hệ nhân quả giữa các thuộc tính nội
bộ và chất lượng bên ngoài. Trong trường hợp này, chất lượng được xem như là
một đặc tính vốn có của sản phẩm.
5. Góc nhìn dựa vào giá trị (Value-Based View): Chất lượng, theo góc nhìn này
phụ thuộc vào tổng giá trị mà khách hàng vui lòng trả cho nó. Chất lượng là vô
nghĩa nếu một sản phẩm không có ý nghĩa kinh tế.
Trong tài liệu về tiêu chuẩn ISO 9126 thì chất lượng phần mềm được định nghĩa
trên sáu thuộc tính là: tính năng, tính đáp ứng, tính dễ dùng, tính hiệu quả, tính có thể
bảo trì được và tính khả chuyển.
2.2 Kiểm thử và vai trò của kiểm thử
Kiểm thử phần mềm đóng một vai trò quan trọng trong việc đảm bảo sự thành
công của một sản phẩm phần mềm. Theo tài liệu [2], đảm bảo chất lượng của một sản
phẩm phần mềm là cả quá trình cải tiến phầm mềm thông qua việc lặp đi lặp lại quá

trình kiểm thử - tìm lỗi – sửa lỗi trong suốt quá trình phát triển phần mềm. Ứng với
từng giai đoạn khác nhau trong quá trình phát triển phần mềm, phải có sự đánh giá

13
hoạt động cách hệ thống có thể hoạt động đúng khi thực hiện kiểm thử ở mức hệ thống
trước khi bàn giao sản phẩm. Theo Friedman và Voas đã mô tả thì kiểm thử phần mềm
là một quá trình thẩm định cho việc đánh giá và cải thiện chất lượng phần mềm.
Thông thường, các hoạt động đánh giá phần mềm được chia làm hai loại:
 Phân tích tĩnh (static analysis): Là việc đánh giá chương trình mà không cần
thực thi trên các mã lệnh của chương trình, nó có thể là các hoạt động xem xét
(review) lại các tài liệu đặc tả, tài liệu thiết kế, tài liệu ca kiểm thử, hoặc là
thanh tra mã nguồn (code inspection), .v.v.
 Phân tích động (dynamic analysis): Là việc đánh giá chương trình mà cần thực
thi trên các mã lệnh của chương trình, trong đó có kỹ thuật kiểm thử hộp đen và
hộp trắng.
Bằng việc thực hiện phân tích tĩnh và phân tích động thì người kiểm thử viên
mong muốn tìm được nhiều lỗi nhất có thể, và đảm bảo các lỗi phát hiện sẽ được sửa
trong các giai đoạn sớm của quy trình phát triển phần mềm.
Xác minh (Verification) và thẩm định (Validation) là hai công việc xuyên suốt
trong quá trình phát triển phần mềm ngay từ giai đoạn phân tích thiết kế phần mềm.
Xác minh là việc kiểm tra xem phần mềm có gặp được yêu cầu đặc tả của hệ
thống không? Nó trả lời cho câu hỏi “Hệ thống đã được xây dựng đúng theo tài liệu
đặc tả hay chưa?”, mục tiêu của viêc xác minh là phát hiện các lỗi lập trình.
Thẩm định là sự kiểm tra xem phần mềm có thỏa mãn yêu cầu của người sử dụng
không? Việc thẩm định chú trọng vào sản phẩm cuối cùng khi bàn giao cho khách
hàng, mục tiêu là phát hiện các lỗi về thiết kế, về đặc tả. Một hệ thống xây dựng đúng
đặc tả, nhưng chưa chắc đã đáp ứng được yêu cầu của khách hàng, vì đặc tả có thể sai,
thiết kế có thể thiếu chi tiết, và quá trình sử dụng không thuận tiện cho khách hàng
2.3 Các mục tiêu của kiểm thử
Theo tài liệu [6], các bên liên quan trong quy trình phát triển phần mềm sẽ bao

gồm: lập trình viên, kiểm thử viên, quản trị dự án và khách hàng. Mỗi đối tượng này
đều có những cái nhìn khác nhau về mục tiêu của kiểm thử như sau:
 Chƣơng trình hoạt động đƣợc: Các lập trình viên thường chỉ quan tâm đến
việc làm thế nào để chương trình hoạt động được trong các điều kiện thông
thường.
 Chƣơng trình không hoạt động đƣợc: Lập trình viên ít khi quan tâm đến
vấn đề khác của chương trình là khi nào thì chương trình không hoạt động
được, làm thế nào khi chương trình bị lỗi.
 Giảm rủi ro của lỗi:Nhà quản trị phần mềm thường quan tâm đến khía cạnh
là giảm rủi ro của lỗi gây ra. Hầu hết các hệ thống phần mềm phức tạp đều
chứa lỗi - là nguyên nhân hệ thống thất bại. Bởi vậy nếu các lỗi được phát
hiện và sửa trong khi thực hiện kiểm thử, tỷ lệ hệ thống gặp rủi ro sẽ giảm.

14
 Giảm chi phí của việc kiểm thử: Chi phí cho việc kiểm thử bao gồm chi phí
thiết kế, bảo trì và thực thi các ca kiểm thử; chi phí phần tích kết quả thực
hiện của mỗi ca kiểm thử; chi phí tài liệu hóa các ca kiểm thử và chi phí cho
hệ thống hoạt động và tài liệu hóa các hoạt động đó. Khách hàng thường
mong muốn là giảm các chi phí của việc kiểm thử nhưng vẫn đảm bảo chất
lượng.
Mục tiêu chính của kiểm thử là có thể giám chi phí của việc kiểm thử bằng cách
thiết kế các bộ ca kiểm thử hiệu quả bao phủ vùng kiểm thử tốt với số lượng ca kiểm
thử ít hơn nhưng chất lượng vẫn được đảm bảo.
2.4 Các hoạt động kiểm thử
Theo [2], để kiểm thử một chương trình phần mềm kỹ sư kiểm thử phải thực hiện
một chuỗi các hoạt động như sau:
 Xác định đối tượng cần kiểm thử: Đối tượng được xác định là mục đích để
thiết kế một hay nhiều ca kiểm thử đảm bảo chương trình thỏa mãn đối tượng
đó. Một đối tượng rõ ràng sẽ kết nối tới một ca kiểm thử.
 Lựa chọn các giá trị đầu vào: Việc lựa chọn này dựa vào đặc tả yêu cầu, mã

nguồn hoặc mong muốn của chúng ta.
 Tính toán giá trị đầu ra mong muốn: Tức là ứng với các giái trị đầu vào, cần
tính toán giá trị đầu ra mong muốn của chương trình .
 Thiết lập môi trường kiểm thử của chương trình: Chuẩn bị môi trường kiểm
thử của chương trình, ở bước này tất cả các giả định ngoài của chương trình
phải được thỏa mãn. Ví dụ: các hệ thống mạng, các cơ sở dữ liệu cần được
thiết lập một cách đúng đắn, máy tương tác.
 Tiến hành kiểm thử chương trình: Kỹ sư kiểm thử thực hiện chương trình với
các tập giá trị đầu vào và quan sát giá trị đầu ra thực tế của chương trình. Để
thực hiện một ca kiểm thử, các giá trị đầu vào phải được cung cấp cho
chương trình ở các thời điểm khác nhau.
 Phân tích kết quả kiểm thử: Phân tích các kết quả kiểm thử để so sánh kết
quả đầu ra thực tế với kết quả đầu ra mong muốn. Độ phức tạp của phép so
sánh này phụ thuộc vào độ phức tạp của dữ liệu quan sát. Cuối cùng là đưa ra
quyết định về kết quả hoạt động của chương trình là thỏa mãn (pass), không
thoải mãn (fail) yêu cầu của người dùng hay không đưa ra được quyết định.
2.5 Các mức độ kiểm thử
Theo mô hình phát triền phần mềm chữ V thì kiểm thử phần mềm là một chuỗi
các hoạt động tiến hình song song cùng hoạt động phát triển phần mềm, từ lập kế
hoạch và kiểm soát quá trình kiểm thử, phân tích yêu cầu và thiết kế ca kiểm thử, viết
ca kiểm thử,tiến hành kiểm thử phần mềm, đánh giá các kết quả kiểm thử, báo cáo và
tổng hợp các hoạt động kết thúc quá trình kiểm thử. Chúng ta có thể nhìn thấy rõ mối

15
liên hệ giữa hoạt động phát triền phần mềm (lập trình) và hoạt động kiểm thử phần
mềm (kiểm thử) theo hình 2.1.

Hình 2.1 Mô hình phát triền phầm mềm chữ V
Theo mô hình này, các hoạt động kiểm thử phần mềm bao gồm:
1. Kiểm thử đơn vị,

2. Kiểm thử tích hợp,
3. Kiểm thử hệ thống ,
4. Kiểm thử chấp nhận.
Mỗi hoạt động này tương ứng với các pha trong phát triển phần mềm từ đặc tả yêu
cầu của khách hàng đến hoạt động lập trình.
2.5.1. Kiểm thử đơn vị
Theo [2], đơn vị (unit) là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm
thử được như hàm, thủ tục, lớp hay phương thức đều có thể được xem là đơn vị. Các
thành phần đơn vị này sẽ được kiểm thử tại cấp độ kiểm thử mức đơn vị trong quy
trình kiểm thử phần mềm.
Kiểm thử đơn vị hay còn gọi là unit testing (UT), là cấp độ kiểm thử cho phép
kiểm tra, tìm kiếm lỗi bên trong chức năng của chương trình phần mềm (ví dụ module,
đối tượng, lớp ). Việc kiểm thử module ở mức đơn vị thường sẽ do lập trình viên thực
hiện trước khi nó được chuyển giao sang giai đoạn tích hợp với các module khác.
Công đoạn này cần được thực hiện sớm nhất trong giai đoạn viết mã nguồn và xuyên
suốt chu kỳ phát triển phần mềm.

16
Trước khi thực hiện UT, kiểm thử viên nên xác định các tiêu chí cũng như các
đối tượng sẽ được kiểm thử trong giai đoạn này một cách rõ ràng. Trong thực tế, UT
nên kiểm tra được các đối tượng sau.
 Kiểm tra, xác minh hoạt động của các tham số với giá trị bình thường
(norm).
 Kiểm tra, xác minh hoạt động của các tham số với giá trị biên.
 Kiểm tra, xác minh hoạt động của các tham số với giá trị không nằm trong
miền giới hạn (abnormal).
 Kiểm tra sự hoạt động của các vòng lặp.
 Kiểm tra sự hoạt động của các hàm đệ quy.
 Kiểm tra sự truy cập cấu trúc dữ liệu/truy cập file.
 Đảm bảo rằng tất các các câu lệnh, các nhánh lệnh được thực thi đúng.

Vì đơn vị được chọn để kiểm tra thường có kích thước nhỏ và chức năng hoạt
động đơn giản, chúng ta không khó khăn gì trong việc tổ chức kiểm thử, ghi nhận và
phân tích kết quả kiểm thử. Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục
cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn thể đang được kiểm tra.
Thực tế cho thấy thời gian tốn cho hoạt động kiểm thử đơn vị sẽ được đền bù bằng
việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm thử và sửa lỗi ở các mức
kiểm thử sau đó.
Thông thường, kiểm thử đơn vị đòi hỏi kiểm thử viên có kiến thức về thiết kế và
mã nguồn của chương trình. Mục đích của UT là đảm bảo thông tin được xử lý và xuất
khỏi đơn vị là chính xác trong mối tương quan với dữ liệu nhập và chức năng của đơn
vị đó. Điều này thường đòi hỏi tất cả các nhánh bên trong thành phần đơn vị đều phải
được kiểm tra để phát hiện nhánh phát sinh lỗi. Một nhánh thường là một chuỗi các
lệnh được thực thi trong một đơn vị. Thực tế, việc chọn lựa các nhánh để đơn giản hóa
quá trình kiểm thử và quét hết thành phần đòi hỏi kiểm thử viên phải có kỹ thuật, đôi
khi phải dùng thuật toán để chọn lựa.
Cùng với các mức độ kiểm thử khác, kiểm thử đơn vị cũng đòi hỏi phải chuẩn bị
trước các ca kiểm thử hoặc kịch bản kiểm thử, trong đó chỉ định rõ dữ liệu đầu vào,
các bước thực hiện và dữ liệu đầu ra mong muốn. Các ca kiểm thử và kịch bản kiểm
thử này nên được giữ lại để tái sử dụng.
Thực tế đã chứng minh rằng, với kiểm thử mức đơn vị, chúng ta có thể thực thi
việc kiểm thử với sự hỗ trợ của các công cụ phát triển như framework hoặc công cụ
gỡ lỗi (debugging tool) [8]. Thông thường, số lượng lỗi tìm ra ở giai đoạn kiểm thử
mức đơn vị có thể chiếm hơn 25% tổng số lượng lỗi của toàn bộ dự án.Kiểm thử tích
hợp được thực hiện bởi các kỹ sư lập trình và kỹ sư kiểm thử phần mềm nhằm đảm
bảo rằng chương trình có thể hoạt động đúng khi tích hợp các đơn vị lại với nhau.
Kiểm thử tích hợp tương đương với việc kiểm tra thiết kế chi tiết, xem chương trình có
thoả mãn thiết kế chi tiết hay không.

17
2.5.2. Kiểm thử tích hợp,

Kiểm thử tích hợp - intergration test là việc kết hợp các thành phần của một ứng
dụng lại với nhau như một ứng dụng hoàn chỉnh và tiến hành kiểm thử chúng. Nếu
như kiểm thử đơn vị kiểm tra các thành phần và đơn vị riêng lẻ thì kiểm thử tích hợp
lại kết hợp chúng lại với nhau và kiểm tra sự giao tiếp và tương tác giữa chúng. Kiểm
thử tích hợp là giai đoạn tiếp theo của kiểm thử đơn vị được thực hiện bởi nhóm kiểm
thử viên và tập trung vào việc tích hợp các thành phần đơn vị của hệ thống [2]. Trước
khi thực thi kiểm thử tích hợp chúng ta phải đảm bảo rằng các thành phần đơn vị đã
thực hiện UT thành công.
Mục tiêu chính của kiểm thử tích hợp là phát hiện lỗi giao tiếp xảy ra giữa các
đơn vị, tích hợp các thành phần đơn vị đơn lẻ thành các hệ thống nhỏ và cuối cùng là
tích hợp thành một hệ thống hoàn chỉnh chuẩn bị cho kiểm thử ở mức hệ thống. Có
một số phép kiểm thử đơn giản trên giao tiếp giữa đơn vị với các thành phần liên quan
khác, tuy nhiên mọi giao tiếp liên quan đến thành phần đơn vị chỉ thật sự được kiểm
tra đầy đủ khi các đơn vị này được tích hợp với nhau trong khi thực hiện kiểm thử tích
hợp.
Trừ một số ít trường hợp ngoại lệ, còn lại kiểm thử tích hợp chỉ nên thực hiện
trên những đơn vị đã được kiểm tra cẩn thận trước đó bằng kiểm thử đơn vị trước đó
và được đảm bảo rằng tất cả các lỗi mức đơn vị đã được sửa chữa. Trên thực tế việc
tích hợp giữa các đơn vị dẫn đến những tình huống hoàn toàn khác do đó việc kiểm
thử từng đơn vị là chưa đủ. Một chiến lược cần quan tâm trong kiểm thử tích hợp là
nên tích hợp dần từng đơn vị. Một thành phần đơn vị tại một thời điểm được tích hợp
vào một nhóm các đơn vị khác đã tích hợp trước đó và đã hoàn tất các đợt kiểm thử
tích hợp trước đó. Lúc này, ta chỉ cần kiểm thử giao tiếp của đơn vị mới thêm vào với
hệ thống các đơn vị đã tích hợp trước đó, điều này sẽ làm cho số lượng ca kiểm thử
giảm đi rất nhiều, và sai sót sẽ giảm đáng kể. Trong kiểm thử ở mức tích hợp, có hai
chiến lược cơ bản là kiểm thử từ dưới lên và kiểm thử từ trên xuống.
1. Kiểm thử từ dưới lên (bottom up testing) là quá trình tích hợp và kiểm thử
các module ở 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 module ở tầng dưới cùng mà nhóm các module 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 .

Ưu điểm: Chiến lược kiểm thử từ dưới lên sẽ giúp cho kiểm thử viên tránh được
việc phải tạo ra các bộ giả lập đầu vào phức tạp hay tạo các kết quả nhân tạo để thực
hiện kiểm thử và thuận tiện cho việc phát triển các module thứ cấp dùng lại được.
Nhược điểm: Phát hiện chậm các lỗi thiết kế và chậm trễ trong việc có được phiên
bản thực thi của hệ thống.
2. Kiểm thử từ trên xuống (top down testing) là quá trình tiến hành kiểm
thử các module ở mức cao trước, các module ở mức thấp được tạm thời phát triển với
các chức năng hạn chế. Thông thường để sớm có một phiên bản phần mềm để thực

18
hiện người ta thường tiến hành tích hợp theo một nhánh cho đến các module cấp thấp
nhất.
Ưu điểm: Giúp cho người phát triển phát hiện sớm các lỗi thiết kế và có phiên bản
thực thi hoạt động sớm.
Nhược điểm: Phương pháp này tồn tại hạn chế là khó có thể mô phỏng được các
chức năng của module cấp thấp phức tạp. Ngoài ra, chúng ta không kiểm thử được đầy
đủ các chức năng của hệ thống.
Hai phương pháp được sử dụng trong kiểm thử tích hợp là kiểm thử hộp trắng
(để kiểm thử cấu trúc) và kiểm thử hộp đen (kiểm thử chức năng). Ngoài ra, khi tiến
hành hành tích hợp cần phải sử dụng kỹ thuật bộ cuống và bộ lái để thay thế cho
những mô đun còn thiếu mà cần thiết cho phần hệ thống được kiểm thử (xem hình 2.2)

Hình 2.2 Kỹ thuật bộ cuống và bộ lái trong chiến lƣơc tích hợp dần
Một yêu cầu đặt ra không thể bỏ qua khi kiểm thử tích hợp là phải tiến hành kiểm
thử hồi quy mỗi khi tích hợp thêm mô đun mới hay sửa đổi một mô đun trong số các ô
đun đã kiểm thử.
2.5.3. Kiểm thử hệ thống
Kiểm thử hệ thống (ST) là cấp độ thực hiện việc kiểm thử toàn bộ các chức năng
của hệ thống có phù hợp với yêu cầu đặc tả hay không. Kiểm thử hệ thống được thực
hiện sau khi giai đoạn kiểm thử đơn vị và kiểm thử tích hợp đã được thực hiện thành

công cho tất cả các module. Thông thường loại kiểm thử này tốn rất nhiều công sức và
thời gian. Trong nhiều trường hợp, việc kiểm thử đòi hỏi một số thiết bị hỗ trợ, phần
mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân
bố, hoặc hệ thống nhúng.
Ở mức độ hệ thống, người kiểm thử cũng tìm kiếm các lỗi, nhưng trọng tâm là
đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất
lượng của toàn bộ hệ thống.
Điểm khác nhau giữa kiểm thử tích hợp và kiểm thử hệ thống là kiểm thử hệ
thống chú trọng các hành vi và lỗi trên toàn hệ thống, còn kiểm thử tích hợp chú trọng

19
sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau. Thông
thường ta phải thực hiện kiểm thử đơn vị và kiểm thử tích hợp để đảm bảo mọi thành
phần đơn vị và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện kiểm
thử hệ thống. Sau khi hoàn thành giai đoạn kiểm thử tích hợp thì một hệ thống phần
mềm được hình thành cùng với các thành phần đã được kiểm tra đầy đủ. Tại thời điểm
này, lập trình viên hoặc kiểm thử viên bắt đầu kiểm thử phần mềm như một hệ thống
hoàn chỉnh.
Việc lập kế hoạch cho kiểm thử hệ thống nên bắt đầu từ giai đoạn hình thành và
phân tích các yêu cầu. Kiểm thử hệ thống làm nhiệm vụ kiểm tra các hành vi chức
năng của phần mềm và các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử
dụng, hiệu năng và bảo mật. Mức kiểm thử này đặc biệt thích hợp cho việc phát hiện
lỗi giao tiếp với phần mềm hoặc phần cứng bên ngoài, chẳng hạn các lỗi “tắc nghẽn”
(deadlock) hoặc chiếm dụng bộ nhớ. Sau giai đoạn ST, phần mềm thường đã sẵn sàng
cho khách hàng hoặc người dùng cuối cùng kiểm thử chấp nhận sản phẩm (Acceptance
test) hoặc dùng thử ( Alpha/Beta Test).
Kiểm thử hệ thống đòi hỏi nhiều công sức, thời gian, tính chính xác và khách
quan nên cấp độ kiểm thử này thường được thực hiện bởi một nhóm kiểm thử viên
hoàn toàn độc lập với nhóm phát triển dự án. Mặt khác kiểm thử hệ thống lại gồm
nhiều loại kiểm thử khác nhau, phổ biến nhất gồm kiểm thử chức năng (Function test),

kiểm thử hiệu năng (Performance test), kiểm thử khả năng chịu tải (Stress test hay
Load test), kiểm thử bảo mật (Security test), kiểm thử khả năng phục hồi (Recovery
test) và kiểm thử cấu hình (Configuration test).
− Kiểm thử chức năng: Bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu
thiết kế.
− Kiểm thử khả năng vận hành: Bảo đảm tối ưu việc phân bổ tài nguyên hệ thống
(ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy
vấn
− Kiểm thử khả năng chịu tải: Bảo đảm hệ thống vận hành đúng dưới áp lực cao (ví
dụ nhiều người truy xuất cùng lúc). Kiểm thử khả năng chịu tải tập trung vào các
trạng thái tới hạn, các "điểm chết", các tình huống bất thường
− Kiểm thử cấu hình: Kiểm tra sự cấu thành của hệ thống từ các thành phần dự
kiến.
− Kiểm thử khả năng an toàn và bảo mật: Bảo đảm tính toàn vẹn, bảo mật của dữ
liệu và chương trình của hệ thống khi có sự xâm nhập và tấn công từ bên ngoài
− Kiểm thử khả năng phục hồi: Bảo đảm hệ thống có khả năng khôi phục trạng thái
ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt quan
trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến.

20
Trên thực tế không nhất thiết phải thực hiện tất cả các loại kiểm thử nêu trên mà
tùy vào yêu cầu và đặc trưng của từng hệ thống, tuỳ khả năng và thời gian cho phép
của dự án, khi lập kế hoạch, trưởng dự án sẽ quyết định áp dụng những loại kiểm thử
nào.
Các ca kiểm thử trong kiểm thử hệ thống được xây dựng để xác minh các ứng
dụng có phù hợp với yêu cầu được đưa ra trong tài liệu đặc tả hệ thống hay không. Các
ca kiểm thử cần phải được viết đủ chi tiết cho các hành vi hoặc chức năng được kiểm
thử, các thông tin bắt buộc cần có trong ca kiểm thử bao gồm: mục đích của ca kiểm
thử, môi trường thực thi kiểm thử, các bước chi tiết để tiến hành kiểm thử, dữ liệu đầu
vào, dữ liệu đầu ra mong đợi.

2.5.4. Kiểm thử chấp nhận.
Thông thường sau giai đoạn kiểm thử hệ thống là giai đoạn kiểm thử chấp nhận
sản phẩm - acceptance test (AT), được khách hàng thực hiện hoặc ủy quyền cho một
nhóm thứ ba kiểm thử. Mục đích của AT là để chứng minh phần mềm thỏa mãn tất cả
các yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm.
Đối với những sản phẩm bán rộng rãi trên thị trường cho nhiều người sử dụng,
thông thường sẽ thông qua hai loại kiểm thử gọi là kiểm thử Alpha – Alpha test và
kiểm thử Beta – Beta test.
Với Alpha test, người dùng kiểm thử phần mềm ngay tại nơi phát triển phần
mềm và trong môi trường được quản lý, lập trình viên sẽ ghi nhận các lỗi hoặc phản
hồi của khách hàng và lên kế hoạch sửa chữa.
Với Beta test, phần mềm sẽ được gửi tới cho người dùng để kiểm thử ngay trong
môi trường thực, lỗi hoặc phản hồi cũng sẽ được gửi ngược lại cho lập trình viên để
sửa chữa.
Nếu khách hàng không quan tâm và không tham gia vào quá trình phát triển phần
mềm thì kết quả AT sẽ sai lệch rất lớn, mặc dù phần mềm đã trải qua tất cả các kiểm
thử trước đó. Sự sai lệch này liên quan đến việc hiểu sai yêu cầu cũng như sự mong
đợi của khách hàng. Ví dụ, một phần mềm xuất sắc vượt qua các phép kiểm thử về
chức năng được thực hiện bởi nhóm phát triển dự án, nhưng khách hàng khi kiểm thử
sau cùng vẫn thất vọng vì bố cục màn hình nghèo nàn, thao tác không tự nhiên, không
theo tập quán sử dụng của khách hàng, của người sử dụng thì phần mềm đó cũng
không được coi là hoàn hảo.
Gắn liền với giai đoạn kiểm thử chấp nhận thường là một nhóm những dịch vụ
và tài liệu đi kèm như tài liệu hướng dẫn cài đặt, tài liệu hướng dẫn sử dụng, Tất cả
tài liệu đi kèm phải được cập nhật và kiểm thử chặt chẽ.
2.5.5. Kiểm thử hồi quy
Kiểm thử hồi quy không phải là một mức kiểm thử thuộc mô hình, như các mức
độ kiểm thử đã nêu ở trên mà là kiểm thử lại phần mềm sau khi có một sự thay đổi nào
đó xảy ra, để bảo đảm phiên bản phần mềm sau thay đổi thực hiện tốt các chức năng

21
như phiên bản cũ và sự thay đổi không gây ra lỗi mới trên những chức năng vốn đã
làm việc tốt. Kiểm thử hồi quy có thể thực hiện tại mọi mức kiểm tra, đặc biệt trong
kiểm thử tích hợp.
Mặc dù không phải là một mức kiểm thử nhưng kiểm thử hồi quy là một trong
những loại kiểm thử tốn nhiều thời gian và công sức nhất. Do đó, việc bỏ qua kiểm thử
hồi quy là "không nên" vì có thể dẫn đến tình trạng phát sinh hoặc tái xuất hiện những
lỗi nghiêm trọng, mặc dù ta "tưởng rằng" những lỗi đó hoặc không có hoặc đã được
kiểm thử và sửa chữa.

22
Chƣơng 3.Các kỹ thuật kiểm thử phần mềm
Chương 3 trình bày các kỹ thuật kiểm thử phần mềm được áp dụng cho mức độ
kiểm thử đơn vị.
Trong kiểm thử phần mềm, chúng ta thường dùng hai phương pháp chính là kiểm
thử tĩnh (static testing) và kiểm thử động (dynamic testing). Kiểm thử động bao gồm
các chiến lược: kiểm thử hộp đen (black box testing) và kiểm thử hộp trắng (white box
testing).
3.1 Kiểm thử hộp đen
Kiểm thử hộp đen là một chiến lược kiểm thử quan trọng trong hoạt động kiểm
thử phần mềm, khái niệm “hộp đen” ở đây là chỉ việc kiểm thử viên không biết
chương trình bên trong được cài đặt như thế nào, họ chỉ biết rằng nó phải làm gì, và
làm như thế nào để thỏa mãn các yêu cầu đặc tả - đã được cụ thể hóa thành các ca
kiểm thử. Một số kỹ thuật được áp dụng trong chiến lược kiểm thử hộp đen: Kỹ thuật
phân lớp tương đương (Equivalence partitioning), kỹ thuật phân tích giá trị biên
(Boundary value analysis), kỹ thuật dùng bảng quyết định (Decision table), kỹ thuật
dùng bảng chuyển trạng thái (State transition) và kỹ thuật kiểm thử ca sử dụng (Use
case testing).
3.1.1. Kỹ thuật phân lớp tương đương(Equivalence Class Testing)
Phân lớp tương đương là một kỹ thuật kiểm thử hộp đen dựa trên tài liệu đặc tả
của hệ thống. Kỹ thuật phân lớp tương đương chia miền dữ liệu vào thành các lớp dữ
liệu con thỏa mãn điều kiện các giá trị thuộc một miền sẽ có sự tương tác là như nhau,
tức là cùng một kết quả trả ra từ đó suy dẫn ra các ca kiểm thử. Kỹ thuật này nhằm xác
định ra một ca kiểm thử mà làm phát hiện ra một lớp lỗi, do đó giảm tổng số các ca
kiểm thử phải được xây dựng [4].

Hình 3.1 Trực quan mô tả phân lớp tƣơng đƣơng.
Thiết kế các ca kiểm thử cho phân lớp tương đương dựa trên việc đánh giá của
các lớp tương đương cho một điều kiện đầu vào. Lớp tương đương đại diện cho tập các

23
trạng thái hợp lệ hay không hợp lệ đối với điều kiện đầu vào. Trong phân lớp tương
đương dữ liệu được phân thành một trong hai lớp sau: Lớp tương đương hợp lệ (là lớp
chứa dữ liệu nằm trong miền giá trị hợp lệ) và lớp tương đương không hợp lệ (là lớp
chứa dữ liệu nằm trong miền giá trị không hợp lệ).
Thiết kế Test-case bằng phân lớp tương đương tiến hành theo hai bước:
(1). Xác định các lớp tương đương và
(2). Xác định các ca kiểm thử.
(1)Xác định các lớp tương đương
Theo [9], lớp tương đương có thể được xác định dựa theo các yếu tố sau:
 Nếu điều kiện đầu vào xác định một miền giới hạn [a,b] thì một lớp tương
đương hợp lệ (lớp này bao gồm các giá trị a < X <b) và hai lớp tương đương
không hợp lệ (một lớp chứa các giá trị X < a và một lớp chứa các giá trị
X>b) được xác định.
 Nếu điều kiện đầu vào yêu cầu những giá trị xác định {M
1
}, {M
2
}, {M
3
},
{M
4
}, …{M
n
} thì một lớp tương đương hợp lệ (lớp này chứa các giá trị xác

định {M
1
, M
2
, M
3
, M
4
, …, M
n
}) và một lớp tương đương không hợp lệ( lớp
này chứa các giá trị nằm ngoài {M
1
, M
2
, M
3
, M
4
, …, M
n
}) được xác định.
 Nếu điều kiện đầu vào xác định cho từng giá trị riêng lẻ thì xác định một lớp
cho từng giá trị đầu vào hợp lệ
 Nếu điều kiện đầu vào xác định số lượng của giá trị hợp lệ (Ví dụ là n) thì
xác định một lớp tương đương cho số lượng giá trị hợp lệ và hai lớp tương
đương cho giá trị không hợp lệ - một là 0, một là nhiều hơn n giá trị
 Nếu một điều kiện đầu vào phải là một giá trị thì một lớp tương đương hợp lệ
(là giá trị đó) và một lớp tương đương (không là giá trị đó) không hợp lệ
được xác định.

(2) Xác định các ca kiểm thử
Với các lớp tương đương xác định được ở bước trên, bước thứ hai là sử dụng các
lớp tương đương đó để xác định các ca kiểm thử. Quá trình này như sau [2]:
1. Gán một số duy nhất cho mỗi lớp tương đương.
2. Với mỗi lớp tương đương bao gồm các giá trị hợp lệ chưa được bao phủ bởi
các ca kiểm thử trên thì viết một ca kiểm thử mới bao phủ được nhiều nhất có
thể các lớp tương đương.

24
3. Với mỗi lớp tương đương bao gồm các giá trị không hợp được bao phủ hết
bởi các ca kiểm thử trên thì ta viết một ca kiểm thử mà bao phủ một và chỉ
một trong các lớp tương đương chưa được bao phủ.
Kỹ thuật theo kiểm thử phân lớp tương đương bao gồm ba kỹ thuật: Phân lớp
tương đương yếu, phân lớp tương đương mạnh và phân lớp tương đương truyền thống.
Phân lớp tương đương yếu là kỹ thuật dựa trên nguyên tắc chung của phân lớp
tương đương tức là chia miền dữ liệu đầu vào thành các lớp con tương đương. Việc
sinh ca kiểm thử trong phân lớp tương đương yếu phải đảm bảo mỗi lớp con được
kiểm tra ít nhất một lần. Do đó, số trường hợp kiểm thử trong kỹ thuật phân lớp tương
đương yếu bằng giá trị lớn nhấy của số phân hoạch biến đầu vào hay chính là lực
lượng lớn nhất của phân hoạch.
Phân lớp tương đương mạnh được tiến hành sau khi phân hoạch miền giá trị của
các biến đầu vào thành các lớp tương đương, ta sẽ sinh trường hợp kiểm thử theo
nguyên tắc mỗi ca kiểm thử là một phần tử tích đề các của các phân hoạch con đó. Vì
vậy, số ca kiểm thử sinh ra chính là số phần từ của tích đề các này.
Phân lớp tương đương truyền thống là kỹ thuật đơn giản nhất trong các kỹ thuật
kiểm thử theo phân lớp tương đương. Với kỹ thuật này thì việc phân lớp tương đương
cho các biến giá trị đầu vào chỉ cần quan tâm hai lớp sau:
 Lớp tương đương hợp lệ: Chứa dữ liệu của biến đầu vào nằm trong miền hợp lệ.
 Lớp tương đương không hợp lệ: Chứa dữ liệu của biến đầu vào nằm trong miền
không hợp lê.

Ý tưởng của việc sinh ca kiểm thử cho kỹ thuật này thực hiện theo nguyên tắc:
Khi chúng ta xây dựng ca kiểm thử cho trường hợp đúng thì chỉ cần lấy các giá trị biến
đầu vào nằm trong miền hợp lệ. Tức là ca kiểm thử sinh ra với điều kiện giá trị đầu
vào của tất cả các biến đều nằm trong miền hợp lệ. Khi tạo ca kiểm thử cho trường hợp
sai thì chỉ cần lấy một trong các biến đầu vào có giá trị không nằm trong miền hợp lệ.
Tức là với các biến đầu vào không hợp lệ, mỗi ca kiểm thử sẽ bao gồm một biến đầu
vào có giá trị nằm trong miền không hợp lệ và các biến còn lại có giá trị nằm trong
miền hợp lệ.
Nhận xét:
Ƣu điểm: Phân lớp tương đương (EP) phù hợp với hầu hết các hệ thống có miền
giá trị đầu vào của các biến cần được chia thành nhiều phân vùng, tập con. EP có thể
áp dụng tương tự cho các cấp độ kiểm thử mức đơn vị, kiểm thử tích hợp và kiểm thử
hệ thống. Hơn nữa việc phân chia miền dữ liệu đầu vào thành các lớp tương đương con