phƯƠng phÁp phÂn tÍch sỰ Ảnh hƯỞng cỦa cÁc thÀnh...
TRANSCRIPT
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
NGUYỄN THỊ HỒNG VÂN
PHƯƠNG PHÁP PHÂN TÍCH SỰ ẢNH HƯỞNG CỦA CÁC
THÀNH PHẦN VÀ ỨNG DỤNG CHO KIỂM THỬ HỒI QUY
TRONG CÁC DỰ ÁN JAVA EE
LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN
Hà Nội – 2018
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
NGUYỄN THỊ HỒNG VÂN
PHƯƠNG PHÁP PHÂN TÍCH SỰ ẢNH HƯỞNG CỦA CÁC
THÀNH PHẦN VÀ ỨNG DỤNG CHO KIỂM THỬ HỒI QUY
TRONG CÁC DỰ ÁN JAVA EE
Ngành: Công nghệ thông tin
Chuyên ngành: Kỹ Thuật Phần Mềm
Mã số: 8480103.01
LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN
NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS. TS. PHẠM NGỌC HÙNG
Hà Nội – 2018
i
MỤC LỤC
MỤC LỤC ................................................................................................................... i
LỜI CAM ĐOAN ...................................................................................................... iii
LỜI CẢM ƠN ........................................................................................................... iv
DANH MỤC THUẬT NGỮ VIẾT TẮT ................................................................... v
DANH MỤC HÌNH VẼ ............................................................................................ vi
DANH MỤC BẢNG ............................................................................................... viii
Chương 1. Giới thiệu .................................................................................................. 9
Chương 2. Phương pháp phân tích sự ảnh hưởng trong JCIA ................................. 11
2.1 Bộ công cụ JCIA ............................................................................................. 11
2.2 Phân tích các phụ thuộc .................................................................................. 17
2.2.1 Tiền xử lý mã nguồn ................................................................................. 17
2.2.2 Phân tích sự phụ thuộc cho Struts 2 .......................................................... 17
2.2.3 Phân tích sự phụ thuộc trong Java Core ................................................... 19
2.2.4 Phân tích phụ thuộc cho công nghệ kết nối cơ sở dữ liệu JDBC ............. 20
2.2.5 Phân tích phụ thuộc cho Hibernate ........................................................... 24
2.3 Quản lý phiên bản ........................................................................................... 27
Chương 3. Phương pháp phân tích ảnh hưởng các thành phần giao diện và phân
loại kiểm thử hồi quy ............................................................................................... 28
3.1 Phương pháp phân tích ảnh hưởng các thành phần giao diện ........................ 28
3.1.1 Phân tích kiến trúc Java Servlet ................................................................ 28
3.1.2 Phương pháp phân tích sự ảnh hưởng....................................................... 31
3.2 Phương pháp phân loại kiểm thử hồi quy ....................................................... 35
3.2.1 Kiểm thử hồi quy ...................................................................................... 35
3.2.2 Phân loại kiểm thử hồi quy ................................................................... 35
3.2.3 Quy trình kiểm thử hồi quy dựa trên phương pháp đề xuất .................. 36
Chương 4. Thực nghiệm và triển khai ..................................................................... 36
4.1 Giới thiệu công cụ JCIA mở rộng ................................................................... 38
4.2 Thực nghiệm ................................................................................................... 39
4.3. Ý nghĩa của công cụ thực nghiệm .................................................................. 39
Chương 5. Kết luận .................................................................................................. 53
ii
TÀI LIỆU THAM KHẢO ........................................................................................ 56
iii
LỜI CAM ĐOAN
Tôi xin cam đoan rằng những nghiên với đề tài “Phương pháp phân tích
sự ảnh hưởng của các thành phần và ứng dụng cho kiểm thử hồi quy trong
các dự án Java EE” được trình bày trong luận văn này là công trình nghiên cứu
của riêng tôi dưới sự hướng dẫn của thầy giáo PGS. TS. Phạm Ngọc Hùng,
không sao chép lại của người khác. Tất cả các nguồn tài liệu tham khảo, các
công trình nghiên cứu liên quan đều được trích dẫn cụ thể.
Tôi xin chịu hoàn toàn trách nhiệm nếu có bất kỳ phát hiện nào về sự sao
chép mà không có trích dẫn trong tài liệu tham khảo.
iv
LỜI CẢM ƠN
Đầu tiên, tôi xin gửi lời cảm ơn chân thành tới thầy giáo PGS. TS. Phạm
Ngọc Hùng - người đã hướng dẫn tận tình, chỉ bảo và đóng góp ý kiến quý báu
cho tôi trong suốt quá trình học tập và làm khóa luận. Trong quãng thời gian
được thầy hướng dẫn, tôi đã học hỏi được nhiều kinh nghiệm về phương pháp
nghiên cứu, kỹ năng trình bày. Thầy còn tiếp thêm cho tôi niềm tin vượt qua khó
khăn giúp tôi trưởng thành hơn trong cuộc sống.
Tôi xin gửi lời cảm ơn chân thành đến các thầy cô giáo khoa Công nghệ
thông tin trường Đại học Công nghệ - Đại học Quốc gia Hà Nội đã tận tình
truyền đạt những kiến thức quý báu, tạo điều kiện tốt nhất cho tôi trong suốt thời
gian học tập và nghiên cứu. Tiếp theo, tôi xin gửi lời cảm ơn đến gia đình và
người thân đã luôn bên cạnh động viên, cổ vũ và là chỗ dựa vững chắc để tôi
yên tâm học hành trong suốt những năm qua. Tôi cũng xin gửi lời cảm ơn chân
thành đến Bùi Quang Cường và Ngô Hải Yến đã tạo điều kiện giúp đỡ tôi để
nghiên cứu công cụ JCIA.
Mặc dù đã rất cố gắng nhưng luận văn chắc chắn không tránh khỏi những
thiếu sót, tôi rất mong nhận được những ý kiến đánh giá và phê bình từ phía các
Thầy Cô để luận văn được hoàn thiện hơn.
Tôi xin chân thành cảm ơn!
Hà Nội, tháng 10 năm 2018
Học viên
Nguyễn Thị Hồng Vân
v
DANH MỤC THUẬT NGỮ VIẾT TẮT
STT Từ viết tắt Từ đầy đủ Ý nghĩa
1 AST Abstract Syntax Tree Cây cấu trúc trừu tượng
2 CIA Change Impact Analysis Phân tích ảnh hưởng sự
thay đổi
3 DAO Data Access Object Đối tượng truy cập dữ
liệu
4 ERD Entity Relationship
Diagram
Biểu đồ quan hệ thực thể
5 Java EE Java Enterprise Edition Java phiên bản doanh
nghiệp
6 JCIA Java Change Impact
Analysis
Phân tích ảnh hưởng sự
thay đổi mã nguồn trong
các dự án Java
7 JDBC Java Database Connectivity Giao diện tương tác với
cơ sở dữ liệu quan hệ
trong Java
8 JDG Java Dependency Graph Đồ thị phụ thuộc Java EE
9 MVC Model - View - Controller Mô hình thiết kế ứng
dụng Web
10 ORM Object Relational Mapping Ánh xạ quan hệ đối
tượng
vi
DANH MỤC HÌNH VẼ
Hình 2.1. Giao diện chính của công cụ JCIA.................................................. 13
Hình 2.2. Màn hình Project View ................................................................... 13
Hình 2.3. Màn hình Dependency View ........................................................... 14
Hình 2.4. Change Impact View ....................................................................... 15
Hình 2.5. Hiển thị mã nguồn ........................................................................... 15
Hình 2.6. Change Set View ............................................................................. 16
Hình 2.7. Impact Set View .............................................................................. 16
Hình 2.8. Mô hình ứng dụng Struts2............................................................... 17
Hình 2.9. Quy trình phân tích sự phụ thuộc cho ứng dụng Struts 2 ............... 18
Hình 2.10. Ví dụ minh họa đồ thị chuỗi .......................................................... 22
Hình 2.11. Quá trình xây dựng và dự đoán câu truy vấn ................................ 23
Hình 2.12. Quá trình phân tích phụ thuộc cho Hibernate ............................... 24
Hình 2.13. So sánh cây cấu trúc giữa hai phiên bản mã nguồn ...................... 27
Hình 3.1. Kiến trúc Java Servlet ..................................................................... 28
Hình 3.2. Vòng đời của Java Servlet ............................................................... 29
Hình 3.3. Mã nguồn sử dụng nền tảng Java Servlet ....................................... 30
Hình 3.4. Phân loại kiểm thử hồi quy ............................................................. 35
Hình 3.5. Quy trình kiểm thử hồi quy đề xuất ................................................ 36
Hình 4.1. Kiến trúc của công cụ JCIA ............................................................ 38
Hình 4.2. Kết quả đầu ra của công cụ ............................................................. 39
Hình 4.3. Ứng dụng Web quản lý bệnh viện. ................................................. 40
Hình 4.4. Lỗi xảy ra ở phiên bản 1.................................................................. 49
Hình 4.6. Yêu cầu thêm mới cho giao diện quản lý bệnh nhân ...................... 50
Hình 4.7. Nghiệp vụ liên quan đến Health Insurance ..................................... 50
Hình 4.8. Kết quả tập thay đổi và ảnh hưởng cho kiểm thử đơn vị ................ 51
Hình 4.9. Kết quả tập thay đổi và ảnh hưởng cho kiểm thử giao diện ........... 51
Hình 4.10. Kết quả kiểm thử hồi quy giao diện với Ranorex ......................... 52
Hình 4.11. Kết quả tập thay đổi và ảnh hưởng cho kiểm thử tích hợp ........... 52
viii
DANH MỤC BẢNG
Bảng 2.1. Ý nghĩa các kiểu cạnh trong đồ thị chuỗi ....................................... 24
Bảng 2.2. Các phương thức truy xuất CSDL có sẵn của Hibernate ............... 26
Bảng 4.1. Mô tả yêu cầu chức năng quản lý nhân viên .................................. 41
Bảng 4.2. Mô tả yêu cầu chức năng quản lý phòng ........................................ 42
Bảng 4.3. Mô tả yêu cầu chức năng quản lý dịch vụ ...................................... 42
Bảng 4.4. Mô tả yêu cầu chức năng quản lý bệnh nhân ................................. 43
Bảng 4.5. Mô tả yêu cầu chức năng đặt phòng ............................................... 43
Bảng 4.6. Mô tả yêu cầu chức năng quản lý thuốc ......................................... 44
Bảng 4.7. Mô tả yêu cầu chức năng quản lý bán thuốc .................................. 44
9
Chương 1. Giới thiệu
Trong lĩnh vực phát triển phần mềm hiện nay, hầu hết các ứng dụng phần
mềm đều được phát triển trên nền Web. Chính vì vậy, việc kiểm thử để đảm bảo
chất lượng các ứng dụng Web là một vấn đề rất cần thiết. Tuy nhiên, các ứng
dụng Web ngày càng trở nên phức tạp, đặc biệt là đối với các ứng dụng Web sử
dụng nền tảng Java EE - một trong những giải pháp đang được sử dụng phổ biến
để triển khai cho các ứng dụng Web doanh nghiệp. Các ứng dụng này thường
được phát triển trong thời gian dài, với quy mô lớn và có độ phức tạp cao, ví dụ
như các ứng dụng xử lý nghiệp vụ logic trong các lĩnh vực ngân hàng, thuế, kế
toán, v.v. Khi một phiên bản mới được bàn giao có thể là do nâng cấp, sửa đổi
mã nguồn, v.v., việc kiểm thử viên phải kiểm thử lại toàn bộ chức năng của phần
mềm là rất cần thiết để đảm bảo các chức năng vẫn hoạt động tốt, bởi vì một sự
thay đổi nhỏ trong ứng dụng cũng có thể gây ra một số ảnh hưởng không thể dự
đoán trước hay thậm chí là cả những sai sót tiềm ẩn bên trong đối với ứng dụng
đang phát triển. Phương pháp đơn giản để kiểm thử hồi quy là chạy tất cả các ca
kiểm thử của phiên bản trước [1]. Tuy nhiên, việc kiểm thử lại toàn bộ này là rất
tốn kém về thời gian và công sức. Do đó, để hoàn thành công việc kiểm thử
đúng tiến độ và hiệu quả, các công ty phần mềm cần phải áp dụng các phương
pháp và công cụ nhằm tối ưu được các hoạt động kiểm thử. Phương pháp phân
tích sự ảnh hưởng của các thành phần kết hợp với công cụ kiểm thử tự động để
thực hiện kiểm thử hồi quy là một giải pháp hữu hiệu nhằm nâng cao tính hiệu
quả và chính xác, giảm thiểu chi phí và rút ngắn thời gian trong quá trình kiểm
thử các sản phẩm phần mềm nói chung và các ứng dụng Web nói riêng. Thay vì
kiểm thử lại toàn bộ ứng dụng, kiểm thử viên chỉ cần kiểm thử các thành phần bị
thay đổi và thành phần có khả năng bị ảnh hưởng dựa trên thay đổi đó.
Phân tích ảnh hưởng sự thay đổi (Change Impact Analysis - CIA) [3,4,5] là
giải pháp để giải quyết bài toán trên. CIA đóng một vai trò quan trọng trong các
giai đoạn phát triển phần mềm, bảo trì và kiểm thử hồi quy. Đối với nhóm phát
triển, CIA có thể được ứng dụng vào việc giúp nhận biết các thay đổi cần thực
hiện dựa trên các thay đổi có sẵn. Đối với kiểm thử viên, CIA có thể ứng dụng
vào việc xác định những ca kiểm thử có liên quan đến phần mã nguồn chỉnh sửa
giúp giảm số lượng các ca kiểm thử và rút ngắn thời gian kiểm thử hồi quy mà
vẫn đảm bảo được chất lượng phần mềm.
Trong thực tế, có một số công cụ hỗ trợ quản lý phiên bản mã nguồn như
Git, SVN, VSS, v.v., các công cụ này giúp lập trình viên quản lý được các dòng
lệnh thay đổi qua các phiên bản khác nhau. Tuy nhiên, để có thể đánh giá được
10
các ảnh hưởng từ sự thay đổi là chưa có giải pháp thỏa đáng. Một số nghiên cứu
trước đã đề xuất các phương pháp và công cụ thực hiện việc đảm bảo chất lượng
mã nguồn cho ứng dụng doanh nghiệp [2]. Công cụ JCIA ra đời phần nào giải
quyết được bài toán trên cho ứng dụng Java EE, công cụ giúp người dùng có thể
thực hiện phân tích ảnh hưởng sự thay đổi cho các ứng dụng Java EE đa nền
tảng, hỗ trợ các công nghệ nền tảng (framework) như Hibernate, Struts, Spring.
Mặc dù vậy, công cụ này còn khá đơn giản, phân tích sự phụ thuộc chủ yếu cho
mã nguồn Java và chưa mang lại tính hiệu quả trong việc kiểm thử hồi quy ở
góc nhìn của kiểm thử viên.
Dựa trên ý tưởng về phương pháp phân tích phụ thuộc trong mã nguồn
Java, một cải tiến được nghiên cứu nhằm phân tích ảnh hưởng sự thay đổi cho
các thành phần liên quan đến giao diện, từ đó kiểm thử viên sẽ có góc nhìn
khách quan hơn về công việc kiểm thử hồi quy cần thực hiện trên các giao diện
thay đổi và ảnh hưởng, cũng như đưa ra một cái nhìn khách quan giữa lập trình
viên và kiểm thử viên. Trong nghiên cứu này, công nghệ Java Servlet sẽ được
tập trung hỗ trợ đầu tiên. Sau đó, luận văn sẽ hoàn thiện dần phương pháp cho
các nền tảng khác. Ngoài ra, luận văn cũng phát triển một giải pháp phân loại
kiểm thử sau khi có được tập thay đổi và ảnh hưởng từ hai phiên bản khác nhau
để hỗ trợ cho việc kiểm thử hồi quy được thực hiện một cách hiệu quả. Một bộ
công cụ được phát triển như là một phiên bản tiếp theo của công cụ JCIA [5] để
thực hiện các giải pháp đã triển khai và tiến hành thực nghiệm nhằm minh
chứng cho tính hiệu quả của công cụ phát triển.
Phần còn lại của luận văn được cấu trúc như sau. Chương 2 trình bày về
phương pháp phân tích sự ảnh hưởng trong công cụ JCIA đã được thực hiện. Ở
Chương 3, luận văn này giới thiệu phương pháp cải tiến bao gồm phương pháp
phân tích sự phụ thuộc cho thành phần giao diện trong công nghệ Java Servlet,
phân loại kiểm thử từ các tập thay đổi và tập ảnh hưởng tìm được. Tiếp đến,
Chương 4 mô tả công cụ hỗ trợ, kết quả thực nghiệm và thảo luận. Cuối cùng,
Chương 5 là kết luận của luận văn và các định hướng nghiên cứu trong tương
lai.
11
Chương 2. Phương pháp phân tích sự ảnh hưởng trong JCIA
Nội dung của chương này sẽ trình bày về lý thuyết kiểm thử hồi quy và
công cụ JCIA đã được xây dựng từ phương pháp phân tích ảnh hưởng sự thay
đổi [2]. Trước tiên, luận văn sẽ trình bày khái niệm kiểm thử hồi quy, sau đó
trình bày tổng quan về bộ công cụ JCIA, tiếp theo là các phương pháp phân tích
sự ảnh hưởng các thành phần cho một số nền tảng và công nghệ trong dự án
Java EE.
2.1 Kiểm thử hồi quy
Khi phát triển một hệ thống phần mềm, điều quan trọng là đạt được mức
yêu cầu về chất lượng. Một lỗi nhỏ trong hệ thống cũng có thể là tốn kém để sửa
chữa sau khi sản phẩm đã được bàn giao. Vì vậy, kiểm thử là một khía cạnh
quan trọng trong dự án phát triển sản phẩm của hệ thống phần mềm. Để tìm lỗi
trong sản phẩm thiết kế càng sớm càng tốt, kiểm thử được thực hiện trong nhiều
giai đoạn. Một hệ thống phần mềm lớn thường được chia thành nhiều hệ thống
con, và một hệ thống con được chia thành các mô đun nhỏ hơn. Kiểm thử phần
mềm sau đó có thể được tách thành bốn giai đoạn: kiểm thử đơn vị, kiểm thử
tích hợp, kiểm thử hệ thống và kiểm thử chấp nhận người dùng.
Khi phát triển phần mềm liên quan đến thay đổi mã nguồn do lỗi hoặc bổ
sung tính năng mới, khách hàng muốn có các tính năng mới trong phiên bản mới
nhất, nhưng mong đợi các tính năng cũ vẫn giữ nguyên. Dựa vào kinh nghiệm
đã cho thấy những sửa đổi này có thể gây ra chức năng làm việc trước đó thất
bại. Để kiểm tra tính toàn vẹn của phần mềm đối với loại lỗi bất ngờ này, kiểm
thử hồi quy được sử dụng. Kiểm hồi quy có thể được thực hiện trên mỗi trong
bốn giai đoạn kiểm thử nêu trên, và được thực hiện lý tưởng mỗi khi mã nguồn
được sửa đổi hoặc sử dụng trong môi trường mới.
Kiểm thử hồi quy là kiểm tra lại có lựa chọn của một hệ thống hoặc thành
phần để xác minh rằng các sửa đổi không gây ra các ảnh hưởng không mong
muốn và hệ thống hoặc thành phần đó vẫn phải tuân thủ các yêu cầu cụ thể. Để
giảm thiểu thời gian thực hiện công việc này một cách hiệu quả, việc lựa chọn kĩ
thuật kiểm thử và kiểm thử tự động là rất cần thiết. Một cách đơn giản để kiểm
thử hồi quy là kiểm thử lại toàn bộ phiên bản trước đó. Tuy nhiên, khi phiên bản
mới có sự thay đổi thì các ca kiểm thử của phiên bản trước đó có thể không chạy
lại được mà không có sự sửa đổi hay cập nhật. Một bộ các ca kiểm thử tốt phải
được duy trì chạy xuyên suốt qua các phiên bản của hệ thống bằng cách cập
nhật, loại bỏ các ca kiểm thử lỗi thời qua các phiên bản. Các ca kiểm thử dư
thừa không ảnh hưởng đến tính đúng, sai cũng như phát hiện được lỗi của hệ
12
thống, chúng chỉ ảnh hưởng đến thời gian và chi phí kiểm thử. Như đã đề cập
trước đó, người ta ước tính kiểm thử hồi quy có thể chiếm gần một nửa chi phí
bảo trì phần mềm. Việc loại bỏ các ca kiểm thử dư thừa nên được thực hiện giúp
giảm thời gian và chi phí kiểm thử. Chi phí cho việc thực hiện lại một bộ kiểm
thử có thể được giảm bằng cách chọn một tập hợp các ca kiểm thử được thực
hiện lại, bỏ qua các ca kiểm thử không liên quan hoặc ưu tiên thực hiện một tập
con của bộ kiểm thử liên quan đến thay đổi [1].
2.2 Bộ công cụ JCIA
Trong quá trình phát triển phần mềm, việc ra đời các phiên bản mới thay
thế phiên bản cũ là tất yếu để giải quyết các yêu cầu thay đổi từ khách hàng, sửa
lỗi, nâng cấp và mở rộng hệ thống, v.v. Đối với các dự án trong giai đoạn nâng
cấp và bảo trì, lập trình viên khó để hiểu các kiến trúc của các ứng dụng trước
khi những thay đổi đó được thực hiện do thiếu hoặc không đầy đủ tài liệu phần
mềm. Do đó, việc kiểm soát toàn bộ sự ảnh hưởng của việc thay đổi là rất khó
khăn và có thể dẫn tới nhiều rủi ro cho doanh nghiệp.
Công cụ JCIA ra đời với mục đích hỗ trợ xây dựng phần mềm hiệu quả và
dễ dàng hơn. Công cụ hỗ trợ phân tích ảnh hưởng của sự thay đổi cho các dự án
viết bằng Java EE sử dụng các công nghệ: EJB, JSF, CDI, JAX-WS, JPA, v.v.
JCIA bao gồm các mô-đun chính: bộ xử lý cơ sở, bộ phân tích ảnh hưởng sự
thay đổi, bộ phân tích cấu trúc, bộ trình diễn, bộ quản lý người dùng và lịch sử
phân tích. Trong đó, mô-đun xử lý cơ sở bao gồm hai thành phần con là bộ tiền
xử lý và bộ phân tích phụ thuộc theo từng nền tảng khác nhau để sinh cây cấu
trúc và phụ thuộc cho các nút trên cây [2].
Bộ công cụ này nhận đầu vào là toàn bộ mã nguồn dự án doanh nghiệp sử
dụng các nền tảng và công nghệ Java EE dưới dạng tệp nén. Người dùng tải dự
án lên JCIA, công cụ sẽ hiển thị cấu trúc của dự án và đồ thị phụ thuộc giữa các
thành phần. JCIA cung cấp hai cách để thực hiện việc phân tích ảnh hưởng sự
thay đổi bằng hai cách:
Người dùng chọn tập thay đổi và phân tích trực tiếp trên giao diện hiển thị
phụ thuộc. Đầu vào là mã nguồn, đầu ra là kiến trúc của mã nguồn thể
hiện dưới dạng đồ thị cây và dạng đồ thị phụ thuộc.
Phân tích tự động bằng cách người dùng tải lên mã nguồn đã thay đổi,
công cụ thực hiện so sánh hai phiên bản mã nguồn và phân tích ảnh
hưởng rồi trả về kết quả báo cáo.
13
Công cụ gồm ba phần giao diện chính: Project View, Central View bao
gồm Dependency View và Change Impact View, Change Set View và Impact
Set View. Hình 2.1 mô tả giao diện chính của công cụ JCIA với các phụ thuộc
được thể hiện bằng mũi tên có chiều từ nút (node) sở hữu phụ thuộc đến nút bị
gọi.
Hình 2.1. Giao diện chính của công cụ JCIA
- Khung nhìn Project View
Khung nhìn Project View cung cấp cho người dùng giao diện trực quan để
xem mã nguồn dự án đầu vào dưới dạng cây thư mục. Nút chức năng “Expand
All” dùng để hiển thị các thành phần chứa bên trong thư mục và các thư mục
con trong nó (như Hình 2.2).
Hình 2.2. Màn hình Project View
14
- Khung nhìn Dependency View
Khung nhìn Dependency View cho phép hiển thị tất cả các thành phần
trong dự án và sự phụ thuộc lẫn nhau giữa chúng. Bao gồm các phụ thuộc hàm
gọi hàm, hàm dùng biến.
Mũi tên nối giữa hai nút thể hiện rằng hai đối tượng đó có mối quan hệ phụ
thuộc lẫn nhau. Xem thông tin cụ thể của một nút bằng cách chọn tệp, một cửa
sổ sẽ hiển thị thông tin của tệp đó (như Hình 2.3).
Hình 2.3. Màn hình Dependency View
Việc hiển thị phụ thuộc trên giao diện cũng được phân mức tùy vào yêu
cầu người dùng với ba mức: All, None, Partial. Mức All cho phép hiển thị tất cả
phụ thuộc, mức None không hiển thị phụ thuộc, Partial chỉ hiển thị phụ thuộc
liên quan đến nút đang làm việc.
Để thêm một nút vào tập thay đổi, chọn nút đó và chọn chức năng Change.
Sau khi nút được thêm vào tập thay đổi, nút sẽ chuyển sang màu xanh. Để xem
mã nguồn của tệp, chọn một nút thuộc kiểu tệp, sau đó chọn chức năng View
Source Code (như Hình 2.4).
- Khung nhìn Change Impact View
Change Impact View là phần giao diện được sinh ra sau khi thực hiện phân
tích ảnh hưởng, dữ liệu hiển thị sẽ chứa những nút có liên quan đến kết quả phân
tích ảnh hưởng (như Hình 2.5).
15
Hình 2.4. Change Impact View
Hình 2.5. Hiển thị mã nguồn
- Khung nhìn Change Set View
Để thay đổi thuộc tính của một đối tượng (lớp, biến hay hàm), các thay đổi
được lưu trong tập Change và được thể hiện trong khung nhìn Change Set (như
Hình 2.6). Từ đó có thể thay đổi theo mong muốn của người dùng và gửi lên hệ
thống yêu cầu phân tích.
16
Hình 2.6. Change Set View
Các nút chức năng bao gồm: Impact Level, Upload Change Set, Clean all
và Analyze.
Impact Level: Là giá trị thể hiện cho mức ảnh hưởng muốn phân tích. Với
mức 1 là các tệp ảnh hưởng trực tiếp và tương tự các mức 2, 3, 4, v.v.
Upload Change Set: Để thay đổi nhiều tệp cùng một lúc bằng cách tải lên
một tệp text chứa đường dẫn của các tệp thay đổi trong mã nguồn dự án. Công
cụ sẽ tự tìm kiếm các tệp và thêm chúng vào tập thay đổi.
Clean all: Xóa bỏ toàn bộ các tập thay đổi và tập ảnh hưởng đã được phân tích.
Analyze: Thực hiện phân tích tập thay đổi để tìm các tập bị ảnh hưởng.
- Khung nhìn Impact Set View
Là nơi hiển thị các tệp ảnh hưởng sau khi công cụ thực hiện quá trình phân
tích ảnh hưởng từ tệp thay đổi (như Hình 2.7). Nút chức năng Export Data dùng
để xuất dữ liệu phân tích. Người dùng sẽ nhận được một tệp .zip chứa các tệp
thuộc tập thay đổi và tập ảnh hưởng cùng với một tệp MS. Excel chứa thông tin
của chúng.
Hình 2.7. Impact Set View
17
2.3 Phân tích các phụ thuộc
2.2.1 Tiền xử lý mã nguồn
Định nghĩa 2.1: (Biểu đồ phụ thuộc Java EE), cho mã nguồn ứng dụng
Java EE, một biểu đồ phụ thuộc Java EE viết tắt là JDG (Java dependency
graph) được định nghĩa là một cặp (V, E) với V = {v1,v2,...,vk} là tập nút đại diện
cho các thành phần trong mã nguồn như thư mục, tệp, lớp, phương thức, thuộc
tính, thẻ (XML, JSP), v.v., và E = {(vi,vj) | vi,vj ∈V} là tập các cạnh. Mỗi cạnh
(vi,vj) đại diện cho quan hệ phụ thuộc giữa vi và vj có nghĩa là vi phụ thuộc vào vj
[5].
Mã nguồn ứng dụng Java EE cho trước sẽ được xử lý để xây dựng cây thư
mục ở mức tệp. Một cây cấu trúc trừu tượng (Abstract syntax tree - AST) được
xây dựng bằng cách sử dụng công cụ phát triển của Java (Java Development
Tools - JDT). Dựa trên cây AST thu được, các thành phần ở cấp độ thấp hơn
như lớp, phương thức, thuộc tính, v.v. và các phụ thuộc trong các thành phần
được phát hiện và thêm vào JDG. Sự phụ thuộc giữa các thành phần liên quan
đến công nghệ Java EE và các dịch vụ Web được xác định để thêm vào các cạnh
của JDG. Kết quả là JDG tương ứng với mã nguồn sẽ được tạo ra [5].
Trong ứng dụng Java EE, ngoài mã nguồn Java còn nhiều định dạng mã
nguồn được sử dụng như XML, JSP, XHTML, v.v., mỗi định dạng sẽ có cấu
trúc cú pháp tương ứng. Các mã nguồn này sẽ được tiền xử lý để đưa về định
dạng chung là cây cấu trúc, các nút trong cây cấu trúc chứa các thông tin cần
thiết để phân tích phụ thuộc và chúng được thiết kế tối ưu phục vụ cho việc
duyệt cây và tìm kiếm các nút trên cây dễ dàng hơn [2].
2.2.2 Phân tích sự phụ thuộc cho Struts 2
Hình 2.8. Mô hình ứng dụng Struts2
18
Struts 2 là một công nghệ nền tảng được thiết kế theo mô hình MVC bao
gồm Model, View, Controller như Hình 2.8. Trong đó View hiển thị dữ liệu
trong một định dạng cụ thể thường là mã nguồn JSP, Model định nghĩa các đối
tượng để tương tác với cơ sở dữ liệu, Model sẽ định nghĩa thuộc tính đối tượng
và thường dùng mã nguồn Java, Controller xử lý lôgic, làm vai trò điều hướng
giữa Model và View thông qua lớp FilterDispatcher cùng với tệp cấu hình do
người dùng định nghĩa sử dụng mã nguồn XML. Một ví dụ cho mã nguồn cấu
hình Struts 2 cho chức năng hiển thị được mô tả trong Mã nguồn 2.1.
Mã nguồn 2.1. Mã tệp cấu hình Struts 2
<action name=“hienthi” class=“controller.HelloActionSupport”
method=“hienthi”>
<result name=“success”>/WEB-INF/hienthi.jsp</result>
</action>
Hình 2.9 mô tả quy trình phân tích sự phụ thuộc cho Struts 2.
Hình 2.9. Quy trình phân tích sự phụ thuộc cho ứng dụng Struts 2
Quy trình phân tích sự phụ thuộc bắt đầu từ tệp cấu hình trong mã nguồn
Struts 2, các thông tin phụ thuộc giữa các thành phần sẽ được khai thác với phụ
thuộc từ thẻ <action> đến hàm hienthi() của lớp HelloActionSupport và một
phụ thuộc từ thẻ <result> đến tệp JSP hienthi.jsp. Để phân tích sự phụ thuộc
trong ứng dụng sử dụng Struts 2, bao gồm các bước như sau [2]:
19
Bước 1: trình xác nhận sẽ kiểm tra mã nguồn của dự án có sử dụng Struts
2 không, đầu ra là cây cấu trúc tương ứng với tệp cấu hình chính của
Struts 2.
Bước 2: một trình phân tích cú pháp sẽ tìm kiếm tất cả tệp cấu hình được
khai báo trong struts.xml và duyệt tất cả các tệp cấu hình, lưu thông tin
trong Configuration Model chứa thông tin về : Package, Action, Result,
Result Type, Interceptor, Interceptor Stack.
Bước 3: trình phân tích phụ thuộc sẽ đọc thông tin từ Configuration
Model cùng với phân tích cây cấu trúc để xác định phụ thuộc và thêm vào
cây cấu trúc.
2.2.3 Phân tích sự phụ thuộc trong Java Core
Trong mã nguồn Java, có ba loại quan hệ chính giữa các lớp: quan hệ phụ
thuộc, thành phần và kế thừa [2]. Dựa vào các quan hệ này, bộ phân tích phụ
thuộc cho Java Core sẽ phân tích các nút là thành phần Java trên biểu đồ phụ
thuộc Java EE và xác định phụ thuộc Java Core giữa các thành phần.
Quan hệ phụ thuộc: hai lớp gọi là phụ thuộc nếu phương thức của lớp này
sử dụng đối tượng của lớp kia để thực hiện các thao tác. Khi hai lớp phụ thuộc,
những thay đổi ở lớp này sẽ ảnh hưởng đến lớp kia. Ví dụ, Mã nguồn 2.2 gồm
phương thức f sử dụng đối tượng lớp B, C để thực hiện thao tác.
Mã nguồn 2.2. Mã Java thể hiện quan hệ phụ thuộc
public class A {
public void f(B b, C c) { … }
public void f(){
B b = new B();
C c = new C();
…. }
}
Quan hệ thành phần: một lớp sẽ chứa các thuộc tính là đối tượng của lớp
khác. Ví dụ, lớp A chứa các thuộc tính là đối tượng của lớp B như Mã nguồn
2.3.
Mã nguồn 2.3. Mã Java thể hiện quan hệ thành phần
public class A {
int a;
private B b; // B là một lớp
... }
20
Quan hệ kế thừa: một lớp con kế thừa các thuộc tính public của lớp cha và
có thể thêm một số các thuộc tính riêng. Khi lớp cha thay đổi thì các lớp con kế
thừa nó sẽ bị ảnh hưởng. Ví dụ trong Mã nguồn 2.4, lớp B kế thừa thành phần
public của lớp A và có thêm đặc tính riêng k.
Mã nguồn 2.4. Mã Java thể hiện quan hệ kế thừa
public class A {
int a;
public int f(){...} }
class B extends A{
public void k(){...} }
2.2.4 Phân tích phụ thuộc cho công nghệ kết nối cơ sở dữ liệu JDBC
JDBC (Java Database Connectivity) là một giao diện lập trình ứng dụng
của Java (API) được dùng để kết nối và truy xuất cơ sở dữ liệu. JDBC quản lý
kết nối đến cơ sở dữ liệu, gửi các câu truy vấn từ ứng dụng Java tới cơ sở dữ liệu
và xử lý kết quả sau truy vấn thành các đối tượng của Java. Mã nguồn 2.5 là một
ví dụ về câu truy vấn trong JDBC [2].
Mã nguồn 2.5. Mã nguồn chương trình Sample
public String getTableName(String a){
return “Consumer where name =” +a ; }
public Consumer findConsumer(boolean isOrderId, int order, Session
session) {
List<Consumer> consumers = new ArrayList<>();
String orderBy = “order by”;
if (order == 0)
orderStr = “”;
else {
if (isOrderId)
orderStr+= “category”;
if (order == -1) orderStr += “desc”; else orderStr + = “asc”;}
consumers = session.createQuery(“Select*
From”+getTableName()+orderBy);
return consumers; }
21
Một vấn đề quan trọng cần giải quyết từ Mã nguồn 2.5 làm thế nào để biết
được câu truy vấn cuối cùng có giá trị gì và có ảnh hưởng đến bảng nào trong cơ
sử dữ liệu. Hiện nay có một vài công cụ đã giải quyết được vấn đề này: JSA,
JDBC Checker, v.v. Trong phần này, một phương pháp dự đoán giá trị câu truy
vấn mã nguồn Java bằng đồ thị chuỗi được trình bày.
Định nghĩa 2.2: Phép toán gộp: Cho hai tập A = {a1 , a2 ,..., an} và B =
{b1, b2 ,...,bm}. Phép toán gộp hai tập A và B, kí hiệu: A ○ B là một tập C thỏa
mãn [2]:
C = {(a + b) | a ∈ A và b ∈ B}
Định nghĩa 2.3: Đồ thị chuỗi: Đồ thị gốc r là nút rỗng, có hướng thể hiện
quá trình thay đổi giá trị của một chuỗi kí tự, kí hiệu G = <V, E>, V là tập các
đỉnh, E = V × OP × V biểu diễn tập các cạnh của đồ thị với các kiểu cạnh: OP =
{INIT, CONCAT}. Mỗi đỉnh v ∈ V gồm ba giá trị, kí hiệu v = (l, t, c, Rv) [2].
Trong đó:
l ∈ {STRING, VARIABLE, METHOD, APPENDABLE, UNDEFINED}
là nhãn của đỉnh.
t ∈ {UNION, PRODUCT} là kiểu xử lí của đỉnh.
c: thông tin lưu trữ của đỉnh. Với l = STRING, c thể hiện cho một chuỗi kí
tự. Với l = VARIABLE hoặc APPENDABLE, c thể hiện cho tên biến.
Với l = METHOD, c thể hiện cho tên hàm.
Rv: tập dự đoán chứa những giá trị chuỗi có thể có của đỉnh v. Nếu vl =
STRING, Rv được khởi tạo là {vc}, ngược lại là {∅}.
Ý nghĩa các các kiểu cạnh được thể hiện trong Bảng 2.1. Biểu thức v1
(label) v2 biểu thị một cạnh có hướng từ đỉnh v1 tới đỉnh v2 với kiểu là label [2].
Mã nguồn 2.5 mô tả một đồ thị chuỗi được biểu diễn như Hình 2.10. Đầu
tiên, mọi câu lệnh trong mã nguồn sẽ được quét, chỉ câu lệnh sử dụng hàm
createQuery sẽ được xử lý. Nút mới được tạo tùy theo kiểu của tham số truyền
vào và thêm vào đồ thị. Nếu nó là phương thức, nội dung của phương thức được
quét, giá trị câu lệnh return sẽ được xử lý và thêm vào đồ thị. Nếu phần tử vừa
thêm là biến cục bộ, bộ sinh đồ thị sẽ quét trong phương thức sử dụng biến đó.
Nếu câu lệnh thay đổi giá trị biến được tìm thấy, đỉnh mới được tạo tùy thuộc
vào việc thay đổi là khởi tạo hay cộng gộp và thêm vào đồ thị.
Trong trường hợp giá trị mới đó được tạo nên bởi nhiều thành phần nhỏ, ví
dụ như “select * from” + getTableName() +orderBy thì mỗi thành phần được
nối trực tiếp đến phần tử thêm cuối cùng trong đồ thị với cạnh kiểu CONCAT.
22
Những đoạn câu lệnh ở trong cặp if…then, then…else được tính như một đồ thị
con có đỉnh là phần tử được thêm cuối cùng trong đồ thị, và đỉnh gốc đó được
đặt kiểu PRODUCT. Trong trường hợp câu lệnh cần thêm vào đồ thị ở trong
vòng lặp, ta phải xác định giá trị được thêm ở dạng chuỗi kí tự bình thường, hay
là phần tử của một mảng. Nếu là một chuỗi kí tự, giá trị của đỉnh được thêm vào
đồ thị có dạng <<(value)+>>. Nếu là phần tử của mảng, toàn bộ phương thức
sẽ được quét lại lần nữa để tìm ra những giá trị được thêm vào mảng, sau đó
được thêm vào đồ thị. Cứ quét như vậy tới cuối phương thức hoặc không còn
nút nào được thêm mới nữa thì kết thúc việc sinh đồ thị [2].
Hình 2.10. Ví dụ minh họa đồ thị chuỗi
Sau khi đồ thị chuỗi được xây dựng, một bộ giải đồ thị sử dụng phương
pháp đệ quy cùng thuật toán duyệt tiền thứ tự để dự đoán câu truy vấn có thể
được tạo ra. Mỗi kiểu xử lí t của đỉnh v thể hiện cách thêm giá trị các đỉnh ra của
v vào tập dự đoán Rv như nào. Giả sử đỉnh v có tập đỉnh ra là VOUT = {v1,
v2,...,vn}. Gọi VCONCAT ⊂ VOUT là tập đỉnh thỏa mãn ∀ vi ∈ VCONCAT, cạnh từ v
đến vi có nhãn CONCAT, theo thứ tự FIFO (First In First Out - đỉnh được thêm
vào cây trước sẽ được lấy ra trước). Với Rv là tập dự đoán của đỉnh v [2], khi đó:
v UNION VOUT → Rv = Rv ○ Rv1 ○ Rv2 ○…○ Rvn với v1, v2,…, vn ∈ VOUT
v PRODUCT VOUT → Rv = (Rv ○ Rv1) ∪ (Rv ○ Rv2) ∪…∪ (Rv ○ Rvt) với v1,
23
v2,…, vt ∈ VCONCAT. Còn lại, ∀ vj ∈ VOUT \ VCONCAT, tập dự đoán Rvj sẽ
được thêm trực tiếp vào tập dự đoán R của đỉnh METHOD, VARIABLE
và APPENDABLE phía trên gần nhất.
Hình 2.11. Quá trình xây dựng và dự đoán câu truy vấn
Từ đồ thị chuỗi, phương pháp giải đồ thị để tìm tập dự đoán được biểu
diễn như sau:
q = R “from” + R “getTableName” ○ R “order”
= {“select * from”} ○ ({“Consumer where name =”} ○ R”a”) ○ R “order by”
= {“select * from”} ○ ({“Consumer where name =”} ○
{“<<UNDEFINED>>“}) (({“order by”} ○ R “category”) ∪ “”)
= {“select * from”} ○ {“Consumer where name = <<UNDEFINED>>”} ○ (({
“order by” } ○ (({“category”} ○ {“desc”}) ∪ ({“category”} ○ { “asc”))) ∪
“”)
= {“select * from Consumer where name = <<UNDEFINED>>”} ○ (({“order
by”} ○ {“category desc”, “category asc”}) ∪ {“”})
= {“select * from Consumer where name = <<UNDEFINED>>”}, “select *
from Consumer where name = <<UNDEFINED>> ○ ({“order by category
desc”, “order by category asc”} ∪ {“”})
= [“select * from Consumer where name = <<UNDEFINED>>”,
“select * from Consumer where name = <<UNDEFINED>> order by
category desc”,
“select * from Consumer where name = <<UNDEFINED>> order by
category asc”]
Sau khi tập dự đoán được xây dựng xong, các câu truy vấn được phân tích.
Các bảng sử dụng trong câu ở các vị trí quan trọng như: sau “from”, sau “join”,
v.v. sẽ được lấy ra. Danh sách những bảng này sẽ được thêm vào cây cấu trúc và
sinh phụ thuộc.
24
Bảng 2.1. Ý nghĩa các kiểu cạnh trong đồ thị chuỗi
Biểu thức Ý nghĩa Tương đương mã nguồn Java
v1 (INIT) v2
Giá trị của v2
là giá trị khởi
tạo của v1
String var = “init value”;
StringBuilder b = new
StringBuilder();
method() {return “value”;}
v1 (CONCAT)
v2
Giá trị v2 được
thêm vào giá
trị của v1
var += “concat value”;
b.append(“append value”);
2.2.5 Phân tích phụ thuộc cho Hibernate
ORM Framework (Object Relational Mapping Framework) là một kỹ thuật
chuyển đổi dữ liệu giữa các cơ sở dữ liệu quan hệ sang các đối tượng trong ngôn
ngữ lập trình hướng đối tượng như Java, C#, v.v. Hibernate là một trong những
công nghệ nền tảng cung cấp API cho phép ứng dụng có thể thao tác với cơ sở
dữ liệu, ánh xạ các bảng trong cơ sở dữ liệu với các đối tượng trong Java.
Hibernate hỗ trợ ánh xạ tự động thông qua tệp ánh xạ XML hoặc dùng
Annotation để ánh xạ các trường trong bảng với các thuộc tính của đối tượng
Java.
Hình 2.12. Quá trình phân tích phụ thuộc cho Hibernate
Hình 2.12 mô tả các bước phân tích phụ thuộc cho Hibernate [2]. Đầu tiên,
bộ phân tích sẽ xác định xem mã nguồn có sử dụng Hibernate hay không bằng
cách tìm tệp cấu hình hibernate.hbm.xml. Tiếp theo, bộ phân tích sẽ đọc các thẻ
có trong tệp cấu hình và chỉ ra các thẻ XML, mỗi thẻ XML có thể khai báo một
tệp ánh xạ XML khác hoặc một lớp Java. Sau đó, bộ phân tích sẽ xác định tệp
cấu hình ánh xạ theo cách nào và phân tích theo cách tương ứng. Mỗi nút thể
hiện cho bảng, cột của cơ sở dữ liệu được tạo và thêm vào cây AST hiện tại. Các
nút này cũng được bộ phân tích truy vấn sử dụng để tìm những thành phần có
khả năng tác động đến cơ sở dữ liệu.
25
Mã nguồn 2.6. Một phần tệp hibernate.cfg.xml
<hibernate-configuration>
<session-factory>
<property name=“hibernate.connection.url”>
jdbc:mysql://localhost:3306/testdb
<property name=“hibernate.connection.username”>
root
</property>
<property name=“hibernate.connection.password”>
1234567890
</property>
<mapping resource=“Employee.hbm.xml” />
</session-factory>
</hibernate-configuration>
Mã nguồn 2.7. Tệp ánh xạ Employee.hbm.xml
<hibernate-mapping>
<class name=“Employee” table=“EMPLOYEE”>
<meta attribute=“class-description”>
</meta>
<id name=“id” type=“int” column=“id”>
<generator class=“native”/>
</id>
<property name=“firstName” column=“first_name” type=“string”/>
<property name=“lastName” column=“last_name” type=“string”/>
<property name=“salary” column=“salary” type=“int”/>
</class>
</hibernate-mapping>
Mã nguồn 2.6 là một ví dụ về tệp cấu hình trong Hibernate, bộ phân tích sẽ
tìm tất cả các thẻ <mapping> chứa thông tin ánh xạ từ cơ sở dữ liệu với lớp
trong Java. Với phương pháp ánh xạ bằng tệp XML, thẻ <mapping> sử dụng
thuộc tính là “resource” cùng với tên tệp XML chứa thông tin ánh xạ. Còn với
phương pháp Annotation, thuộc tính là “class” và tên lớp Java với đầy đủ
package.
26
Trong Mã nguồn 2.7 của tệp ánh xạ Employee.hbm.xml, thực thể Employee
được ánh xạ với bảng EMPLOYEE trong thẻ <class>. Khóa chính id được ánh
xạ với thuộc tính id trong thẻ <id>, first_name với firstName, last_name với
lastName, salary với salary trong thẻ <property>.
Bộ phân tích Hibernate được chia thành hai phần: phân tích câu truy vấn
và hàm phân tích thực thể. Hibernate đã xây dựng sẵn các phương thức tương
tác với cơ sở dữ liệu bằng thực thể, danh sách các phương thức cho trong Bảng
2.2 [2]. Tham số truyền vào các hàm này có thể là tên của thực thể Java dưới
dạng “package.name”. Đi cùng với tên thực thể là đối tượng Java chứa các giá
trị cần gửi cho cơ sở dữ liệu, hoặc chỉ cần gửi đối tượng Java. Các phương thức
này có các đặc điểm khá riêng biệt nên chúng dễ được tìm thấy bằng cách quét
qua từng câu lệnh. Sau đó phân tích các tham số truyền vào phương thức này và
xác định kiểu thực thể của tham số.
Bảng 2.2. Các phương thức truy xuất CSDL có sẵn của Hibernate
Phương thức Mô tả
delete(Object object)
delete(String entityName, Object object) Xóa một bản ghi
get(Class clazz, Serializable id)
get(String entityName, Serializable id) Lấy thông tin bản ghi
load(Class clazz, Serializable id)
load(Object object, Serializable id) Lấy thông tin bản ghi
merge(Object object)
merge(String entityName, Object object) Cập nhật bản ghi
save(Object object)
save(String entityName, Object object) Lưu bản ghi
update(Object object)
update(String entityName, Object object) Cập nhật bản ghi
persist(Object object)
persist(String entityName, Object object) Lưu bản ghi
27
2.4 Quản lý phiên bản
Bộ so sánh mã nguồn [2] nhận đầu vào là phiên bản mã nguồn đã được
thay đổi, một trình kiểm tra sẽ quét toàn bộ mã nguồn mới, so sánh với mã
nguồn gốc để tìm ra những tệp có nội dung thay đổi hoặc có thể là tệp thêm vào
hoặc tệp bị xóa. Với tệp thay đổi, bộ tiền xử lý tương ứng với mã nguồn tệp đó
sẽ được sử dụng tạo cây AST mới. Sau đó, thông tin nút gốc được sử dụng để
định danh trên cây AST của mã nguồn gốc. Tiếp theo, một trình duyệt cây sẽ
duyệt hậu thứ tự được thực hiện và tìm ra các nút được thêm mới, xóa đi, v.v.
Đầu ra của bộ so sánh mã nguồn là tệp thay đổi để cung cấp cho việc phân tích
ảnh hưởng sự thay đổi.
Hình 2.13. So sánh cây cấu trúc giữa hai phiên bản mã nguồn
Hình 2.13 là một ví dụ so sánh hai phiên bản mã nguồn của dự án. Nút
File_A.java được định danh trên cây cấu trúc mã nguồn gốc, sau đó trình duyệt
cây thực hiện duyệt hậu thứ tự đồng thời trên hai cây với độ sâu cấp ba, nhận
thấy nút thuộc tính có tên ID đã được thay đổi kiểu từ kiểu int thành kiểu long,
và nút phương thức A2() tồn tại trên cây mới nhưng không có trên cây gốc, do
đó nút này đã được thêm mới.
28
Chương 3. Phương pháp phân tích ảnh hưởng các thành phần
giao diện và phân loại kiểm thử hồi quy
Chương 2 đã trình bày phương pháp phân tích phụ thuộc trong mã nguồn
Java và một số công nghệ nền tảng kèm theo công cụ JCIA. Chương này, luận
văn sẽ trình bày phương pháp phân tích ảnh hưởng các các thành phần giao diện
trong công nghệ Java Servlet. Tiếp theo là trình bày về kiểm thử hồi quy và phân
loại kiểm thử hồi quy từ các thành phần thay đổi và ảnh hưởng tìm được từ công
cụ. Cuối chương là quy trình kiểm thử hồi quy dựa trên phương pháp cải tiến.
3.1 Phương pháp phân tích ảnh hưởng các thành phần giao diện
Với các nền tảng khác nhau thì mã nguồn Java tương tác với các mã nguồn
giao diện theo những cách khác nhau. Vì vậy, hiện tại công cụ JCIA tập trung
vào phân tích ảnh hưởng giao diện cho công nghệ Java Servlet.
3.1.1 Phân tích kiến trúc Java Servlet
Java Servlet là chương trình chạy trên phía máy chủ Web và đóng vai trò
như một lớp trung gian giữa một yêu cầu đến từ một trình duyệt Web
hoặc HTTP Client với cơ sở dữ liệu hoặc các ứng dụng trên HTTP Server.
Hình 3.1. Kiến trúc Java Servlet
Hình 3.1 mô tả kiếm trúc của Java Servlet với các thành phần như sau:
Web Browser là một trình duyệt giúp người dùng có thể truy cập được
máy chủ Web thông qua giao thức HTTP.
29
Web Server là một chương trình máy tính sử dụng HTTP (Hypertext
Transfer Protocol) để truyền tải dữ liệu.
Servlet Container là một phần của máy chủ Web được viết bởi ngôn ngữ
Java để xử lý các Web động, yêu cầu tính toán từ máy khách.
Database là nơi chứa dữ liệu tương tác của hệ thống.
Dữ liệu sẽ được nhập vào khung dữ liệu trên trình duyệt máy chủ của máy
khách sau đó giao tiếp với máy chủ Web thông qua giao thức HTTP để truyền
và nhận dữ liệu. Web Server có nhiệm vụ trung chuyển dữ liệu và điều hướng
đến Servlet Container để thực thi các tác vụ tương ứng với yêu cầu từ phía máy
khách. Servlet Container gọi phương thức init() của servlet để khởi tạo và nó
được gọi một lần khi servlet được tải lần đầu tiên.
Container gọi phương thức service() của servlet để xử lý HTTP request,
tức là đọc dữ liệu trong yêu cầu và hình thành một response. Web Server trả lại
kết quả dựa trên yêu cầu.
Hình 3.2. Vòng đời của Java Servlet
Khi Servlet được tải lần đầu tiên các bước 1, 2, 3 được thực thi. Các bước
này chỉ được gọi khi Servlet được gọi lần đầu. Servlet Container sẽ gọi phương
thức init() một lần duy nhất khi khởi tạo Servlet. Phương thức init() phải được
thực hiện thành công trước khi Servlet có thể nhận bất kỳ yêu cầu nào. Bước
30
4 được gọi khi có yêu cầu từ phía người dùng tới Servlet. Service() được gọi bởi
Servlet container để cho phép Servlet đáp ứng yêu cầu từ phía người dùng, nó
chỉ được gọi sau khi phương thức init() của Servlet đã được thực hiện thành
công. Phương thức Destroy() chỉ được gọi khi tất cả các luồng trong phương
thức dịch vụ của Servlet đã thoát hoặc sau một khoảng thời gian chờ nhất định.
Hình 3.3 là một ví dụ về mã nguồn sử dụng nền tảng Java Servlet:
Hình 3.3. Mã nguồn sử dụng nền tảng Java Servlet
Đầu tiên, yêu cầu từ người dùng sẽ được gửi đến Server bằng giao thức
HTTP thông qua URL. Tiếp theo, dựa vào các thông số đầu vào hostname và
port, máy chủ Web sẽ điều hướng tới Servlet Container tương ứng, cụ thể trong
ví dụ này là Servlet helloservlet. Sau đó, tệp web.xml sẽ là nơi định nghĩa ánh xạ
31
giữa servlet name với các url tương ứng, cũng như lớp tương ứng. Từ các ánh xạ
và các thông số đầu vào từ URL sẽ quyết định tệp java được gọi và tùy vào
phương thức do máy khách truyền lên thì một trong hai phương thức doPost()
hoặc doGet() được gọi. Đối tượng ServletOutputStream dùng để gửi dữ liệu về
cho máy khách mà cụ thể ở đây là trình duyệt.
3.1.2 Phương pháp phân tích sự ảnh hưởng
Ý tưởng phân tích được dựa trên kiến trúc và luồng dữ liệu trong Java
Servlet kết hợp với kết quả phân tích mã nguồn từ công cụ JCIA hiện có.
Hình 3.4. Phương pháp phân tích
Hình 3.4 mô tả một bộ mã nguồn dự án bao gồm 3 phần: tệp cấu hình, mã
nguồn giao diện và mã nguồn Java. Trong đó, các phụ thuộc trong mã nguồn
Java đã được phân tích từ phiên bản trước. Từ tệp cấu hình và các annotation,
xác định được các Java Servlet và URL ánh xạ của chúng. Sau đó, các phụ thuộc
giữa mã nguồn Java và mã nguồn giao diện được phân tích, các thành phần giao
diện tương tác với servlet thông qua URL ánh xạ với servlet với action là
phương thức của servlet. Các tệp Java Servlet truyền và nhận dữ liệu từ giao
diện thông qua các HTTP Request, Response và Session. Từ mã nguồn giao
diện, các thành phần của giao diện được phân tích dựa vào các tags để tìm phụ
thuộc giữa các tag và phụ thuộc giữa các tệp giao diện.
Hình 3.5 mô tả các bước phân tích phụ thuộc cho Java Servlet. Bước đầu
tiên, bộ phân tích sẽ tìm tệp cấu hình web.xml/annotation để xác định xem mã
nguồn có sử dụng Java Servlet hay không. Nếu tìm thấy, bộ phân tích sẽ tìm tệp
servlet và trỏ đến URL. Bước tiếp theo, bộ phân tích sẽ phân tích các thành phần
32
giao diện và mã nguồn Java trong JSP để tìm phụ thuộc giữa giao diện và mã
nguồn Java. Sau đó, bộ phân tích tìm các giá trị được gửi từ các tệp Java tới giao
diện và nhận từ giao diện bằng Session, Request, Response.
Hình 3.5. Quá trình phân tích phụ thuộc
Mã nguồn 3.1 là một ví dụ cho việc tìm kiếm các Java Servlet thông qua
tệp cấu hình web.xml. Thông tin về Java Servlet đã được khai báo rõ ràng nhờ
vào các <servlet> và <servlet-mapping> liên hệ bằng <servlet-name>. Như
vậy, có một phụ thuộc Servlet ánh xạ từ lớp Java tại đường dẫn
Controller/SANPHAM_CTR tới URL Sanpham.do.
Mã nguồn 3.1. Mã cấu hình web.xml trong Java Servlet
<servlet>
<servlet-name>Sanpham</servlet-name>
<servlet-class>Controller.SANPHAM_CTR</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name></servlet-name>
<servlet-pattern>/Sanpham.do<servlet-pattern>
</servlet-mapping>
Mã nguồn 3.2 thể hiện mối quan hệ giữa URL và Java Servlet thông qua
Annotation. Từ đó, phụ thuộc từ LoginService.class tới URL /LoginService có
thể dễ dàng nhận ra được.
Mã nguồn 3.2. Mã Annotation trong Java Servlet
@WebServlet(“/LoginService”)
public class LoginService extends HttpServlet
Tiếp theo, bộ phân tích sẽ phân tích đến phụ thuộc giữa các thành phần
giao diện. Công cụ tìm đến các tệp JSP, phân tích các thẻ và thu thập các thuộc
33
tính của từng thẻ. Dựa trên các thuộc tính của các thẻ giao diện trong các tệp
JSP, các phụ thuộc giữa các tệp sẽ được hình thành.
Mã nguồn 3.3. Phụ thuộc trong mã nguồn giao diện
<div class=“wrapper”>
<%@include file=“templates/user/side-bar.jsp”%>
<div class=“main-panel”>
<%@include file=“templates/user/nav-bar.jsp”%>
<%@include file=“reception/booked.jsp”%>
<%@include file=“templates/footer.jsp”%>
</div>
</div>
Mã nguồn 3.3 thể hiện sự phụ thuộc từ các thẻ <div> tới các tệp với các
đường dẫn templates/user/side-bar.jsp, templates/user/nav-bar.jsp,
reception/bookbed.jsp, templates/footer.jsp. Nếu mã nguồn trong các tệp này bị
thay đổi thì giao diện chứa mã nguồn trên cũng bị thay đổi.
Sau đó là quá trình phân tích phụ thuộc giữa mã nguồn Java và mã nguồn
giao diện thông qua dữ liệu được lưu tại Session và vận chuyển thông qua
HTTPRequest, HTTPResponse. Từ đó, công cụ nhận được các phụ thuộc bằng
cách tìm ra các đối tượng tương ứng trong mã nguồn. Bên cạnh đó, giao diện
cũng tương tác với mã nguồn Java thông qua các lời gọi đến URL theo các giao
thức HTTP. Dựa vào ánh xạ đã phân tích từ cấu hình, bộ phân tích sẽ đánh dấu
lại các phụ thuộc.
Mã nguồn 3.4. Phụ thuộc giữa mã nguồn Java và mã nguồn giao diện
String user = request.getParameter(“user”);
String pass = request.getParameter(“pass”);
<form method=“POST” action=“LoginService”>
<input type=“text” name=“user” placeholder="Username” required>
<input type=“text” name=“password” placeholder=“Password”
required>
<input type=“submit” name=“Login” placeholder="”Login
Loginmodal-submit” value=“Login”>
Mã nguồn 3.4 cho thấy mã nguồn Java lấy dữ liệu từ hai input trong giao
diện thông qua phương thức getParameter của request. Ngoài ra, mã nguồn
34
cũng thể hiện mối quan hệ giữa form tới lớp servlet có ánh xạ với URL
LoginService.
Ngoài các phụ thuộc trên, mã nguồn JSP còn tương tác với các đối tượng
Java bằng cách nhúng các mã nguồn Java vào trong nội dung của chính nó.
Thông qua đó, JSP có thể sử dụng các phương thức và thuộc tính của các đối
tượng Java mà không cần phải khai báo Servlet. Như vậy, việc tương tác giữa
Java và JSP trở nên linh hoạt và dễ dàng hơn.
Mã nguồn 3.5 nằm trong tệp patientmgmt.jsp có gọi đến đối tượng Java là
AdminDAO, Employee, RoomType và Room là các đối tượng không được khai
báo Servlet. Nhờ đó, JSP có thể lấy dữ liệu từ Java, xử lý chúng và trả kết quả
về cho giao diện. Như ví dụ trong Mã nguồn 3.5, các dữ liệu về rooms lấy được
từ phương thức getListObject() của AdminDAO đã được JSP lấy ra và hiển thị
dưới dạng các dòng dữ liệu từ trong bảng. Tuy nhiên, hiện tại trong luận văn
việc tìm phụ thuộc của mã nguồn Java trong JSP còn hạn chế và sẽ cải thiện
trong tương lai.
Mã nguồn 3.5. Phụ thuộc mã nguồn Java nhúng trong mã nguồn JSP
35
3.2 Phương pháp phân loại kiểm thử hồi quy
3.2.1 Phân loại kiểm thử hồi quy
Có một số cách để kiểm thử hồi quy có thể được thực hiện. Tuy nhiên,
điều này phụ thuộc vào các yếu tố như loại thay đổi được đưa ra, sửa lỗi, v.v.
Một tập hợp các kiểm thử có thể thực hiện theo luồng sau:
Kiểm thử hồi quy đơn vị: thực hiện kiểm thử lại đối với sự thay đổi ở mô-
đun hoặc vùng nào đó của ứng dụng.
Kiểm thử hồi quy tích hợp: thực hiện kiểm thử lại đối với sự thay đổi ở các
mô-đun kèm theo những tương tác với nó.
Kiểm thử hồi quy toàn bộ: kiểm tra lại toàn bộ ứng dụng, không phụ thuộc
vào vị trí của sự thay đổi.
Tùy thuộc vào tình hình của dự án bao gồm: thời gian, chi phí và nguồn
lực sẵn có, mức độ nghiêm trọng của sự thay đổi mà việc thực hiện kiểm thử hồi
quy sẽ hiệu quả nếu chọn đúng bộ kiểm thử thay vì kiểm thử lại toàn bộ. Hiện
nay, cũng có một số công cụ quản lý mã nguồn có thể thấy được các dòng lệnh
thay đổi. Tuy nhiên việc kiểm thử như thế nào, phân loại ra sao và được thực
hiện bởi lập trình viên hay kiểm thử viên là chưa có công cụ nào hỗ trợ. Các
công cụ quản lý mã nguồn hiện nay đều không hỗ trợ tích hợp kiểm thử.
Hình 3.4. Phân loại kiểm thử hồi quy
Hình 3.6 mô tả việc phân loại kiểm thử hồi quy. Dựa trên các phân tích sự
ảnh hưởng mà công cụ JCIA đã thực hiện bao gồm các phụ thuộc liên quan đến
mã nguồn Java và mã nguồn giao diện JSP với nền tảng Java Servlet. Một
phương pháp phân loại kiểm thử hồi quy được đề xuất bao gồm: kiểm thử hồi
36
quy đơn vị, kiểm thử hồi quy tích hợp và kiểm thử hồi quy cho giao diện. Mục
đích của việc phân loại như trên là để đưa ra cái nhìn khách quan giữa lập trình
viên và kiểm thử viên. Lập trình viên có thể kiểm thử hồi quy cho đơn vị và tích
hợp các đơn vị một cách hiệu quả và kiểm thử viên có thể kiểm thử hồi quy cho
các trang thay đổi và ảnh hưởng.
Giao diện cần được kiểm thử có thể được xác định dựa vào kiểu đối tượng
khi dựng cây cấu trúc, đó là các tệp và các thẻ JSP. Kết hợp với dữ liệu phân
tích hai phiên bản, công cụ có thể đưa ra các tệp giao diện có thể bị thay đổi và
cần phải kiểm thử lại.
Từ các phụ thuộc đã phân tích được, bộ công cụ sẽ tự động phân loại kiểm
thử hồi quy cho các phương thức trong Java. Nếu phương thức đó không gọi đến
bất kỳ một phương thức nào khác thì sẽ được phân loại vào kiểm thử đơn vị. Và
ngược lại nếu phương thức đó gọi đến bất kỳ một phương thức khác thì sẽ được
phân loại vào kiểm thử tích hợp.
3.2.3 Quy trình kiểm thử hồi quy dựa trên phương pháp cải tiến
Hình 3.5. Quy trình kiểm thử hồi quy đề xuất
Luận văn đề xuất một quy trình kiểm thử hồi quy dựa trên kết quả của
công cụ JCIA như Hình 3.5. Đầu tiên, mã nguồn dự án Java EE phiên bản trước
37
khi thay đổi sẽ được đưa vào công cụ để phân tích, sau đó một phiên bản mã
nguồn Java EE được sửa đổi sẽ được đưa vào công cụ JCIA mở rộng để so sánh
hai phiên bản và tìm ra các thành phần bị ảnh hưởng. Sau khi có được kết quả
đầu ra là các thành phần thay đổi và bị ảnh hưởng, các thành phần này sẽ được
phân loại dựa trên các tệp mã nguồn là Java Core hay JSP. Tiếp theo là chọn các
ca kiểm thử cần kiểm tra lại và cập nhật ca kiểm thử nếu có thay đổi để đưa vào
các công cụ kiểm thử để thực hiện kiểm thử hồi quy Ranorex (công cụ kiểm thử
giao diện).
38
Chương 4. Công cụ hỗ trợ và thực nghiệm
Ở chương này, luận văn sẽ trình bày về quá trình thực nghiệm và triển khai
với công cụ JCIA mở rộng và công cụ hỗ trợ kiểm thử hồi quy Ranorex.
4.1 Giới thiệu công cụ JCIA mở rộng
Dựa trên những cải tiến phương pháp đã được trình bày ở trên, bộ công cụ
JCIA mở rộng thừa kế mã nguồn từ JCIA đã được triển khai và cài đặt sử dụng
cho các công nghệ nền tảng Spring, Hibernate, Struts 2. Công cụ JCIA mở rộng
tập trung phân tích ảnh hưởng cho công nghệ Java Servlet nhằm tìm ra các thành
phần dự đoán thay đổi liên quan đến giao diện. Hình 4.1 mô tả kiến trúc của bộ
công cụ JCIA phiên bản trước và phần mở rộng trong phiên bản mới (phần mở
rộng là phần được bôi đậm trong hình).
Hình 4.1. Kiến trúc của công cụ JCIA
Công cụ JCIA mở rộng nhận đầu vào là mã nguồn Java EE sử dụng công
nghệ Java Servlet. Trong bộ tiền xử lý, mã nguồn Java sẽ được phân tích nhờ
thư viện Java Development Tools phục vụ cho yêu cầu định danh và tìm kiếm
nút. Bộ phân tích ảnh hưởng được kế thừa từ công cụ JCIA, mở rộng phân tích
sự ảnh hưởng cho các thành phần giao diện trong Java Servlet. Sau đó, dựa vào
bộ so sánh phiên bản và kỹ thuật phân tích ảnh hưởng WAVE-CIA đã có; một
39
bộ phân loại các thành phần dựa trên các phụ thuộc được thực hiện nhằm mục
đích hỗ trợ cho kiểm thử hồi quy.
Hình 4.2 mô tả kết quả đầu ra của công cụ sau khi so sánh hai phiên bản
mã nguồn bao gồm các thành phần thay đổi và các thành phần dự đoán thay đổi.
Các thành phần này được phân loại hỗ trợ cho việc kiểm thử hồi quy bao gồm
các thành phần cho kiểm thử đơn vị, các thành phần kiểm thử tích hợp và kiểm
thử giao diện.
Hình 4.2. Kết quả đầu ra của công cụ
4.2 Thực nghiệm
Sau đây, luận văn sẽ trình bày một ví dụ áp dụng công cụ JCIA phân tích
cho mã nguồn ứng dụng Web Java EE quản lý bệnh viện [7]. Đây là một ứng
dụng quản lý các thông tin cơ bản liên quan đến bệnh viện như: quản lý nhân
viên, quản lý thông tin bệnh nhân, quản lý đặt phòng, quản lý thuốc, quản lý
dịch vụ khám chữa bệnh. Ứng dụng Web này có chức năng phân theo các quyền
như Hình 4.3.
Ứng dụng Web này bao gồm các trang:
Đăng nhập: Người dùng cần phải đăng nhập vào thành công vào hệ thống
để có thể sử dụng các chức năng quản lý của hệ thống. Tài khoản dùng để truy
cập vào hệ thống được cung cấp và khởi tạo bởi người quản trị hệ thống. Tương
ứng với mỗi loại người dùng khác nhau, người quản trị sẽ cung cấp quyền truy
cập vào hệ thống khác nhau. Từ đó, người dùng có thể truy cập được một vào
giao diện chức năng tương ứng với quyền được cung cấp.
40
Hình 4.3. Ứng dụng Web quản lý bệnh viện.
User Admin: Sau khi đăng nhập thành công người quản trị hệ thống sẽ có
quyền thực hiện các chức năng như: quản lý nhân viên, quản lý phòng, quản lý
dịch vụ y tá, gửi/nhận tin nhắn từ người dùng khác, thay đổi mật khẩu.
- Quản lý nhân viên: Ở chức năng này, người quản trị hệ thống có thể thực hiện
thêm mới, sửa, xóa nhân viên và phân loại phòng ban cho nhân viên. Việc phân
loại nhằm phân quyền cho nhân viên khi tham gia sử dụng trong hệ thống. Nhân
viên thuộc phòng ban nào sẽ được phân quyền sử dụng chức năng tương ứng của
phòng ban đó. Thông tin của nhân viên bao gồm các thông tin chung, trình độ
chuyên môn và kinh nghiệm làm việc, phòng ban. Kết quả của việc thêm, sửa,
xóa nhân viên thành công, nhân viên sẽ được hiển thị trong danh sách nhân viên
được thể hiện trong bảng “All Employees”. Bên cạnh đó, để giúp tiết kiệm thời
gian cho quản trị viên, hệ thống có cung cấp chức năng tìm kiếm nhanh trong
bảng thông tin nhân viên trong bảng.
41
Bảng 4.1 mô tả chi tiết các yêu cầu dữ liệu đầu vào của từng trường trong
chức năng quản lý nhân viên.
Bảng 4.1. Mô tả yêu cầu chức năng quản lý nhân viên
Tên trường Bắt buộc Khoảng hợp lệ Khác
First Name Có Lớn hơn 3 ký
tự
Không được bỏ trống
Father Name Có Không được bỏ trống
Family Name Không
Address Có Không được bỏ trống
Password Có 6-16 ký tự Không được bỏ trống
Bao gồm cả chữ viết
thường và viết hoa
Confirm Password Có 6-16 ký tự Không được bỏ trống
Bao gồm cả chữ viết
thường và viết hoa
Phải trùng với
Password
Email Có Không được bỏ trống
Phải nhập đúng định
dạng email
Date of Birth Có Không được bỏ trống
Phone Có Không được bỏ trống
Chỉ bao gồm ký tự số
Không chứa dấu cách
Select Gender Không
Category, Employee
Job, User Name,
Date, Institute
Name,
Year, Position,
Degree,
Quatification
Có
Không được bỏ trống
- Quản lý phòng: Chức năng quản lý phòng cho phép quản trị viên có thể thêm,
sửa, xóa thông tin các phòng. Danh sách các phòng sau khi được thêm mới hoặc
sửa đổi sẽ được hiển thị trên trang quản lý phòng giúp quản trị viên biết được
42
những loại phòng hiện có trong bệnh viên, số lượng giường cũng như giá của
từng loại phòng. Ngoài ra nhằm giúp quản trị viên tìm kiếm thông tin nhanh
chóng, hệ thống còn cung cấp thêm chức năng tìm kiếm nhanh.
Bảng 4.2 mô tả chi tiết yêu cầu dữ liệu đầu vào của từng trường trong
chức năng quản lý nhân viên.
Bảng 4.2. Mô tả yêu cầu chức năng quản lý phòng
Tên trường Bắt buộc Khoảng hợp lệ Khác
Room Type Có Không Không được bỏ trống
Room Number Có Không Không được bỏ trống
Number of Bed Có Lớn hơn 0 Không được bỏ trống
Chỉ được phép nhập ký tự số
- Quản lý dịch vụ y tá: Chức năng quản lý dịch vụ y tá cung cấp cho quản trị
viên hệ thống các chức năng cơ bản thêm, sửa, xóa các dịch vụ y tá. Thông tin
các dịch vụ hiển thị trong bảng, người dùng có thể tìm kiếm thông tin về các
dịch vụ.
Bảng 4.3 mô tả chi tiết yêu cầu của dữ liệu đầu vào của từng trường trong
chức năng quản lý dịch vụ y tá.
Bảng 4.3. Mô tả yêu cầu chức năng quản lý dịch vụ
Tên trường Bắt buộc Khoảng hợp lệ Khác
Nurse, Shift
Time, Service
Date, Department
Có
Không Không được bỏ trống
User Receptionist: Hệ thống cho phép người dùng này thực hiện các chức
năng như: quản lý bệnh nhân, đặt phòng cho bệnh nhân, gửi/nhận tin nhắn từ
người dùng khác, đổi mật khẩu.
- Quản lý bệnh nhân: Hệ thống cho phép người dùng Receptionist quản lý các
thông tin về bệnh nhân với các chức năng: thêm, sửa, xóa thông tin bệnh nhân
bao gồm thông tin cá nhân và thông tin người thân. Các thông tin bệnh nhân liên
quan đến bệnh nhân được hiển thị trong bảng “All Patient”. Bên cạnh đó, người
dùng có thể tìm kiếm thông tin bệnh nhân trong bảng với chức năng tìm kiếm.
- Quản lý đặt phòng: Hệ thống cho phép người dùng Receptionist thực hiện
chức năng: thêm, sửa, xóa thông tin đặt phòng. Thông tin chi tiết về phòng đặt
43
được hiển thị trong bảng và người dùng có thể tìm kiếm thông tin phòng đặt
bằng cách thực hiện chức năng tìm kiếm phía trên mỗi bảng.
Bảng 4.4 mô tả chi tiết yêu cầu của dữ liệu đầu vào của từng trường trong
chức năng quản lý bệnh nhân.
Bảng 4.4. Mô tả yêu cầu chức năng quản lý bệnh nhân
Tên trường Bắt buộc Khoảng hợp lệ Khác
First Name Có Lớn hơn 3 ký tự Không được bỏ trống
Father Name, Family
Name, Address Không
Email Có
Không được bỏ trống
Nhập đúng định dạng
Date of Birth Có Không được bỏ trống
Phone Có Không được bỏ trống
Chỉ được phép nhập số
Select Gender, Blood
Type, Full Name,
Address, Relationship
Không
Bảng 4.5 mô tả chi tiết yêu cầu của dữ liệu đầu vào của từng trường trong
chức năng quản lý bệnh nhân và đặt phòng.
Bảng 4.5. Mô tả yêu cầu chức năng đặt phòng
Tên trường Bắt buộc Khoảng hợp lệ Khác
First Name Có Lớn hơn 3 ký tự Không được bỏ trống
Father Name, Family
Name, Address
Không
User Pharmacist: Hệ thống cho phép người dùng thực hiện các chức
năng như: quản lý thuốc, bán thuốc cho bệnh nhân, gửi/nhận tin nhắn của người
dùng khác, thay đổi mật khẩu.
- Quản lý thuốc: Ở chức năng này, người dùng Pharmacist có thể thực hiện các
chức năng: thêm, sửa, xóa thông tin thuốc. Các thông tin liên quan đến thuốc
được hiển thị trong bảng “All Drugs”, người dùng có thể tìm kiếm thông tin về
thuốc tại bảng này bằng cách sử dụng chức năng tìm kiếm.
44
- Quản lý bán thuốc: Chức năng cho phép người dùng Pharmacist quản lý thuốc
được bán cho bệnh nhân và có thể thực hiện thêm, sửa, xóa thông tin thuốc bán
ra và thông tin này được hiển thị trong bảng cho phép người dùng tìm kiếm
thông tin với chức năng tìm kiếm. Bên cạnh đó người dùng có thể in hóa đơn
thuốc.
Bảng 4.6 mô tả chi tiết yêu cầu của dữ liệu đầu vào của từng trường trong
chức năng quản lý bán thuốc.
Bảng 4.6. Mô tả yêu cầu chức năng quản lý thuốc
Tên trường Bắt buộc Khoảng hợp lệ Khác
Drug Name Có Không được bỏ trống
Cost Có Lớn hơn 0 Không được bỏ trống
Chỉ cho phép nhập ký tự số
Quantity Có Lớn hơn 0 Không được bỏ trống
Chỉ cho phép ký tự số
Production date Có Không được bỏ trống
Drug expired Có Không được bỏ trống
Bảng 4.7 mô tả chi tiết yêu cầu của dữ liệu đầu vào của từng trường trong
chức năng quản lý bán thuốc.
Bảng 4.7. Mô tả yêu cầu chức năng quản lý bán thuốc
Tên trường Bắt buộc Khoảng hợp lệ Khác
Drug Name,
Patient
Có Không được bỏ trống
Unit Per Day Có Lớn hơn 0 và nhỏ
hơn 4
Không được bỏ trống
Quantity Có Lớn hơn 0 và nhỏ
hơn 50 Không được bỏ trống
Take From, End
Take Có
Không được bỏ trống
Nhập đúng định dạng
dd/mm/yyyy
Dựa trên các mô tả yêu cầu và các đặc tả kể trên, một tập các ca kiểm thử
được thiết kế cho từng chức năng trong hệ thống. Dưới đây là tập các ca kiểm
thử cho một số chức năng chính.
45
Chức năng Add Patient
STT Hành động Phản hồi từ hệ thống
Trường hợp thêm Patient thành công
1
1. Nhập vào các trường sau với giá
trị hợp lệ:
- First Name, Father Name, Family
Name, Address, Email, Date of
Birth, Phone, Select Gender, Blood
Type
2. Chọn chức năng “Next”
Nhập vào các trường sau với giá trị
hợp lệ: Full Name, Address,
Relationship, Phone
3. Chọn chức năng “Finish”
Hệ thống hiển thị thông báo
tương ứng “Success Add
Patient”
Nhập giá trị không hợp lệ vào trường Email
2
1. Nhập sai định dạng Email
2. Nhập giá trị hợp lệ vào các
trường còn lại
Hệ thống hiển thị thông báo
tương ứng “Please enter a
valid email address”
Nhập vào giá trị trống
3
Để trống các trường bắt buộc:
- First Name, Email, Date of Birth,
Phone
2. Chọn chức năng “Next”
Next of Skin
- Phone
3. Chọn chức năng “Finish”
Hệ thống hiển thị thông báo
tương ứng dưới các trường
“This field is required”
Nhập giá trị không hợp lệ vào trường Phone
4
1. Nhập chữ cái/ký tự đặc biệt vào
vào trường Phone
2. Nhập giá trị hợp lệ vào các
trường còn lại
Hệ thống hiển thị thông báo
tương ứng dưới các trường
“This field is invalid”
Nhập giá trị không hợp lệ vào trường First Name
5 Nhập vào trường First Name < 3 ký
tự
Hệ thống hiển thị thông báo
tương ứng “Please enter at
least 3 characters”
46
Chức năng Book Bed
STT Hành động Phản hồi từ hệ thống
Trường hợp Book Bed thành công
1
1. Chọn và nhập các giá trị hợp
lệ:
- Room, Patient, Department
2. Chọn chức năng “Book Bed”
Hệ thống hiển thị thông báo tương
ứng “Success Added Book Bed”
Trường hợp nhập vào giá trị trống
Để trống các trường bắt buộc:
- Room, Patient, Department
2. Chọn chức năng “Book Bed”
Hệ thống hiển thị thông báo tương
ứng dưới các trường “This field is
required”
Chức năng Sell Drug
STT Hành động Phản hồi từ hệ thống
Trường hợp Sell Drug thành công
1
1. Chọn và nhập các giá trị hợp
lệ:
- Drug, Patient, Unit Per Day,
Quantity, Take From, End Take
2. Chọn chức năng “Sell Drug”
Hệ thống hiển thị thông báo tương
ứng “Selled Successfully, Warning
Drug Quantity Less Than 50”
Nhập vào giá trị trống
2
Để trống các trường bắt buộc:
- Drug
- Patient
- Unit Per Day
- Quantity
- Take From
- End Take
2. Chọn chức năng “Sell Drug”
Hệ thống hiển thị thông báo tương
ứng dưới các trường “This field is
required”
Nhập sai định dạng Quantity
3
1. Nhập giá trị âm vào trường
Quantity
2. Các trường còn lại nhập giá
trị hợp lệ
3. Chọn chức năng “Sell Drug”
Hệ thống hiển thị thông báo tương
ứng “Please enter a valid number
between 1 and 50”
47
STT Hành động Phản hồi từ hệ thống
4
1. Nhập giá trị vào trường
Quantity lớn hơn số lượng thuốc
còn lại trong cơ sở dữ liệu.
2. Các trường còn lại nhập giá
trị hợp lệ
3. Chọn chức năng “Sell Drug”
Hệ thống hiển thị thông báo tương
ứng “You Enter Quantity more than
Drug Quantity”
5
1. Nhập giá trị 0 vào trường
Quantity
2. Các trường còn lại nhập giá
trị hợp lệ
3. Chọn chức năng “Sell Drug”
Hệ thống hiển thị thông báo tương
ứng “Please enter a valid number
between 1 and 50”
6
1. Nhập giá trị >50 vào trường
Quantity
2. Các trường còn lại nhập giá
trị hợp lệ
3. Chọn chức năng “Sell Drug”
Hệ thống hiển thị thông báo tương
ứng “Please enter a valid number
between 1 and 50”
7
1. Nhập chữ vào trường
Quantity
2. Các trường còn lại nhập giá
trị hợp lệ
3. Chọn chức năng “Sell Drug”
Hệ thống hiển thị thông báo tương
ứng “Please enter a number”
Nhập sai định dạng Unit Per Day
8
1. Nhập chữ vào trường Unit Per
Day
2. Các trường còn lại nhập giá
trị hợp lệ
3. Chọn chức năng “Sell Drug”
Hệ thống hiển thị thông báo tương
ứng “Please enter a number”
9
1. Nhập giá trị > 4 vào trường
Unit Per Day
2. Các trường còn lại nhập giá
trị hợp lệ
3. Chọn chức năng “Sell Drug”
Hệ thống hiển thị thông báo tương
ứng “Please enter a valid number
between 1 and 4”
48
STT Hành động Phản hồi từ hệ thống
10
1. Nhập giá trị âm vào trường
Unit Per Day
2. Các trường còn lại nhập giá
trị hợp lệ
3. Chọn chức năng “Sell Drug”
Hệ thống hiển thị thông báo tương
ứng “Please enter a valid number
between 1 and 4”
Nhập sai định dạng Take From/End Take
11
1. Nhập chữ vào trường Take
From
2. Các trường còn lại nhập giá
trị hợp lệ
3. Chọn chức năng “Sell Drug”
Hệ thống hiển thị thông báo tương
ứng “Please enter a valid format
dd/mm/yyyy”
14
1. Nhập Take From lớn hơn End
Take
2. Các trường còn lại nhập giá
trị hợp lệ
3. Chọn chức năng “Sell Drug”
Hệ thống hiển thị thông báo tương
ứng “Please enter Take From < End
Take”
Trường hợp giảm tiền thuốc đối với bệnh nhân có Health Insurance
15
1. Chọn bệnh nhân có Health
Insurance
2. Các trường còn lại nhập giá
trị hợp lệ
3. Chọn chức năng “Sell Drug”
4. Chọn chức năng “Invoice”
Tiền thuốc được tính đúng theo
công thức Total Cost = Cost
*Quantity-(Cost*Quantity*%level
Health_Insurance)
Trường hợp không giảm tiền thuốc đối với bệnh nhân không có Health
Insurance
16
1. Chọn bệnh nhân không có
Insurance Health
2. Các trường còn lại nhập giá
trị hợp lệ
3. Chọn chức năng “Sell Drug”
4. Chọn chức năng “Invoice”
Tiền thuốc được tính đúng theo
công thức Total Cost =
Cost*quantity
49
Chức năng tính Fee
STT Hành động Phản hồi từ hệ thống
Trường hợp Paid thành công
1 Chọn chức năng “Check” để
thanh toán
Hệ thống hiển thị “Paid
successfully” trong cột Fee
Trường hợp bệnh nhân đã Book Bed thành công
3 Kiểm tra thông tin bệnh nhân Hiển thị đầy đủ thông tin bệnh
nhân đã Book Bed thành công
Bài toán đặt ra: Sau khi kiểm thử phiên bản 1, kiểm thử viên đã phát hiện
ra một số lỗi bao gồm: cập nhật thông tin bệnh nhân không thành công, không
hiển thị thông báo sau khi xóa thông tin bệnh nhân, màn hình “Sell Drug” và
“Manage Drug” thiếu xác nhận các trường bắt buộc. Trong phiên bản mới,
khách hàng yêu cầu nhóm phát triển sửa lỗi tìm được ở phiên bản 1 và thêm một
số yêu cầu thay đổi.
Hình 4.4. Lỗi xảy ra ở phiên bản 1
Yêu cầu thứ nhất: Thêm trường cho bệnh nhân nội trú (In Patient) và
ngoại trú (Out Patient) trong màn hình quản lý bệnh nhân. Nếu là bệnh nhân nội
trú, bệnh nhân được phép thực hiện chức năng đặt phòng thông qua
Receptionist. Nếu bệnh nhân đăng ký ngoại trú sẽ không thể đặt phòng thành
công.
50
Hình 4.5. Yêu cầu thêm mới cho giao diện quản lý bệnh nhân
Yêu cầu thứ hai: Thêm trường kiểm tra Health Insurance với các mức độ 1,
2, 3, 4 tương ứng việc giảm 10%, 20%, 30%, 40% số tiền mà bệnh nhân phải trả
cho đặt phòng và mua thuốc.
Hình 4.6. Nghiệp vụ liên quan đến Health Insurance
Sau khi tiếp nhận yêu cầu của khách hàng và làm rõ yêu cầu, nhóm phát
triển thực hiện triển khai và đưa ra một phiên bản mới. Kiểm thử viên thực hiện
cập nhật các ca kiểm thử dựa theo yêu cầu thay đổi của khách hàng. Lúc này, mã
nguồn của phiên bản mới sẽ được đưa vào công cụ JCIA để so sánh và phân tích
sự ảnh hưởng từ các thay đổi.
Hình 4.8 mô tả kết quả sau khi đưa vào công cụ JCIA để phân tích bao
gồm các thành phần thay đổi và thành phần dự đoán thay đổi. Các thành phần
này được phân loại kiểm thử hồi quy cho đơn vị.
51
Hình 4.7. Kết quả tập thay đổi và ảnh hưởng cho kiểm thử đơn vị
Từ kết quả trên, lập trình viên sẽ phải thực hiện kiểm thử đơn vị cho tất cả
các hàm thay đổi và hàm bị ảnh hưởng để đảm bảo chất lượng cho phiên bản 2.
Việc kiểm thử đơn vị có thể kết hợp với công cụ CTF4Junit, công cụ này hỗ trợ
sinh ca kiểm thử cho đơn vị cho mã nguồn Java. Tuy nhiên, công cụ mới chỉ hỗ
trợ một phần đối với các hàm với kiểu dữ liệu nguyên thủy.
Tiếp theo là kết quả phân loại kiểm thử hồi quy cho các thành phần giao
diện (như Hình 4.9).
Hình 4.8. Kết quả tập thay đổi và ảnh hưởng cho kiểm thử giao diện
Từ kết quả trên, kiểm thử viên sẽ phải cập nhật các ca kiểm thử và chọn ra
một bộ các các ca kiểm thử phù hợp để thực hiện kiểm thử hồi quy giao diện.
Dựa vào kết quả đầu ra của công cụ JCIA mở rộng như Hình 4.10, các màn hình
giao diện thay đổi và dự đoán thay đổi sẽ được kiểm thử để đảm bảo chất lượng
của phiên bản mới. Việc kiểm thử giao diện được kết hợp với công cụ Ranorex,
52
công cụ này hỗ trợ kiểm thử giao diện tự động bằng kỹ thuật ghi lại và phát lại
để kiểm thử tính chính xác giữa tương tác người dùng và giao diện.
Hình 4.9. Kết quả kiểm thử hồi quy giao diện với Ranorex
Hình 4.10. Kết quả tập thay đổi và ảnh hưởng cho kiểm thử tích hợp
4.3. Ý nghĩa của công cụ thực nghiệm
Công cụ JCIA mở rộng là một giải pháp nhằm hỗ trợ kiểm thử hồi quy cho
các ứng dụng Web doanh nghiệp Java EE. Thực nghiệm cho thấy hướng phát
triển tiềm năng của phương pháp đối với việc đảm bảo chất lượng phần mềm.
Tuy phương pháp và công cụ vẫn còn một số hạn chế nhưng công cụ này vẫn có
ý nghĩa quan trọng trong việc kiểm thử hồi quy. Công cụ này giúp tìm ra các
thành phần bị ảnh hưởng từ các thành phần thay đổi và giúp nhóm phát triển
cũng như kiểm thử viên có góc nhìn khách quan hơn trong việc phát triển ứng
dụng cũng như đảm bảo chất lượng. Đây là một giải pháp giúp giảm kinh phí và
53
rút ngắn thời gian cũng như nâng cao tính hiệu quả và chính xác trong quá trình
kiểm thử các ứng dụng Web doanh nghiệp.
Khi sử dụng công cụ JCIA mở rộng, thay vì việc thực hiện lại toàn bộ các
ca kiểm thử, chúng ta chỉ việc nén các tệp mã nguồn hai phiên bản khác nhau và
cho vào công cụ để phân tích. Việc này giúp chúng ta giảm thiểu rủi ro, thời
gian, công sức và chi phí thực hiện. Thực nghiệm cho thấy thay vì phải kiểm thử
toàn bộ mã nguồn dự án (gồm 309 hàm trong mã nguồn Java và 35 tệp giao diện
với mã nguồn JSP), kiểm thử viên chỉ cần tập trung kiểm thử lại 101 hàm (bao
gồm 89 hàm cho kiểm thử đơn vị và 12 hàm cho kiểm thử tích hợp) và 15 tệp
giao diện cho kiểm thử giao diện. Chi phí kiểm thử giảm (309+35-101-
15)/(309+35) = 66.3%.
Do đó, việc áp dụng công cụ để kiểm thử hồi quy mang lại rất nhiều lợi
ích. Với ưu điểm đã nêu, trong tương lai công cụ có khả năng áp dụng hiệu quả
cho các ứng dụng Web với các ngôn ngữ lập trình khác nhau.
54
Chương 5. Kết luận
Luận văn đã cải tiến phương pháp và bộ công cụ phục vụ cho quy trình
kiểm thử hồi quy để đảm bảo chất lượng mã nguồn các ứng dụng doanh nghiệp
trên nền tảng và công nghệ Java EE. Các phương pháp được đề xuất bởi [2,5]
tập trung phân tích chủ yếu cho mã nguồn Java. Tuy nhiên với các nền tảng khác
nhau thì mã nguồn Java còn tương tác với các mã nguồn giao diện theo những
cách khác nhau. Trong luận văn này, tác giả đã hoàn thành thêm chức năng cho
bộ công cụ nhằm đáp ứng cho việc phân tích mã nguồn giao diện cho các ứng
dụng sử dụng công nghệ Java Servlet. Bên cạnh đó, công cụ còn hỗ trợ phân loại
kiểm thử hồi quy từ các thành phần thay đổi và ảnh hưởng bao gồm kiểm thử
đơn vị, kiểm thử tích hợp và kiểm thử giao diện. Từ đó, đưa ra cái nhìn khách
quan giữa kiểm thử viên và lập trình viên. Đối với các kiểm thử viên, họ có thể
thực hiện kiểm thử hồi quy dựa trên mã nguồn hoặc đặc tả. Nếu kiểm thử hồi
quy dựa trên đặc tả sẽ chọn ra các ca kiểm thử để thực hiện nếu nó liên quan đến
phần đặc tả bị thay đổi, kỹ thuật này đòi hỏi đặc tả phải được quản lý tốt. Tuy
nhiên, với phương pháp cải tiến mà luận văn đã thực hiện, việc kiểm thử hồi quy
sẽ dựa trên mã nguồn. Kiểm thử viên chỉ cần thực hiện một số ca kiểm thử dựa
trên kết quả phân tích sự ảnh hưởng các thành phần giao diện. Còn đối với lập
trình viên họ có thể sử dụng công cụ để đánh giá được các thay đổi trong mã
nguồn. Một bộ ánh xạ giữa thành phần mã nguồn và các giao diện, chức năng
của ứng dụng được tích hợp, giúp bộ công cụ này thực sự có ích và có thể ứng
dụng vào quá trình đảm bảo chất lượng phần mềm ở các công ty phát triển phần
mềm hiện nay.
Về thực nghiệm, luận văn đã áp dụng công cụ để so sánh hai phiên bản mã
nguồn cho ứng dụng Web quản lý bệnh viện. Kết quả thực nghiệm cho thấy,
công cụ cải tiến tìm được các thành phần ảnh hưởng liên quan đến giao diện ứng
dụng Web mà công cụ trước không tìm thấy. Thêm vào đó là việc phân loại các
thành phần ảnh hưởng và thành phần thay đổi. Từ đó, hỗ trợ kiểm thử hồi quy
một cách hiệu quả. Dựa vào kết quả thực nghiệm, công cụ đã cho chúng ta thấy
được tính khả dụng của công cụ giúp giảm thời gian và chi phí kiểm thử hồi
quy.
Dựa trên những gì đã thực hiện được, trong tương lai sẽ có thêm nhiều phụ
thuộc giao diện cho các nền tảng khác được thêm vào để xử lý giúp bộ phân tích
ảnh hưởng dự đoán tập ảnh hưởng chính xác hơn. Bộ quản lý và so sánh các
phiên bản mã nguồn sẽ được tích hợp với các hệ thống quản lý phiên bản như
SVN, Git và công cụ kiểm thử hồi quy. Bộ công cụ sẽ hỗ trợ cho thêm nhiều
55
công nghệ và nền tảng khác của Java, và xa hơn nữa, trong tương lai bộ công cụ
có thể phân tích cho các ngôn ngữ khác.
56
TÀI LIỆU THAM KHẢO
TIẾNG VIỆT
[1] Phạm Ngọc Hùng, Trương Anh Hoàng, Đặng Văn Hưng (2014), Giáo trình
kiểm thử phần mềm, NXB Đại học Quốc gia Hà Nội.
[2] Bùi Quang Cường, Nguyễn Minh Hiếu, Đinh Tiến Lộc. Bộ công cụ đảm bảo
chất lượng mã nguồn cho các ứng dụng doanh nghiệp, Hội nghị NCKH khoa
CNTT, ĐH Công nghệ, 2018.
TIẾNG ANH
[3] Bixin Li. WAVE-CIA: a novel CIA approach based on call graph mining. In
Proceedings of the 28th Annual ACM Symposium on Applied Computing.
[4] Bixin Li, Xiaobing Sun, Hareton Leung, Sai Zhang. A survey of code-based
change impact analysis techniques. In Software Testing, Verification and
Reliability. Wiley Online Library (2012).
[5] Le Ba Cuong, Son Van Nguyen, Duc Anh Nguyen, Pham Ngoc Hung, Hieu
Vo Dinh. A Tool for Change Impact Analysis of Java EE Applications.
Information Systems Design and Intelligent Applications. Advances in
Intelligent Systems and Computing, vol 672. Springer, Singapore (2018).
[6] Ann Millikin (2014), What Types of Software Testing Can and Should Be
Automated, https://www.seguetech.com/types-software-testing-can-should-
be-automated/.
[7] Salah, Hospital Management System, https://github.com/salahatwa/Hospital-
Management-System