Hướng tiếp cận thời gian thực cho việc tính toán và ước lượng tài nguyên sử dụng của chương trình

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

NGUYỄN TRỌNG KHÁNH

HƯỚNG TIẾP CẬN THỜI GIAN THỰC CHO VIỆC TÍNH
TOÁN VÀ ƯỚC LƯỢNG TÀI NGUYÊN SỬ DỤNG CỦA
CHƯƠNG TRÌNH

Ngành: Khoa học máy tính
Chuyên ngành: Khoa học máy tính (hệ chuẩn)
Mã Số: 60 48 01 01

LUẬN VĂN THẠC SĨ
Ngành: Khoa học máy tính

Hà Nội – 2015


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

NGUYỄN TRỌNG KHÁNH

HƯỚNG TIẾP CẬN THỜI GIAN THỰC CHO VIỆC TÍNH
TOÁN VÀ ƯỚC LƯỢNG TÀI NGUYÊN SỬ DỤNG CỦA
CHƯƠNG TRÌNH

Ngành: Khoa học máy tính
Chuyên ngành: Khoa học máy tính (hệ chuẩn)
Mã Số: 60480101

LUẬN VĂN THẠC SĨ
Ngành: Khoa học máy tính
NGƯỜI HƯỚNG DẪN KHOA HỌC: TS. PHẠM NGỌC HÙNG
ĐỒNG HƯỚNG DẪN: PGS. TS. NGUYỄN VIỆT HÀ

Hà Nội – 2015


LỜI CẢM ƠN
Trước tiên, tôi xin dành lời cảm ơn chân thành và sâu sắc đến thầy PGS. TS.
Phạm Ngọc Hùng và PGS. TS. Nguyễn Việt Hà – những người đã hướng dẫn, khuyến
khích, chỉ bảo và tạo cho tôi những điều kiện tốt nhất từ khi bắt đầu cho tới khi hoàn
thành công việc của mình.
Tôi xin dành lời cảm ơn chân thành tới các thầy cô giáo khoa Công nghệ thông
tin, trường Đại học Công nghệ, ĐH QGHN đã tận tình đào tạo, cung cấp cho tôi những
kiến thức vô cùng quý giá và đã tạo điều kiện tốt nhất cho tôi trong suốt quá trình học
tập, nghiên cứu tại trường.
Đồng thời tôi xin chân thành cảm ơn những người thân trong gia đình cùng toàn
thể bạn bè đã luôn giúp đỡ, động viên tôi trong những lúc gặp phải khó khăn trong việc
học tập và nghiên cứu chương trình thạc sĩ tại Đại học Công nghệ, ĐHQGHN.

1


LỜI CAM ĐOAN
Tôi xin cam đoan rằng luận văn thạc sĩ công nghệ thông tin “Hướng tiếp cận
thời gian thực cho việc tính toán và ước lượng tài nguyên sử dụng của chương trình” là
công trình nghiên cứu của riêng tôi, không sao chép lại của người khác. Trong toàn bộ
nội dung của luận văn, những điều đã được trình bày hoặc là của chính cá nhân tôi
hoặc là được tổng hợp từ nhiều nguồn tài liệu. Tất cả các nguồn tài liệu tham khảo đều

có xuất xứ rõ ràng và hợp pháp.
Tôi xin hoàn toàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy
định cho lời cam đoan này.
Hà Nội, ngày … tháng … năm 2015

Nguyễn Trọng Khánh

2


MỤC LỤC
LỜI CẢM ƠN .................................................................................................................. 1
LỜI CAM ĐOAN ............................................................................................................ 2
DANH MỤC HÌNH VẼ ................................................................................................... 5
DANH MỤC BẢNG ........................................................................................................ 5
CHƯƠNG 1. GIỚI THIỆU .............................................................................................. 6
CHƯƠNG 2. TỔNG QUAN VỀ PHÂN TÍCH CHƯƠNG TRÌNH ............................... 9
2.1. Tổng quan kĩ thuật kiểm thử hộp trắng dòng điều khiển...................................... 9
2.2. Quy trình chung của kiểm thử hộp trắng dòng điều khiển theo hướng động ....... 9
2.3. Quy trình chung của kiểm thử hộp trắng dòng điều khiển theo hướng tĩnh ....... 11
2.3.1. Các tiêu chí phủ kiểm thử ........................................................................... 12
2.3.2. Đồ thị dòng điều khiển ................................................................................ 13
2.3.3. Đường kiểm thử .......................................................................................... 14
2.4. So sánh kĩ thuật kiểm thử hộp trắng dòng điều khiển theo hướng tĩnh và động 15
2.5. Tầm quan trọng của tự động hóa quy trình kiểm thử hộp trắng dòng điều khiển
.................................................................................................................................... 16
CHƯƠNG 3. PHƯƠNG PHÁP TIẾP CẬN THỜI GIAN THỰC CHO VIỆC ƯỚC
LƯỢNG TÀI NGUYÊN SỬ DỤNG CỦA CHƯƠNG TRÌNH .................................... 17
3.1. Các nghiên cứu liên quan..................................................................................... 19
3.2. Công cụ đo đạc và tập dữ liệu đầu vào của chương trình .................................... 21

3.2.1. Công cụ đo đạc ............................................................................................. 21
3.2.2. Tập dữ liệu đầu vào ...................................................................................... 24
3.3. Thành phần xây dựng mô hình ............................................................................ 25
3.3.1. Phương pháp hồi qui .................................................................................... 25
3.3.2. Đánh giá mô hình toán học .......................................................................... 27
CHƯƠNG 4. CÔNG CỤ QUAN SÁT VÀ ĐO ĐẠC TÀI NGUYÊN SỬ DỤNG
CHƯƠNG TRÌNH ......................................................................................................... 29
4.1. Công cụ cài đặt .................................................................................................... 29

3


4.1.1. Mục đích chương trình ................................................................................ 29
4.1.2.

Kiến trúc chương trình .............................................................................. 29

4.1.3.

Cài đặt chương trình .................................................................................. 32

4.1.3.

Hướng dẫn sử dụng chương trình ............................................................. 33

4.1.4.

