ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ MAI THỊ KIM OANH KHẢO SÁT MỘT SỐ PHƢƠNG PHÁP SINH BỘ
KIỂM THỬ TRONG KIỂM THỬ HỘP ĐEN

LUẬN VĂN THẠC SĨ Hà Nội - 2011

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ MAI THỊ KIM OANH

KHẢO SÁT MỘT SỐ PHƢƠNG PHÁP SINH BỘ
KIỂM THỬ TRONG KIỂM THỬ HỘP ĐEN Ngành : CÔNG NGHỆ THÔNG TIN
Chuyên ngành : CÔNG NGHỆ PHẦN MỀM
Mã số : 60 48 10

LUẬN VĂN THẠC SĨ
Tôi xin cam đoan rằng, đây là kết quả nghiên cứu của tôi trong đó có sự giúp đỡ rất lớn
của thầy hướng dẫn và các đồng nghiệp ở cơ quan. Các nội dung nghiên cứu và kết quả
trong đề tài này hoàn toàn trung thực.
Trong luận văn, tôi có tham khảo đến một số tài liệu của một số tác giả đã được liệt kê tại
phần tài liệu tham khảo ở cuối luận văn.

Hà nội, tháng 5 năm 2011
Học viên thực hiện Mai Thị Kim Oanh


3.1.2. Kiểm thử biên mở rộng 17
3.1.3. Kiểm thử trường hợp xấu nhất 18
3.1.4. Kết hợp kiểm thử trường hợp xấu nhất và kiểm thử biên mở rộng 19
3.1.5. Một số ví dụ về miền giá trị các kiểu biến 20
3.1.6. Nhận xét 22
3.2. Phương pháp kiểm thử dựa trên phân hoạch tương đương 23
3.2.1. Phân lớp tương đương yếu 25 3.2.2. Phân lớp tương đương mạnh 25
3.2.3. Phân lớp tương đương truyền thống 26
3.2.4. Nhận xét 27
3.3. Phương pháp kiểm thử dựa trên bảng quyết định 28
3.3.1. Định nghĩa bảng quyết định 28
3.3.2. Áp dụng bảng quyết định cho bài toán Tam giác 30
3.3.3. Áp dụng bảng quyết định cho bài toán Next Date 32
3.3.3.1. Phép thử đầu tiên cho bài toán NextDate 35
3.3.3.2. Phép thử thứ hai cho bài toán NextDate 36
3.3.3.3. Phép thử thứ ba cho bài toán NextDate 38
3.3.4. Nhận xét 42
3.4. So sánh các phương pháp 43
Chương 4. Ứng dụng 46
4.1. Đặc tả bài toán 46
4.2. Thiết kế ca kiểm thử cho bài toán có các biến độc lập 46
4.2.1. Bài toán 46
4.2.2. Áp dụng các phương pháp kiểm thử để sinh ca kiểm thử 47
4.2.2.1. Phương pháp phân tích giá trị biên cơ bản 47
4.2.2.2. Phương pháp phân tích giá trị biên mở rộng 49
4.2.2.3. Phương pháp phân lớp tương đương yếu 50
4.2.2.4. Phương pháp phân lớp tương đương mạnh 50


Viết tắt
Tên đầy đủ
AT
Acceptance Test
BVT
Boundary Value Testing
DT
Decision Table
EP
Equivalence Partitioning
ST
System Test
UT
Unit Test
DANH MỤC BẢNG VÀ HÌNH VẼ
Hình 2.1. Tiến trình thực hiện kiểm thử. 5
Hình 2.2. Sơ đồ các cấp độ kiểm thử. 8
Hình 2.3. Kiểm thử bottom up. 10
Hình 2.4. Kiểm thử top-down. 11
Hình 3.1. Các cặp giá trị biên cơ bản. 15

