Cac ky thuat nhan dang cac yeu cau can kiem thu 190440 khotrithucso com

MỤC LỤC
DANH MỤC CÁC TỪ VIẾT TẮT, KÝ HIỆU................................................3
DANH MỤC CÁC BẢNG................................................................................4
DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ...........................................................5
MỞ ĐẦU...........................................................................................................7
Chương 1 TỔNG QUAN..................................................................................8
1.1 Mục tiêu và phạm vi..........................................................................8
1.2 Những đề xuất của đề tài...................................................................9
1.3 Tổng quan đề tài................................................................................9
1.4 Đóng góp của đề tài........................................................................10
Chương 2 KHÁI NIỆM CƠ BẢN...................................................................11
2.1 Phân tích và biểu diễn luồng điều khiển.........................................11
2.2 Phân tích sự phụ thuộc....................................................................11
2.3 Sự thực thi biểu trưng.....................................................................13
2.4 Các thủ tục quyết định....................................................................14
Chương 3 CÁC KỸ THUẬT ĐỐI SÁNH....................................................15
3.1 Các kỹ thuật liên quan.....................................................................15
3.1.1 Kỹ thuật tìm kiếm sự khác nhau dựa trên mục đích chung của
chương trình....................................................................................16
3.1.2 Kỹ thuật tìm kiếm sự khác nhau dựa vào mục đích cụ thể của
chương trình....................................................................................19
3.2 Thuật tốn tìm kiếm sự khác nhau..................................................20
3.2.1 Tổng quan thuật toán.............................................................21
3.2.2. Mức lớp và giao diện............................................................22
3.2.3 Mức phương thức...................................................................23
3.2.4 Mức đỉnh ( node level)...........................................................23
3.2.5 Độ phức tạp của thuật toán....................................................33
3.3 Cơng cụ tìm kiếm sự khác nhau Jdiff.............................................33
Chương 4 PHÂN TÍCH ẢNH HƯỞNG ĐỘNG............................................35
4.1 Các nghiên cứu liên quan................................................................35
4.2 Kỹ thuật ảnh hưởng bao phủ - Coverage Impact............................39

2

4.3.1 Mối quan hệ của thực thi sau.................................................40
4.3.2 Thuật toán thực thi sau...........................................................41
4.3.3 Các thực thi đa luồng.............................................................44
4.4 Các công cụ phân tích ảnh hưởng động..........................................45
4.4.1 Cơng cụ CoverageTool..........................................................45
4.4.2 Cơng cụ thực thi sau..............................................................45
4.5 Nghiên cứu thực nghiệm trên thuật tốn phân tích ảnh hưởng động..
......................................................................................................47
4.5.1 Cài đặt thực nghiệm...............................................................47
4.5.2 Đánh giá chi phí.....................................................................47
Chương 5 XÁC ĐỊNH YÊU CẦU KIỂM THỬ.............................................50
5.1 Các kỹ thuật liên quan.....................................................................50
5.1.1 Ví dụ minh họa......................................................................52
5.1.2 Tổng quan về phương pháp tiếp cận......................................53
5.2 Tính tốn và kiểm tra các yêu cầu kiểm thử...................................54
5.2.1 Tiêu chuẩn của các thay đổi cơ bản.......................................55
5.2.2 Thuật toán..............................................................................57
5.2.3 Kiểm tra các yêu cầu kiểm thử..............................................63
5.2.4 Đa thay đổi.............................................................................64
5.2.5 Tích hợp với phân tích ảnh hưởng động................................67
5.3 Ma trận - cơng cụ thử nghiệm để xác định các yêu cầu kiểm thử...68
5.4 Nghiên cứu việc “xác định các yêu cầu kiểm thử”.........................69
5.4.1 Cài đặt công cụ ma trận.........................................................69
5.4.2 Các ảnh hưởng đến tính hợp lệ..............................................70
5.4.3 Nghiên cứu 1: Tiêu chuẩn đang tồn tại..................................70
Chương 6 KẾT LUẬN VÀ HƯỚNG NGHIÊN CỨU TƯƠNG LAI............72

6.1 Đánh giá về kết quả nghiên cứu......................................................72
6.2 Hướng nghiên cứu trong tương lai..................................................73
TÀI LIỆU THAM KHẢO...............................................................................74


3

DANH MỤC CÁC TỪ VIẾT TẮT, KÝ HIỆU
Từ viết tắt
BAMT

Tên tiếng Anh

Ý nghĩa

Binary Matching Tool

Công cụ đối sánh nhị phân

CFG

Control Flow Graph

Đồ thị luồng điều khiển

EAT

Execute After Tool

Công cụ kiểm thử thực thi sau

ECFG

Enhanced Control Flow Graph Đồ thị luồng điều khiển tăng
cường

FDD

Forward Direct Dependence

JABA

Java Architech for Byte Code Kiến trúc Java cho việc phân
Analysis
tích byte code

Phụ thuộc trực tiếp tiến

JIG

Java Interclass Graph

Đồ thị các lớp nội Java

JVM

Java Virtual Machine

Máy ảo Java

LOC

Line of Code

Số dòng lệnh

SDG

System Dependence Graph

Đồ thị phụ thuộc hệ thống

PSE

Partial Symbolic Execute

Thực thi biểu trưng bộ phận

Empty set

Tập rỗng




4

DANH MỤC CÁC BẢNG
Bảng 1: Bao phủ các vector bit cho các vết thực thi trên Hình 10..................39
Bảng 2: Giá trị của F, L, và C trong quá trình thực hiện ví dụ........................43

Bảng 3: Các chương trình hướng đối tượng....................................................47
Bảng 4: Thời gian thực thi...............................................................................48
Bảng 5: Các đường điều kiện và các trạng thái biểu trưng từ s4 s1 của P và
P’.....................................................................................................................62
Bảng 6: Đường các điều kiện và các trạng thái biểu trưng từ s2 đến s5 trong
phiên bản gốc và phiên bản đã chỉnh sửa........................................................65
Bảng 7: Tỷ lệ phần trăm bộ kiểm thử đưa ra các hành vi khác nhau trên 50 bộ
kiểm thử đầu vào đáp ứng các tiêu chí phù hợp lệnh cho Tcas và Schedule.. 70
Bảng 8: Tỷ lệ phần trăm bộ kiểm thử đưa ra hành vi khác nhau trên 50 bộ
kiểm thử đáp ứng tất cả các khoảng cách sử dụng đầy đủ các tiêu chí-i (0,1, 2)
cho Tcas và Schedule......................................................................................71


