Nguyền Ngọc Hải

--21--

4/10/2013

Mục lục
Phần I: Giới Thiệu về Kiếm
TRƯỜNG
Thử Phần
ĐẠIMầm.......................................................3
HỌC HÙNG
1.1 Khái niệm kiểm thử phần
mềm.................................................................3
VƯƠNG
1.2 Mục tiêu của kiếm thử...............................................................................4
KHOA TOÁN - CÔNG
1.3 Những khó khăn của kiếm thử..................................................................4
NGHỆ
1.4 Các phuxmg pháp kiểm thủ’.....................................................................4
1.5 Các kỹ thuật thiết kế trường họp kiểm thử................................................4
1.6 Phưong pháp thử các mô đun....................................................................4
PHÀN II GIỚI THIỆU CHI TIÉT VÈ KIỂM THỬ..............................................5
2.1 Nguyên tắc CO’ bản kiểm thử phần mềm.................................................5
2.2 Các phưong pháp kiếm thủ’.......................................................................5
2.3 Các kỹ thuật thiết kế trưòng họp kiểm thử.................................................7
2.3.1 Kiêm thủ’ hộp đen - Black box testing................................................7
*Phân Đoạn Tương Đương........................................................................7
*Phân tích giá trị biên - Boundary Value Analysis...................................9
* Kỹ Thuật Cause-Effect Graphing........................................................10
* Đoán lỗi...............................................................................................15

Mạnh Bá
* Độ
phức
tạp
lặp Lương
(Cyclomatic
Complexity)
21
2.3.3 Kiểm
thửSinh Viên
hộp Thựcxám
Gray
box
testing
Hiện: 22
1. Nguyễn Ngọc Hải (Trưởng Nhóm)
Phương
pháp
thử
các
mô
đun
2. Nguyễn Xuân Chiến
..........................................................................................................................
22
2.4.1 Kiểm thử mô đun................................................................................22
2.4.2 Kiểm
thủ’
tích
hợp

phát triển phần mềm đế đảm bảo rằng phần mềm thoả mãn các yêu cầu thiết
kế và các yêu cầu đó đáp ứng các nhu cầu của người dùng. Các kỹ thuật kiếm
thử phần mềm đã, đang được nghiên cứu, và việc kiếm thử phần mềm đã trở
thành qui trình bắt buộc trong các dự án phát triến phần mềm trên thế giới.
Kiểm thử phần mềm là khâu mấu chốt đế đảm bảo chất lượng phần mềm,
là đánh giá cuối cùng về đặc tả thiết kế và mã hóa.
Kiểm thử phần mềm là quá trình chạy thử một ứng dụng để phát hiện lồi
và xem nó có thỏa mãn các yêu cầu đã đặt ra trong quá trình phát triển phần
mềm, những người phát triển phần mềm và các kỹ sư kiểm thử cùng làm việc đế
phát hiện lỗi và đảm bảo chất lượng sản phẩm. Một sản phẩm phần mềm được
phân phổi phải có đầy đủ các chức năng yêu cầu và tương thích với phần cứng
của khách hàng.
•

Chi phí của kiếm thử chiếm
•

40% tổng công sức phát triển

•

>=30% tổng thời gian phát triển

Sơ đô kiêm thử


Nguyền Ngọc Hải
1.2 Mục tiêu của kiếm thử

-4-

Nguyền Ngọc Hải
-5PHẦN II GIỚI THIỆU CHI TIẾT VÊ KIỂM THỦ

4/10/2013

Có thể sử dụng một số kỹ thuật trong quá trình kiểm thử nhằm
tăng
hiệu quả của họat động này. Mc Gregor mô tả các kỹ thuật kiêm thử
nhu những công cụ được thiết kế đế đảm bảo rằng tất cả các khía cạnh
của sản phẩm đều đuợc khảo sát. Mặt khác, các kỹ thuật kiểm thử là
những công cụ để dễ dàng đạt được hiệu quả kiểm thử.
2.1 Nguyên tắc cơ bản kiếm thử phần mềm.

