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

TRỊNH THỊ MINH HIỂN

XÂY DỰNG CÁC CA KIỂM THỬ TỰ ĐỘNG TỪ
GIAO DIỆN PHẦN MỀM

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Ệ
==========oOo==========

TRỊNH THỊ MINH HIỂN

XÂY DỰNG CÁC CA KIỂM THỬ TỰ ĐỘNG TỪ
GIAO DIỆN PHẦN MỀM
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Ĩ
NGƯỜI HƯỚNG DẪN KHOA HỌC: TS. TRƯƠNG NINH THUẬN

HÀ NỘI - 2011

MỤC LỤC
LỜI CAM ĐOAN .......................................................................................................................... 3
MỤC LỤC ...................................................................................................................................... 4
DANH MỤC CÁC KÝ HIỆU THUẬT NGỮ VIẾT TẮT ...................................................... 1
DANH MỤC CÁC HÌNH VẼ ..................................................................................................... 2
DANH MỤC CÁC BẢNG ........................................................................................................... 3
Mở đầu ............................................................................................................................................ 1
Chương 1 ......................................................................................................................................... 3
Tổng quan về kiểm thử và kiểm thử tự động ............................................................................. 3
1.1. Kiểm thử phần mềm ........................................................................................................................... 3
1.1.1. Khái niệm kiểm thử phần mềm ................................................................................................. 3
1.1.2. Mục tiêu kiểm thử ..................................................................................................................... 3
1.1.3. Luồng thông tin kiểm thử ......................................................................................................... 3
1.2. Kiểm thử tự động ............................................................................................................................... 4
1.2.1. Khái niệm kiểm thử tự động ...................................................................................................... 4
1.2.2. Lợi ích và hạn chế của kiểm thử tự động .................................................................................. 5
1.2.3. Phân loại công cụ kiểm thử tự động .......................................................................................... 6

Chương 2 ......................................................................................................................................... 8
Phương pháp sinh ca kiểm thử tự động ...................................................................................... 8
2.1. Phương pháp sinh Test Case tự động dựa trên đặc tả ....................................................................... 8
2.2.1. Phương pháp sinh Test Case dựa trên đặc tả SCR .................................................................... 8
2.2.2. Phương pháp sinh Test Case dựa trên đặc tả UML................................................................. 12
2.2. Phương pháp sinh Test Case tự động dựa trên Mơ hình ................................................................. 16
2.2.1. Phương pháp sinh Test Case dựa trên biểu đồ cộng tác UML. .............................................. 16
2.2.2. Phương pháp sinh Test Case tự động dựa trên lược đồ Use case ........................................... 20

Chương 3 ....................................................................................................................................... 29
Phương pháp sinh Test Case tự động từ giao diện .................................................................. 29

3.1. Tổ hợp kiểm thử ............................................................................................................................... 29
3.1.1. Tham số và mức ....................................................................................................................... 29
3.1.2. Tổ hợp các tham số .................................................................................................................. 30
3.1.3. Qui trình thiết kế tổ hợp kiểm thử ........................................................................................... 31
3.2. Áp dụng phương pháp sinh Test Case từ giao diện với ví dụ cụ thể .............................................. 32
3.2.1. Kiểm thử form Login .............................................................................................................. 32
3.2.2. Kiểm thử form Lương Cơ Bản ................................................................................................ 33

Chương 4 ....................................................................................................................................... 35
Công cụ hỗ trợ .............................................................................................................................. 35
4.1. Thiết kế chức năng ........................................................................................................................... 35
4.1.1. Thiết kế tổng quan .................................................................................................................... 35
4.1.2. Biểu đồ Use case ...................................................................................................................... 36
4.1.3. Biểu đồ hoạt động .................................................................................................................... 36
4.1.4. Biểu đồ lớp ............................................................................................................................... 37
4.2. Cài đặt ............................................................................................................................................... 39
4.2.1. Nhập tham số ............................................................................................................................ 39
4.2.2. Nhập kết quả............................................................................................................................. 40


4.2.3. Nhập điều kiện ......................................................................................................................... 41
4.3.4. Sinh Test Case .......................................................................................................................... 42
4.3. Ưu, nhược điểm của công cụ .......................................................................................................... 45

Kết luận ......................................................................................................................................... 46
TÀI LIỆU THAM KHẢO .......................................................................................................... 47


DANH MỤC CÁC KÝ HIỆU THUẬT NGỮ VIẾT TẮT
#

1
2
3
4

Thuật ngữ
Test Case
Tester
Test

Ý nghĩa
Ca kiểm thử
Kiểm thử viên
Kiểm thử


DANH MỤC CÁC HÌNH VẼ
Hình 1.1 Luồng thơng tin kiểm thử ............................................................................. 4
Hình 2.1 Quy trình chung của việc tạo ra các Test Case từ đặc tả SCR ...................... 11
Hình 2.2 Sự kiện gọi (call events)1 ............................................................................ 13
Hình 2.3 Sự kiện tín hiệu (signal events)1 .................................................................. 13
Hình 2.4 Sự kiện thời gian (time Events) 1 ................................................................. 14
Hình 2.5 Sự kiện thay đổi (Change Events) 1 ............................................................. 14
Hình 2.6 Quy trình tạo ra các Test Case từ đặc tả UML ............................................ 15
Hình 2.7 Biểu đồ use-case mơ tả u cầu của hệ thống đăng kí khóa học của một
trường đại học. ........................................................................................................... 21
Hình 2.9 Tài liệu mơ tả qui trình đăng kí mơn học của luồng sự kiện cơ bản của use
case............................................................................................................................ 23
Hình 2.10 Tài liệu mơ tả qui trình đăng kí mơn học của luồng ln phiên của use case.
.................................................................................................................................. 23

Hình 3.1 Quy trình thiết kết tổ hợp kiểm thử .............................................................. 31
Hình 4.1 Biểu đồ Use case ......................................................................................... 36
Hình 4.2 Biểu đồ hoạt động. ...................................................................................... 37
Hình 4.3 Biểu đồ lớp.................................................................................................. 38


DANH MỤC CÁC BẢNG
Bảng 1.1 Các bước sử dụng công cụ để tiến hành kiểm thư tự động………………….. 5
Bảng 2.1 Những kịch bản có thể xảy ra cho biểu đồ biểu diễn tại…………………... 24
Bảng 2.2 Những kịch bản này sẽ sử dụng như cơ sở để tạo ra những Test Case…….. 24
Bảng 2.3 Ma trận kịch bản từng phần cho Use Case “Đăng kí mơn học”…………... 25
Bảng 2.4 Ma trận Test Case cho Use Case “Đăng kí mơn học”……………………... 26
Bảng 2.5 Ma trận Test Case với giá trị dữ liệu………………………………………. 27