5

DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ
Hình 1: Q trình tạo các yêu cầu kiểm thử....................................................10
Hình 2: Một phần mã lệnh của lớp Library. Đồ thị luồng điều khiển của
phương thức getCheckOutBooks....................................................................12
Hình 3: Một phần mã lệnh của chương trình gốc (P) và chương trình đã chỉnh
sửa (P’)............................................................................................................16
Hình 4: Thuật tốn đối sánh - Func_Differencing .........................................22
Hình 5: Hai đồ thị ECFG cho thủ tục unavaiableBookFinder.main trong P và
P’.....................................................................................................................26
Hình 6: ECFG cho UnavaiableBookFinder.main (a) và đồ thị khoảng cách
trung gian cho thủ tục này hình (b, c, d).........................................................30
Hình 7: Thuật tốn đối sánh Func_DistanceThreshold...................................33
Hình 8: Một phần mã nguồn của chương trình gốc P.....................................37
Hình 9: Đồ thị gọi của chương trình P............................................................37
Hình 10: Các vết của P. Ký hiệu ... trong Exec4 có nghĩa là chuỗi được lặp lại

nhiều lần..........................................................................................................37
Hình 11: Đồ thị toàn bộ- bộ phận DAG cho các vết trong Hình 10................38
Hình 12: Thuật tốn thu thập thực thi sau.......................................................42
Hình 13: So sánh độ chính xác của các kết quả. Thể hiện bằng số phần trăm
các phương thức trong tập ảnh hưởng.............................................................49
Hình 14: Một phần mã nguồn của chương trình gốc P với thay đổi ở lệnh thực
thi s4................................................................................................................52
Hình 15: Một phần của chương trình để minh họa cho việc xác định các câu
lệnh ở khoảng cách 1 từ câu lệnh rẽ nhánh....................................................56
Hình 16:Thuật tốn tính tốn các u cầu kiểm thử........................................58
Hình 17: Cây thực thi biểu trưng từ s4 đến s1 trong P....................................60


6

Hình 18: Một phần chương trình minh họa việc xách định các lệnh ở khoảng
cách 2 trong biểu diễn của đa thay đổi............................................................64
Hình 19: Cơng cụ ma trận kiểm thử................................................................67
Hình 20: Ma trận nhận dạng............................................................................68


7

MỞ ĐẦU
Trong suốt vịng đời của mình, phần mềm ln phải thay đổi do nhiều
lý do khác nhau, như việc sửa chữa lỗi, nâng cao hiệu suất, cấu trúc lại mã
lệnh. Kiểm thử phần mềm đã sửa đổi là một hoạt động chính được thực hiện
nhằm mục đích đảm bảo rằng các thay đổi này nằm trong dự định có thể kiểm
sốt được và khơng ảnh hưởng đến các phần còn lại của phần mềm. Vấn đề
cơ bản của việc kiểm thử phần mềm trong trường hợp đó là phải quyết định

xem các bộ kiểm thử như thế nào là đầy đủ đối với sự thay đổi, các trường
hợp kiểm thử nào là tốt nhất tạo ra đầu vào phù hợp để đạt được mục đích
kiểm thử phần bị thay đổi. Hiện tại các kỹ thuật chủ yếu thực hiện việc đánh
giá sự đầy đủ của các bộ kiểm thử chỉ dựa trên luồng điều khiển và luồng dữ
liệu. Chúng không xem xét những ảnh hưởng của sự thay đổi trên các trạng
thái của tồn bộ chương trình, do vậy dẫn đến hạn chế việc đảm bảo rằng các
phần thay đổi sẽ được kiểm thử.
Luận văn nghiên cứu các kỹ thuật nhận dạng các yêu cầu cần kiểm thử
của phần mềm đã thay đổi. So sánh ưu nhược điểm của các kỹ thuật hiện có,
đồng thời đề xuất hướng cải tiến trong các thuật toán để đảm bảo xác định
được các yêu cầu kiểm thử một cách chính xác, nhanh chóng, đầy đủ nhất. Sử
dụng kỹ thuật này kiểm thử viên sẽ chủ động tạo ra các bộ kiểm thử phù hợp,
tối ưu, đảm bảo sự tin cậy đối với chất lượng cả các phiên bản phần mềm đã
thay đổi. Nghiên cứu cũng đưa ra các thực nghiệm với các cơng cụ dựa trên
thuật tốn đã tối ưu để minh họa các kỹ thuật trên, nhằm xác định các kiểm
thử cần thiết để đảm bảo các trường hợp kiểm thử thích hợp đối với các trạng
thái chương trình khác nhau tại các phần đã được chọn lựa trước của phần
mềm. Các kỹ thuật này bao gồm: kỹ thuật tính tốn sự tương ứng, sự khác
nhau giữa các phiên bản phần mềm và hai kỹ thuật phân tích ảnh hưởng động
để xác định các bộ phận của phần mềm bị ảnh hưởng bởi sự thay đổi với sự
chính xác của tập các kiểm thử được thực hiện.


8

Chương 1 TỔNG QUAN
Phần mềm luôn luôn là một đối tượng chịu sức ép của việc thay đổi.
Trong suốt vòng đời của mình phần mềm phải trải qua sự biến đổi liên tiếp
nhau. Bởi vì những sự thay đổi là thường xuyên và liên tục nên vấn đề đặt ra
là việc phải thực hiện kiểm thử như thế nào đối với các phiên bản phần mềm