Bảng 3.17 Phiên bản mở rộng của bảng quyết định 3.16 [6] 34
Bảng 3.18 Các điều kiện loại trừ lẫn nhau với các luật không xảy ra [6] 34
Bảng 3.19 Một bảng quyết định dư thừa [6] 34
Bảng 3.20 Một bảng quyết định không nhất quán [6] 35
Bảng 3.21 Bảng quyết định cho thử nghiệm đầu tiên với 256 luật [6] 36
Bảng 3.22 Bảng quyết định phép thử thứ 2 với 36 luật [6] 38
Bảng 3.23 Bảng quyết định cho hàm “NextDate” [6] 40
Bảng 3.24 Bảng quyết định được thu gọn cho hàm “NextDate” [6] 41
Bảng 3.25 Các trường hợp kiểm thử cho bài toán “NextDate” [6] 42
Hình 3.14. So sánh tính hiệu quả của các phương pháp kiểm thử. 44
Hình 3.15. So sánh tính hiệu quả của các phương pháp kiểm thử. 44
Bảng 3.26 Lựa chọn các phương pháp kiểm thử. 45
Hình 4.1. Giao diện bài toán “Nhập điểm cho sinh viên”. 47
Bảng 4.1 Các giá trị biên cơ bản cho bài toán “Nhập điểm sinh viên” 48
Bảng 4.2 Các trường hợp kiểm thử biên cơ bản cho bài toán “Nhập điểm sinh viên” 48
Bảng 4.3 Các giá trị biên mở rộng cho bài toán “Nhập điểm sinh viên” 49
Bảng 4.4 Kết quả kiểm thử biên mở rộng cho bài toán “Nhập điểm sinh viên” 49
Bảng 4.5 Các trường hợp kiểm thử cho phân lớp tương tương yếu 50
Bảng 4.6 Kết quả kiểm thử theo phương pháp phân lớp tương đương mạnh 51
cho bài toán “Nhập điểm sinh viên” 51
Bảng 4.7 Các trường hợp kiểm thử cho phân lớp tương tương 52
truyền thống với bài toán “Nhập điểm sinh viên” 52
Bảng 4.8 So sánh các phương pháp sinh ca kiểm thử cho bài toán “Nhập điểm sinh viên” 53
Hình 4.2. Giao diện bài toán “NextDate” 55
Bảng 4.9 Các giá trị biên cơ bản cho bài toán “NextDate” 55
Bảng 4.10 Kết quả kiểm thử theo phương pháp phân tích giá trị biên cơ bản cho bài toán
“NextDate” 56
Bảng 4.11 Các giá trị biên mở rộng cho bài toán “NextDate” 56
Bảng 4.12 Kết quả kiểm thử giá trị biên mở rộng cho bài toán “NextDate” 56
Bảng 4.13 Các trường hợp kiểm thử cho phân lớp tương tương yếu với bài toán “NextDate” 57

lượng của bộ kiểm thử này. Tuy nhiên, các công ty phần mềm hiện nay chủ yếu sử dụng
phương pháp phân hoạch tương đương để sinh bộ kiểm thử. Phương pháp này sẽ rất tốn
kém khi số lượng đầu vào của một chức năng cần kiểm thử là lớn. Hơn nữa, phương pháp
này chỉ hiệu quả với giả thiết là các đầu vào hoàn toàn độc lập nhau. Với những bài toán
có đầu vào phụ thuộc lẫn nhau, phương pháp phân hoach tương đương khó phát hiện ra
các lỗi gây ra bởi những phụ thuộc này. Để giải quyết bài toán này, chúng ta cần khảo sát
các phương pháp sinh bộ kiểm thử và đưa ra gợi ý cho các công ty trong việc lựa chọn
hay kết hợp các phương pháp để đảm bảo chất lượng phần mềm.
1.2. Nội dung nghiên cứu
Luận văn tập trung vào việc nghiên cứu và khảo sát một số phương pháp sinh bộ kiểm thử
thường được sử dụng trong kiểm thử hộp đen như: kiểm thử giá trị biên, kiểm thử dựa
trên phân hoạch tương đương và kiểm thử dựa trên bảng quyết định. Với mỗi phương
pháp, luận văn sẽ đưa ra các tiêu chí sinh bộ kiểm thử, đồng thời đánh giá được ưu điểm,
nhược điểm và khả năng phát hiện lỗi của từng phương pháp theo bộ kiểm thử được sinh
ra. Từ kết quả của quá trình khảo sát, luận văn sẽ đưa ra những được gợi ý cho từng loại
bài toán, từng hệ thống phù hợp với phương pháp kiểm thử nào. 2 Luận văn cũng sẽ tiến hành thử nghiệm các phương pháp kiểm thử nêu trên cho hai
bài toán cụ thể và đưa ra các phân tích đánh giá cho các phương pháp kiểm thử đã khảo
sát trong phạm vi luận văn này.
1.3. Cấu trúc luận văn
Các phần còn lại của luận văn có cấu trúc như sau:
Chương 2 trình bày các kiến thức tổng quan nhất về kiểm thử phần mềm bao gồm:
các khái niệm cơ bản về kiểm thử phần mềm (định nghĩa, lý do, vai trò và mục tiêu của
kiểm thử), tiến trình thực hiện kiểm thử bao gồm những giai đoạn nào, các công việc cần
thực hiện trong suốt quá trình kiểm thử là gì và các cấp độ kiểm thử trong kiểm thử phần