Ví dụ .......................................................................................................... 34

4.2. Thực nghiệm ........................................................................................................ 36

4.2.1. Thí nghiệm với các thuật toán thông thường ............................................... 38
4.2.2. Thử nghiệm về nguồn mở ............................................................................ 42
4.2.3. Các hạn chế mô hình .................................................................................... 43
CHƯƠNG 5. KẾT LUẬN.............................................................................................. 45
TÀI LIỆU THAM KHẢO .............................................................................................. 47

4


DANH MỤC HÌNH VẼ
STT
Hình 2.1
Hình 2.2
Hình 2.3
Hình 2.4
Hình 3.1

Hình 3.2
Hình 4.1

Hình 4.2
Hình 4.3
Hình 4.4
Hình 4.5
Hình 4.6
Hình 4.7

Nội dung
Quy trình chung của kiểm thử hộp trắng dòng điều khiển
theo hướng động.

Ví dụ một luật chèn mã nguồn trong DMS/SRT.
Mã nguồn hàm triangle sau khi thêm khối mã nguồn mới.
Quy trình chung của kiểm thử hộp trắng dòng điều khiển
theo hướng tĩnh.
Mô hình của phương pháp với hai thành phần gồm công
cụ đo đạc và công cụ xây dựng mô hình.

Trang
10

Thủ tục tính toán ma trận xác định sau khi thêm vào 3 bộ
đếm để đo đạc tài nguyên của chương trình này
Cấu trúc của chương trình

22

Cài đặt bộ đếm cho thuật toán sắp xếp nổi bọtHướng dẫn
sử dụng chương trình
Cài đặt bộ đếm cho thuật toán tháp hà nội
Hướng dẫn sử dụng chương trình
Độ phức tạp của QuickSort bằng mô hình logarit tuyến
tính
Độ phức tạp thuật toán Quick Sort bằng mô hình Logarit

32

So sánh giữa phương pháp tiếp cận của chúng tôi và CF
TrendProf

11

11
12
19

28

33
35
36
36
41

DANH MỤC BẢNG
STT

Nội dung

Trang

Bảng 4.1 Số liệu về các mô hình được hỗ trợ

29

Bảng 4.2 Các thuật toán tiêu chuẩn cho nghiên cứu

30

Bảng 4.3 Kết quả thí nghiệm của các thuật toán tiêu chuẩn

33

Bảng 4.4 Nguồn mở cho nghiên cứu

33

Bảng 4.5 Kết quả thí nghiệm cho nguồn mở

36

5


CHƯƠNG 1. GIỚI THIỆU
Trong thời đại bùng nổ thông tin, khi mà tất cả các lĩnh vực trong ngành công
nghệ thông tin đều phát triển rất mạnh mẽ, điều này dẫn đến việc tăng rất nhanh về
lượng dữ liệu lưu trữ và sử dụng. Trong hầu hết các tổ chức cũng như doanh nghiệp,
lượng dữ liệu lưu trữ và sử dụng tăng trung bình từ 30% đến 50% mỗi năm. Lượng
thông tin mà các tổ chức cũng như doanh nghiệp xử lý mỗi ngày lên tới hơn 60
terabyte - tăng hơn 1000 lần so với thập niên trước [1]. Bởi vậy, việc phần mềm ngày
nay phải có khả năng mở rộng để xử lý với lượng dữ liệu ngày càng lớn là điều hiển
nhiên. Ví dụ, những chức năng rất cơ bản của một phần mềm như tìm kiếu, sắp xếp hay
so sánh, v.v. sẽ phải làm việc với những cơ sở dữ liệu lớn hơn rất nhiều so với quá khứ.
Việc này không những làm tăng độ phức tạp của chương trình mà còn làm tăng rất
nhiều thời gian xử lý của chương trình. Bởi vậy, việc nghiên cứu và đo đạc khả năng
mở rộng của chương trình [14] để đảm bảo được tính ổn định cũng như thời gian chạy
hợp lý với người dùng trở thành một mảng rất quan trọng trong quá trình phát triển
phần mềm .
Ở thời điểm hiện tại, có ba cách tiếp cận phổ biến cho việc phân tích và đo đạc
khả năng mở rộng của chương trình dựa trên độ phức tạp tính toán và lượng tài nguyên
sử dụng của chương trình đó. Cách tiếp cận đầu tiên đó là phân tích tĩnh [8, 17], việc

phân tích này dự trên tính toán độ phức tạp của chương trình bằng cách xây dựng mô
hình của chương trình dựa trên các trạng thái của chúng. Hướng tiếp cận rất chính xác
nhưng chỉ phù hợp với những chương trình nhỏ do độ phức tạp trong tính toán và đo
đạc là rất lớn. Hướng tiếp cận thứ hai là hướng tiếp cận amortised được mô tả trong
[9,10,12]. Hướng tiếp cận này đánh giá lượng tài nguyên sử dụng trong những trường
hợp xấu nhất của chương trình bằng cách quan sát và phân tích tất cả những trạng thái
cũng như hành động của chương trình đó. Tương tự như hướng tiếp cận đầu tiên,
hướng tiếp cận này cũng chỉ khả thi đối với những chương trình nhỏ. Hướng tiếp cận

6


thứ ba là hướng tiếp cận thời gian thực được mô tả trong các nghiên cứu tại [5, 6, 13].
Hướng tiếp cận này đo đạc chi phí tính toán trung bình của chương trình khi chạy. Kết
quả chi phí tính toan trong những nghiên cứu [5, 6, 13] là tương đồng với những mô
hình toán học như là đa thức hay lũy thừa. Tuy nhiên, những nghiên cứu này đề có
những giới hạn liên quan đến số lượng mô hình toán học mà họ hỗ trợ hay là thời gian
chạy quá lâu.
Luận văn này đề xuất một hướng tiếp cận thời gian thực mới nhằm giải quyết
những giới hạn của hướng tiếp cận thời gian thực như đã mô tả ở trên. Hướng tiếp cận
của đề xuất tính toán tài nguyên sử dụng trung bình của chương trình dựa trên dữ liệu
đầu vào thay vì dự đoán thời gian chạy thực của chương trình một cách thiếu chọn lọc.
So sánh với những hướng tiếp cận thời gian thực khác, hướng tiếp cận này có thể hỗ
trợ nhiều mô hình toán học và có thời gian thực thi nhanh hơn. Cụ thể hơn, hướng tiếp
cận của nghiên cứu này gồm hai thành phần chính. Thành phần đầu tiên là những công
cụ đo đạc (monitor instrumentation) và thành phần thứ hai là để xây dựng mô hình toán
học tương đương (model construction). Đầu tiên, những công cụ đo đạc sẽ theo dõi và
đo đạc lượng tài nguyên sử dụng của chương trình dựa trên những tập dữ liệu đầu vào
tương ứng. Sau đó, thành phần xây dựng mô hình toán học sẽ tiến hành xây dựng để
phù hợp những dữ liệu và kết quả quan sát được với những mô hình toán học mà chúng

