Kiểm thử phần mềm Hướng đối tượng trên Biểu đồ lớp

MỞ ĐẦU
Cùng với sự phát triển vượt bậc của Công nghệ
thông tin, đặc biệt trong lĩnh vực Công nghệ phần mềm,
hoạt động kiểm thử đã được đặc biệt chú trọng, thu hút sự
tập trung nghiên cứu của các nhà khoa học, các học giả
trên toàn thế giới. Song, bên cạnh những thành tựu khoa
học, hoạt động kiểm thử vẫn chưa thể khẳng định được
rằng một sản phẩm phần mềm ra đời có chắc chắn đảm
bảo tính đúng đắn, có lỗi hay không.
Ngày nay, với sự phổ dụng và tính ưu việt của kỹ
thuật lập trình hướng đối tượng, sản phẩm phần mềm đã
có những bước đột phá về chất lượng. Tuy nhiên, vấn đề
kiểm soát lỗi và hoàn thiện sản phẩm vẫn gặp rất nhiều
khó khăn. Một trong những nguyên nhân dẫn đến tình
trạng trên là do chúng ta chưa nhận thức đầy đủ ý nghĩa
của hoạt động kiểm thử khi thực hiện các giai đoạn trong
tiến trình phát triển phần mềm; các phương pháp kiểm
thử truyền thống vẫn được sử dụng phổ biến. Hơn nữa,
độ phức tạp của phần mềm ngày càng cao; sự linh hoạt,
mềm dẻo và những đặc điểm đa dạng của kỹ thuật lập

1


trình hướng đối tượng, nếu người phát triển phần mềm
không cẩn thận, đôi khi sẽ trở nên nhập nhằng, dễ phát
sinh lỗi.
Với thực trạng và yêu cầu trên, việc kiểm thử các
hệ thống hướng đối tượng cần phải được nghiên cứu kỹ,
có chiều sâu; trong đó kiểm thử hệ thống hướng đối
tượng dựa trên các mô hình hợp nhất là một trong những

phương pháp có thể tiếp cận nghiên cứu.
Mô hình hợp nhất có tính ưu việt về mặt mô hình
hóa một cách trực quan. Ngày nay, ngôn ngữ mô hình
hóa hợp nhất (UML) đã trở thành công cụ quen thuộc
trong tiến trình phát triển hệ thống hướng đối tượng
(HTHĐT). Một trong những dạng biểu đồ thường
dùng để thực hiện việc mô hình hóa là biểu đồ lớp. Biểu
đồ lớp không những cho ta cách nhìn tổng quan về cấu trúc
mà còn thể hiện hành vi của hệ thống. Một cách chủ quan
rằng, hoạt động kiểm thử dựa trên biểu đồ lớp sẽ tối ưu và
mang lại hiệu quả cao cho nguồn tài nguyên cần chi phí
trong hoạt động này. Bởi vậy, chúng em tiến hành tìm hiểu
về vấn đề kiểm thử HTHĐT trên biểu đồ lớp
Hưng Yên, ngày…tháng…năm 2013
2


Nhóm sv thực hiện
Phạm Thị Thanh Hải
Nguyễn Thị Dung
Đỗ Thj Giang

3


1. Mục đích nghiên cứu
Đề tài có tên “Tìm hiểu về kiểm thử hệ thống
hướng đối tượng (object orient system testing)” được
thực hiện với mục đích đưa ra giải pháp và quy trình
kiểm thử HTHĐT dựa trên biểu đồ lớp.

Mục tiêu của đề tài là trình bày một cách tổng quan
về kiểm thử HTHĐT dựa trên lớp và đưa ra quy trình áp
dụng thực tế.
Để đạt được mục tiêu, đề tài cần thực hiện các nhiệm vụ sau:
- Tìm hiểu HTHĐT; UML và biểu đồ lớp (Class Diagram).
- Nghiên cứu về kiểm thử hướng đối tượng (OOT).
- Xây dựng quy trình kiểm thử HTHĐT dựa trên biểu đồ
lớp.
- Ứng dụng quy trình vào HTHĐT cụ thể, từ đó đưa ra
đánh giá tính hiệu quả của quy trình đề xuất.

