Tóm tắt luận văn Thạc sĩ Công nghệ thông tin: 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

Chia sẻ: Yi Yi | Ngày: | Loại File: PDF | Số trang:19

Thêm vào BST

Báo xấu

41
lượt xem 3
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Luận văn nghiên cứu 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ời các bạn cùng tham khảo nội dung chi tiết.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Tóm tắt luận văn Thạc sĩ Công nghệ thông tin: 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

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.Java EE đang được xem như một giải pháp phổ biến để triển khai các ứng dụng Web doanh nghiệp hiện nay. Các công nghệ cốt lõi sử dụng trong Java EE bao gồm: EJB, JSF, CDI, JAX-WS, v.v và có thể tích hợp với các framework khác như Hibernate, Struts, Spring, v.v. 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ụ này giúp ta 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 framework như Hibernate, Struts, Spring. Tuy nhiên 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ả cao trong việc kiểm thử hồi quy ở góc nhìn của kiểm thử viên. 1
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 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. 2
2. Phương pháp phân tích sự ảnh hưởng trong JCIA 2.1 Giới thiệu về 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, mở rộng hệ thống, v.v. Một thành phần phần mềm bị thay đổi có thể là thuộc tính, phương thức, tệp hoặc một tập các tệp. Khi một hoặc nhiều thành phần thay đổi, các tập thành phần khác sẽ bị ảnh hưởng. Đối với lập trình viên, họ có thể không nắm rõ được hế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 người quản lý họ quan tâm đến sự ảnh hưởng các thành phần mã nguồn khi có sự thay đổi xảy ra. 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. JMS, v.v. Công cụ thiết kế mang lại sự tối giản trong thao tác đối với người sử dụng. 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. Để phân tích sự thay đổi, người dùng đánh dấu các thành phần dự kiến thay đổi và yêu cầu công cụ phân tích. Sau khi phân tích xong, các thành phần dự đoán thay đổi được hiển thị. Một cách khác, công cụ JCIA sẽ phân tích tự động bằng cách tải lên mã nguồn đã thay đổi và so sánh hai phiên bản mã nguồn và phân tích ảnh hưởng, trả về và báo cáo kết quả. 2.2 Tổng quan về bộ công cụ JCIA JCIA bao gồm năm mô-đun chính: bộ xử lý cơ sở, bộ phân tích ảnh hưởng sự tha đổ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. Mô- đun xử lý cơ sở bao gồm hai thành phần co là bộ tiền xử lý và bộ phân tích phụ thuộc theo từng công nghệ và nền tảng để sinh cây cấu trúc và phụ thuộc cho các nút trên cây. 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. 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. - Khung nhìn Project View 3
Khung nhìn Project View cung cấp cho người dùng giao diện trực quan để xem dưới dạng cây thư mục của dự án đầu vào. Người dùng có thể biết thông tin về dự án được đưa vào hệ thống và các thành phần chưa bên trong nó thông qua khung nhìn này. Để thao tác mở hoặc đóng một thư mục, nháy chuột trái vào một thư mục, để mở toàn bộ thư mục và tất cả các thư mục con trong nó, chuột phải vào thư mục và chọn “Expand All”. Để hiện thị thông tin chi tiết về một lớp nào đó, nháy chuột vào lớp muốn hiển thị, thông tin class sẽ được hiển thị trong khung nhìn Class View. - 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 node thể hiện rằng hai đối tượng đó có mối quan hệ phuộc thuộc lẫn nhau. Xem thông tin cụ thể của một node bằng cách đưa con trỏ chuột đến tệp, một cửa sổ pop-up sẽ hiển thị thông tin. 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 node đang làm việc. Để thêm một node vào tập thay đổi, bấm chuột phải vào node rồi chọn Change. Sau khi node được thêm vào tập thay đổi, node sẽ chuyển sang màu xanh. Để xem mã nguồn của tệp, chọn một node thuộc kiểu têp, chuột phải chọn View Source Code. - Khung nhìn Change Impact View Change Impact View là phần giao diện được sinh ra sau khi bạn thực hiện phân tích ảnh hưởng. Nó khá giống với Dependency View nhưng dữ liệu hiển thị của nó chỉ chứa những node có liên quan đến kết quả phân tích ảnh hưởng giúp bạn dễ quan sát tập trung vào kết quả phân tích hơ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 dổi được lưu trong tập Change và được thể hiện trong khung nhìn Change Set. 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.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 … 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 project. Công cụ sẽ tự tìm kiếm các tệp và thêm chúng vào tâp thay dổ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. 4
Analyze: Thực hiện phân tích tập thay đổi để tìm các tập bị hưởng 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. 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 Excel chứa thông tin của chúng. 2.3 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ệ 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 5
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.3 Phân tích các phụ thuộc 2.3.1 Tiền xử lý mã nguồn Định nghĩa: (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 đượ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. 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 AST được xây dựng bằng cách sử dụng công cụ JDT của Java. 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 như JSF, CDI, 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. 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.3.2 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. 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. 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. 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ẽ bj ảnh hưởng. 2.3.3 Phân tích sự phụ thuộc cho Struts 2 6
Struts 2 là một framework được thiết kế theo mô hình MVC bao gồm Model, View, Controller. 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ý logic, 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ị. Để 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:  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.3.4 Phân tích sự phụ thuộc cho Hibernate ORM Framework (Object Relational Mapping Framework) là những công cụ giúp chuyển đổi và ánh xạ những kiểu cấu trúc dữ liệu từ những hệ thống không tương thích về đối tượng phù hợp. Hibernate là một trong những framework này, ánh xạ các bảng trong CSDL với các đối tượng Java gọi là thực thể và đồng thời sử dụng JDBC để quản lí và cải tiến các thao tác đến CSDL. Hibernate sử dụng hai phương pháp ánh xạ là dùng tệp ánh xạ XML hoặc dùng Annotation để định nghĩa thông tin bảng trực tiếp trong lớp Java. Do Hibernate có thể quản lí các bảng được ánh xạ, nên các bảng của CSDL được sử dụng sẽ được xác định ngay đầu tiên khi các tệp cấu hình được phân tích. Các bước phân tích phụ thuộc cho Hibernate được mô tả như Hình 2.12. Đầu tiên, bộ phân tích sẽ tìm tệp cấu hình hibernate.hbm.xml để xác định xem mã nguồn có sử dụng 7
Hibernate hay không. Nếu tìm thấy, 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 khai báo việc ánh xạ đối tượng. 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. Bộ phân tích sẽ xác định tệp cấu hình ánh xạ theo cách thức nào, từ đó sẽ có cách phân tích tương ứng. Các nút thể hiện cho bảng, cột của CSDL được tạo và thêm vào cây cấu trúc hiện tại. Cùng với đó, các nút này đượ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 CSDL. Hibernate hiện có hai cách thức tương tác với CSDL là dùng phương thức được xây dựng sẵn có sử dụng thực thể hoặc sử dụng câu truy vấn. Do đó bộ phân tích Hibernate sẽ chia ra làm hai phần nhỏ là phân tích hàm tương tác thực thể và phân tích câu truy vấn. Hibernate đã xây dựng sẵn các phương thức tương tác với CSDL bằng thực thể, danh sách các phương thức cho trong Bảng 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” ví dụ như “sample.entity.Consumer”. Đi kèm với tên thực thể là đối tượng Java chứa các giá trị cần gửi cho CSDL, hoặc chỉ cần gửi đối tượng Java là đủ. 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ác 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 thực kiểu thực thể của tham số. 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ử 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 nền tảng Java Servlet. 3.1 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.  Web browser: 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. 8
 Web server: 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 form 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, nhận dữ liệu. Webserver có nhiệm vụ trung chuyển dữ liệu và điều hướng đến Servlet Container để thực các tác vụ tương ứng với yêu cầu từ phía client. Servlet Container gọi init () method của servlet để khởi tạo (được gọi một lần khi servlet được load lần đầu tiên. Container gọi service () method 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ả yêu cầu. 3.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ó. Các bước phân tích phụ thuộc cho Java Servlet được mô tả như trong hình dưới. Đầu tiên, bộ phân tích sẽ tìm đến tệp cấu hình web.xml và các annotation, từ đó sẽ tìm được các ánh xạ từ các Java Servlet và các URL tương ứng. Nếu như không tìm được Java Servlet nào thì quá trình phân tích sẽ dừng lại. Mã nguồn 1. Mã cấu hình web.xml trong Java Servlet 9
Mã nguồn 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 và liên hệ bằng . Như vậy, có một phụ thuộc servlet ánh xạ từ class Java tại đường dẫn Controller/SANPHAM_CTR tới URL Sanpham.do. Mã nguồn 2. Mã Annotation trong Java Servlet Mã nguồn 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. 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 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. Phụ thuộc trong mã nguồn giao diện 10
Mã nguồn trên thể hiện sự phụ thuộc từ các thẻ tới các tệp với các đường dẫn templates/user/sidebar.jsp, templates/user/navbar.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 4. Phụ thuộc giữa mã nguồn Java và mã nguồn giao diên Mã nguồn trên 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 class servlet có ánh xạ với URL LoginService. 3.3 Phương pháp 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 ở module 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 retest đối với sự thay đổi ở các module 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. 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 11
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ác 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.3 Quy trình kiểm thử hồi quy dựa trên phương pháp đề xuất 3.4 Quá trình kiểm thử hồi quy là việc kiểm thử lại tất cả các thành phần thay đổi cũng như các thành phần bị ảnh hưởng. Luận văn đề xuất một phương pháp kiểm thử hồi quy dựa trên kết quả của công cụ JCIA. Đầu tiên, mã nguồn dự án Java EE phiên bản trước 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 12
sửa đổi sẽ được đưa vào công cụ JCIA để 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 để đưa vào các công cụ kiểm thử để thực hiện kiểm thử hồi quy như CTF4Junit (công cụ kiểm thử đơn vị cho hàm Java), Ranorex (công cụ kiểm thử giao diện). 4. Thực nghiệm và triển khai 4.1 Giới thiệu về công cụ JCIA mở rộng Công cụ nhận đầu vào là mã nguồn dự án Java EE sử dụng nền tảng Java Servlet dưới dạng file .zip. Sau khi chọn tệp đưa vào hệ thống, một đường dẫn tới mã nguồn Java đang cần hệ thống phân tích, hệ thống luôn hiển thị gợi ý tự động là src/java (đường dẫn mặc định của các project tạo bởi NetBeans). Việc lựa chọn bộ phân tích phụ thuộc sẽ giúp công cụ tập trung vào phân tích chuyên biệt cho một công nghệ cụ thể. Hệ thống hiện tại có thể phân tích phụ thuộc cho Struts2, JavaCore, Hibernate. Ngoài ra hệ thống cũng có thể hiển thị tất cả các phụ thuộc hoặc không hiển thị phụ thuộc nào. Sau khi tải mã nguồn dự án thành công, công cụ sử dụng các phương pháp phân tích ảnh hưởng giữa các thành phần đặc biệt là các thành phần giao diện được mở rộng trong công cụ để tìm ra sự phụ thuộc giữa các tệp giao diện với nhau. Để so sánh hai phiên bản mã nguồn dự án, một phiên bản mới của mã nguồn dự án kèm một tệp (info.txt) chứa thông tin các tệp bị thay đổi được tải lên cùng với việc lựa chọn mức độ phân tích phụ thuộc tại Impact Level. Công cụ sẽ thực hiện phân tích ảnh hưởng thay đổi cho phiên bản mới. Hệ thống sẽ tự động tìm những tệp được liệt kê và thực hiện quá trình phân tích ảnh hưởng. Sau đó, công cụ sử dụng một phương pháp phân loại kiểm thử hồi quy từ các tập thay đổi và ảnh hưởng, từ đó có thể xuất dữ liệu phân tích ra tệp Excel, PDF, CSV để sử dụng làm đầu vào cho các công cụ kiểm thử. 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 13
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. 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. - 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 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. 14
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. - 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ụ. 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 đượ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. 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. - 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à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. 15
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. 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. 16
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 dưới đây 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ị. 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. 17
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 dưới đây. 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, 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, 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. 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 18
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 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. 19