tôi hỗ trợ. Hiện tại, nghiên cứu trong luận văn này đã có thể hỗ trợ được năm mô hình
toán học phổ biến. Nghiên cứu này cũng tập trung vào việc đo đạc và ước lượng tài
nguyên tính toán và độ sâu sử dụng của bộ nhớ stack mà chương trình cần như là hai
thước đo chính để đánh giá tài nguyên của chương trình. Hướng tiếp cận này cũng có
thể được mở rộng để áp dụng với những độ đo tài nguyên khác. Tuy nhiên, trong
khuôn khổ nghiên cứu của luận văn này, nghiên cứu chỉ tập trung vào hai thước đo như
đã nêu trên. Bằng cách so sánh kết quả của hướng tiếp cận này với những kết quả dựa
trên lý thuyết chúng tôi có thể đánh giá được khả năng mở rộng cũng như lỗi tiềm ẩn
của chương trình. Luận văn cũng xây dựng một công cụ để mô phỏng hướng tiếp cận
7


này bằng ngôn ngữ lập trình Java và sử dụng công cụ này để đo đạc những thuật toán
chuẩn và một số chương trình mã nguồn mở nhằm minh chứng cho tính hiệu quả của
phương pháp đề xuất.
Phần còn lại của luận văn được cấu trúc như sau. Hướng tiếp cận đề xuất nhằm
tính toán và ước lượng tài nguyên sử dụng của các chương trình sẽ được mô tả chi tiết
trong Chương 2. Chương 3 giới thiệu về công cụ cài đặt hỗ trợ phương pháp đề xuất
cũng như mô tả chi tiết về quá trình thực nghiệm nhằm minh chứng cho tính hiệu quả
của phương pháp đề xuất. Cuối cùng, kết luận và định hướng phát triển trong tương lai
của luận văn sẽ được trình bày trong Chương 4.

8


CHƯƠNG 2. TỔNG QUAN VỀ PHÂN TÍCH CHƯƠNG TRÌNH
Ở phần này, khóa luận trình bày các kiến thức tổng quan về phân tích chương
trình. Kĩ thuật chính mà chúng tôi hướng tới ở đây là kiểm thử hộp trắng dòng điều
khiển gồm hai kĩ thuật kiểm thử hướng tĩnh và hướng động, đồng thời đưa ra sự so
sánh về ưu điểm và nhược điểm của từng kĩ thuật.

2.1. Tổng quan kĩ thuật kiểm thử hộp trắng dòng điều khiển
Kiểm thử hộp trắng dòng điều khiển chia ra gồm kiểm thử hướng tĩnh và kiểm
thử hướng động. Đầu vào của hai kĩ thuật này đều là mã nguồn và tiêu chí phủ kiểm
thử. Sau một loạt quá trình phân tích, đầu ra tương ứng là tập ca kiểm thử. Mỗi một kĩ
thuật đều có những ưu điểm và hạn chế riêng. Mục tiêu của kiểm thử hộp trắng dòng
điều khiển là tìm tập ca kiểm thử tối thiểu nhưng đạt được độ phủ tối đa.
2.2. Quy trình chung của kiểm thử hộp trắng dòng điều khiển theo hướng động
Theo kĩ thuật này, mã nguồn sẽ được thêm các đoạn chương trình con trước khi
thực thi trong môi trường chạy. Hình 0.1 trình bày quy trình chung của kiểm thử động.
Nhìn chung, kĩ thuật này gồm 6 bước cơ bản được diễn giải theo thứ tự dưới đây:
Bước 1. Chèn thêm các đoạn mã nguồn mới vào mã nguồn cần kiểm thử.
Bước 2. Chọn ngẫu nhiên một tập giá trị đầu vào hợp lệ làm ca kiểm thử đầu tiên.
Bước 3. Thực thi chương trình với bộ giá trị vừa tìm được. Nếu không thực thi
được, quay lại bước 2 để sinh bộ giá trị khác.
Bước 4. Tìm tập các câu lệnh đã được đi qua với bộ giá trị ở bước 3 để xây dựng
được hệ ràng buộc tương ứng.
Bước 5. Phủ định hệ ràng buộc thu được ở bước 4 để sinh các hệ ràng buộc mới
có tác dụng sinh các ca kiểm thử kế tiếp. Nếu không thể sinh hệ phủ định
nào khác, thuật toán kết thúc.
Bước 6. Giải hệ ràng buộc thu được ở bước 5 để sinh ca kiểm thử kế tiếp. Nếu
không có ca kiểm thử nào thỏa mãn, quay về bước 5 để tìm hệ ràng buộc
phủ định mới sao cho khác hệ ràng buộc hiện tại. Ngược lại, quay lại bước 3
để sinh ca kiểm thử kế tiếp.
9


Source
code
Tiêu chí
phủ

Pha chèn thêm khối
lệnh mới
Tìm ca kiểm thử
khởi đầu ngẫu nhiên
Thực thi ca kiểm
thử vừa tìm được
Tái tạo đường thực thi
Tạo đường thực thi mới

Kết
thúc

False

Tìm được ca
kiểm thử mới

True