Mở đầu
Trong những năm gần đây cùng với sự phát triển của phần cứng máy tính, phần
mềm có nhiều bước tiến quan trọng. Sản xuất phát triển phần mềm hiện nay đã trở
thành một ngành công nghiệp thực sự. Cũng như các ngành công nghiệp khác, khi quy
mô chức năng của các phần mềm được sản xuất ngày càng phức tạp thì yêu cầu về
quản lý chất lượng phần mềm ngày càng được quan tâm. Do đó, kiểm thử phần mềm
phải được thực hiện thường xuyên trong suốt vòng đời phát triển của phần mềm để
đảm bảo chất lượng.
Như chúng ta đã biết, giao diện người dùng đồ họa (Graphical User Interface GUI) là một trong những cách phổ biến nhất để người sử dụng tương tác với hệ thống
phần mềm. Khi kết thúc giai đoạn kiểm thử hệ thống, các tester tiếp tục kiểm thử phần
mềm với các chức năng bổ sung cung cấp bởi giao diện đồ hoạ. GUI làm cho việc
kiểm thử hệ thống khó khăn hơn vì các nguyên nhân: do bản chất sự kiện điều khiển
của GUI, các sự kiện không mong muốn, miền dữ liệu đầu vào/đầu ra vơ hạn mà lập
trình viên khơng lường trước được vì khơng thể kiểm thử tất cả các luồng dữ kiện.
Thơng qua GUI, các tester có thể thực hiện kiểm thử hộp đen để tìm ra lỗi của phần

mềm. Một trong những lý do quan trọng nhất trong kiểm thử phần mềm là thiết kế và
tạo ra các Test Case có hiệu quả. Chi phí kiểm thử phần mềm thường chiếm tới 40%
tổng các nỗ lực dành cho một dự án phát triển phần mềm. Vì thế, giảm chi phí cho việc
tạo Test Case (thời gian, cơng sức) cũng là một trong những vấn đề được quan tâm
trong kiểm thử phần mềm. Tự động hoá việc tạo Test Case khơng những giúp giảm chi
phí trong việc tạo Test Case mà cịn giúp đồng nhất hố chất lượng Test Case. Để
đồng nhất hóa cơng việc viết Test Case bằng các phương pháp tự động nhằm giảm bớt
công sức và thời gian của tester, làm cho chất lượng của Test Case tốt hơn, chúng tôi
nghiên cứu phương pháp sinh Test Case từ giao diện, từ đó phát triển cơng cụ sinh
Test Case từ giao diện để hỗ trợ tester trong việc tạo Test Case để kiểm thử phần mềm.
Luận văn được trình bày theo bốn chương với nội dung sau:
Chương 1: Tổng quan về kiểm thử và kiểm thử tự động
Trình bày tổng quan về kiểm thử, kiểm thử tự động.
Chương 2: Phương pháp sinh Test Case tự động
Trình bày các khái niệm cơ bản về Test Case và các Phương pháp
sinh Test Case tự động hiện hay.
Chương 3: Phương pháp sinh Test Case từ giao diện
Trình bày phương pháp sinh Test Case từ giao diện và áp dụng
phương pháp sinh Test Case từ giao diện với ví dụ cụ thể.
Chương 4: Công cụ hỗ trợ
Xây dựng công cụ sinh Test Case tự động bằng phương pháp sinh


2

Test Case từ giao diện.
Sau khi nghiên cứu và thử nghiệm, trong phần Kết luận có nêu một số tổng kết
và nhận xét về công cụ sinh Test Case tự động, đồng thời đề ra hướng nghiên cứu tiếp
theo.



3

Chương 1
Tổng quan về kiểm thử và kiểm thử tự động
1.1. Kiểm thử phần mềm
1.1.1. Khái niệm kiểm thử phần mềm
Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần
mềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm cung cấp cho
người có lợi ích liên quan những thơng tin về chất lượng của sản phẩm hay dịch vụ
phần mềm ấy. Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay khiếm khuyết
phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm trong nhiều ngành
khác nhau.
Theo Glen Myers: Kiểm thử phần mềm là quá trình vận hành chương trình để tìm
ra lỗi [12]. Vấn đề đặt ra là: Cần vận hành như thế nào để hiệu suất tìm ra lỗi là cao
nhất và chi phí (cơng sức, thời gian) là ít nhất.

1.1.2. Mục tiêu kiểm thử
Các nguyên tắc được xem như mục tiêu kiểm thử là:
Kiểm thử là một quá trình thực thi chương trình với mục đích tìm lỗi.
Một trường hợp kiểm thử tốt là trường hợp kiểm thử mà có khả năng cao việc
tìm thấy các lỗi chưa từng được phát hiện.
Một kiểm thử thành công là kiểm thử mà phát hiện lỗi chưa từng được phát
hiện.

1.1.3. Luồng thông tin kiểm thử
Luồng thông tin cho kiểm thử được biểu diễn bởi mơ hình trong hình 1.1. Hai
kiểu của đầu vào được truyền cho quá trình kiểm thử:
Cấu hình phần mềm: gồm các đặc tả yêu cầu, đặc tả thiết kế, và mã nguồn.
Cấu hình kiểm thử: gồm có kế hoạch kiểm thử, các thủ tục, trường hợp kiểm

thử, và các công cụ kiểm thử.


4

Hình 1.1 Luồng thơng tin kiểm thử

1.2. Kiểm thử tự động
1.2.1. Khái niệm kiểm thử tự động
Trong hầu hết các mơ hình phát triển phần mềm, “lập trình – phát triển – sửa
lỗi” có thể lặp đi lặp lại rất nhiều lần trước khi phát hành, tuy nhiên hầu hết trong số
chúng vẫn tồn tại lỗi. Mặc dù nhóm phát triển đã cố gắng phát hiện và sửa lỗi thông
qua kiểm thử thủ công nhưng lỗi luôn tiềm ẩn và xuất hiện trở lại. Kiểm thử tự động là
cách tốt nhất để nâng cao hiệu quả của kiểm thử phần mềm.
Kiểm thử thủ công được thực hiện bởi kiểm thử viên thơng qua việc quan sát
ứng dụng trên màn hình, từ dữ liệu đầu vào, so sánh dữ liệu nhận được với kết quả
mong đợi và lưu lại. Kiểm thử thủ cơng được lặp đi lặp lại trong suốt vịng đời phát
triển của phần mềm, mỗi khi có sự thay đổi về mã nguồn chương trình, sự thay đổi về
mơi trường, phần cứng đều phải tiến hành kiểm thử lại. Nếu một phần mềm phải thực
hiện vài nghìn Test Case thì có thể chỉ đủ thời gian thực hiện số Test Case ấy 1 lần, tuy
nhiên, để đảm bảo phần mềm khi phát hành khơng có lỗi, nhóm phát triển phải kiểm
thử rất nhiều lần để kiểm tra xem lỗi tìm ra trong lần kiểm thử trước đó đã được sửa
hay chưa và đảm bảo khơng có lỗi mới phát sinh. Kiểm thử tự động có thể giải quyết
vấn đề này. Kiểm thử tự động phần mềm là tiến trình thực hiện một cách tự động một
số bước của các ca kiểm thử, bằng cách sử dụng một công cụ nhằm rút ngắn thời gian
và công sức kiểm thử [1]. Cơng cụ kiểm thử tự động có thể thực hiện lại các hành
động được xác định trước, so sánh với kết qua mong đợi và ghi lại kết quả.
Để kiểm thử tự động cần thực hiện các công việc sau [1]:
-


