Đầ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à
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
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
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
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.
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
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