đã được sửa đổi, việc xác dịnh những kiểm thử nào là cần thiết và hiệu quả là
rất quan trọng. Kiểm thử hồi quy (Regression Testing) là một hoạt động trong
kiểm thử các phiên bản đã thay đổi của phần mềm nhằm làm tăng sự tin cậy,
để đảm bảo rằng các thay đổi này không gây ảnh hưởng bất lợi cho phần còn
lại của phần mềm. Do việc kiểm thử không những cần kiểm tra chính các
chức năng đã thay đổi mà cịn phải kiểm tra các chức năng còn lại của phần
mềm bị ảnh hưởng như thế nào đối với sự thay đổi đó nên các hoạt động kiểm
thử này luôn luôn gặp phải thách thức lớn. Đa số các nghiên cứu trong kiểm
thử hồi quy tập trung vào 3 hoạt động chính:
- Chọn lọc kiểm thử hồi quy [6].
- Đánh giá các bộ kiểm thử theo độ ưu tiên.
- Giảm số lượng các bộ kiểm thử [14].
Những hoạt động này nhằm mục đích làm tăng tính hiệu quả của việc
kiểm thử hồi quy bằng cách giảm số lượng các trường hợp kiểm thử cần thiết
để chạy lại, duy trì và sắp xếp lại thứ tự các trường hợp kiểm thử dựa trên một
số tiêu chuẩn, ví dụ như là mức độ bao phủ. Tuy nhiên có một số ít các nghiên
cứu khác đã tập trung vào việc ước lượng, đánh giá và cải thiện chất lượng
của các bộ kiểm thử hồi quy. Đa số các nghiên cứu này đánh giá quá cao sự
chính xác của các bộ kiểm thử đang tồn tại trong việc thi hành phần mềm với
chi tiết cụ thể của các thay đổi. Hơn thế nữa, những nghiên cứu đó thường
khơng cung cấp các hướng dẫn thích hợp cho kiểm thử viên tạo các đầu vào
mới để thu được các kết quả rõ ràng khi mà các bộ kiểm thử đang tồn tại
khơng đánh giá được chính xác sự thay đổi đó.

1.1 Mục tiêu và phạm vi
Mục tiêu của nghiên cứu này là nghiên cứu so sánh các kỹ thuật kiểm
thử hồi quy hiện có, đưa ra các cải tiến dựa trên các kỹ thuật đó để xác định
các yêu cẩu kiểm thử đối với phần mềm đã bị thay đổi. Để đạt được mục tiêu
này, nghiên cứu tập trung vào vấn đề định nghĩa các tiêu chí cụ thể của việc
kiểm thử và xác định các kiểm thử cần thiết cho việc kiểm thử các thay đổi

(Các bộ kiểm thử phải đảm bảo tính chính xác, đầy đủ. Số lượng các bộ kiểm
thử phải được giảm tối đa để giảm thời gian kiểm thử hồi quy). Đồng thời với
việc thực thi các kiểm thử đó là việc đưa ra các hướng dẫn để có thể tạo ra các
bộ đầu vào kiểm thử mới để kiểm thử các thay đổi một cách hiệu quả nhất.


9

1.2 Những đề xuất của đề tài
Nội dung nghiên cứu của đề tài là các kỹ thuật phân tích tĩnh chương
trình có hiệu quả để tìm ra các điểm tương ứng, các điểm khác nhau trong
toàn bộ hai phiên bản của phần mềm. Đồng thời kết hợp với kỹ thuật phân
tích động tăng cường các thơng tin tính tốn để xác định các yêu cầu cần thiết
nhất, hiệu quả nhất liên quan đến việc kiểm thử phần mềm.

1.3 Tổng quan đề tài
Quá trình tạo ra các yêu cầu đối kiểm thử đối với phần mềm đã thay đổi
được mô tả trong hình 1, bao gồm 3 hoạt động là: đối sánh tìm kiếm sự khác
nhau, phân tích các ảnh hưởng động, và xác định các yêu cầu kiểm thử. Đầu
vào là hai phiên bản của một chương trình: phiên bản gốc P và một phiên bản
đã thay đổi, chỉnh sửa P’. Chi tiết về các hoạt động này được giới thiệu trong
các chương tiếp theo.
Chương hai mô tả các khái niệm nền tảng. Đó là các khái niệm trong
phân tích chương trình: đồ thị luồng phụ thuộc điều khiển và đồ thị luồng phụ
thuộc dữ liệu, sự thực thi mô hình.
Chương ba trình bày kỹ thuật mới nhằm xác định các yêu cầu kiểm
thử và các kỹ thuật hỗ trợ trong việc phân loại luồng xử lý, hình 1. Cụ thể,
chương này giới thiệu một kỹ thuật tìm ra sự khác biệt, giúp đưa ra các báo
cáo về thông tin thay đổi, bao gồm thông tin về sự khác nhau và sự tương ứng
trong toàn bộ hai phiên bản P và P’ ở mức các lệnh.

Chương bốn giới thiệu hai kỹ thuật phân tích ảnh hưởng động, sử dụng
các thơng tin thay đổi và một bộ kiểm thử (hoặc một tập các thực thi T), để
tìm ra các phần của phiên bản P’ bị ảnh hưởng bởi các thay đổi (các thông tin
ảnh hưởng) trong các thực thi. Bên cạnh đó chương bốn cũng phân tích, so
sánh ưu nhược điểm của hai kỹ thuật này.
Chương năm đưa ra một công nghệ sử dụng thông tin thay đổi và ảnh
hưởng để xác định các yêu cầu đối với việc kiểm thử. Các yêu cầu này giúp
ước lượng, đánh giá một cách hiệu quả nhất chất lượng của các bộ kiểm thử ,
giúp nâng cao độ tin cậy đối với việc kiểm thử các thay đổi và đưa ra các
hướng dẫn cho việc tạo ra các đầu vào kiểm thử mới để kiểm thử chương
trình.
Mỗi phần trong ba chương đầu tiên thảo luận các kỹ thuật liên quan và
so sánh các ưu nhược điểm của chúng. Chúng được mô tả chi tiết và giới
thiệu các công cụ để thực hiện các kỹ thuật này.
Chương sáu là sự tổng kết, đánh giá về các kết quả của đề tài và hướng
nghiên cứu trong tương lai.


10

Hình 1: Quá trình tạo các yêu cầu kiểm thử