Hình 0.1. Quy trình chung của kiểm thử hộp trắng dòng điều khiển theo hướng
động.
Trong bước 1, quá trình chèn thêm khối mã nguồn mới vào mã nguồn cần kiểm
thử được tiến hành một cách tự động. Công cụ DMS/SRT1 được đánh giá khá mạnh mẽ
để thực hiện pha này. Đoạn mã nguồn thêm vào có chức năng đánh dấu, thoát chương
trình hoặc ghi thông tin về quá trình thực thi ra tệp, v.v. Để làm được điều này, chúng
tôi cần xây dựng các luật chèn thêm mã nguồn mới vào mã nguồn cần kiểm thử.
Với công cụ DMS/SRT, mỗi một luật bắt đầu với từ khóa rule và theo sau là tên
đặt cho luật. Từ khóa rewrite to nêu cách biến đổi đoạn mã nguồn gốc về đoạn mã
nguồn mới. Kiểu dữ liệu có thể là expression (ứng với biểu thức), statement (ứng với

câu lệnh gán hoặc khởi tạo), type (ứng với kiểu dữ liệu), identifier (ứng với định danh
như tên biến, tên hàm), v.v. Hình 0.2 mô tả một luật chèn thêm câu lệnh đánh dấu vào
khối lệnh điều khiển rẽ nhánh. Cụ thể, biến mảng visited đánh dấu vị trí câu lệnh đi qua

10


được bổ sung vào mã nguồn ban đầu ngay sau mỗi khối lệnh điều khiển rẽ nhánh. Hình
0.3 đưa ra mã nguồn triangle sau khi áp dụng luật.

Hình 0.2: Ví dụ một luật chèn mã nguồn trong DMS/SRT.

Hình 0.3. Mã nguồn hàm triangle sau khi thêm khối mã nguồn mới.

2.3. Quy trình chung của kiểm thử hộp trắng dòng điều khiển theo hướng tĩnh
Trong kiểm thử tĩnh, mã nguồn không được thực thi trong môi trường chạy để
sinh ca kiểm thử. Trong kiểm thử tĩnh, quá trình chạy ca kiểm thử chỉ thực hiện duy
11


nhất một lần với từng ca kiểm thử để tính toán giá trị trả về và đảm bảo ca kiểm thử
thực thi không có vấn đề. Các bước tổng quát trong kĩ thuật này được trình bày ở Hình
0.4. Đầu tiên, đồ thị dòng điều khiển được xây dựng dựa trên mã nguồn và tiêu chí phủ
kiểm thử. Bước tiếp theo, từ đồ thị dòng điều khiển chúng tôi xây dựng được tập
đường kiểm thử. Mỗi một đường kiểm thử trong tập đường kiểm thử mô tả hành vi
chương trình với một miền bộ đầu vào nào đó. Sau đó, pha tìm ca kiểm thử thỏa mãn
đường kiểm thử được tiến hành. Cuối cùng, ca kiểm thử được thực thi trong môi
trường chạy.
Source code

Xây dựng đồ thị
dòng điều khiển

Tiêu chí phủ
Xây dựng tập
đường kiểm thử
Tìm tập ca kiểm thử
Thực thi tập ca
kiểm thử
Kết thúc
Hình 0.4. Quy trình chung của kiểm thử hộp trắng dòng điều khiển theo hướng tĩnh.

2.3.1. Các tiêu chí phủ kiểm thử
Tiêu chí phủ kiểm thử là một thước đo để đánh giá tính đúng đắn của mã nguồn
cần kiểm thử với một tập ca kiểm thử nào đó. Tập ca kiểm thử khiến mã nguồn có độ
phủ cao được đánh giá là tốt hơn so với tập ca kiểm thử khác khiến mã nguồn có độ
phủ thấp hơn. Chất lượng mã nguồn được đánh giá tỉ lệ thuận với độ phủ.
Độ phủ được đánh giá dựa trên hai thông số gồm tiêu chí phủ kiểm thử và tập ca
kiểm thử. Công thức tính độ phủ là tỉ lệ các thành phần được kiểm thử trên tổng số các
thành phần cần kiểm thử sau khi đã thực hiện tập ca kiểm thử. Thành phần có thể là
câu lệnh, điểm quyết định, điều kiện con, đường thi hành hoặc là sự kết hợp của chúng.

12


Tiêu chí phủ kiểm thử được giới thiệu lần đầu tiên vào 1963 trong tạp chí hàng
tháng “Communications of the ACM”. Cho tới nay, nhiều tiêu chí phủ kiểm thử được
đưa ra. Khóa luận sử dụng ba tiêu chí phủ kiểm thử phổ biến để đánh giá chất lượng
mã nguồn gồm:
 Phủ câu lệnh: Mỗi một câu lệnh được thực thi ít nhất một lần sau khi chạy tập

ca kiểm thử.
 Phủ nhánh: Mỗi một nhánh đều được đi qua ít nhất một lần sau khi chạy tập ca
kiểm thử.
 Phủ điều kiện con: Mọi nhánh đúng-sai đều được đi qua với một tập ca kiểm thử
nào đó, trong đó các câu lệnh điều kiện kép được phân tách thành các câu lệnh
điều kiện đơn.
2.3.2. Đồ thị dòng điều khiển
Sinh ca kiểm thử dựa trên mã nguồn phức tạp và khó khăn hơn so với sinh ca
kiểm thử dựa trên đồ thị dòng điều khiển (Control Flow Graph – CFG). CFG là một đồ
thị có hướng mô tả cấu trúc lôgic của chương trình một cách trực quan và đơn giản
hơn, gồm có các đỉnh tương ứng với các câu lệnh/nhóm câu lệnh và các cạnh là các
dòng điều khiển giữa các câu lệnh/nhóm câu lệnh. Đỉnh đầu tiên của CFG là trạng thái
đầu tiên của hàm, đỉnh cuối cùng của CFG là trạng thái kết thúc của hàm. Đỉnh i nối
đến đỉnh j thì câu lệnh tương ứng đỉnh j có thể được thực thi sau khi thực hiện câu lệnh
tương ứng ở đỉnh i.
Trong ngôn ngữ C, các cấu trúc điều khiển trong CFG gồm tuần tự, rẽ nhánh,
while...do, do...while, for. Hình 0.5 minh họa các cấu trúc điều khiển nêu trên. Trong
đó đỉnh có nhãn c tượng trưng cho câu lệnh điều kiện. Các đỉnh còn lại tượng trưng câu
lệnh gán, khai báo, v.v. Các thành phần cơ bản của đồ thị dòng điều khiển gồm đỉnh
xuất phát, đỉnh xử lí, đỉnh quyết định, đỉnh kết nối và đỉnh kết thúc.
 Đỉnh xuất phát và đỉnh kết thúc: Hai đỉnh này là duy nhất, trong đó đỉnh xuất