hay một tập hợp các tiến trình được thiết kế để đảm bảo mã hóa máy tính thực hiện theo
cái mà chúng đã được thiết kế để làm, và không thực hiện bất cứ thứ gì không mong
muốn. Đây là một pha quan trọng trong quá trình phát triển hệ thống, giúp cho người xây
dựng hệ thống và khách hàng thấy được hệ thống mới đã đáp ứng yêu cầu đặt ra hay
chưa.
2.1.2. Lý do kiểm thử phần mềm
Mặc dù kiểm thử phần mềm là một quy trình bắt buộc trong vòng đời phát triển phần
mềm nhưng hầu hết các phần mềm hiện tại vẫn còn lỗi lọt đến khách hàng hoặc được
chính người sử dụng tìm ra trong quá trình kiểm thử chấp nhận sản phẩm (acceptance
test). Nguyên nhân một phần lớn là do kiểm thử viên chưa làm đúng quy trình trong quá
trình xây dựng các ca kiểm thử. Vì vậy chúng ta cần hiểu rõ lý do của việc kiểm thử để từ
đó thấy được ý nghĩa của việc xây dựng ca kiểm thử hiệu quả. Có một số lý do chính của
hoạt động kiểm thử phần mềm như sau. Lý do thứ nhất, về khía cạnh xem xét sản phẩm,
người phát triển muốn kiểm tra phần mềm như một phần tử của hệ thống hoạt động thì cần
phải thực hiện thông qua hoạt động kiểm thử phẩn mềm. Lý do quan trọng thứ hai là khi
4 thực hiện tốt hoạt động kiểm thử, chúng ta sẽ hạn chế được chi phí cho các thất bại do lỗi
gây ra sau này. Đây chính là hiệu quả của hoạt động kiểm thử mang lại và cũng chính là mục
tiêu của người phát triển hệ thống khi thực hiện hoạt động kiểm thử phần mềm. Ngoài ra
còn có một lý do liên quan đến giải pháp phát triển, khi thực hiện hoạt động kiểm thử, đội
phát triển sẽ có kế hoạch tốt nâng cao chất lượng suốt quá trình phát triển phần mềm [1].
2.1.3. Vai trò của kiểm thử phần mềm
Thực tế đã chứng minh hoạt động kiểm thử có vai trò vô cùng quan trọng trong tiến trình
phát triển phần mềm. Vai trò đó được thể hiện qua chi phí và hiệu quả của hoạt động kiểm
thử mang lại. Về mặt chi phí, hoạt động kiểm thử chiếm khoảng 40% tổng công sức phát
triển phần mềm và chiếm tới hơn 30% tổng thời gian phát triển. Ngoài ra với các phần mềm
có ảnh hưởng tới sinh mạng thì chi phí kiểm thử có thể gấp từ 3 đến 5 lần tổng các chi phí
khác cộng lại [1]. Vai trò của hoạt động kiểm thử phần mềm còn thể hiện ở hiệu quả mà nó

trước đó. Dựa vào kết quả thực tế khi chạy chương trình và so sánh với kết quả mong đợi,
kiểm thử viên sẽ đưa ra được kết luận cuối cùng, tạo báo cáo kiểm thử để hoàn thành quá
trình kiểm thử.
2.3. Các phƣơng pháp kiểm thử phần mềm
Hiện nay, có hai phương pháp chính đang được áp dụng rộng rãi trong kiểm thử phần
mềm là kiểm thử hộp trắng và kiểm thử hộp đen. Chúng ta sẽ đi vào tìm hiểu cụ thể hai
phương pháp này trong mục 2.3.1 và 2.3.2.
2.3.1. Kiểm thử hộp trắng
Kiểm thử hộp trắng (white box testing) là loại kiểm thử hướng logic nhằm mục đích khảo
sát cấu trúc bên trong của chương trình. Chiến lược này xuất phát từ dữ liệu kiểm thử
bằng sự kiểm thử tính logic của chương trình. Kiểm thử viên sẽ truy cập vào cấu trúc dữ
liệu và giải thuật bên trong chương trình và cả mã lệnh thực hiện chúng.