1.4 Đóng góp của đề tài
Nghiên cứu này có một số đóng góp trong lĩnh vực kiểm thử phần mềm.
- Thuật tốn tính tốn sự khác nhau và sự tương ứng đối với các phiên
bản chương trình phần mềm.
- Kỹ thuật nhằm xác định các bộ phận, thành phần của phần mềm bị ảnh
hưởng bởi sự thay đổi bằng một tập các thực thi chi tiết.
- Kỹ thuật nhằm xác định các yêu cầu kiểm thử đối với các phiên bản
phần mềm đã được sửa đổi, đảm bảo rằng các trường hợp kiểm thử

thích hợp, đầy đủ và đưa ra kết quả trong các luồng điều khiển khác
nhau hoặc các trạng thái chương trình khác nhau ở các điểm được chọn.
- Nghiên cứu các công cụ thực hiện các kỹ thuật đó.
- Các so sánh, đánh giá kết quả dựa trên thực nghiệm.


11

Chương 2 KHÁI NIỆM CƠ BẢN
Chương hai giới thiệu các khái niệm nền tảng làm cơ sở cho các kỹ thuật
sẽ được trình bày ở các chương tiếp theo. Phần dưới đây đưa ra các khái niệm
cơ bản trong phân tích chương trình bao gồm: đồ thị luồng điều khiển, sự phụ
thuộc của của điều kiển và dữ liệu, sự thực thi mơ hình.

2.1 Phân tích và biểu diễn luồng điều khiển
Đa số các kỹ thuật phân tích chương trình đều cần thông tin về luồng
điều khiển bên trong và giữa các thủ tục trong tồn bộ chương trình. Phân tích
luồng điều khiển sẽ thực hiện việc tính tốn các thơng tin bằng cách phân tích
các câu lệnh trong chương trình. Thơng tin luồng điều khiển thường được
biểu diễn bằng đồ thị luồng điều khiển. Dưới đây là một số định nghĩa.
Định nghĩa 1: Một đồ thị luồng điều khiển (CFG) G= (N, E) cho một chương
trình P là một đồ thị có hướng. Trong đó:
- N là số đỉnh, mỗi đỉnh (Node) tương ứng với một câu lệnh trong P.
- E (Edge) là số cạnh, mỗi cạnh thể hiện luồng của điều khiển giữa các
câu lệnh trong P.
- N cũng chứa một đầu vào duy nhất và các đỉnh đầu ra nó chính là đầu
vào và kết quả đầu ra tương ứng của thủ tục P.
- Mỗi cạnh trong E được gán nhán True (T) hoặc False (F).
Hình 2, mơ tả thủ tục getCheckedOutBooks trong lớp Library, đó là một đồ
thị luồng điều khiển CFG.

2.2 Phân tích sự phụ thuộc
Một phân tích khác trong nghiên cứu này là phân tích sự phụ thuộc [10].
Nó xác định các mối quan hệ phụ thuộc giữa các lệnh trong chương trình.
Định nghĩa trong phần này dựa trên các kết quả được giới thiệu bởi Ferrante
[10]. Ví dụ dưới xem xét hai lớp của sự phụ thuộc.
Một kiểm soát phụ thuộc xảy ra giữa một lệnh và một quyết định khi giá
trị của quyết định đó được tính tốn mỗi khi lệnh được thực thi. Một phụ
thuộc dữ liệu xảy ra giữa hai lệnh khi một biến được sử dụng trong một lệnh
có thể chứa giá trị không sai lệch nếu hai câu lệnh được đảo ngược. Tiếp theo,
các phụ thuộc dữ liệu, phụ thuộc điều khiển được định nghĩa một cách hình
thức hơn như dưới đây:


12

Định nghĩa 2: Giả sử G = ( N, E) là một CFG, và u, v € N. Đỉnh u là
một phụ thuộc điều khiển vào đỉnh v với nhãn “L” nếu và chỉ nếu v có đỉnh
nối tiếp v’ theo cạnh ngoài được gán nhãn “L” và v’’ sao cho mọi đường
trong G từ v’ đến đỉnh đầu ra chứa u nhưng có ít nhất một đường trong G từ
v’’ tới đỉnh đầu ra không chứa u.
public class Library { Set<Book> getCheckedOutBooks ( ) { s1
Set<Book> chOut = new HashSet<Book>( ) ;
s2
for (Book book:books )
s3
if ( book.getStatus() == Book.CHECKEDOUT)
s4
chOut.add (book ) ;
s5

i f ( chOut.isEmpty () )
s6
chOut = new EmptySet<Book>( ) ;
s7
return chOut ;
}
.. .
}

Hình 2: Một phần mã lệnh của lớp Library. Đồ thị luồng điều khiển
của phương thức getCheckOutBooks
Ví dụ, giả sử đồ thị luồng điều khiển của phương thức
getCheckedOutBooks trong hình 2: đỉnh s3 là một phụ thuộc điều khiển vào
đỉnh s2 với nhãn “T” bởi vì s2 có 2 đỉnh nối tiếp s3 và s5, và mỗi đường từ s3


13

tới đỉnh đầu ra đều chứa s3, nhưng khơng có đường nào từ s5 tới đỉnh đầu ra
chứa s3.
Định nghĩa 3: Cho đồ thị G= (N, E) là một đồ thị luồng điều khiển. u, v
€ N. Đỉnh v là một phụ thuộc dữ liệu và đỉnh u nếu và chỉ nếu đỉnh u định
nghĩa một biến x, v sử dụng x, và có 1 đường đi trong đồ thị G từ đỉnh u tới v
mà khơng có bất cứ một đỉnh nào khác định nghĩa x.
Ví dụ, trong phương thức getCheckedOutBooks, đỉnh s7 là một phụ
thuộc dữ liệu vào đỉnh s1 bởi vì đỉnh s1 định nghĩa biến chOut, s7 sử dụng
biến chOut, và khơng có một đỉnh nào trên đường (s1, s2, s5, s7) định nghĩa
chOut.

2.3 Sự thực thi biểu trưng