phát đại diện cho tên hàm.
 Đỉnh quyết định: Là đỉnh tương ứng với câu lệnh điều kiện trong khối lệnh điều
khiển rẽ nhánh, do...while, while..do. Ví dụ cụ thể, với khối lệnh điều khiển “if
(a > b) { ... }” thì đỉnh quyết định tương ứng với “a > b”.

13


 Đỉnh kết nối: Là đỉnh có nhiều hơn hai đỉnh khác trỏ đến mà không phải đỉnh

quyết định.
 Đỉnh xử lí: Là đỉnh tương ứng với câu lệnh gán, câu lệnh khởi tạo hoặc câu lệnh
khai báo và không phải đỉnh kết nối. Các khối lệnh điều khiển cũng chứa các
loại câu lệnh này. Ví dụ, khối lệnh “for (i = 0; i < 10; i++)” chứa hai đỉnh xử lí
gồm câu lệnh gán “i = 0” và câu lệnh tăng giá trị biến i là “i++”.

Hình 0.5: Các cấu trúc điều khiển phổ biến.

2.3.3. Đường kiểm thử
Với một bộ giá trị đầu vào, một tập các câu lệnh gán, câu lệnh khai báo và câu
lệnh điều kiện được đi qua. Danh sách các câu lệnh này được sắp theo thứ tự thực hiện
chính là một đường đi. Trong số tất cả các đường đi có thể, một tập đường đi được
chọn sao cho thỏa mãn tiêu chí phủ kiểm thử được gọi là tập đường kiểm thử.
Đường kiểm thử là một đường đi từ đỉnh đầu tiên đến đỉnh cuối cùng của CFG
được biểu diễn dưới một tập các đỉnh từ đỉnh v1 đến đỉnh vn, trong đó hai đỉnh liền kề
có cạnh nối với nhau. Nếu cạnh (vi ,vj) (i ≠ j) là nhánh false, câu lệnh lưu ở đỉnh vi
được viết phủ định. Tập đường đi độc lập gồm k đường đi PATH1, PATH2, …, PATHk
thỏa mãn: giữa mọi cặp đường đi độc lập PATHi và PATHj (i ≠ j) không chung ít nhất
một cạnh trở lên.
Tìm kiếm tập đường kiểm thử là bước trung gian trong quá trình sinh tập ca kiểm
thử. Hai vấn đề liên quan đến tập đường kiểm thử rất quan trọng gồm:
 Vấn đề thực thi được hay không thực thi được. Một đường kiểm thử gọi là thực
thi được nếu tìm kiếm được một ca kiểm thử sao cho khi thực thi trong môi

14


trường thật thì đường kiểm thử nêu trên được đi qua. Ngược lại, đường kiểm thử
gọi là không thực thi được.
 Tính phức tạp mã nguồn. Một mã nguồn gọi là phức tạp nếu chứa nhiều vòng

lặp như nhiều vòng lặp lồng nhau hoặc nhiều vòng lặp nối tiếp nhau, kích thước
lớn hoặc thuật toán phức tạp. Mã nguồn càng phức tạp càng khiến quá trình tìm
kiếm đường kiểm thử trở nên khó khăn hơn và mất thời gian hơn.
2.4. So sánh kĩ thuật kiểm thử hộp trắng dòng điều khiển theo hướng tĩnh và
động
Mỗi một kĩ thuật kiểm thử đều có những ưu điểm và hạn chế riêng. Để có cái
nhìn tổng quan về hai kĩ thuật, chúng tôi đưa ra sự so sánh về số ca kiểm thử, thời gian
sinh ca kiểm thử, khả năng kiểm thử vòng lặp, ảnh hưởng bởi phức tạp mã nguồn đối
với hai kĩ thuật.
 Về số ca kiểm thử. Nhìn chung, với mã nguồn chỉ chứa các câu lệnh rẽ nhánh và
không chứa vòng lặp, hai kĩ thuật kiểm thử nêu trên cho số bộ ca kiểm thử như
nhau. Tuy nhiên, trong trường hợp có vòng lặp thì kĩ thuật kiểm thử tĩnh đưa ra
số ca kiểm thử ít hơn so với kiểm thử động. Theo hướng tĩnh, các đường đi chứa
vòng lặp lặp lại một lần sẽ được cấu trúc lại để lặp nhiều hơn một lần. Nói cụ
thể hơn, từ một đường kiểm thử chứa vòng lặp ban đầu sẽ sinh ra một tập các
đường kiểm thử mới dùng để kiểm thử tính đúng đắn vòng lặp. Nếu vòng lặp
trong đường kiểm thử xác định được số lần lặp tối đa thì số đường đi mới sinh
ra là bảy. Ngược lại, nếu vòng lặp không xác định số lần lặp tối đa thì số đường
đi mới sinh ra là bốn.
Với mã nguồn chứa vòng lặp, kiểm thử động sử dụng kĩ thuật phủ định hệ
để sinh ca kiểm thử kế tiếp nên số ca kiểm thử có thể rất lớn hoặc không xác
định. Cụ thể, trường hợp số ca kiểm thử rất lớn xảy ra khi vòng lặp có cận lặp
lớn, ví dụ, khối lệnh điều khiển “for (int i = 0; i < 1000; i++)” có số lần lặp tối
đa là 1000 lần. Trường hợp số ca kiểm thử không xác định xảy ra khi số lần lặp
không được biết trước như “while (m!=n){...}”, trong đó m và n là hai tham số
kiểu nguyên truyền vào hàm. Để giải quyết hai vấn đề này, một vài công cụ
kiểm thử như PathCrawler chèn thêm mã nguồn xác định số lần lặp tối đa của