Trong lúc kiểm thử, công nghệ phần mềm phát sinh một chuỗi các trường
họp kiếm thử được sử dụng đế “tách tùng phần” phần mềm. Kiếm thử là
một bước trong qui trình phần mềm mà có thế được xem xét bởi đội ngũ
phát triển bằng cách phá vỡ thay vì xây dựng. Các kỹ sư phần mềm
chính là những người xây dựng và việc kiểm thử yêu cầu họ vượt qua các
khái niệm cho trước về độ chính xác và giải quyết mâu thuẫn khi các lỗi
được xác định.
2.2 Các phương pháp kiếm thử

Có 2 phương pháp kiểm thử chính là: Kiếm thử tĩnh và Kiểm thử động.
2.2.1 Thử tĩnh

Khái niệm
Phương pháp thử phần mềm thông qua việc sử dụng giấy, bút trên bàn đế kiểm
tra logic, lần từng chi tiết ngay sau khi lập trình xong
Chủ yếu kiểm tra mã, các tài liệu đặc tả
Các phương pháp thử tĩnh

Khả năng gợi ý định hướng thay đối phần mềm
Tiến trình duyệt:
1. Đánh giá đầu vào
2. Chuẩn bị quản lí
3. Lập kế hoạch
4. Gặp gỡ trước
5. Chuẩn bị riêng
6. Duyệt
7. Gia công/ bám sát
8. Ket thúc, đánh giá


Điều kiện bên ngoài

Các lóp tương đương hợp Các lóp tương đương
lệ
không hợp lệ
NguyềnNgọc
NgọcHải
Hải
-7
Nguyền
-8-

4/10/2013
4/10/2013