Thu thập các đặc tả yêu cầu hoặc các ca kiểm thử, lựa chọn những phần cần
thực hiện kiểm thử tự động.


5

-

Phân tích và thiết kế mơ hình cho kiểm thử tự động.
Sử dụng công cụ để tiến hành kiểm thử, với các bước cho ở bảng sau:

Bước
1

Nội dung thực hiện
Tạo testScript

2

Chỉnh sửa testScript

3

Chạy testScript

4

Đánh giá kết quả

Mô tả

Sử dụng công cụ kiểm thử để ghi lại các thao tác
lên phần mềm và sinh tự động các testScript
Chỉnh testScript để thực hiện kiểm tra đúng yêu
cầu đặt ra, tức alf làm theo ca kiểm thử cần thực
hiện.
Vận hành và giám sát hoạt động kiểm tra phần
mềm bằng testScript
Kiểm tra kết quả sau khi thực hiện kiểm thử tự
động. Bổ sung, chỉnh sửa những sai sót nếu cần.

Bảng 1.1 Các bước sử dụng công cụ để tiến hành kiểm thư tự động

1.2.2. Lợi ích và hạn chế của kiểm thử tự động
Kiểm thử tự động có một số ưu điểm:
 Tiết kiệm thời gian và chi phí
Sau khi xây dựng, cơng cụ kiểm thử tự động có thể làm đi làm lại mà khơng
mất thêm chi phí và nhanh hơn kiểm thử thủ cơng thơng thường. Kiểm thử tự động có
thể giảm thời gian kiểm thử từ thời lượng ngày, sang giờ. Tiết kiệm được thời gian tức
là tiết kiệm được chi phí.
 Tăng độ chính xác
Ngay cả những kiểm thử viên nhiều kinh nghiệm cũng có thể có những sai lầm
khi thực hiện kiểm thử thủ công. Kiểm thử tự động sẽ thực hiện các bước một cách
chính xác vào mọi thời điểm và luôn ghi lại kết quả kiểm thử.
 Tăng độ bao phủ của kiểm thử
Kiểm thử tự động tăng phạm vi của kiểm thử từ đó cải thiện chất lượng phần
mềm. Kiểm thử tự động có thể thực hiện những công việc mà kiểm thử thủ công
không làm được, như chạy trên nhiều máy tính với cấu hình khác nhau. Kiểm thử tự
động có thể “nhìn” bên trong của ứng dụng, xem nội dung của bộ nhớ, bảng dữ liệu,
nội dung tập tin và trạng thái của chương trình để xác định xem sản phẩm có đáp ứng
được mong đợi khơng. Kiểm thử tự động có thể thực hiện hàng nghìn Test Case phức

tạp một cách dễ dàng trong suốt thời gian kiểm thử để bao phủ hết tất cả các trường
hợp.


6

 Kiểm thử tự động làm những việc mà kiểm thử thủ công không làm được
Với một công ty phần mềm lớn nhất cũng không thể thực hiện việc kiểm sốt
ứng dụng web với hàng nghìn người truy cập cùng 1 lúc. Kiểm thử tự động có thể mơ
phỏng hàng chục, hàng trăm hay thậm chí hàng nghìn người sử dụng ảo tương tác với
mạng hay ứng dụng web.
Bên cạnh đó cũng có những khó khăn cơ bản sau [1]:
- Cần chi phí để tạo và bảo trì các đặc tả kiểm thử (script).
- Đòi hỏi kỹ thuật viên phải có kĩ năng sử dụng cơng cụ tạo script.
- Khơng áp dụng được trong việc tìm lỗi mới của phần mềm.

1.2.3. Phân loại cơng cụ kiểm thử tự động
Chi phí kiểm thử phần mềm thường chiếm tới 40% tổng các nỗ lực dành cho
một dự án phát triển phần mềm. Vì thế, các nhà nghiên cứu và người thực hành đã cố
gắng phát triển một số thế hệ các công cụ kiểm thử tự động khác nhau để giúp giảm
thiểu chi phí này. Chúng bao gồm:
- Bộ phân tích tĩnh. Các hệ thống phân tích chương trình hỗ trợ cho “việc
chứng minh” các lỹ lẽ tĩnh để phát hiện những vấn đề yếu kém về cấu trúc
và định dạng của chương trình.
- Bộ kiểm tốn mã. Những bộ lọc chun dụng dùng để kiểm tra chất lượng
chương trình để đảm bảo rằng, nó đáp ứng các chuẩn mã hố tối thiểu.
- Bộ xử lý khẳng định. Những hệ thống tiền xử lý/hậu xử lý này được sử dụng
để cho biết liệu những mệnh đề do người lập trình tạo ra, được gọi là khẳng
định về hành vi của chương trình có thực sự đáp ứng được yêu cầu khi thực
hiện chương trình hay khơng.

- Bộ sinh tệp kiểm thử. Những bộ xử lý sinh ra và điền các giá trị đã xác định
vào các tệp để chương trình đọc vào khi kiểm thử.
- Bộ sinh dữ liệu kiểm thử. Những hệ thống phân tích hỗ trợ cho người dùng
trong việc lựa chọn dữ liệu kiểm thử làm cho chương trình hành xử theo một
cách cụ thể.
- Bộ kiểm chứng kiểm thử. Chúng đo mức bao quát của việc kiểm thử bên
trong, thường liên quan tới cấu trúc điều khiển của sự vật kiểm thử và báo
cáo về giá trị bao quát cho chuyên gia đảm bảo chất lượng.
- Bộ mô phỏng mơi trường. Nó là một hệ thống dựa trên máy tính giúp người
kiểm thử mơ hình hố mơi trường bên ngồi của hệ thời gian thực để mơ
phỏng các điều kiện vận hành thực một cách động.
- Bộ phân tích luồng dữ liệu. Cơng cụ này theo dõi dấu vết luồng dữ liệu đi
qua hệ thống (tương tự như bộ phân tích đường đi) và cố gắng tìm ra những