15

mỗi vòng lặp hoặc thêm yêu cầu thời gian chạy. Tuy nhiên, nhìn chung số ca
kiểm thử vẫn khá lớn gây khó khăn cho quản lí.
 Về thời gian sinh ca kiểm thử. Một cách tổng quan, kiểm thử động thực thi ca
kiểm thử lặp lại nhiều lần nên thời gian sinh ca kiểm thử lâu hơn. Một điểm
chung là hai kĩ thuật đều có bước giải hệ ràng buộc để sinh ca kiểm thử mới.
Thời gian giải hệ chiếm tỉ lệ đáng kể trong tổng thời gian sinh ca kiểm thử. Tuy
nhiên, các công cụ có khả năng giải hệ được phát triển khá mạnh mẽ và công bố
rộng rãi trong thời gian gần đây nên sự so sánh về thời gian giải hệ có thể bỏ
qua.
 Về khả năng kiểm thử vòng lặp. Kiểm thử tĩnh hướng đến chỉ kiểm thử một
vòng lặp duy nhất tại một thời điểm. Do đó, trong trường hợp có nhiều vòng lặp,
chẳng hạn như đường kiểm thử đi qua hai vòng lặp lồng nhau thì quy trình kiểm
thử tiến hành với từng vòng lặp riêng và tìm cách phá vỡ cấu trúc lặp các vòng
lặp còn lại. Ngược lại, kiểm thử động hướng đến kiểm thử tính đúng đắn của các
vòng lặp một cách đồng thời thay vì riêng rẽ. Tư tưởng này mô phỏng quá trình
thực thi trong thực tế.
 Tính phức tạp mã nguồn. Hiện nay, quy tắc viết mã nguồn rất đa dạng và các
quy tắc mới có thể được đưa ra trong các phiên bản trình biên dịch mới. Kiểm
thử tĩnh bị hạn chế bởi tính phức tạp mã nguồn. Ví dụ, trường hợp mã nguồn
chứa các hàm biến đổi xâu thì kĩ thuật kiểm thử này yêu cầu cần phải xây dựng
lại các hàm đó một cách thủ công. Ngược lại, kiểm thử động không bị ảnh
hưởng lớn bởi những sự thay đổi này và bởi tính phức tạp mã nguồn. Nguyên
nhân chính do kiểm thử động tận dụng thế mạnh trình biên dịch để sinh ca kiểm
thử mới.
2.5. Tầm quan trọng của tự động hóa quy trình kiểm thử hộp trắng dòng điều
khiển
Ba trong số những nguyên nhân chính dẫn đến vấn đề tự động hóa quy trình kiểm
thử hộp trắng dòng điều khiển gồm:

16


 Thời gian sinh ca kiểm thử bằng tay khá lâu và dễ dẫn đến sai sót. Nguyên nhân
chính phụ thuộc vào trình độ chuyên môn của kiểm thử viên, độ phức tạp mã
nguồn và chịu áp lực bởi môi trường làm việc.
 Chi phí về nguồn nhân lực cho pha kiểm thử khá tốn kém. Muốn đảm bảo chất
lượng phần mềm (đặc biệt với dự án lớn) thì chi phí nguồn nhân lực càng cao.
Do đó, vấn đề quản lí khối lượng nguồn nhân lực trở nên phức tạp và rắc rối.
Các thống kê cho thấy chi phí pha kiểm thử có thể chiếm tới 40%-60% tổng chi phí
phát triển dự án phần mềm [2]. Các phần mềm hệ thống, phần mềm doanh nghiệp, v.v.
đều đòi hỏi chất lượng cao nên pha kiểm thử luôn được chú trọng và không thể bỏ qua.
Hơn nữa, mỗi khi phần mềm được nâng cấp thì quá trình kiểm thử được tiến hành lại
dẫn đến chi phí đã cao nay càng cao hơn.

CHƯƠNG 3. PHƯƠNG PHÁP TIẾP CẬN THỜI GIAN THỰC CHO VIỆC ƯỚC
LƯỢNG TÀI NGUYÊN SỬ DỤNG CỦA CHƯƠNG TRÌNH
Giả sử rằng n là một đặc điểm của dữ liệu đầu vào của chương trình, ví dụ như
kích cỡ của chương trình, ... và F(n) là công thức để mô tả mối quan hệ giữa dữ liệu
đầu vào và tài nguyên sử dụng của chương trình. Hướng tiếp cận của luận văn sẽ dựa
trên tập dữ liệu đầu vào để quan sát và đo đạc tài nguyên sử dụng của chương trình
(F(n)). Sau đó áp dụng mô hình hồi qui dựa trên kết quả đo đạc được để sinh ra hàm
RF(n) – Hàm xấp xỉ của F(n):
F(n) → RF(n)
Hướng tiếp cận đề xuất phải đối mặt với ba thách thức chính như sau. Thứ nhất
đó là hướng tiếp cận này cần đến sự hỗ trợ của các mô hình toán học để có thể so sánh
và dự đoán được lượng tài nguyên sử dụng của chương trình. Ví dụ, như trong nghiên
cứu này chúng tôi sử dụng mô hình toán học phổ biến như tuyến tính, logarit tuyến
tính, mũ, lũy thừa. Với những chương trình mà không có những mô hình toán học hỗ
trợ tương ứng thì có thể dẫn đến việc dự đoán tài nguyên không chính xác. Thách thức

17