2. Đối tượng và phạm vi nghiên cứu
2.1. Đối tượng nghiên cứu


- Lý thuyết về HTHĐT, UML và biểu đồ lớp.
- Kiểm thử hướng đối tượng (OOT), kiểm thử lớp.
- Một số kỹ thuật kiểm thử hướng đối tượng (OOT).
2.2. Phạm vi nghiên cứu
- Đặc trưng, tính chất của HTHĐT.
- Kiểm thử HTHĐT: cơ sở lý thuyết, các kỹ thuật
kiểm thử.
- Kiểm thử HTHĐT mức lớp (Class Testing).


CHƯƠNG 1
HỆ THỐNG HƯỚNG ĐỐI TƯỢNG
VÀ KIỂM THỬ PHẦN MỀM
1.1.
1.1.1.

HỆ THỐNG HƯỚNG ĐỐI TƯỢNG
Một số khái niệm

1.1.1.1. Đối tượng (Object)
Đối tượng là sự kết hợp giữa dữ liệu và thủ tục ( hay
còn gọi là các phương thức – method) thao tác trên dữ liệu
đó. Có thể đưa ra công thức phản ánh bản chất kỹ thuật lập
trình hướng đối tượng như sau:
Đối tượng=Dữ liệu + Phương thức
1.1.1.2. Lớp (Class)
Lớp là một tập các đối tượng có cấu trúc dữ liệu và các
phương thức giống nhau( hay nói cách khác là một tập các
đối tượng cùng loại). Như vậy khi có một lớp thì chúng ta sẽ
biết được một mô ta cấu trúc dữ liệu và phương thức của các
đối tượng thuộc lớp đó. Một đối tượng sẽ là một thể hiện cụ
thể của lớp đó. Trong lập trình, chúng ta có thể coi một lớp
như là một kiểu dữ liệu, còn các đối tượng sẽ là các biến có
kiểu là lớp.
1.1.1.3. Lớp con (SubClass)


Lớp con là một lớp thông thường nhưng có thêm tính chất
kế thừa một phần hay toàn bộ các đặc tính của một lớp
khác. Lớp chia sẻ sự kế thừa gọi là lớp cha (parent class). ll
1.1.1.4. Lớp trừu tượng (Abstract Class)
Lớp trừu tượng là một lớp mà nó không thể thực thể hóa
thành một đối tượng thực dụng được. Lớp này được thiết
kế nhằm tạo ra một lớp có các đặc tính tổng quát nhưng bản
thân lớp đó chưa có ý nghĩa (hay không đủ ý nghĩa) để có

thể tiến hành viết mã cho việc thực thể hóa.
Thí dụ: Lớp "hinh" được định nghĩa không có dữ liệu nội tại
và chỉ có các phương thức "tinh_chu_vi", "tinh_dien_tich".
Nhưng vì lớp hinh này chưa xác định được đầy đủ các đặc
tính của nó (cụ thể các biến nội tại là tọa độ các đỉnh nếu là
đa giác, là đường bán kính và toạ độ tâm nếu là hình tròn, ...)
nên nó chỉ có thể được viết thành một lớp trừu tượng. Sau
đó, người lập trình có thể tạo ra các lớp con chẳng hạn như
là lớp "tam_giac", lớp "hinh_tron", lớp "tu_giac",.... Và
trong các lớp con này người viết mã sẽ cung cấp các dữ liệu
nội tại (như là biến nội tại r làm bán kính và hằng số nội tại
Pi cho lớp "hinh_tron" và sau đó viết mã cụ thể cho các
phương thức "tinh_chu_vi" và "tinh_dien_tich").
1.1.2.

Các tính chất cơ bản