Sự thực thi biểu trưng [7] là một kỹ thuật phân tích chương trình. Khơng
giống các kỹ thuật thơng thường thực thi một chương trình với một tập các
đầu vào không đổi, cố định, sự thực thi biểu trưng thực thi chương trình một
cách biểu trưng dựa trên một tập các lớp đầu vào. Sự thực thi biểu trưng tính
tốn một biểu trưng đại diện của các tính tốn các biến trong chương trình dọc
theo đường từ điểm đầu vào đến điểm đầu ra và miền của đường tính các giá
trị đầu vào. Với bất kỳ đường nào, đại diện biểu trưng của đường tính tốn
(các giá trị của tất cả các biến đầu ra tại điểm cuối của đường) và miền đường
đi (miền của các biến đầu vào cho đường sẽ được thực thi) có thể được phát
triển một cách tăng dần như là các lệnh trên đường được thông dịch. Để phát
triển đại diện này, sự thực thi biểu trưng gán mỗi đầu vào với một giá trị biểu
trưng và đánh giá mỗi đường đi bằng cách thơng dịch lệnh trên đường đó dựa
trên khái niệm về các giá trị biểu trưng này. Trong quá trình thực thi, các giá
trị của các biến chương trình được duy trì như là các biểu diễn đại số qua tên
của biểu trưng. Ở mỗi điểm dọc theo một đường, giá trị của các biến được thể
hiện như là một vector ( s(y1), s(y2), …), trong đó s(yi) là giá trị biểu trưng
hiện tại của biến yi. Uớc lượng đường đi chính là một vector các giá trị của tất
cả các biến đầu ra ở điểm cuối của mỗi đường. Miền của đường đi cũng được
hình thành một cách tăng dần bằng cách thông dịch các quyết định rẽ nhánh
của các câu lệnh điều kiện trong đường đi. Ở mỗi quyết định nhánh p, biểu thị
các tên biểu trưng, quyết định được đánh giá bằng cách thay thế mỗi biến
bằng các biểu diễn biểu trưng để đạt được một khẳng định với sự thay thế p s.
Nếu đường đi đưa ra nhánh của quyết định là đúng, miền bị hạn chế bởi các
ràng buộc ps; ngược lại, nó bị hạn chế bởi rảng buộc ⌐p s . Do đó, miền của
đường là một kết nối của các ràng buộc ps,i hoặc ⌐ps,i. , phụ thuộc và các
nhánh được chọn thực thi, với tất cả các quyết định rẽ nhánh dựa trên đường
đi. Đối với các đường không thực thi, kết nối các ràng buộc là khơng thỏa
mãn, và do đó khơng có các giá trị cố định của các biến đầu vào có thể chỉ
dẫn tới đường đi đó.

14

Có 3 loại thực thi biểu trưng đó là:
- Sự thực thi biểu trưng đường phụ thuộc.
- Sự thực thi biểu trưng động.
- Sự thực thi biểu trưng toàn bộ.
Sự phân loại này chủ yếu dựa vào các kỹ thuật mà chúng sử dụng để chọn các
đường sẽ được thực thi. Sự thực thi biểu trưng đường phụ thuộc lựa chọn các
đường từ đầu vào của người dùng hoặc để khám phá cách thức sử dụng trong
bộ máy thực thi biểu trưng. Sự thực thi biểu trưng động lựa chọn các đường đi
dựa trên các đường đã được thực thi bằng các dữ liệu đầu và cụ thể. Sự thực
thi biểu trưng tồn bộ khơng lựa chọn một đường đơn lẻ để thực thi nhưng cố
gắng tạo ra một biểu diễn biểu trưng của các ước lượng, tính tốn đường đi và
các miền đường đi mà thể hiện tất cả các đường.

2.4 Các thủ tục quyết định
Khi thực thi một chương trình một cách biểu trưng, một bộ máy thực
biểu trưng thực thi cần kiểm tra xem một đường con được khám phá là có thể
thực thi được. Để đạt được mục đích này, bộ máy đó địi hỏi một thủ tục
quyết định (một phương thức để giải quyết vấn đề của quyết định), để giải
quyết được xem có thể thực thi một đường con hay khơng (ví dụ, sự thỏa mãn
của các ràng buộc đường của đường con đó). Thủ tục quyết định phải có thể
điều khiển khả năng thỏa mãn vấn đề một cách logic. Mặt khác, sự thực thi
biểu trưng đề cập đến sự thỏa mãn của vấn đề khi các công thức chứa các
nguyên tố được thông dịch với sự đánh giá cao đối với các lý thuyết nền tảng
của số học tính tốn số ngun và số thực, và các lý thuyết về mảng, danh
sách, và các cấu trúc dữ liệu khác. Vấn đề này dược biết đến như là vấn đề
các lý thuyết đơn vị khả năng thỏa mãn (Satisfiability Modulo Theories –
SMT) với một lý thuyết T: được cho bởi một công thức (ví dụ, các ràng buộc

đường) F, quyết định khi nào F là một thỏa được của T.
Có hai cách tiếp cận tới SMT: Cách tiếp cận tích cực (eager approach) và
các tiếp cận lười (lazy approach). Cách tiếp cận tích cực chuyển công thức
đầu vào trong một bước bảo đảm thỏa được đơn nhất thành một công thức xác
định CNF và sử dụng một bộ giải pháp SAT [11] để kiểm tra tính thỏa được
của nó. Ngược lại cách tiếp cận lười, ban đầu xem xét mỗi nguyên tố xuất
hiện trong công thức đơn giản F đơn giản như là một biểu trưng xác định và
gửi công thức đã được biến đổi đến bộ giải pháp SAT. Nếu bộ giải pháp SAT
đưa ra báo cáo rằng công thức là không thỏa mãn, thì cơng thức gốc F cũng
khơng thỏa được T. Nếu kết quả đưa ra là mơ hình thỏa được, thì F là thỏa
được với T. Ngược lại, bộ giải pháp T trả về phản hồi có thể hướng dẫn bộ
giải pháp SAT trong việc xây dựng một mô hình mới của F. Quá trình này
được lặp lại cho tới khi bộ giải pháp SA tìm thấy một mơ hình T thỏa được
hoặc trả lại kết quả là khơng thỏa được.


15