thứ hai chính là việc phải giảm thiểu thời gian chạy và theo dõi của chương trình. Thời
gian chạy chương trình của hướng tiếp cận này phụ thuộc chủ yếu vào tập dữ liệu đầu
vào bởi vì phương pháp này đòi hỏi phải chạy chương trình dựa trên tập dữ liệu đầu
vào đó. Việc chạy chương trình với quá nhiều dữ liệu đầu vào có thể làm tăng thời gian
chạy và đo đạc của nghiên cứu. Tuy nhiên, nếu tập dữ liệu đầu vào không đủ thì có thể
dẫn đến kết quả và mô hình mô phỏng không thực sự hoàn toàn chính xác. Thách thức
thứ ba chính là sự cần thiết cho việc tối ưu công cụ đo đạc thời gian thực để có thể đo
chính xác được tài nguyên sử dụng. Lý do cho sự cần thiết này chính là lượng tài
nguyên sử dụng phụ thuộc vào cách thức chạy của chương trình và dữ liệu đầu vào. Ví
dụ như thuật toán sắp xếp nổi bọt (Bubble sort) về lý thuyết có độ phức tạp là O(n2).
Tuy nhiên, có rất nhiều cách cài đặt và thực thi cho thuật toán này và lượng tài nguyên
sử dụng cho mỗi cách cài đặt là khác nhau. Bên cạnh đó, lượng dữ liệu đầu vào sử
dụng càng lớn thì thời gian chạy của chương trình lại càng lâu hơn.
Để giải quyết những vấn đề trên, chúng tôi đề xuất hướng tiếp cận nhằm ước
lượng tài nguyên sử dụng của chương trình như mô tả trong hình 2.1. Hướng tiếp cận
này bao gồm hai thành phần chính: công cụ đo đạc và xây dựng mô hình tài nguyên sử
dụng. Đầu vào của công cụ đo đạc sẽ là chương trình cần ước lượng tài nguyên sử
dụng và tập dữ liệu đầu vào của chương trình đó. Công cụ đo đạc sẽ tiến hành theo dõi
và đo đạc tài nguyên sử dụng dựa trên tập dữ liệu đầu vào bằng cách chạy chương trình
này. Đầu ra của công cụ đo đạc sẽ là tập dữ liệu được sử dụng làm đầu vào cho phần
xây dựng mô hình toán học. Phần xây dựng mô hình sau đó sẽ đánh giá và xây dựng
mô hình tương ứng dựa trên đầu ra của phần công cụ đo đạc. Đầu ra cuối cùng của
phương pháp đề xuất là mô hình toán học tương ứng cho tài nguyên sử dụng của
chương trình đầu vào.

18

Hình 3.1. Mô hình của phương pháp với hai thành phần gồm công cụ đo đạc và
công cụ xây dựng mô hình.
3.1. Các nghiên cứu liên quan
Có rất nhiều nghiên cứu về tính toán và ước lượng tài nguyên sử dụng cho các
chương trình. Dưới đây là các nghiên cứu gần nhất và mới nhất về hướng nghiên cứu
này.
Wilhelm và đồng nghiệp [20] đã xác định giới hạn thời gian thực hiện của
chương trình bằng cách sử dụng giải thích trừu tượng, lý thuyết đằng sau phân tích
chương trình tĩnh. Giới hạn là cách sử dụng thời gian bằng giây và sử dụng cho việc
xác minh hạn chế thời gian của yêu cầu hệ thống. Công việc có hiệu quả trong các hệ
thống nhúng cũng như các chương trình thời gian thực.
Một nghiên cứu khác của V.Sarkar [18] mô tả một khuôn khổ chung cho việc
xác định thời gian thực hiện chương trình. Khuôn khổ mô hình hoá chương trình bằng
đồ thị luồng điều khiển. Thời gian thực hiện trung bình được ước tính bằng thời gian
chạy trung bình của các chi nhánh của nó. Ngược lại với [18, 20], phương pháp tiếp
cận của chúng ta tập trung vào việc ước tính mức sử dụng tài nguyên bao gồm chi phí

19


tính toán và mức sử dụng khung ngăn xếp, và không phụ thuộc vào các chi tiết kiến
trúc hệ thống như cache, pipeline.
Goldsmith và đồng nghiệp [6] giới thiệu trend-prof để đo các chương trình phức
tạp thực nghiệm và phù hợp với sự quan sát hai mô hình: tuyến tính và Powerlaw.
trend-prof đã được cải thiện thành CF-TrendProf và BB-TrendProf bởi tác giả trong
nghiên cứu [5]. Mục đích nghiên cứu là để phát hiện các lỗi tiềm năng và xác nhận
hiệu suất chương trình. Giới hạn nghiên cứu là sự thiếu hụt các mô hình nên nó không
thể ước tính hiệu suất của thuật toán tiêu chuẩn như thuật toán sắp xếp nhanh

(Quicksort) với độ phức tạp logarit tuyến tính. Bên cạnh đó, hiệu suất của CFTrendProf và BBTrendProf thấp vì chúng mất hàng giờ để trả về kết quả trong khi cách
tiếp cận của chúng ta hỗ trợ một số mô hình và được lưu trữ một năng đầy hứa hẹn.
B. S. Gulavani và S. Gulwani đề xuất một cách tiếp cận [7] mô tả một miền số
chính xác để tính thời gian phân tích. Các tên miền số được xây dựng bởi hai hoạt động
miền nâng cụ thể là biểu hiện trừu tượng và biểu thức tối đa để tính bất biến phi tuyến
tính và giới hạn rời rạc tương ứng. Tuy nhiên, phương pháp này chỉ áp dụng cho các
chương trình số học và không thể phân tích hiệu suất của chương trình lớn. Ngược lại,
cách tiếp cận của chúng ta có thể sử dụng trong các chương trình đa dạng với các ước
lượng tài nguyên sử dụng chính xác.
S.Gulwani và đồng nghiệp [8] cũng đã giới thiệu một kỹ thuật để tính toán giới
hạn biểu tượng của chương trình. Giới hạn tính toán được tạo về chức năng định lượng
là phi tuyến tính, rời rạc và thử nghiệm trên các cấu trúc dữ liệu sử dụng chung. Yêu
cầu các chức năng định lượng được người dùng định nghĩa và sử dụng nhiều quầy là
các hạn chế của nghiên cứu. Ngược lại, cách tiếp cận của chúng ta tự động giám sát
việc sử dụng tài nguyên và được chứng minh là có hiệu quả trong cả hai chương trình
của thuật toán chuẩn và nguồn lớn.

20