6 Đối tượng của kiểm thử hộp trắng là mã nguồn chương trình, cụ thể là các mô đun
đơn vị. Kiểm thử hộp trắng tập trung vào việc kiểm tra các chi tiết thủ tục (logic xử lý,
thuật toán), các con đường logic (luồng điều khiển) và các trạng thái của chương trình (dữ
liệu cục bộ) [1]. Hiện nay, có một số kỹ thuật hay được sử dụng trong kiểm thử hộp trắng
như: đồ thị dòng (do Tom McCabe đưa ra đầu tiên), ma trận kiểm thử (số đường đi, trọng
số trên từng cạnh), điều khiển theo dòng dữ liệu, các cấu trúc chu trình – giá trị đặc trưng.
Phương pháp kiểm thử hộp trắng cũng có thể được sử dụng để đánh giá sự hoàn thành
của một bộ kiểm thử mà được tạo cùng với các phương pháp kiểm thử hộp đen (sẽ trình
bày trong mục 2.3.2). Điều này cho phép các nhóm phát triển phần mềm khảo sát các
phần của một hệ thống ít khi được kiểm tra và đảm bảo rằng những điểm chức năng quan
trọng nhất đã được kiểm thử.
2.3.2. Kiểm thử hộp đen
Kiểm thử hộp đen (black box testing) là một trong những phương pháp kiểm thử quan trọng
nhất trong tiến trình kiểm thử phần mềm. Kiểm thử hộp đen cũng được gọi là kiểm thử

phần mềm được kiểm tra thực sự được xây dựng thế nào nên sẽ có nhiều hạn chế trong việc
tập trung vào kiểm thử cái gì. Đó là lý do giải thích tại sao có nhiều trường hợp mà một
kiểm thử viên hộp đen viết rất nhiều các ca kiểm thử để kiểm tra một thứ gì đó mà đáng lẽ
có thể chỉ cần kiểm tra bằng một ca kiểm thử duy nhất, hoặc một số phần của chương trình
không được kiểm tra chu đáo.
Do vậy, kiểm thử hộp đen có ưu điểm của “ một sự đánh giá khách quan”, không phụ
thuộc vào quan điểm của người xây dựng chương trình mà thiên về cách nhìn của người sử
dụng nhiều hơn, mặt khác nó lại có nhược điểm của “thăm dò mù” nên đôi khi hơi tốn thời
gian và chi phí cho việc kiểm thử nếu không chọn được phương pháp/chiến lược kiểm thử
phù hợp và hiệu quả.
2.4. Các cấp độ kiểm thử phần mềm
Theo mô hình thác nước trình bày trong hình 2.2 thì kiểm thử phần mềm gồm có các
cấp độ: kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống và kiểm thử chấp nhận sản
phẩm. Mỗi cấp độ kiểm thử sẽ có một số đặc điểm riêng và phù hợp với từng giai đoạn của
quá trình xây dựng và phát triển phần mềm.
Dựa vào hình 2.2 bên dưới ta thấy tương ứng với mỗi giai đoạn phát triển phần mềm sẽ
có một cấp độ kiểm thử phù hợp với giai đoạn đó. Mỗi cấp độ kiểm thử được thực hiện theo
một thứ tự nhất định và có mục tiêu cụ thể cho từng giai đoạn. Trong thực tế, để việc tạo và
thực thi các ca kiểm thử đạt kết quả cao thì quá trình phân tích, thiết kế của hoạt động kiểm
thử cần được làm song song và phù hợp với các giai đoạn phát triển phần mềm. Hơn nữa,
kiểm thử viên nên tham gia vào quá trình xem xét tài liệu càng sớm càng tốt để đưa ra kế
hoạch và chiến lược kiểm thử phù hợp nhất cho hệ thống [4].
8
Hình 2.2. Sơ đồ các cấp độ kiểm thử.
2.4.1. Kiểm thử đơn vị
Một đơ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. Ví dụ,
các 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ị 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) [4]. 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.
2.4.2. Kiểm thử tích hợp
Kiểm thử tích hợp - intergration test là sự kết hợp các thành phần của một ứng dụng và kiểm
thử chúng như một ứng dụng đã hoàn thành. Trong khi UT kiểm tra các thành phần và đơn
vị riêng lẻ thì kiểm thử tích hợp 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ị, nó đượ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. 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. Trong UT, lập trình viên cố
gắng 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 đơn vị. 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.
10


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
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.