Chương 3 CÁC KỸ THUẬT ĐỐI SÁNH
Đối sánh là bước đầu tiên nhằm tạo ra các yêu cầu cho việc kiểm thử đối
với phần mềm đã thay đổi là xác định các thay đổi giữa phiên bản gốc và
phiên bản đã chỉnh sửa (như chỉ ra trong hình 1). Thơng tin chính xác về các
thay đổi giúp xác định các yêu cầu kiểm thử không chỉ tạo ra các yêu cầu mà
còn giúp phát hiện các hành động khác nhau khi thực thi phiên bản đã chỉnh
sửa dựa trên tập các đầu vào thỏa mãn chúng. Các thông tin thay đổi khơng
chính xác có thể là ngun nhân dẫn đến việc tạo ra các yêu cầu kiểm thử sai
lầm: ví dụ như các đầu vào thỏa được yêu cầu không giúp phát hiện ra các
hoạt động khác nhau đối với phiên bản đã chỉnh sửa. Việc nhận biết khơng
những địi hỏi biết được các thơng tin thay đổi mà cịn phải ánh xạ tồn bộ
chương trình trong phiên bản gốc và các phiên bản đã chỉnh sửa. Bộ nhận biết

tạo ra các yêu cầu kiểm thử bằng cách so sánh trạng thái chương trình tại các
lệnh trong phiên bản gốc với các trạng thái chương trình tại các câu lệnh
tương ứng ở phiên bản đã chỉnh sửa. Do đó, bộ nhận biết đòi hỏi phải ánh xạ
giữa các câu lệnh trong hai phiên bản. Các kỹ thuật được trình bày dưới đây
giúp xác định các thông tin thay đổi và các ánh xạ của hai phiên bản.

3.1 Các kỹ thuật liên quan
Hiện nay có một vài kỹ thuật và cơng cụ giúp cho việc so sánh mã nguồn
file dạng text (ví dụ như tiện ích UNIX Diff [15]) đã được giới thiệu. Tuy
nhiên, các kỹ thuật này đều có những hạn chế đó là những khác nhau về mặt
văn bản có thể đưa ra các báo cáo khơng có hiệu quả đối với cú pháp hoặc
ngữ nghĩa chương trình. Ví dụ như các thông tin thêm vào của một phương
thức không bao giờ được gọi đến và các thay đổi trong các chú giải, các
khoảng trắng, và nó khơng xem xét các thay đổi gián tiếp ngữ nghĩa chương
trình do sự thay đổi văn bản.
Ta xem xét ví dụ dưới đây, có hai phiên bản của một phần chương trình
viết bằng ngơn ngữ Java như trong hình 3. Phiên bản gốc P và phiên bản đã
chỉnh sửa P’. Cả hai phiên bản đều sử dụng cùng một lớp thư viện như trong
hình 2. Kết quả đầu ra khi chạy cơng cụ so sánh sự khác nhau giữa P và P’ đó
là phương thức EmptySet.addAll đã bị chèn thêm vào và cấu trúc thừa kế loại
exception đã bị thay đổi. Tuy nhiên, các phát hiện đó chỉ ra rằng việc gọi
res.addAll trong UnavailBookFinder.main của P và P’ có thể bị ràng buộc bởi
các phương thức khác, và exception có thể khơng được ném ra bởi việc gọi
res.addAll trong phương thức unavailBookFinder.main, có thể bỏ qua mà
khơng phân tích các thơng tin thêm. Một ví dụ khác, xem xét trường hợp khi
chạy bộ tìm kiếm sự khác nhau đối với phiên bản trung gian khi mà chỉ


16

phương thức EmptySet.addAll được thêm vào cả P và cả trong phiên bản thay
đổi P’. Kết quả đầu ra đối với cặp P và P’ có thể khơng thể hiện rằng các
ngoại lệ có thể được ném ra khi gọi res.addAll trong phương thức
UnavailBookFinder.main có thể bị bắt được bởi các khối catch khác.

Hình 3: Một phần mã lệnh của chương trình gốc (P) và chương trình
đã chỉnh sửa (P’)
Các kỹ thuật tìm kiếm sự khác nhau khác đang tồn tại được cụ thể hóa để tính
tốn sự khác nhau trong các chương trình. Các kỹ thuật này có thể được chia
ra thành 2 nhóm (sẽ được trình bày ở trong mục 3.1.1 và 3.1.2): Các kỹ thuật
tìm kiếm sự khác nhau dựa trên mục đích chung và các kỹ thuật tìm kiếm sự
khác nhau dựa vào các mục tiêu cụ thể.

3.1.1 Kỹ thuật tìm kiếm sự khác nhau dựa trên mục đích chung của
chương trình
Các kỹ thuật này có thể được phân loại thành 3 nhóm:
- Phân tích sự khác nhau của chương trình dựa dựa trên so sánh văn bản
(text-based).


17

- Phân tích sự khác nhau của chương trình dựa trên so sánh về mặt cú
pháp (syntactic-based).
- Phân tích sự khác nhau của chương trình dựa trên so sánh về mặt ngữ
nghĩa (semantic-based).
3.1.1.1. Tìm kiếm sự khác nhau dựa trên so sánh văn bản.
Cách tiếp cận của Maletic và Collard [21] là kỹ thuật phân tích, tìm kiếm
sự khác nhau dự trên việc so sánh văn bản (text-based). Về cơ bản kỹ thuật
chuyển đổi các file chương trình nguồn viết bằng C/C++ thành một định dạng