7

tham chiếu dữ liệu không xác định, đặt chỉ số sai và các lỗi khác có liên
quan tới dữ liệu.
Việc dùng cơng cụ để tự động hố kiểm thử phần mềm đang phát triển, và có thể
sẽ phát triển rất nhanh trong thập kỉ tới. Các công cụ kiểm thử tạo ra những thay đổi
lớn trong kiểm thử phần mềm, đem lại hiệu quả kinh tế cũng như cải tiến độ tin cậy
của các hệ thống dựa trên máy tính một cách đáng kể.


8

Chương 2
Phương pháp sinh ca kiểm thử tự động
Ca kiểm thử (Test Case) là một thành phần mô tả đầu vào, hành động hoặc sự

kiện và một kết quả mong đợi để xác định liệu một chức năng của ứng dụng đó làm
việc đúng khơng. Một trong những lý do quan trọng nhất trong kiểm thử phần mềm là
thiết kế và tạo ra các Test Case có hiệu quả. Chi phí kiểm thử phần mềm thường chiếm
tới 40% tổng các nỗ lực dành cho một dự án phát triển phần mềm. Vì thế, giảm chi phí
cho việc tạo Test Case (thời gian, công sức) cũng là một trong những vấn đề được
quan tâm trong kiểm thử phần mềm. Tự động hố việc tạo Test Case khơng những
giúp giảm chi phí trong việc tạo Test Case mà còn giúp đồng nhất hố chất lượng Test
Case.
Có hai phương pháp tạo Test Case tự động: phương pháp tĩnh và phương pháp
động. Phương pháp tĩnh dựa trên thực thi các ký hiệu mô tả; phương pháp động đạt
được từ dữ liệu cần thiết bằng việc chạy chương trình trong khi kiểm thử.
Đã có nhiều nghiên cứu về việc sinh các Test Case tối ưu dựa trên các đặc tả, tuy
nhiên, không thể đạt 100% các Test Case tối ưu. Từ khi ngôn ngữ mô hình được sử
dụng rộng rãi, đã có rất nhiều nghiên cứu về phương pháp sinh Test Case tự động dựa
trên mơ hình bằng cách sử dụng lược đồ UML như: state-chart diagrams, use-case
diagrams, sequence diagrams,..

2.1. Phương pháp sinh Test Case tự động dựa trên đặc tả
Đặc tả có vai trị quan trọng trong kiểm thử phần mềm. Thứ nhất, đặc tả cung
cấp thông tin để kiểm tra đầu vào/đầu ra của chương trình có đúng khơng. Thứ hai, đặc
tả cung cấp thông tin để lựa chọn Test Case và để đánh giá độ phù hợp của kiểm thử.
Kiểm thử dựa trên đặc tả lấy thông tin kiểm thử từ đặc tả của phần mềm. Trong kiểm
thử phần mềm, kiểm thử dựa trên đặc tả có nhiều ưu điểm. Kiểm thử dựa trên đặc tả
đơn giản hơn các kỹ thuật kiểm thử khơng dựa trên đặc tả. Bên cạnh đó, nhờ phát triển
giai đoạn kiểm thử cùng lúc với việc thực hiện và thiết kế cho phép sử dụng các kiểm
thử đã lấy được để chuẩn hoá đặc tả gốc giúp tăng chất lượng đặc tả - cũng là tăng chất
lượng phần mềm.

2.2.1. Phương pháp sinh Test Case dựa trên đặc tả SCR
Đặc tả SCR (Software Cost Reducation) xây dựng bảng để xác định yêu cầu

hành vi cho hệ thống phần mềm gắn vào thời gian thực. Lợi ích của phương pháp SCR
là: cấu trúc xác định tốt, điều này cho phép sử dụng phương pháp phân tích cấu trúc


9

kiểm tra sự đồng nhất và tính hồn chỉnh của đặc tả. Bên cạnh đó, các ứng dụng SCR
cung cấp khả năng phát hiện dấu vết từ yêu cầu phần mềm với mã nguồn. Phương
pháp sinh Test Case dựa theo đặc tả SCR thiết lập các tiêu chuẩn. Những tiêu chuẩn
này cung cấp một quá trình chuẩn, một phương pháp để đo lường việc kiểm thử và
một nền tảng cho việc tự động hố hồn tồn việc tạo Test Case [10].

2.2.2.1 Mơ hình kiểm thử
Trong mơ hình, kiểm thử được tạo ra như một sản phẩm nhiều mức, nhiều bước
thực hiện và nhiều phần. Các giá trị đầu vào là các giá trị đầu vào của Test Case,
những giá trị này cần thoả mãn trực tiếp các yêu cầu. Các thành phần khác cung cấp
các giá trị hỗ trợ, gồm các kết quả đầu ra được mong đợi, các dữ liệu đầu vào cần thiết
để có trạng thái phù hợp. Mơ hình này định nghĩa Test Case tại bốn mức: (1) mức
chỉnh sửa kế tiếp, (2) mức chỉnh sửa đầy đủ các thuộc tính, (3) mức chỉnh sửa từng cặp
kế tiếp, và (4) mức thứ tự hoàn thành.
Để áp dụng những mức này, các đặc tính/yêu cầu dựa trên trạng thái và xem
như một đồ thị trực tiếp, được gọi là đồ thì đặc tả. Mỗi nút cho thấy một trạng thái
trong đặc tính/yêu cầu, và các cạnh đưa ra những chuyển tiếp có thể.
(1) Mức chỉnh sửa kế tiếp
Mức này tương tự với tiêu chuẩn chỉnh sửa nhánh trong kiểm thử cấu trúc. Mức
chỉnh sửa kế tiếp đòi hỏi mỗi sự chuyển tiếp trong đồ thị đặc tả được thực hiện ít nhất
một lần.
(2) Mức chỉnh sửa đầy đủ các thuộc tính
Sửa đầy đủ các thuộc tính: Mỗi mệnh đề lần lượt lấy giá trị đúng và sai trong
khi tất cả các mệnh đề khác trong thuộc tính đều lần lượt có các giá trị, giá trị của

thuộc tính sẽ luôn giống như mệnh đề được kiểm thử.
 Một mệnh đề là một biểu thức Boolean mà không bao gồm những tốn tử
Boolean. Ví dụ: các biểu thức liên quan và các biến số Boolean là các mệnh đề.
 Một thuộc tính là một biểu thức Boolean gồm các mệnh đề và/khơng/hoặc