Hình 2.4. Kiểm thử top-down.
Ƣu điểm: Ngược lại với chiến lược bottom up, ưu điểm của kiểm thử top
down sẽ 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.
2.4.3. Kiểm thử hệ thống
Kiểm thử hệ thống hay còn gọi là system test (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 then chốt 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 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 ST. Sau khi hoàn thành
12 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

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.
13 Thực tế cho thấy, 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ụ đôi khi 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.
Gắn liền với giai đoạn AT thường là một nhóm những dịch vụ và tài liệu đi kèm, phổ
biến như tài liệu hướng dẫn cài đặt, 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ẽ. 14 Chƣơng 3. Khảo sát các phƣơng pháp sinh bộ kiểm thử
3.1. Phƣơng pháp kiểm thử giá trị biên
Kiểm thử giá trị biên - Boundary value testing (BVT) [6] là một trong những kỹ thuật kiểm
thử chức năng phổ biến nhất trong tất cả các kỹ thuật dùng để kiểm thử hộp đen. BVT là kỹ
thuật mà các ca kiểm thử được tạo ra dựa trên lý thuyết phân hoạch tập hợp hay cụ thể hơn
Hình 3.1. Các cặp giá trị biên cơ bản.
Để dễ hình dung hơn, kỹ thuật phân tích giá trị biên cơ bản được mô tả bằng hình 3.2,
trong đó các giá trị biên nằm trên các đường biên của miền giá trị đoạn [a,b] và đoạn [c,d] là
các đường biên của phân hoạch tập hợp.

Hình 3.2. Mô tả các giá trị biên cơ bản.
Như vậy việc tạo ra ca kiểm thử với ý tưởng của kỹ thuật kiểm thử giá trị biên cơ bản
là chúng ta chỉ việc lựa chọn các giá trị đầu vào tại các “góc cạnh”, điểm giá trị cuối của mỗi
miền hay gọi là các giá trị biên. Các giá trị biên cũng được kết hợp với các lân cận của nó
hay các vùng biên-viền.
Về phương pháp luận, cơ sở toán học của phương pháp này chính là phương pháp
phân lớp tương đương tập hợp, kiểm thử giá trị biên giúp tạo ra các ca kiểm thử bổ sung
thêm cho phân lớp tương đương, nó cho phép tìm lỗi trong mỗi miền là độc lập và khách
quan như nhau. Vậy việc khó khăn và quan trọng nhất trước tiên là cần phải tìm được các
phân hoạch của miền giá trị đầu vào của các biến. Sau khi xây dựng được các phân hoạch
con, chúng ta sẽ tiến hành xác định các giá trị biên của mỗi miền giá trị được phân chia. Để
dễ dàng hơn trong việc tạo ra các phân hoạch miền giá trị, ngoài các phương pháp toán học,
các phép toán trên tập hợp, người ta đưa ra các khuyến cáo như sau dựa vào kinh nghiệm
thực tế: Tiến hành mở rộng phân hoạch dựa trên các phân hoạch đã có. Với mỗi lớp con của
phân hoạch, chọn một giá trị tùy ý đại diện cho phân hoạch đó. Ngoài ra cần chọn các giá trị
chính xác ở biên trên và biên dưới của mỗi lớp. Cuối cùng chọn các giá trị ngay lập tức ở
dưới và trên mỗi biên. Các giá trị được lựa chọn này sẽ được sử dụng như những ca kiểm
thử cần được thực hiện.
<x1nom; x2min >;< x1nom; x2min+ >;
<x1nom; x2nom >;< x1nom; x2max- >;