gọi là srcML. Cách thức này làm cho cấu trúc chương trình trở nên rõ ràng
hơn so với mã nguồn dạng thô và sau khi chuyển đổi ta sẽ áp dụng bộ tìm
kiếm sự khác nhau để so sánh các thể hiện dưới dạng srcML của hai phiên
bản mã nguồn của chương trình gốc và chương trình đã sửa đổi. srcML là một
định dạng dựa trên ngôn ngữ XML, biểu diễn mã nguồn được gắn với thông
tin cú pháp. Kết quả đầu ra sẽ được kết chuyển thành file tài liệu XML ( cũng
theo định dạng srcML), với các thẻ XML được thêm vào chỉ ra các phần tử
XML giống nhau, phần tử được chèn thêm vào, phần tử bị xóa đi giữa phiên
bản đã biến đổi so với phiên bản gốc. Các tiếp cận này tận dụng các bộ cơng
cụ XML để có thể dễ dàng tạo nên một quá trình tìm kiếm các thông tin thay
đổi liên quan với nhau. Tuy nhiên thực tế kỹ thuật này vẫn bị giới hạn bởi lý
do là vẫn sử dụng cách thức tìm kiếm thơng tin khác nhau dựa trên so sánh
các dịng lệnh (line-based).
3.1.1.2 Tìm kiếm sự khác nhau dựa trên sự so sánh về mặt cú pháp
Kỹ thuật này nhằm mục đích so sánh hai phiên bản của một chương trình
về mặt cú pháp. Để áp dụng kỹ thuật này, chương trình thường được biểu diễn
dưới dạng cây cú pháp trừu tượng hoặc đồ thị luồng điều khiển; do đó, nó có
thể bỏ qua các khác biệt về mặt văn bản (textual differencing) mà khơng ảnh
hưởng đến các chương trình, ví dụ như các thay đổi với các chú thích của
chương trình.
Một vài mơi trường phát triển tích hợp hiện đại, ví dụ như Eclipse, đã hợp
nhất một bộ phân tích cú pháp đối với ngơn ngữ lập trình mà nó hỗ trợ. Do
đó, chúng có thể so sánh các phiên bản của một chương trình một cách hiệu
quả hơn là các cơng cụ dựa trên các so sánh văn bản đơn giản. Tuy nhiên, khả
năng so sánh của các bộ công cụ này vẫn cịn hạn chế, chúng chỉ có thể nhận
ra các thay đổi ở mức độ cú pháp thuần nhất. So sánh khác nhau về mặt cú
pháp không thể xác định trực tiếp ở mức thực thi các câu lệnh liên quan đến
các đặc điểm của hướng đối tượng.
Laski và Szermer giới thiệu một thuật tốn tính tốn độ khác nhau của chương
trình bằng cách phân tích các đồ thị luồng điều khiển của phiên bản gốc và

phiên bản đã sửa đổi [18]. Thuật toán phân loại các thay đổi của chương trình


18

vào các cụm, mỗi cụm có duy nhất một điểm đầu vào, và duy nhất một điểm
đầu ra. Các cụm được thu gọn thành các đỉnh đơn trong hai đồ thị và chúng
được mở rộng, đối chiếu một cách đệ quy. Biểu diễn đồ thị luồng điều khiển
không áp dụng được với các thuộc tính của mơ hình hướng đối tượng; do đó
thuật tốn có thể khơng tính tốn chính xác thơn tin thay đổi đối với các
chương trình hướng đối tượng. Thuật tốn khơng thể phát hiện sự khác nhau ở
một site được gọi, có thể gọi một phương thức mới được thêm vào trong
phiên bản chỉnh sửa khi sử dụng phương thức overriding. Hơn thế nữa, thuật
toán đối chiếu các cụm bị hạn chế về mặt khả năng và có thể đưa ra các kết
quả tính tốn khơng chính xác. Thuật tốn sử dụng tồn bộ các câu lệnh của
hai cụm để quyết định xem liệu rằng hai cụm là có khớp với nhau. Thuật tốn
khơng cho phép đối sánh các cụm ở các mức kết tổ khác nhau. Nguyên nhân
này dẫn đến kết quả đưa ra không chính xác.
BMAT [32] (cơng cụ đối sánh nhị phân) thực hiện việc đối sánh các khối dữ
liệu và các khối mã lệnh giữa hai phiên bản của một chương trình theo định
dạng nhị phân. BMAT sử dụng một số thuật tốn kinh nghiệm để tìm kiếm sự
tương xứng giữa các khối dữ liệu nhị phân. Tuy nhiên các thuật toán kinh
nghiệm chỉ áp dụng cho việc đối sánh ở mức độ nhị phân nhưng không thể áp
dụng với mức mã nguồn hoặc mức Java bytecode. Hơn nữa BMAT khơng
tính tốn được các thông tin thay đổi liên quan tới các cấu trúc hướng đối
tượng, như là các phương thức overriding hoặc các thay đổi trong lớp kế thừa.
3.1.1.3 Tìm kiếm sự khác nhau dựa trên việc so sánh ngữ nghĩa
Kỹ thuật này so sánh hai phiên bản của một chương trình theo ngữ nghĩa
và xác định các khác nhau chỉ khi ngữ nghĩa chương trình thay đổi khi các cú
pháp thay đổi.

Đối sánh ngữ nghĩa (Sematic diff) so sánh hai phiên bản của một chương
trình theo các thủ tục tương ứng, nó tính tốn một tập các phụ thuộc đầu vào,
đầu ra của mỗi thủ tục, và xác định sự khác nhau giữa hai tập tính tốn của
cùng thủ tục trong phiên bản gốc và phiên bản đã sửa đổi. Do chỉ đối sánh ở
mức thủ tục nên kỹ thuật này không bị ảnh hưởng của các phụ thuộc đầu vào,
đầu ra.
Cách tiếp cận của Horwitz [15] ước lượng các khác biệt về cú pháp và
ngữ nghĩa giữa hai chương trình sử dụng thuật tốn phân chia thành phần.
Chương trình được mơ hình hóa dưới dạng đồ thị biểu diễn chương trình
(PRG- Program Representation Graph). Đó là biểu diễn định nghĩa các
chương trình viết bởi ngơn ngữ với các biến vơ hướng, các lệnh gán, các lệnh
điều kiện, các vịng lặp và các lệnh thoát. Hạn chế trong cách tiếp cận của
Horwitz là không áp dụng được với các chương trình viết bằng các ngơn ngữ
truyền thống như C, C++ hoặc Java. Mặc dù PRG có thể mở rộng để bao gồm


19

các đặc điểm của các ngơn ngữ, thuật tốn phân chia thành phần tuy nhiên nó
khơng áp dụng được với các chương trình lớn.