1.1.2.1. Tính trừu tượng (Abstraction


Đây là khả năng của chương trình bỏ qua hay không chú
ý đến một số khía cạnh của thông tin mà nó đang trực tiếp
làm việc lên, nghĩa là nó có khả năng tập trung vào những
cốt lõi cần thiết. Mỗi đối tượng phục vụ như là một "động
tử" có thể hoàn tất các công việc một cách nội bộ, báo cáo,
thay đổi trạng thái của nó và liên lạc với các đối tượng khác
mà không cần cho biết làm cách nào đối tượng tiến hành
được các thao tác. Tính chất này thường được gọi là sự
trừu tượng của dữ liệu.
Tính trừu tượng còn thể hiện qua việc một đối tượng ban

đầu có thể có một số đặc điểm chung cho nhiều đối tượng
khác như là sự mở rộng của nó nhưng bản thân đối tượng
ban đầu này có thể không có các biện pháp thi hành.
1.1.2.2. Tính thừa kế (Inheritance)
Đặc tính này cho phép một đối tượng có thể có sẵn các
đặc tính mà đối tượng khác đã có thông qua kế thừa. Điều
này cho phép các đối tượng chia sẻ hay mở rộng các đặc
tính sẵn có mà không phải tiến hành định nghĩa lại. Tuy
nhiên, không phải ngôn ngữ định hướng đối tượng nào
cũng có tính chất này.
1.1.2.3. Tính đa hình (Polymorphism)
Thể hiện thông qua việc gửi các thông điệp (message).
Việc gửi các thông điệp này có thể so sánh như việc gọi các


hàm bên trong của một đối tượng. Các phương thức dùng trả
lời cho một thông điệp sẽ tùy theo đối tượng mà thông điệp
đó được gửi tới sẽ có phản ứng khác nhau. Người lập trình
có thể định nghĩa một đặc tính (chẳng hạn thông qua tên của
các phương thức) cho một loạt các đối tượng gần nhau
nhưng khi thi hành thì dùng cùng một tên gọi mà sự thi hành
của mỗi đối tượng sẽ tự động xảy ra tương ứng theo đặc tính
của từng đối tượng mà không bị nhầm lẫn.
Thí dụ khi định nghĩa hai đối tượng "hinh_vuong" và
"hinh_tron" thì có một phương thức chung là "chu_vi". Khi
gọi phương thức này thì nếu đối tượng là "hinh_vuong" nó
sẽ tính theo công thức khác với khi đối tượng là "hinh_tron".
1.1.2.4. Tính đóng gói (Encapsulation)
Tính chất này không cho phép người sử dụng các đối
tượng thay đổi trạng thái nội tại của một đối tượng. Chỉ có

các phương thức nội tại của đối tượng cho phép thay đổi
trạng thái của nó. Việc cho phép môi trường bên ngoài tác
động lên các dữ liệu nội tại của một đối tượng theo cách
nào là hoàn toàn tùy thuộc vào người viết mã. Đây là tính
chất đảm bảo sự toàn vẹn của đối tượng.
1.1.3.

Ngôn ngữ mô hình hóa hợp nhất (UML)

1.1.3.1. Định nghĩa
UML là ngôn ngữ mô hình hóa thống nhất có phần chính


bao gồm những kí hiệu hình học được các phương pháp
hướng đối tượng sử dụng để thể hiện và miêu tả thiết kế
của một hệ thống.
1.1.3.2. Ý nghĩa của UML
 UML là ngôn ngữ dùng để trực quan hóa
 UML là ngôn ngữ đặc tả
 UML là ngôn ngữ dùng để xây dựng
 UML là ngôn ngữ dùng để lập tài liệu
1.1.3.3. Các thành phần của UML
 Các phần tử
 Các quan hệ
 Các biểu đồ
1.1.4.

Biểu đồ lớp (Class Diagram)

1.1.4.1. Khái niệm

Một biểu đồ lớp là một dạng mô hình tĩnh miêu tả hướng
nhìn tĩnh của một hệ thống bằng các khái niệm lớp và mối
quan hệ giữa chúng với nhau. Một trong các mục đích của
biểu đồ lớp là tạo nền tảng cho các biểu đồ khác, thể hiện
các khía cạnh khác của hệ thống.
1.1.4.2. Các thành phần của biểu đồ lớp
 Lớp (Class): Thuộc tính (attribute), Phương thức


(method)
 Mối quan hệ giữa các lớp

1.2.

TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM

1.2.1.

Khái niệm

1.2.2.

Quy trình kiểm thử phần mềm
Thực
hiện
Lập

Thiết

Phát

kiểm

kế

kế

triển

thử

hoạc

Test

Test

h

case

script

Đánh giá

Hình 1.15. Qui trình kiểm thử phần mềm
1.2.2.1. Lập kế hoạch và điều khiển test
- Đầu vào:
Customer requirements
Project plan

- Đầu ra:


Tài liệu Test plan
Các nhiệm vụ chính:
• Xác định phạm vi và rủi ro khi thực hiện test
• Xác định hướng tiếp cận (techniques, test items,
coverage…)
• Xác định chính sách và chiến lược test
• Xác định nguồn tài nguyên cho test (e.g. people, test
environment,
• PCs)
• Lập kế hoạch cho nhiệm vụ tiếp theo: phân tích
và thiết kế test, triển khai và thực thi test, đánh
giá test
• Xác định điều kiện dừng test
1.2.2.2. Phân tích và thiết kế test
Đầu vào: SRS, Detail design,Test plan
Đầu ra: Tài liệu Test design
Xem xét lại toàn bộ tài liệu dự án (phân tích rủi ro
sản phẩm, yêu cầu, kiến trúc, thiết kế ..)
Xác định các điều kiện test dựa trên việc phân tích các
danh mục test, đặc tả của chúng…
Thiết kế test: xác định test case
Đánh giá khả năng test được của yêu cầu và hệ thống
Thiết lập môi trường kiểm thử và xác định cơ sở vật chất và


các công cụ cho test
1.2.2.3.

Triển khai và thực thi test

- Triển khai test:
Đầu vào: SRS, Use case, Test Design document
Đầu ra: Test case, Test script, Test data
- Thực thi test:
Đầu vào: Software/Product, Test case, Test script, Test data
Đầu ra: Defect list, Issue list, Test log.
1.2.2.4. Đánh giá điều kiện kết thúc và báo cáo test
- Đầu vào: Test Log, Test Plan
- Đầu ra: Test Report
Đánh giá điều kiện kết thúc là hoạt động để đánh giá
thực thi kiểm thử với mục tiêu đặt ra
Gồm các nhiệm vụ chính sau:
-

Kiểm tra test log với điều kiện dừng test đã đề ra
trong bản thế hoạch

-

Đánh giá xem có cần test thêm hay có nên thay đổi
điều kiện dừng.

-

Báo cáo tóm tắt test cho các bên.

1.2.3.

1.2.3.1.

Các kỹ thuật kiểm thử phần mềm
Kiểm thử chức năng (Functional Testing)
Kiểm thử chức năng là phương pháp kiểm thử chủ


yếu dựa vào đặc tả chức năng của hệ thống. Các ca kiểm
thử hay dữ liệu kiểm thử được dẫn xuất từ đặc tả. Bởi
vậy, kiểm thử chức năng còn được gọi là kiểm thử dựa
trên đặc tả hay kỹ thuật kiểm thử hộp đen (Black-Box
Testing). Kiểm thử chức năng là giải pháp tốt nhất để
tìm ra lỗi thiết kế. Hoạt động kiểm thử được áp dụng cho
các mức độ kiểm thử: Kiểm thử đơn vị, kiểm thử tích
hợp, kiểm thử hệ thống, kiểm thử hồi quy và kiểm thử
chấp nhận.
1.2.3.2. Kiểm thử cấu trúc (Structural
Testing)
Kiểm thử cấu trúc còn gọi là kiểm thử hộp trăng
(White-Box Testing) chủ yếu dựa vào mã nguồn và cấu
trúc chương trình. Kiểm thử cấu trúc cho phép chúng ta
kiểm thử cấu trúc bên trong của phần mềm, với mục đích
kiểm tra tất cả các câu lệnh và điều kiện tồn tại trong
phần mềm đó. Kiểm thử cấu trúc thường phát hiện lỗi lập
trình. Tuy nhiên, đây là phương pháp kiểm thử khó thực
hiện, chi phí cao.
1.3.

TỔNG KẾT CHƯƠNG
Chương này trình bày tổng quan về HTHĐT. Bên

cạnh đó, chúng tôi cũng tìm hiểu một cách chi tiết về


UML và biểu đồ lớp. Nhiều khái niệm về kiểm thử cũng
được đề cập, đặc biệt QTKT và các kỹ thuật kiểm thử
(kiểm thử chức năng và kiểm thử cấu trúc).


CHƯƠNG 2
KIỂM THỬ HỆ THỐNG HƯỚNG ĐỐI
TƯỢNG DỰA TRÊN BIỂU ĐỒ LỚP
2.1.

KIỂM THỬ HỆ THỐNG HƯỚNG ĐỐI

TƯỢNG
2.1.1. Tổng quan về kiểm thử HTHĐT
Ở phần mềm hướng đối tượng, chương trình
được thực hiện dựa trên sự thực thi phương thức của
đối tượng nào đó là thể hiện cụ thể của một lớp mỗi
khi có một sự kiện được kích hoạt. Hướng tiếp cận
tập trung vào kiểm thử các đối tượng thuộc các lớp
và sự tương tác giữa các đối tượng thuộc các lớp
khác nhau. Sự phức tạp của lớp đối tượng đó chính
là: tính bao gói về mặt giữ liệu, sự thừa kế các lớp
với nhau, tính đa hình… điều đó dẫn đến hoạt động
kiểm thử phức tạp hơn. Có thể đưa ra 3 cấp độ khác
nhau cho kiểm thử phần mềm hướng đối tượng như
sau:

Kiểm thử lớp (Class Testing)
Kiểm thử tích hợp đối tượng (Object Integration Testing)
Kiểm thử toàn bộ hệ thống (System Testing)


Hướng tiếp cận theo class
2.1.2. Các chiến lược kiểm thử HTHĐT
2.1.2.1.

Kiểm thử đơn vị (Unit Testing)

- Unit testing đề cập đến các kiểm thử để chứng thực chức
năng của một phần riêng biệt của code, thường ở mức hàm.
Trong một môi trường hướng đối tượng, kiểm thử đơn vị
thường được sử dụng ở mức lớp và kiểm thử các đơn vị nhỏ
nhất bao gồm các hàm constructor và destructor.
- Loại liểm thử này thường được viết bởi các DEV như công
viêc của họ trong việc code (loại tét white- box), để đảm bảo
rằng từng hàm riêng biệt hoạt động đúng theo mong muốn.
một hàm có thể có nhiều kiểm thử, để bắt được các trường


hợp hoặc các nhánh code. Unit testing một mình không thể
bảo đảm chúc năng của một bộ phận của phần mềm mà là sử
dụng để bảo đảm rằng các khối kiến trúc của phần mềm làm
việcđộc lập với nhau.
- Unit testing(kiểm thử đơn vị)cũng được gọi là component
testing(kiểm thử thành phần)
2.1.2.2. Kiểm thử tích hợp hướng đối tượng
Kiểm thử tích hợp hướng đối tượng (OOTT) là kiểm thử tập

hợp các thành phần hướng đối tượng (set of object oriented
components).
Như vậy, có thể hiểu OOTT là kiểm thử sự tương tác giữa
các thành phần hướng đối tượng. Hiểu các thành phần
hướng đối tượng theo nghĩa hẹp là các đối tượng sinh ra bởi
mã lệnh chương trình, theo nghĩa rộng là các đối tượng của
chương trình phần mềm và các thiết bị phần cứng khác hỗ
trợ việc thực thi một phiên làm việc trong hệ thống. Ví dụ,
hệ thống thanh toán thẻ rút tiền tự động ATM (Automated
Teller Machine), các thành phần hướng đối tượng được hiểu
là các đối tượng chương trình phần mềm và thiết bị của máy
ATM.


OOTT kiểm thử sự tương tác giữa hai đối tượng nảy sinhkhi
một đối tượng gọi phương thức của các đối tượng khác bằng
cơ chế gửi thông báo. Những đối tượng này cần phải là thể
hiện của các lớp khác nhau. Nếu các đối tượng đều là thể
hiện của cùng một lớp, khi đó kiểm thử được đề nghị là
kiểm thử lớp (kiểm thử đối tượng).

2.1.2.3. Kiểm thử hệ thống (System Testing)
- System testing kiểm thử một hệ thống đãđược tích hợp
hoàn chỉnh để xác minh rằng nó đáp ứng được yêu cầu.
- Kiêm thử tích hợp hệ thống chứng thực rằng hệ thống đã
được tích hợp với các hệ thống bên ngoài hoặc hệ thống thứ
ba đã được xác định trong các yêu cầu hệ thống.
2.2.
2.2.1.

KIỂM THỬ HTHĐT DỰA TRÊN BIỂU ĐỒ LỚP
Ý nghĩa của biểu đồ lớp trong hoạt động

kiểm thử
2.2.1.1. Xây dựng tập các lớp
- Xây dựng lớp
- Đặc tả lớp


2.2.2.

Kiểm thử Lớp (Class Testing)

2.2.2.1. Kiểm thử phương thức (Method Testing)
Trong hệ thống hướng đối tượng, phương thức
được xem là đơn vị nhỏ nhất nên kiểm thử phương thức
(method testing) có thể được xem là kiểm thử đơn vị
(Unit Testing). Kiểm thử phương thức tập trung vào
từng chi tiết bên trong của mỗi phương thức. Do vậy,
những kỹ thuật kiểm thử đơn vị truyền thống hoàn toàn
phù hợp cho kiểm thử phương thức trong HTHĐT như kỹ
thuật kiểm thử dựa vào đồ thị luồng dữ liệu (DFG), kiểm
thử dựa vào đồ thị luồng điều khiển (CFG), kiểm thử giá
trị biên (BVT),...
2.2.2.2. Kiểm thử lớp đơn (Intra-Class Testing)
 Kiểm thử dựa vào phân tích hợp nhất
Kỹ thuật được xây dựng gồm ba bước chính:
- Phân tích luồng dữ liệu (Data flow analysis)
- Thực thi thành phần tiêu biểu (Symbolic Execution)
- Tinh giảm tự động (Automated deduction)

 Kiểm thử lớp tương đương (Equivalence Classes
Testing) Việc đầu tiên của kỹ thuật kiểm thử này là
phân hoạch không gian trạng thái, từ đó xác định
tập ca kiểm thử.


 Ý tưởng:
- Phân hoạch miền dữ liệu vào thành các lớp các dữ
liệu có quan hệ với nhau.
- Mỗi lớp dùng để kiểm thử một chức năng gọi là
lớp tương đương.
 Ba bước
- Đối với mỗi dữ liệu vào, xác định các lớp
tương đương từ miền dữ liệu vào.
- Chọn dữ liệu đại diện cho mỗi lớp tương
đương
- Kết hợp các dữ liệu thử bởi tích đề-các để
tạo ra bộ dữ liệu kiểm thử
 Nguyên tắc phân hoạch các lớp tương đương
- Nếu dữ liệu vào thuộc một khoảng, xây dựng:
• 1 lớp các giá trị lớn hơn
• 1 lớp các giá trị nhỏ hơn
• n lớp các giá trị hợp lệ
- Nếu dữ liệu là tập hợp các giá trị, xây dựng
• 1 lớp với tập rỗng
• 1 lớp quá nhiều các giá trị
• n lớp hợp lệ


- Nếu dữ liệu vào là điều kiện ràng buộc, xây dựng

• 1 lớp với ràng buộc ñược thỏa mãn
• 1 lớp với ràng buộc không ñược thỏa mãn


Ví dụ
Bài toán tam giác

Thường
Cân
Đều

Nhọn
6,5,3
6,1,6
4,4,4

Vuông
5,6,10
7,4,4
Không thể

Tù
3,4,5
√2,2,√2
Không thể

Không là tam giác -1,2,8

2.2.2.3. Kiểm thử tích hợp lớp (Inter-Class Testing)
Kiểm thử tích hợp lớp (Inter-Class testing) còn

được gọi là kiểm thử Cluster. Cluster là sự tương tác của
các lớp với nhau nhằm thực hiện một yêu cầu nào đó
của hệ thống phần mềm. Kiểm thử cluster được xem là
giai đoạn kiểm thử tích hợp của hệ thống. Kiểm thử
cluster là kiểm thử tập lớp của hệ thống con hoặc cả hệ
thống.
 Kiểm thử dựa vào quan hệ kết tập – sử dụng


Mối quan hệ và sự tương tác giữa các lớp là đặc
tính cơ bản trong HTHĐT. Có thể phân loại nhiều cách
khác nhau dưới góc nhìn Inter-Class. Tuy nhiên, trong
phần này, chúng tôi quan tâm đến quan hệ kết tập và quan
hệ sử dụng.
Kỹ thuật kiểm thử inter-class dựa vào quan hệ kết
tập - ử dụng tạo ra chuỗi trình tự các lời gọi đối với một
tập các đối tượng tạo nên hệ thống nào đó. Hai yêu cầu
cần phải thực hiện là: mở rộng khái niệm quan hệ khai
báo-sử dụng đối với các biến tuyến tính bởi các đối
tượng; việc phân tích luồng dữ liệu lớp sẽ được thực
hiện trên một tập các lớp bằng cách sử dụng thông tin
được tóm tắt của từng lớp. Kỹ thuật này gồm hai bước:
- Tạo ra các đặc tả ca kiểm thử (Generating Test
Case Specifications): Đặc tả ca kiểm thử đối với kiểm
thử interclass là một cặp phương thức; trong đó phương
thức đầu tiên làm thay đổi trạng thái đối tượng, phương
thức thứ hai truy cập trạng thái được thay đổi. Cặp
phương thức này được tạo ra bằng cách xác định trình tự
các lớp cho phép phân tích luồng dữ liệu tăng trưởng và
thực hiện việc phân tích luồng dữ liệu tăng trưởng để xử

lý trạng thái của các lớp có thành phần của các lớp khác.
- Tạo ra các ca kiểm thử (Generating Test Cases)


Một ca kiểm thử tương ứng với một quan hệ defuse, là một trình tự lời triệu gọi các phương thức, bắt đầu
là hàm tạo và kể cả các phương thức trong quan hệ def-use
thông qua lộ trình khai báo-trắng (def-clear). Việc tạo ra
các ca kiểm thử ứng với quan hệ def-use thông qua xác
định các điều kiện trước và sau cho việc thực thi lộ trình
trong các phương thức đơn bằng kỹ thuật thực thi thành
phần tiêu biểu; sau đó lựa chọn các điều kiện thích hợp
nhờ vào kỹ thuật tinh giảm tự động.
 Kiểm thử dựa vào quan hệ thừa kế của các lớp
Trong phần này trình bày kỹ thuật kiểm thử nhóm các lớp
cóquan hệ với nhau bằng cách tái sử dụng thông tin kiểm
thử trên lớp cha để áp dụng cho lớp con thông qua việc khai
thác tính phân cấp tự nhiên trong quan hệ thừa kế. Như
vậy, kỹ thuật kiểm thử dựa vào tính thừa kế của các lớp
được thực hiện qua hai giai đoạn: Kiểm thử trên lớp cơ sở
(lớp cha – parent class) và kiểm thử trên lớp con
(subclass).

- Kiểm thử lớp cơ sở (Base class testing):
Giai đoạn này nhằm mục đích tạo ra lịch sử kiểm
thử của lớp cha. Các mức kiểm thử áp dụng cho lớp
dạng này có thể là intra- class và inter-class tương ứng


với sự tương tác của lớp đó với các đối tượng trong nhóm
bằng các kỹ thuật kiểm thử đã có. Các ca kiểm thử bao

gồm hai loại: ca kiểm thử được tạo ra dựa vào đặc tả và
ca kiểm thử dựa vào chương trình.

- Kiểm thử lớp con (subClass testing):
Trên cơ sở sử dụng lịch sử kiểm thử (HISTORY(P)) và
đồ thị lớp (G(P)) của lớp cha, thuật toán TestSubclass
dẫn xuất ra lịch sử kiểm thử của lớp con R
(HISTORY(R)). HISTORY(R) được dùng để kiểm thử lớp
con.
 Kiểm thử dựa vào cây thực thi (Execution Tree)
Kỹ thuật kiểm thử dựa vào cây thực thi được xây
dựng trên cơ sở ứng dụng lý thuyết về đồ thị - một
phương pháp được sử dụng để mô hình hóa quy trình thực
thi của các lớp và các phần tử trong nó rất hiệu quả .