thành một lóp tương đương họp lệ và hai lớp tương đương không hợp
(6) Điều chỉnh môi trường thực hiện môđun tải (tạo thủ tục đưa các tệp
lệ. Chẳng hạn, nếu đầu vào x=5, thì lớp hợp lệ là x= 5, các lớp không


Ngoài ra,
mộtthửnguyên
tắc(Black
thứ năm
bố là
sung
sử thiết
dụngkế
khả
năng hợp thử
Kiểm
hộp đen
Boxđược
testing)
kỹ là
thuật
trường
phán
đoán,
kinh
nghiệm
trụcchương
giác của
người
kiểmkiếm
thử. thử chỉ quan tâm đến
dựa trên
đặc
tả bề

1.
Gán một
duy nhất cho mỗi lóp tương đương.

Đen-khiĐoán
tất cảlỗicác lớp tương đương hợp lệ được phủ bởi các trường
hợp kiếm thử thì viết một trường hợp kiếm thử mới phủ nhiều nhất có
và một sổ kỹ thuật khác
thể các lóp tương đương họp lệ chưa được phủ.
Hình 1: Black Box testing
Đen khi tất cả các lớp tương đương không họp lệ được phủ bởi các
trường hợp kiểm thử thì hãy viết các trường hợp kiểm thử mới sao cho
*Phân Đoạn Tương Đương
mỗi trường hợp kiểm thử mới chỉ phủ duy nhất một lớp tương đương
không
chưachia
đượcvùng
phủ.thông tin nhập vào của chương trình thành các lớp
Đây làhọp
kỹlệthuật
thông tin/dữ liệu. Lớp tương đương biểu diễn thành một tập các giá trị hợp lệ và


Nguyền Ngọc Hải

-9-

4/10/2013

*Phân tích giá trị biên - Boundary Value Analysis

tối đa là 1,165.25$, hãy viết các ca kiểm thử mà khấu trù' 0.00$ và
1,165.25, khấu trù' âm và khấu trù' lớn hơn 1,165.25$. Chú ý là việc
xem


Nguyền Ngọc Hải

- 10-

4/10/2013

của giới hạn đầu ra (ví dụ, xét chương trình con tính SIN). Ngoài ra,
không phải lúc nào cũng có thể tạo ra 1 kết quả bên ngoài giới hạn đầu
ra, nhưng tuy nhiên rất đáng để xem xét tiềm ẩn đó.
4. Sử dụng nguyên tắc 2 cho mỗi trạng thái đầu ra.
5. Neu đầu vào hay đầu ra của 1 chương trình là tập được sắp thứ tự’ ( ví

dụ,l file tuần tự hay 1 danh sách định tuyến hay 1 bảng) tập trung chú ý
vào các phần tử đầu tiên và cuối cùng của tập họp.
6. Sử dụng sự khéo léo của bạn đế tìm các điều kiện biên.

khoảng giá
trị
tương đưong
Kỹ Thuật Cause-Effect Graphing
Ta thấy rằng 2 kỹ thuật trên dữ liệu đầu vào đã được phân loại đế phân tích. Tuy
nhiên kỹ thuật sắp trình bày dưới đây cho phép xác định ra các trường họp kiểm
thử hiếu quả nhất ngay cả trong lúc dữ liệu đầu vào là khó phân loài thành các
lớp như trong 2 kỹ thuật trên.
Kỹ thuật này gồm có 4 bước như sau :

5. Bằng việc dò theo các điều kiện trạng thái trong đồ thị một cách cấn

thận, bạn chuyển đổi đồ thị thành một bảng quyết định mục vào giới
hạn. Mỗi cột trong bảng mô tả một ca kiểm thử.
6. Các cột trong bảng quyết định được chuyển thành các ca kiếm thử.

Ký hiệu cơ bản cho đồ thị được chỉ ra trong hình 1. Tưởng tượng mồi nút có giá
trị là 0 hoặc 1; 0 mô tả trạng thái vắng mặt và 1 mô tả trạng thái có mặt. Hàm
đồng nhất nói là nếu a là 1 thì ồ là 1; ngược lại, b là 0. Hàm not là nói nếu a là
1 thì b là 0; ngược lại thì b là 1. Hàm or khẳng định rằng nếu a hoặc b hoặc c là
1, thì d là 1; ngược lại d là 0. Hàm and khẳng định nếu cả a và b là 1 thì c là 1;
ngược lại c là 0. Hai hàm or và and được phép có số lượng đầu vào bất kỳ.


0
E1

Nguyền
Ngọc Hải
í1 ©

■""©

""""-©

.../©

Rỉ

- 1123 -

nếu bạn đang khảo sát trạng thái mà 1 đầu ra là 0 và một hay nhiều đầu
ra khác là 1, thì không nhất thiết phải liệt kê tất cả các điều kiện mà
dưới điều kiện đó các đầu vào khác có thế là 1.
3. Khi lần ngược trở lại qua một nút and mà đầu ra của nó là là 0, chỉ cần

liệt kê 1 điều kiện trong đó tất cả đầu vào bằng 0. (Neu nút and ở chính
giữa của đồ thị như vậy thì tất cả các đầu vào của nó xuất phát từ các
nút trung gian khác, có thế có quá nhiều trạng thái mà trong trạng thái
đó tất cả các đầu vào của nó bằng 0.)
Hình 3 Những xem xét được sử dụng khi dò theo đồ thị

Bước tiếp theo là tạo bảng quyết định mục vào giới hạn - ỉimited-entry decision
table. Tương tự với các bảng quyết định, thì nguyên nhân chính là các điều kiện
và kết quả chính là các hành động. Quy trình được sử dụng là như sau:
1. Chọn một kết quả đế là trạng thái có mặt (1).
2. Lần ngược trở lại đồ thị, tìm tất cả những sự kết hợp của các nguyên

nhân (đối tượng cho các rằng buộc) mà sẽ thiết lập kết quả này thành 1.
3. Tạo một cột trong bảng quyết định cho mỗi sự kết hợp nguyên nhân.
4. Với mồi sự kết hợp, hãy quy định trạng thái của tất cả các kết quả khác

và đặt chúng vào mỗi cột.
Những
sự xem
này2,có
xuấttâm
hiệncác
thất
thường,
Trong

mộtcác
cách
đồng thử
thời.ít
kê các trường
hợplập
mànhiều
hướnghơn
về các
ca vào
kiếmcho
thửnút
ít có
ca kiếm

Điều được
này được
gọimột
là đồ
path
- làm
nhạy
đi. Mục
tiêu
có lợi không
liệt kê,
thịsensitizing
nguyên nhân
- kết
quả đường

-

4/10/2013

15có lợi sẽ là những ca kiểm thử được liệt kê. Do đó, tốt hơn hết là liệt kê chúng
trong suốt quá trình phân tích của đồ thị.
* Đoán lỗi
Một kỹ thuật thiết kế trường hợp kiếm thử khác là error guessing - đoán lỗi.
Tester được đưa cho 1 chương trình đặc biệt, họ phỏng đoán, cả bằng trực giác
và kinh nghiệm, các loại lồi có thể và sau đó viết các ca kiểm thử để đưa ra các
lỗi đó.
Thật khó đế đưa ra một quy trình cho kỹ thuật đoán lỗi vì nó là một quy trình có
tính trực giác cao và không thể dự đoán trước. Ý tưởng cơ bản là liệt kê một
danh sách các lỗi có thể hay các trường hợp dễ xảy ra lỗi và sau đó viết các ca
kiếm thử dựa trên danh sách đó. Một ý tưởng khác đế xác định các ca kiếm thử
có liên đới với các giả định mà lập trình viên có thể đã thực hiện khi đọc đặc tả
(tức là, những thứ bị bỏ sót khỏi đặc tả, hoặc là do tình cờ, hoặc là vì người viết
có cảm giác những đặc tả đó là rõ ràng). Nói cách khác, bạn liệt kê những
trường họp đặc biệt đó mà có thế đã bị bỏ sót khi chương trình được thiết kế.
2.3.2

Kiếm thử hộp trắng - White box testing

• Kiếm thử hộp trắng là kiểm tra cấu trúc và logic phần mềm theo mục

tiêu(Trong trường hợp này yêu cầu người kiểm thử phải biết ngôn ngữ
WHITE BOX TESTS

c E>




Nguyền Ngọc Hải

-

4/10/2013

17El, E2 là các biếu thức số học và phép toán quan hệ là một trong các phép toán
sau :
Thủnhất
TụcvàVới
Lệnh
Vàđược
Lệnhthay
Lặpđối
Phức
Tạpsố của
được
một
sổ duy
rằng
mỗiĐiều
hàmKiện
khong
thông
else ifC3
Bl;
then
nó và biến toàn cục.
B2
else
DEF(S) = { X I lệnh s chứa định nghĩa X }
B3
o
o
o
o
USE(S) = { X I lệnh s chứa một lệnh/biểu thức sủ dụng X }
J

thànhnghĩa
tổ 2 Một chuỗi dùng củacầu
trúcX ( gọi là DU của X) ký hiệu [X, s, S’]
Đinh
biến
Đe xây dựng các trường hợp kiếmthử DFT cho thủ tục trên, chúng ta cần phải
là định nghĩa của X trong câu lệnh s vẫn sổng trong câu lênh s\
biết định nghĩa và sử dụng biến ở mồi điều kiện hoặc một khối trong thủ tục này.
Phương
pháp
thử luồng
dữ liệu
yêucâu
cầulệnh
rằngcuối
tất cả
cáckhối
chuỗi
DU
đều
được
Giả sử
biếnkiểm
X được
định nghĩa
trong
của
lệnh
B2,
B3,

nhánh
DU
yêubao
cầutrùm
đường
thực
ngắn của
nhấtchương
từ Bi, 0

tồncác
tại.trường
Trong họp
tình khác.
huông này thì
25
chuối
DUmột
nhưng
là đủelse
đế không
bao hàm
nhánh else của câu lênh ì trên không cần thiết phải bảo hộ bởi phương pháp này.
*. Kiểm Thử Vòng Lặp
DFT rất hũư ích cho các loài kiểm thử một chương trình có nhiều lệnh if và lệnh
Vòng lặp là một trong những nền tảng cho rất nhiều các thuật toán được cài đặc
trong các phần mềm. tuy nhiên cho đến lúc này chúng ta vẫn còn ít chú ý đến
việc xây dựng các trương hợp để kiểm thử.
Kiếm thử vòng lặp tập trung vào tính chất của cấu trúc vòng lặp. Có 4 cầu trúc
vòng lặp như sau: vòng lặp đơn giản, vòng lặp móc nối, vòng lặp tạo thành


Nguyền Ngọc Hải
21•

-

4/10/2013

Bắt đầu tại vòng lặp con trong cùng. Thiết lập tất cả các vòng lặp khác là

các
trường
hợpPhương
kiểm thử
chodùng
vòngcho
lặp vòng
đơn, với
là tổ sẽ được
còn
độc
lặp nữa,
pháp
lặp ntạo
maximum
sổ lần lặp.
sử dụng ở đây.
Vòng Lặp
cấuvẹn
Trúc
• Không
Bỏ tínhCó
toàn
của vòng lặp
Khi nào gặp các cầu trúc lặp như vầy thì nên thiết kế lại. Việc kiếm thử rất phức
tạp.• Chỉ cần một lần duyệt xuyên qua cả vòng lặp
* Độ phức tạp lặp (Cyclomatic Complexity)
Hai lần duyệt xuyên qua cả vòng lặp
Độ phức tạp lặp là 1 số đo phần mềm, cung cấp 1 đơn vị đo định lượng về độ
•

4/10/2013

V(G) = E - N +2, với E là số cung, N là sổ nút của G
V(G) = số vùng (region)
V(G) = p +1, với p là số lượng nút Predicat (nút giả định, không có thật
2.3.3 Kiếm thử hộp xám - Gray box testing

Kiểm thử hộp xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và giải thuật
bên trong cho những mục đích thiết kế các ca kiếm thử, nhưng là kiếm thử ở
mức người sử dụng hay mức hộp đen. Việc thao tác tới dữ liệu đầu vào và định
dạng dữ liệu đầu ra là không rõ ràng, giống như một chiếc “hộp xám ”, bởi vì
đầu vào và đầu ra rõ ràng là ở bên ngoài “hộp đen ” mà chúng ta vẫn gọi về hệ
thống được kiểm tra. Sự khác biệt này đặc biệt quan trọng khi quản lý kiểm thử
tích hợp - Intergartion testỉng giữa 2 modun mã lệnh được viết bởi hai chuyên
viên thiết kế khác nhau, trong đó chỉ giao diện là được đưa ra đế kiếm thử. Kiếm
thử hộp xám có thế cũng bao gồm cả thiết kế đối chiếu đế quyết định, ví dụ, giá
trị biên hay thông báo lỗi.
2.4 Phương pháp thử các mô đun
2.4.1

Kiểm thử mô đun

Kiếm thử tích hợp với mục đích là kiếm tra giao diện và sự liên tác giữa
các mô đun. Do vậy, các mô đun đã được kiểm thử xong coi như không có lỗi ở


Nguyền Ngọc Hải

- 23



Nguyền Ngọc Hải

-24-

4/10/2013

* Kiểm tra bottom-up
Nguyên tắc của bottom-up là kiếm tra mọi thay đối tại module có thế
ảnh hưởng tới chức năng của nó. Trong kiểm tra bottom-up, toàn bộ khối là
đơn vị đế đánh giá. Tất cả các module được mã hoá và kiếm tra riêng rẽ.

Các trường hợp kiểm tra: các trường hợp kiểm tra là dữ liệu vào được
tạo đế thế hiện từng khối và toàn bộ hệ thống thoả mãn tất cả các yêu cầu
thiết kế.
Mồi trường hợp kiểm tra nên được phát triển đế kiểm tra nghiệm các
đòi hỏi thiết kế đặc trưng, thiết kế chức năng, hoặc mã đã được thoả mãn.
Hơn nữa các trường họp kiếm tra cần dự đoán các output.
Mỗi đơn nguyên của ứng dụng (Ví dụ: module, subroutine, program,
utiĩity,...) phải được kiểm tra với ít nhất hai trường hợp kiểm tra: một trường
hợp chạy tốt và một trường hợp không chạy. Trong trường họp chạy sai hệ
phải đưa được thông báo, quay lại (rollback) được trạng thái ban đầu của
giao dịch.
Đe chắc chắn rằng các trường hợp được toàn diện nhất, người ta


Nguyền Ngọc Hải
•

-25 -

* Kiểm thử hệ thống - System Test
Mục đích System Test là kiểm thử thiết kế và toàn bộ hệ thống (sau khi tích
hợp) có thỏa mãn yêu cầu đặt ra hay không.
System Test bắt đầu khi tất cả các bộ phận của phần mềm đã được tích họp
thành công. 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.


Nguyền Ngọc Hải

- 26

4/10/2013

Điếm khác nhau then chốt giữa Integration Test và System Test là System Test
chú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test 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 Unit Test và Integration Test đế bảo đảm mọi Unit và
sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện System Test.
Sau khi hoàn thành Integration Test, 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 System Test nên bắt đầu từ giai đoạn hình
thành và phân tích các yêu cầu.
System Test kiểm thử cả các hành vi chức năng của phần mềm lẫn 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 System Test, 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).

Nhìn từ quan điếm người dùng, các cấp độ kiếm thử trên rất quan trọng: Chúng
bảo đảm hệ thống đủ khả năng làm việc trong môi trường thực.
Lưu ý là 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. Tùy
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, người Quản lý dự án sẽ quyết định áp dụng những loại
kiểm thử nào.
• Kiểm thử chấp nhận sản phẩm - Acceptance Test

Thông thường, sau giai đoạn System Test là Acceptance Test, được khách hàng
thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện). Mục đích của
Acceptance Test là đế chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách
hàng và khách hàng chấp nhận sản phâm (và trả tiền thanh toán họp đồng).
Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trường
hợp, các phép kiếm thử của System Test và Acceptance Test gần như tương tự’,
nhưng bản chất và cách thức thực hiện lại rất khác biệt.
Đối với những sản phẩm dành 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ử


Nguyền Ngọc Hải

- 28

4/10/2013

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ả Acceptance Test 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 chò' 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 thực hiện bởi


3

0

2

3

4

5

Nguyền Ngọc Hải
-29--3031 4/10/2013
1
1
1
0
PHẦN III MỘT SỐ ÚNG DỤNG CỦA KỸ THUẬT KIỂM THỬ
Áp
1 dụng kỹ thuật kiểm 0thử hộp đen:
Chương
1 trình đọc vào 3 giá trị nguyên từ hộp thoại vào. Ba giá trị này tương ứng
với chiều dài 3 cạnh của 1 tam giác. Chương trình hiến thị 1 thông điệp cho biết
tam
là
giác thường,
cân,quyêt
hay đều.

nhau, 0và tam giác thường thì có 3 cạnh khác nhau
0 có 2 trong
0 3 cạnh bằng
0
- kết12quả
tiên.Vẽ
RI đồ
có thị
mặtnguyên
nếu nútnhân
các nút
và 3 = 1,0. Nút 1 2 = 1 khi 1 và 2 = 1,1.
1
0
0
0
Do
đặc
tả
có
sự
kết
hợp
đầu
vào
nên
trước
đồ thị
Áp dụng lần lượt cho sự có mặt của từng kếttiên,
quảáp

Ca2 kiểm
động

số bất kỳ trong 3 số luôn lớn
hơn số thứ 3, và không có cặp 4.
2 sổ bất kỳ nào trong 3 số đó
Ket quả là:

2,3,4
RI
2,4,3 3 sổ có giá trị bằng nhau.
Hai trong
3,2,4
Ba số3,4,2
có giá trị bằng nhau.
4,2,3
4,3,2

2Cả 3 giá trị nhập vào đều là sổ
nguyên dương, và tổng cảu 2

3,3,4
3,4,3

số bất kỳ trong 3 số luôn lớn

4,3,3

hơn số thứ 3, và tồn tại một
cặp 2 số trong 3 số đó là =

dương.
giá trị bằng nhau.
4Cả 3 giá trị nhập vào đều là số
1,2,4
nguyên dương, và tồn tại 2 số Và 5 hoán vị của
trong 3 số có tổng nhỏ hơn
nó
Phân lớp tương đương
Xác định các lớp tương
hoặc bằng sô còn lại.
đương
5Tồn tại một giá trị nhập vào
A,2,2
không phải là số nguyên
-1,1,1
Các giá trị nhập vào là
số
Các giá trị là nguyên
Các giá trị là dương
Hằng số
Tống 2 số bất kỳ so với
số thứ 3

Cả 3 giá trị đều là số (1)

R4

4/10/2013
1.1,1,1