3.1.2 Kỹ thuật tìm kiếm sự khác nhau dựa vào mục đích cụ thể của
chương trình
Các tiếp cận theo hình thức này tính tốn thơng tin khác nhau theo các
mục tiêu cụ thể, kết quả các thông tin khác nhau được lấy làm mục tiêu để tối
ưu việc tìm kiếm. Tiếp cận của Binkley [1] ước lượng các khác nhau về ngữ
nghĩa giữa hai phiên bản chương trình nhằm làm giảm chi phí của kiểm thử
hồi quy. Dựa trên đồ thị phụ thuộc hệ thống (System Dependence GraphSDG), kỹ thuật giúp xác định các đỉnh không tương xứng và các đỉnh nằm ở
các cạnh luồng điều khiển hoặc dữ liệu đi vào. Sau đó nó thực thi việc chuyển
tiếp các phần bắt đầu từ các đỉnh tới tất cả các đỉnh bị ảnh hưởng trong đồ thị.

Raghavan và các đồng sự đã giới thiệu bộ công cụ tìm kiếm sự khác nhau
được gọi là DEX (Difference extractor) [26]. DEX so sánh hai đồ thị ngữ
nghĩa trừu tượng (ví dụ các cây cú pháp trừu tượng tăng cường với các cạnh
mở rộng mà mã hóa thơng tin về loại đỉnh) biểu thị hai phiên bản của một
chương trình. Kết thúc việc đối sánh, DEX sẽ cho ra một mã soạn thảo có
chứa những biến đổi cần thiết để chuyển đồ thị ngữ nghĩa của phiên bản gốc
sang đồ thị ngữ nghĩa của phiên bản mới. Công cụ này cũng tổng hợp các
thống kê về các thay đổi liên quan tới các nhân tố về bản chất các lỗi của dự
án phần mềm.
Ren và các đồng sự giới thiệu CHIANTI [27], một cơng cụ phân tích ảnh
hưởng sử dụng một bộ máy tìm kiếm sự khác nhau nhằm xác định các thay
đổi nguyên tố giữa hai phiên bản của một chương trình Java và các phụ thuộc
giữa những thay đổi đó. Rangarajan cũng sử dụng dấu hiệu của các thay đối
nguyên tố ở các mức phương thức và mức lớp chương trình. Rangarajan đã
giới thiệu bộ cơng cụ mang tên JEVOLVE, nó phân tích các chương trình
Java và xác định các lớp thay đổi buộc phải kiểm thử lại. Hai cơng cụ trên có
tác dụng ở mức độ phương thức và mục tiêu của chúng là cung cấp các thông
tin về sự khác nhau để xác định các trường hợp kiểm thử nào sẽ bị ảnh hưởng
bởi sự thay đổi phiên bản chương trình (CHIANTI cũng xác định các thay đổi
ảnh hưởng tới các trường hợp kiểm thử). Do đó, các kết quả khi áp dụng kỹ
thuật này là khơng chính xác với một vài cơng nghệ phân tích chương trình
bao gồm việc xác định các kiểm thử địi hỏi.
Xing và Stroulica giới thiệu UMLDiff [34], một thuật toán dùng tự động phát
hiện các thay đổi về cấu trúc giữa các thiết kế của chuỗi các phiên bản của
một chương trình hướng đối tượng. UMLDiff so sánh các lược đồ lớp của hai
phiên bản chương trình và sử dụng thông tin cấu trúc để xác định sự thay đổi.
Sự khác nhau được xác định bao gồm: việc thêm, xóa bỏ, chuyển, đổi tên các
gói, lớp, giao diện, trường, và các phương thức. UMLDiff có thể làm việc ở

20

mức độ phương thức, mức độ lớp và nó khơng so sánh các câu lệnh trong hai
phương thức tương ứng.

3.2 Thuật tốn tìm kiếm sự khác nhau
Như đã trình bày ở phần giới thiệu (1.3), thơng tin chính xác về sự khác
nhau và sự tương ứng giữa hai phiên bản của một chương trình là rất cần thiết
để đưa ra các yêu cầu kiểm thử hiệu quả. Tuy nhiên, các phương pháp tiếp
cận về đối sánh các phiên bản phần mềm hiện nay thường gặp phải những
giới hạn như phân tích ở trên. Hơn nữa hầu hết các báo cáo chỉ đưa ra các
thống kê về việc thay đổi trong các khai báo (ví dụ các thay đổi trong phương
thức truy nhập mơ hình và khai báo lớp cấp cao nhất). Để góp phần giảm bớt
các hạn chế đó, luận văn đưa ra một định nghĩa về cách biểu diễn đồ thị mới
và một thuật toán ước lượng sự khác nhau sử dụng biểu diễn đó để tìm ra các
thay đổi ở mức độ câu lệnh giữa hai phiên bản của một chương trình. Cách
biểu diễn mới này là sự phát triển đồ thị luồng điều khiển (CFG) truyền thống
để mơ hình hóa các hoạt động sinh ra bởi các đặc trưng của chương trình
hướng đối tượng. Với cách biểu diễn này, luận văn đề xuất việc xây dựng bộ
công cụ giúp xác định các thay đổi về khai báo và mối quan hệ của chúng tới
các mốc ở mức câu lệnh khi mà các hành động khác nhau có thể xảy ra.
Thuật toán mới này kế thừa các thuật tốn đối sánh hiện có [18], gồm 5 bước:
Bước 1: Đối sánh các lớp (class), các giao diện (interface) và các phương
thức (method) của hai phiên bản.
Bước 2: Xây dựng các đồ thị luồng điều khiển hiệu quả cho việc đối sánh các
phương thức trong phiên bản gốc và phiên bản đã chỉnh sửa của chương trình.
Bước 3: Thu gọn mỗi đồ thị thành một chuỗi các đỉnh (node) và các khoảng
cách (hammock) [10] (Mỗi đồ thị con chỉ có một điểm đầu vào và một điểm
đầu ra).
Bước 4: Thực hiện việc so sánh các cặp phương thức tương ứng trong phiên

bản gốc và phiên bản đã chỉnh sửa, thu gọn các đồ thị để xác định các khoảng
cách tương ứng.
Bước 5: Cuối cùng, thực hiện đệ quy mở rộng và đối sánh các khoảng cách và
các đỉnh tương ứng.