nhiều tốn tử Boolean. Một thuộc tính khơng có một tốn tử Boolean cũng là
một mệnh đề. Nếu một mệnh đề xuất hiện hơn một lần trong thuộc tính, mỗi sự
xuất hiện là một mệnh đề riêng biệt.
Mức chỉnh sửa đầy đủ các thuộc tính địi hỏi mỗi mệnh đề trong mỗi thuộc tính
trên mỗi sự chuyển tiếp được kiểm thử một cách độc lập.
Giả sử ta có thuộc tính (X^Y), X là mệnh đề kiểm thử, thì Y phải đúng. Tương
tự như vậy, nếu thuộc tính là (XvY), Y phải là sai.
Để thoả mãn đầy đủ các thuộc tính, ta sử dụng cây biểu thức từng phần. Cây
biểu thức từng phần là một cây nhị phân có nhiều toán tử nhị phân và nhiều toán hạng


10

cho các nút, và các biến hoặc các hằng số tại các nút lá. Các toán tử nhị phân là
AND(^), OR(v), và các toán tử liên quan {> , < , <=, >= , #}; toán tử NOT.
Chỉnh sửa đầy đủ thuộc tính bằng việc đi trên cây. Đầu tiên, một mệnh đề kiểm
thử được chọn. Sau đó cây từng phần được đi từ mệnh đề kiểm thử tới gốc, sau đó từ
gốc đi tới mỗi mệnh đề. Nếu mẹ của nó là V thì anh chị em của nó phải có giá trị
False, nếu cha mẹ của nó là ^, anh chị em của nó phải có giá trị True. Nếu một nút là
toán tử NOT, nút mẹ được cho giá trị ngược của nút con. Điều này lặp lại cho mỗi nút
giữa mệnh đề kiểm thử và mệnh đề gốc.
Khi mệnh đề gốc đã đạt được, các giá trị có thể được sinh ngược trở lại bằng
cách di chuyển cây đơn. Nếu một nút ^ có giá trị True thì cả hai con phải có giá trị
True, nếu một nút ^ có giá trị False thì một trong hai con cũng phải có giá trị False (cái
nào cũng được). Nếu một nút V có giá trị False thì cả hai con phải có giá trị False. Nếu
một nút V có giá trị True, thì một trong hai con phải có giá trị False (cái nào cũng

được). Nếu một nút là toán tử NOT, nút mẹ cho giá trị ngược của nút con.
Một số ngôn ngữ đặc thù, chẳng hạn như SCR, xem xét các biến khởi động sự
kiện khác biệt so với các biến khác trong thuộc tính chuyển tiếp. Trường hợp này,
mệnh đề tương đương với các biến khởi động sự kiện nên đưa ra giá trị khác nhau,
nhưng nên duy trì các biến đó. Nếu nó khơng cịn là một biến khởi động nữa tương
đương với việc khơng Test Case. Thêm vào đó, một biến khởi động sự kiện thực tế xác
định hai giá trị, một giá trị trước và một giá trị sau. Để kiểm thử đầy đủ các thuộc tính
với các biến khởi động sự kiện, cả giá trị trước và sau nên được kiểm thử. Điều này
được thực hiện bằng việc giả định hai phiên bản của biến khởi động sự kiện, A và A',
ở đó A đưa ra giá trị trước và A' cho ra giá trị sau.
(3) Mức chỉnh sửa các cặp chuyển tiếp.
Mức chỉnh sửa cặp chuyển tiếp: Với mỗi trạng thái S tạo nên các yêu cầu kiểm
thử. Giả sử cho mỗi chuyển tiếp đến và đi, cả hai sự chuyển tiếp phải được thực hiện
tuần tự.
Giả sử có trạng thái sau:
1

P2
2

i

Pi

P1

S

Pii


ii

Piii
iii

Để kiểm trử trạng thái S ở mức độ cặp chuyển tiếp, phải kiểm thử 6 lần: (1) từ 1
đến i, (2) từ 2 đến i, (3) từ 1 đến ii, (4) từ 2 đến ii, (5) từ 1 đến iii, (6) từ 2 đến iii. Việc


11

kiểm thử này đòi hỏi các đầu vào phải thoả mãn các thuộc tính: P1:Pi, P1:Pii, P1:Piii,
P2:Pi, P2:Pii và P2:Piii.
(4) Mức tuần tự hoàn chỉnh
Mức tuần tự hoàn chỉnh là sự chuyển tiếp trạng thái tuần tự từ đó trạng thái sử
dụng thực tiễn hoàn chỉnh của hệ thống.
Tại mức tuần tự hoàn chỉnh: Tester phải xác định tuần tự đầy đủ của các chuyển
tiếp trên đồ thị đặc tả bằng cách chọn các tuần tự trạng thái. Đôi khi việc chọn các tuần
tự trạng thái dựa vào kiến thức và kinh nghiệm của chính tester. Đây là một mức độ tự
động hóa ít nhất của q trình kiểm thử.

2.2.2.2 Tổng kết
Quy trình chung được chỉ ra ở hình 2.1, hay nói một cách đơn giản đây là các
bước của quy trình sinh ra Test Case từ đặc tả SCR.
Đặc tả chức năng

Đồ thị đặc tả

Yêu cầu kiểm thử


Đặc tả kiểm thử

Kịch bản kiểm thử

Hình 2.1 Quy trình chung của việc tạo ra các Test Case từ đặc tả SCR
Quy trình sinh ra Test Case từ đặc tả SCR gồm các bước sau:
- Bước 1: Phát triển các điều kiện chuyển tiếp. Với một số ngơn ngữ đặc tả (ví
dụ SCR), các điều kiện chuyển tiếp được mã hóa trực tiếp trong các đặc tả (đặc tả chức
năng). Với các ngơn ngữ khác, các điều kiện có thể phải qua một thao tác chuyển hoá
khác.
- Bước 2: Phát triển các đồ thị đặc tả. Ta có thể lấy trực tiếp đồ thị đặc tả từ
bảng đặc tả.
- Bước 3: Phát triển các yêu cầu kiểm thử. Các yêu cầu kiểm thử xuất phát từ
các đặc tính chuyển tiếp và được tạo ra từ các điều kiện chuyển tiếp ở bước 1.
- Bước 4: Phát triển các yêu cầu kiểm thử thuộc tính đầy đủ. Xây dựng các bảng
chân lý cho tất cả các thuộc tính trong đồ thị đặc tả, từ đó xây dựng cây biểu thức từng


12

phần. Ta có thể dựa trên cây biểu thức từng phần hoặc dựa trực tiếp vào đặc tả để kiểm
thử chỉnh sửa các thuộc tính.
- Bước 5: Phát triển các yêu cầu kiểm thử cặp chuyển tiếp. Xác định tất cả các
cặp chuyển tiếp bằng cách: Liệt kê tất cả các chuyển tiếp đầu vào (M), tất cả các
chuyển tiếp đầu ra (N), sau đó tạo ra các cặp M*N chuyển tiếp. Những cặp chuyển tiếp
này sẽ được thay thế bởi các thuộc tính từ đồ thị đặc tả.
- Bước 6: Phát triển các yêu cầu kiểm thử hoàn chỉnh. Xác định danh sách hoàn
chỉnh của các trạng thái bằng cách: từ biểu đồ đặc tả, chọn trình tự của các trạng thái
(công việc này do tester đảm nhiệm). Sau đó, xây dựng trình tự của các thuộc tính.
- Bước 7: Xây dựng các đặc tả kiểm thử. Với mỗi một yêu cầu kiểm thử tạo ra

các giá trị tiền tố, các giá trị Test Case, xác nhận các điều kiện, giải phóng các điều
kiện, và các kết quả mong muốn.
- Bước 8: Xây dựng các tập lệnh kiểm thử. Mỗi đặc tả kiểm thử sử dụng để xây
dựng một tập lệnh. Các tập lệnh kiểm thử phản ánh cú pháp đưa vào của chương trình,
vì vậy cần có sự am hiểu về cú pháp đưa vào của chương trình.

2.2.2. Phương pháp sinh Test Case dựa trên đặc tả UML
Đặc tả UML mô tả hành vi của đối tượng, do đó, xây dựng Test Case từ đặc tả
UML sẽ kiểm thử được tồn bộ hành vi của đối tượng.

2.2.2.1 Mơ hình kiểm thử
Trạng thái của một đối tượng là sự kết hợp của tất cả các giá trị của thuộc tính
và các đối tượng mà đối tượng có. Trạng thái động của đối tượng được mơ hình hóa
thơng qua sự chuyển đổi từ một trạng thái này sang trạng thái khác. Trong UML có
năm loại chuyển trạng thái sau: chuyển trạng thái ở mức cao, chuyển trạng thái phức
hợp, chuyển trạng thái bên trong, chuyển trạng thái hoàn thành, chuyển trạng thái khả
năng. Vì mục đích sinh ra mơ hình nên ta chỉ xem xét đến chuyển trạng thái khả năng.
Trạng thái khả năng được kích hoạt khi tồn tại ít nhất một đường dẫn hoàn chỉnh từ
trạng thái nguồn đến trạng thái đích [11].
Sự kiện xuất hiện khi đối tượng chuyển từ trạng thái này sang trạng thái khác.
UML xác định bốn loại sự kiện: sự kiện gọi (call event), sự kiện tín hiệu (signal
event), sự kiện thời gian (time event), và sự kiện thay đổi (change event).
Một sự kiện gọi đưa ra sự tiếp nhận của một yêu cầu để thực hiện một hoạt
động nhất đinh. Kết quả mong đợi là một sự thực hiện của một trình tự các hành động
mà tiêu biểu là hành vi tại một trạng thái cụ thể. Sự tạo và phá hủy đối tượng là hai
trường hợp đặc biệt của một sự kiện gọi. Hình 2.2 minh họa một sự kiện gọi.


13
event

startAutopilot(normal)
Manual

Automatic
Paramenters

Hình 2.2 Sự kiện gọi (call events)1
MovementAgent

Signal

<<signal>>
Collision
Force:Float

Position
velocity
<<send>>

MoveTo()

Send dependency

Parameters

Hình 2.3 Sự kiện tín hiệu (signal events)1
Một sự kiện tín hiệu đưa ra sự chấp nhận của một dấu hiệu đồng bộ cụ thể. Các
sự kiện tín hiệu được mơ hình hóa như các loại được dập khn đưa ra trong hình 2.3.
Sự phụ thuộc của sự kiện Send chỉ ra rằng một thao tác đưa một dấu hiệu cụ thể.
Một sự kiện thời gian đưa ra sự chuyển qua của một khoảng thời gian được chỉ

định sau một sự kiện được chỉ định (thường là đầu vào của một trạng thái hiện tại)
hoặc sự kiện của một thời gian nhất định. Trong UML, sự kiện thời gian được mơ hình
hóa bằng sử dụng các từ khóa After được theo sau bởi một vài biểu thức mà đánh giá
tới một khoảng thời gian. Hình 2.4 minh họa một sự kiện thời gian.

1

Tham khảo theo tài liệu [11].


14
time event

Idle

after (2 seconds)
/dropConnection()

Active
Hình 2.4 Sự kiện thời gian (time Events) 1
Một sự kiện thay đổi xuất hiện khi một biểu thức boolean rõ ràng trở thành
đúng như một kết quả của một sự thay đổi trong giá trị của một hoặc nhiều các thuộc
tính hoặc các kết hợp. Một sự kiện thay đổi được đưa rõ ràng và không là kết quả của
một hành động thay đổi sự kiện. Sự kiện thay đổi thì khác với một sự bảo vệ, một sự
bảo vệ không chỉ được đánh giá tại thời điểm một sự kiện được gửi đi, ngược lại dựa
trên các khái niệm biểu thức boolean kết hợp với một sự kiện thay đổi được đánh giá
liên tục cho tới khi nó trở thành đúng. Sự kiện mà được tạo ra vẫn cịn cho tới khi nó
được sử dụng thậm chí nếu biểu thức boolean biến thành sai. Trong UML, sự kiện thay
đổi được mơ hình hóa bởi việc sử dụng từ khóa when được theo sau bởi một vài biểu
thức boolean. Hình 2.5 minh họa một sự kiện thay đổi.

when(11:49PM) / selfTest()

Change event

Idle
Hình 2.5 Sự kiện thay đổi (Change Events) 1
Trong số bốn loại sự kiện, sự kiện thay đổi có thể diễn đạt như một thuộc tính.
Sau đây, chúng ta áp dụng mơ hình tạo Test Case đặc tả dựa trên trạng thái tới sự
chuyển trạng thái khả năng với sự kiện thay đổi.
(1) Mức độ chỉnh sửa chuyển tiếp
Chỉnh sửa chuyển tiếp: Mỗi chuyển tiếp được phép trong biểu đồ trạng thái
được thực hiện ít nhất một lần.


15

(2) Mức chỉnh sửa thuộc tính đầy đủ
Chỉnh sửa thuộc tính đầy đủ: Mỗi mệnh đề lần lượt lấy giá trị đúng và sai trong
khi tất cả các mệnh đề khác trong thuộc tính có các giá trị chẳng hạn giá trị của thuộc
tính sẽ ln như là giá trị của mệnh đề được kiểm thử.
(3) Mức chỉnh sửa cặp chuyển tiếp
Mức chỉnh sửa cặp chuyển tiếp: Với mỗi trạng thái S, tạo thành các yêu cầu
kiểm thử chẳng hạn cho mỗi chuyển tiếp tiếp theo và mỗi chuyển tiếp trong tương lai,
cả hai chuyển tiếp phải được thực hiện tuần tự.
(4) Mức độ tuần tự hoàn chỉnh
Mức độ tuần tự hoàn chỉnh: Kỹ sư kiểm thử phải xác định các trình tự đầy đủ ý
nghĩa của các chuyển tiếp trên biểu đồ trạng thái bằng việc chọn các trình tự của các
trạng thái nên được đưa vào.

2.2.2.2 Tổng kết

Hình 2.6 đưa ra quy trình chung tạo ra các Test Case.
Trạng thái UML

Phát triển điều kiện chuyển tiếp
Yêu cầu kiểm thử
Đặc tả kiểm thử

Kịch bản kiểm thử

Hình 2.6 Quy trình tạo ra các Test Case từ đặc tả UML
Quy trình tạo ra Test Case từ đặc tả UML gồm các bước:
- Bước 1: Phát triển các điều kiện chuyển tiếp. Bước đầu tiên là được phát triển
các điều kiện chuyển tiếp, được xác định những điều kiện mỗi chuyển tiếp được thực
hiện. Trong UML, các điều kiện được mã hóa trực tiếp trong các đặc tả.
- Bước 2: Phát triển các yêu cầu kiểm thử chỉnh sửa chuyển tiếp. Lấy các thuộc
tính chuyển tiếp. Các điều kiện từ bước 1 được liệt kê một lần tại thời điểm tạo các yêu
cầu kiểm thử.
- Bước 3: Phát triển các yêu cầu kiểm thử thuộc tính đầy đủ. Xây dựng các bảng
chân lý cho tất cả các thuộc tính trong đồ thị đặc tả, từ đó xây dựng cây biểu thức từng


16

phần. Ta có thể dựa trên cây biểu thức từng phần hoặc dựa trực tiếp vào đặc tả để kiểm
thử chỉnh sửa các thuộc tính.
- Bước 4: Phát triển các yêu cầu kiểm thử cặp chuyển tiếp. Phát triển các yêu
cầu kiểm thử cặp chuyển tiếp. Xác định tất cả các cặp chuyển tiếp bằng cách: Liệt kê
tất cả các chuyển tiếp đầu vào (M), tất cả các chuyển tiếp đầu ra (N), sau đó tạo ra các
cặp M*N chuyển tiếp. Những cặp chuyển tiếp này sẽ được thay thế bởi các thuộc tính
từ đồ thị đặc tả.

- Bước 5: Phát triển các u cầu kiểm thử trình tự hồn chỉnh. Xác định danh
sách hoàn chỉnh của các trạng thái bằng cách: từ biểu đồ đặc tả, chọn trình tự của các
trạng thái (công việc này do tester đảm nhiệm). Sau đó, xây dựng trình tự của các
thuộc tính.
- Bước 6: Xây dựng các đặc tả kiểm thử. Với mỗi một yêu cầu kiểm thử tạo ra
các giá trị tiền tố, các giá trị Test Case, xác nhận các điều kiện, giải phóng các điều
kiện, và các kết quả mong muốn.
- Bước 7: Xây dựng các tệp kiểm thử. Mỗi đặc tả kiểm thử được sử dụng để xây
dựng một tệp kiểm thử. Các tệp này cụ thể phải phản ánh cú pháp đưa vào của một
chương trình, do đó cần có sự hiểu biết về cú pháp đưa vào của chương trình.

2.2. Phương pháp sinh Test Case tự động dựa trên Mơ hình
Phương pháp sinh Test Case dưa trên Mơ hình là phương pháp tập trung vào việc
sử dụng các biểu đồ trong UML như biểu đồ trạng thái, biểu đồ lớp, lược đồ use-case,..
để sinh Test Case.
Sử dụng các biểu đồ trạng thái trong việc tạo ra các Test Case định ra các tiêu
chuẩn cho cả test tĩnh và động của các biểu đồ cộng tác các mức.
Sử dụng lược đồ use-case trong việc tạo ra Test Case cho phép sinh ra các Test
Case mang tính hệ thống, giúp dẫn chứng các tài liệu về cách sử dụng và hành vi
tương tác.
Quy trình này giúp cho việc nâng cao chất lượng phần mềm một cách hiệu quả.

2.2.1. Phương pháp sinh Test Case dựa trên biểu đồ cộng tác UML.
Biểu đồ cộng tác UML mơ tả chính xác chức năng của phần mềm. Bên cạnh đó,
biểu đồ cộng tác UML cung cấp một kết nối trong một hình thức mà có thể dễ dàng
được vận dụng để tự động hoá. Tạo Test Case tự động dựa trên biểu đồ cộng tác UML
là một trong những phương pháp tiêu biểu sinh Test Case dựa trên mơ hình.

2.2.1.1 Các biểu đồ cộng tác
Mô ̣t biể u đồ cô ̣ng tác là mô ̣t sự mô tả đồ ho ̣a của mô ̣t sự cô ̣ng tác . Cộng tác là

một phần mô tả của một tập hợp của các đối tượng mà tương tác để thực hiện một vài
hành vi bên trong một ngữ cảnh. Nó gồm các đường rãnh (Slots) được điền vào bởi


17

các đối tượng và các đường liên kết tại thời điểm chạy. Một rãnh cộng tác được gọi là
một vai trị (role) bởi vì nó mơ tả mục đích của một đối tượng hoặc đường liên kết bên
trong cộng tác .
Mô ̣t sự cô ̣ng tác gồ m các ClassifierRoles , AssociationRoles, và Interaction . Mô ̣t
ClassifierRole xác đinh
̣ vai trò để đươ ̣c tham gia bởi mô ̣t đố i tươ ̣ng (Object) bên trong
mô ̣t sự cô ̣ng tác . Mô ̣t AssociationRole xác đinh
̣ các mố i qua n hê ̣ của ClassifierRole tới
các vai trò khác. Mô ̣t Interaction là mô ̣t chuỗi của các liên kế t trong mô ̣t bô ̣ các đố i
tươ ̣ng bên trong mô ̣t đă ̣c tả để thực hiê ̣n mô ̣t mu ̣c tiêu cu ̣ thể .
Mô ̣t thao tác là mô ̣t đă ̣c tả của mô ̣t sự chuyể n
đổ i hoă ̣c xế p hàng mà mô ̣t đố i
tươ ̣ng có thể đươ ̣c yêu cầ u thực hiê ̣n . Nó có một cái tên và một danh sách các tham số .
Mô ̣t phương pháp là mô ̣t thủ tu ̣c mà thực hiê ̣n mô ̣t thao tác đó . Nó là một thuật tốn
hoă ̣c mơ ̣t phầ n mô tả thủ tục.
Các đối tượng trong một biểu đồ cộng tác là các trường hợp của các lớp trong
mơ ̣t biể u đờ lớp.
Có 2 dạng biểu đồ cộng tác: biểu đồ cộng tác mức đặc tả và biểu đồ cộng tác
mức thao tác. Biểu đồ cộng tác mức đặc tả cho thấy các vai trò được xác định bên
trong một sự cộng tác. Biểu đồ gồm một tập hợp của các lớp và các đường tương
đương tới ClassifierRoles và AssociationRoles trong sự cộng tác; Biểu đồ cộng tác
mức thao tác dùng để mô tả thao tác trên đối tượng, cung cấp các thông tin xác định,
chẳng hạn (1) các tham số cho thao tác và cách sử dụng chúng, (2) các tính chất của
việc tham gia vào các biến, ví dụ cục bộ hoặc tồn cục, (3) các ràng buộc qua các kết

hợp, và (4) việc xây dựng và/hoặc bỏ đi của các đối tượng trong quá trình.

2.2.1.2 Các tiêu ch̉n test
Các biểu đồ cộng tác mơ tả cấu trúc và hành vi của hệ thống . Mô ̣t biể u đồ cô ̣ng
tác UML xác định những u cầu gì phải được hồn thành bởi các đối tượng trong một
hê ̣ thố ng, và những liên kế t gì phải đươ ̣c thực hiê ̣n giữa các đố i tươ ̣ng cho mô ̣t công
viê ̣c cu ̣ thể đươ ̣c thực hiê ̣n . Các biểu đồ cộng tác UML được sử dụng ở các mức độ
trừu tươ ̣ng đă ̣c tả khác nhau . Với các biể u đồ cô ̣ng tác hoă ̣c các biể u đồ lớp với các
biể u đồ cô ̣ng tác, có thể được sử dụng để kiểm tra tĩnh mã và test việc chạy ứng dụng.
(1) Mô ̣t số đinh
̣ nghiã
Trước khi xác đinh
̣ các tiêu chuẩ n test ta xác đinh
̣ 12 loại có thể kết nối trong các
biể u đồ cô ̣ng tác. Các loại của các cặp hoặc các đường link, là gọi lại về các định nghĩa
về luồ ng dữ liê ̣u , nhưng đưa ra các tương tác dữ liê ̣u mà xuấ t hiê ̣n ở mô ̣t mức đô ̣ thiế t
kế cao hơn luồ ng dữ liê ̣u tryề n thố ng . Chúng được phân loại dựa trên thông tin từ các
biểu đồ lớp và các biểu đồ cộng tác, nhưng một khi đã định nghĩa, chỉ các biểu đồ
cộng tác cần để tạo ra các test.


18

Một cặp cộng tác là một cặp của ClassifierRolers hoặc AssociationRoles mà được
kết nối thông qua một đường link trong biểu đồ cộng tác. Phần ClassifierRolers mô tả
loại của Object với một bộ của các thao tác và thuộc tính được yêu cầu.
Một đường link định nghĩa biến số là một đường link mà các tác nhân hoạt động
của nó có một giá trị trả lại và được gán vào biến cục bộ. Một đường link cách sử dụng
biến số là một đường link mà danh sách đối số của các tác nhân hoạt động gồm một
biến cục bộ. Một đường link định nghĩa đối tượng là một tác nhân hoạt động mà đưa

lại một tham chiếu tới một đối tượng mà có thể sử dụng được cho đối tượng mục tiêu.
Sử dụng một đường link tạo ra đối tượng là một đường link các tác nhân hoạt động của
nó dẫn chứng tạo ra của lớp CollaborationRole. Một đường link cách sử dụng đối
tượng là một đường link mà các tác nhân hoạt động của nó dẫn chứng một phương
thức về một đối tượng có thể sử dụng cục bộ. Một đường link phá hủy một đối tượng
là một đường link mà các tác nhân hoạt động của nó dẫn chứng phá hủy về một đối
tượng có thể sử dụng cục bộ.
Đôi khi chúng ta quan tâm đến các cặp của các đường link. Một cặp đường link
sử dụng khác của biến số là một cặp của các đường link mà trong đó một đối tượng
trước tiên được sử dụng và sau đó bị bỏ đi. Một đường dẫn chuỗi các tin nhắn là một
đường dẫn mà gồm tất cả tin nhắn trong một cộng tác theo một trật tự được xác định
bởi một biểu đồ cộng tác.
Các cặp đường link cách sử dụng định nghĩa biến số, các cặp đường link cách sử
dụng tạo ra đối tượng có thể được sử dụng để kiểm tra tĩnh các mã. Các đường dẫn
chuỗi tin nhắn có thể được sử dụng để tạo ra các Test Case.
(2) Kiểm tra tĩnh
Kiểm tra có thể thực hiện tĩnh hoặc động. Ở khía cạnh nào đó phần mềm được
thực hiện trên một vài dữ liệu nhập. Kiểm tra tĩnh liên quan tới một vài khía cạnh của
phần mềm mà không cần thực hiện, thường bằng cách đánh giá mã nguồn.
Các biểu đồ cộng tác cung cấp các ràng buộc trên một hệ thống. Ví dụ, một biểu
đồ cộng tác cho một thao tác mô tả thông tin cụ thể mà cần thiết cho thao tác này để
được hoàn thành, chẳng hạn các giá trị trả lại cho một phương thức trong một quá
trình, các loại tham số, vv…
Chúng ta xác định bốn mục nên được sử dụng để kiểm tra mã tĩnh, được mô tả
như sau:
1. ClassifierRoles: Trong một động tác, nếu hai ClassifierRoles bắt nguồn cùng
một lớp cơ sở giống nhau, chúng nên được phân biệt trong điều kiện của các thao tác
được yêu cầu của chúng và các giá trị của các thuộc tính. Bởi vì chúng bắt đầu tư cùng
lớp, có khả năng rằng chúng có thể nhầm lẫn với nhau. Vì lí do này, ClassifierRoles
mà bắt đầu từ cùng lớp nên được test để biết nếu chúng có tất cả các thuộc tính và các

thao tác được yêu cầu.