J.Navas và đồng nghiệp [15] trình bày một phân tích tĩnh cho các chương trình
logic để đo lường các giới hạn trên và dưới của mức sử dụng về kích thước đầu vào.
Các thông tin phân tích liên quan đến số lượng các chấp hành, thời gian và sử dụng bộ
nhớ. Mặc dù có những ý tưởng thú vị, cách tiếp cận này vẫn đòi hỏi nguồn tài nguyên
người dùng định nghĩa và áp dụng cho các chương trình chuẩn.
3.2. Công cụ đo đạc và tập dữ liệu đầu vào của chương trình
3.2.1. Công cụ đo đạc
Trong nghiên cứu này, phương pháp đề xuất tiến hành quan sát lượng tài
nguyên được sử dụng của chương trình. Vì thế, phương pháp này sử dụng một biến
đếm đơn cho mỗi độ đo tài nguyên sử dụng. Hiện tại, nghiên cứu tập trung vào hai

thước đo cơ bản và phổ biến đó là chi phí tính toán và độ sâu của bộ nhớ stack. Trong
tương lai, nghiên cứu này có thể mở rộng ra với nhiều độ đo khác nữa. Vì lý do này,
phương pháp đề xuất và thực nghiệm trong luận văn này sẽ chỉ được tiến hành dựa trên
hai thước đo này mà thôi.
Với công cụ đo chi phí tính toán của chương trình, phương pháp đề xuất đo tổng
số lượng vòng lặp được chạy của một chương trình. Lý do đó là vòng lặp trong mỗi
chương trình thường là nơi chạy tốn nhiều tài nguyên nhất, thậm chí là vượt trội so với
những vùng khác. Biến đếm của chúng tôi sẽ được định nghĩa như một biến toàn cục,
do đó giá trị của biến này sẽ không bị ảnh hưởng bởi lôgic của chương trình. Giá trị
ban đầu của biến đếm là 0 và sẽ được tăng lên 1 với mỗi vòng lặp của chương trình. Do
vậy, phương pháp này có thể áp dụng được cho cả những chương trình bình thường và
chương trình đệ qui.
Với công cụ đo độ sâu của bộ nhớ stack sử dụng, chúng tôi tiến hành đo đạc số
lượng lần đệ qui hoặc gọi lại và độ sâu lớn nhất của bộ nhớ stack mà chương trình cần
để sử dụng. Trong trường hợp đầu tiên, một biến toán cục sẽ được khởi tạo bắt đầu từ 0

21


và tăng lên 1 ở đầu mỗi thủ tục đệ qui. Trong trường hợp thứ hai, chúng tôi sử dụng cơ
chế theo vết bộ nhớ stack để ghi lại số lượng khung và độ sâu của bộ nhớ stack mà
chương trình đang sử dụng. Khung stack là một khung dữ liệu của chương trình được
đưa vào stack của máy tính. Khi một stack được gọi đến, khung stack sẽ đại diện cho
một lần gọi hàm và các tham số của hàm đó. Thường thì một khung stack sẽ trả về địa
chỉ nhớ được đưa vào stack và sau đó sẽ là các tham số của hàm. Nói một cách ngắn
gọn thì phương pháp đo đạc này sẽ tập trung vào việc đánh giá cài đặt của các chương
trình đệ qui.
Như đã nói ở trên, chúng tôi sẽ chèn các bộ đếm vào chương trình và sau đó tiến
hành chạy chương trình dựa trên tập dữ liệu đầu vào. Với mỗi lần chạy, chúng tôi sẽ
tạo ra các cặp <counter, feature> trong đó feature là đặc điểm của tập dữ liệu đầu vào

hiện tại và counter là kết quả mà chúng tôi thu được thông qua việc theo dõi.
Những bộ đếm này có hai đặc điểm chính đó là: tính chính xác và khả năng
thích nghi. Thứ nhất, những bộ đếm này có khả năng đo đạc chính xác số vòng lặp
cũng như khung stack mà chương trình sử dụng. Những bộ đếm tính toán này cũng có
khả năng tính toán và đo đạc những vòng lặp trong những thủ tục đệ qui. Thứ hai, cách
mà nghiên cứu này sử dụng để theo dõi cũng như đo đạc gần như không ảnh hưởng đến
kết quả cũng như hiệu năng của chương trình. Mỗi bộ đếm chỉ có khả năng thay đổi giá
trị của bản thân nó và không hề có liên quan đến những bộ đếm khác. Cuối cùng, mỗi
bộ đếm đều được đặt ở những vị trí cần thiết để có thể đo đạc được chính xác. Vì thế,
người dùng không cần quan tâm đến việc nên bắt đầu chạy chương trình từ đâu. Chúng
được thêm tự động vào chương trình để có thể đo đạc được tài nguyên sử dụng. Chúng
tôi sẽ mô tả cụ thể hơn trong ví dụ 3.1 dưới đây.
Ví dụ 3.1: Giả sử rằng chúng ta có một cài đặt của thủ tục tính toán ma trận xác
định (là thủ tục được sử dụng để tính toán giá trị xác định của tập các phần tử đầu của
ma trận) như ở hình 2.2. Để có thể đo đạc được chi phí tính toán và độ sâu lớn nhất của

22


bộ nhớ stack cũng như tổng số khung stack mà chương trình sử dụng, chúng ta cần ba
bộ đếm: counter1, counter2 và counter3.
-

counter1 đo đạc chi phí tính toán của thủ tục. Tổng số lần vòng lặp ngoài ở dòng
11 được chạy sẽ được tính toán dựa trên giá trị của counter1 ở dòng 20 (Mỗi lần
lặp sẽ tăng giá trị của counter1 lên 1). Tương tự như thế với những vòng lặp ở
trong cũng được tính toán dựa trên counter1 ở dòng 17 và 18.

-

counter2 đo đạc tổng số khung stack mà thủ tục cần sử dụng. Khi thủ tục được
gọi, sẽ có 1 khung stack mới được khởi tạo và biến counter2 ở dòng 2 cũng sẽ
tăng lên 1 với mục đích đo được tất cả những khung stack mới.

-

counter3 đo đạc số lượng lớn nhất của khung stack cần sử dụng để chạy. Nói
một cách khác nó là mức sâu nhất của bộ nhớ stack mà chương trình cần đến.
Bộ đếm được đặt ở dòng 6 và 9, nơi mà điều kiện dừng của thủ tục đệ qui được
thỏa mãn.

23