Nội dung đề tài ngoài phần mở đầu và kết luận, luận văn được tổ chức thành các chương như sau. Chương 1 khái quát khái niệm kiến trúc hướng dịch vụ, công nghệ trục tích hợp, quy trình tích hợp, chuyển giao liên tục; chương 2 đưa ra thực trạng, khó khăn của kiểm thử trên hệ thống sử dụng công nghệ trục tích hợp, phân tích các vấn đề cần giải quyết; chương 3 đưa ra các bước áp dụng thực tế của quy trình với một ứng dụng đơn giản xây dựng dựa trên MuleESB. Phần tổng kết tóm tắt kết quả đạt được, các điểm hạn chế và định hướng phát triển trong tương lai.
ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ ĐINH THỊ LOAN TÌM HIỂU VÀ XÂY DỰNG CƠNG CỤ HỖ TRỢ KIỂM THỬ CÁC HỆ THỐNG HƯỚNG DỊCH VỤ Ngành: Công nghệ thông tin Chuyên ngành: Kỹ thuật phần mềm Mã số: 60480103 TÓM TẮT LUẬN VĂN THẠC SĨ NGÀNH CÔNG NGHỆ THÔNG TIN Hà Nội – 2018 ii MỤC LỤC MỤC LỤC ii DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ .v MỞ ĐẦU CHƯƠNG 1.CƠ SỞ LÝ THUYẾT VÀ CÁC KHÁI NIỆM LIÊN QUAN 1.1.Kiến trúc hệ thống 1.1.1.Kiến trúc hướng dịch vụ 1.1.2.Cơng nghệ trục tích hợp 1.1.3.Xây dựng ứng dụng trục tích hợp dựa tảng MuleESB .5 1.2.Tích hợp triển khai liên tục 1.2.1.Tích hợp liên tục 1.2.2.Chuyển giao liên tục 1.2.3.Một số công cụ hỗ trợ 1.3.Kiểm thử 1.3.1.Các loại kiểm thử 1.3.2.Các cấp độ kiểm thử 1.3.3.Công cụ hỗ trợ kiểm thử ứng dụng API .9 CHƯƠNG 2.KHÓ KHĂN VÀ ĐỀ XUẤT GIẢI PHÁP .11 2.1.Khó khăn .11 2.2.Quy trình kiểm thử ứng dụng ESB 12 2.3.Xây dựng công cụ AsenAPIDriver 13 CHƯƠNG THỰC NGHIỆM 15 3.1.Ứng dụng MuleESB mẫu .15 3.2.Tích hợp quy trình kiểm thử 16 3.3.Sinh mã kiểm thử 16 3.4.Kết 17 KẾT LUẬN 19 TÀI LIỆU THAM KHẢO 21 STT iii DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT Tên viết tắt Từ/Cụm từ API Application Programming Interface CD Continuous Deployment CI Continuous Integration DVCS Distributed Version Control System EAI Enterprise Application Intergration ERP Enterprise resource planning ESB Enterprise Service Bus IB Internet Banking QA Quality Assurance 10 SOA Service Oriented Architecture 11 TCK Test Compatibility Kit 12 UAT User Acceptance Testing 13 WSDL Web Services Description Language v DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ Hình 1.2: Kiến trúc hệ thống sử dụng cơng nghệ trục tích hợp Hình 1.4: Kiến trúc MuleESB [6] Hình 2.1: Quy trình kiểm thử ứng dụng ESB 12 Hình 3.2: Cách phân chia thư mục ứng dụng MuleESB 15 Hình 3.11: Dữ liệu đầu vào 16 Hình 3.12: Dữ liệu đầu mong đợi 17 Hình 3.14: Kết chạy ca kiểm thử 17 Hình 3.15: Chi tiết ca kiểm thử bị thất bại 17 MỞ ĐẦU Kiến trúc phần mềm (Software Architecture) đề cập đến cấu trúc mức cao hệ thống phần mềm với quy tắc tài liệu việc tạo nên cấu trúc Mỗi kiến trúc bao gồm phần tử phần mềm, mối quan hệ chúng đặc tính phần tử quan hệ Thực trạng nhiều hệ thống phần mềm xây dựng phức tạp, chi phí phát triển bảo trì cao, đặc biệt với hệ thống phần mềm cao cấp Hàng chục năm qua, nhiều đề tài nghiên cứu kiến trúc phần mềm cố gắng giải vấn đề Tuy nhiên, độ phức tạp tiếp tục tăng vượt khả xử lý kiến trúc truyền thống Những năm gần đây, kiến trúc hướng dịch vụ (Service-oriented Architecture - SOA) lên giải pháp tối ưu cho tốn Đặc điểm SOA tách rời phần giao tiếp/gọi dịch vụ với phần thực dịch vụ Kiến trúc hướng dịch vụ (SOA) hướng tiếp cận việc tích hợp ứng dụng hệ thống, giải pháp cung cấp cách tiếp cận linh hoạt cho kiến trúc hệ thống phần mềm cho doanh nghiệp Hệ thống xây dựng theo kiến trúc SOA có tính mở rộng cao khả sử dụng lại tốt Các dịch vụ hệ thống công khai internet thông qua giao diện API giúp cho việc kết nối ứng dụng dễ dàng Bên yêu cầu gửi thông điệp tới bên nhận nhận lại phản hồi mà không cần quan tâm đến trình xử lý bên bên nhận Cơng nghệ trục tích hợp (Enterprise Service Bus - ESB) loại kiến trúc phần mềm, chứa tập luật nguyên tắc cho việc tích hợp nhiều ứng dụng khác (về tảng, ngôn ngữ ) vào hay nhiều hệ thống Công nghệ trục tích hợp cầu nối ứng dụng, dịch vụ kiến trúc hướng dịch vụ Áp dụng cơng nghệ trục tích hợp giúp cho thành phần hệ thống có tính tái sử dụng cao, chi phí cho việc phát triển tích hợp ứng dụng hay ứng dụng bên thứ ba thấp Tuy nhiên, tích hợp nhiều ứng dụng khác hệ thống làm cho trình kiểm thử trở nên khó khăn, phức tạp yêu cầu kiểm thử trở nên khắt khe Công nghệ trục tích hợp kết nối nhiều ứng dụng với nhau, kể ứng dụng doanh nghiệp, vậy, trình kiểm thử hệ thống phải xem xét bao quát nhiều yếu tố: nhà cung cấp dịch vụ, thành phần dịch vụ, người dùng dịch vụ, giao tiếp thành phần 2 Q trình kiểm thử hệ thống sử dụng cơng nghệ trục tích hợp tập trung vào giao tiếp thành phần tính có trao đổi tích hợp thơng tin, hay nói cách khác API, vậy, khơng thể thực phần kiểm thử giao diện người dùng Ngồi ra, q trình kiểm thử cần thực song song, tự động hóa với q trình phát triển, tích hợp thành phần vào hệ thống, giúp rút ngắn thời gian tiết kiệm chi phí Hiện nay, trình kiểm thử hệ thống sử dụng kiến trúc trục tích hợp gặp phải khó khăn xây dựng môi trường kiểm thử, sức ép thời gian phát triển ngắn, công cụ hỗ trợ chưa nhiều phải phí Việc dẫn tới quy trình kiểm thử chưa tự động hóa, quy trình bị rút ngắn bỏ qua, xảy lỗi ứng dụng hệ thống đòi hỏi việc tìm lỗi sửa đổi nhiều ứng dụng lúc, gây thời gian tốn tài nguyên, lỗi khơng kiểm sốt chặt chẽ Do đó, vấn đề cần giải quy trình tích hợp có nhiều thay đổi diễn liên tục hệ thống thời gian ngắn Ở toán này, quy trình tích hợp liên tục chuyển giao liên tục giải pháp phù hợp Tích hợp liên tục quy trình phát triển phần mềm đòi hỏi thay đổi hệ thống phải kiểm tra tự động, thông báo kết đến đội phát triển, trước thay đổi đưa lên môi trường triển khai thực tế theo quy trình triển khai liên tục Vì vậy, luận văn nghiên cứu, tìm hiểu, đề xuất quy trình kiểm thử tự động ứng dụng xây dựng công nghệ trục tích hợp cụ thể thư viện MuleESB, áp dụng quy trình tích hợp liên tục chuyển giao liên tục Đồng thời luận văn đưa cơng cụ hỗ trợ cho quy trình, giải vấn đề tự động hóa sinh ca kiểm thử, giúp rút ngắn thời gian kiểm thử Ngoài phần mở đầu kết luận, luận văn tổ chức thành chương sau Chương khái quát khái niệm kiến trúc hướng dịch vụ, cơng nghệ trục tích hợp, quy trình tích hợp, chuyển giao liên tục, cơng cụ hỗ trợ, lợi ích việc sử dụng cơng nghệ trục tích hợp việc phát triển ứng dụng doanh nghiệp số khái niệm liên quan đến kiểm thử ứng dụng Chương đưa thực trạng, khó khăn kiểm thử hệ thống sử dụng cơng nghệ trục tích hợp, phân tích vấn đề cần giải Chương đưa quy trình kiểm thử hệ thống công cụ tự động sinh mã nguồn kiểm thử hỗ trợ quy trình trình bày Chương đưa bước áp dụng thực tế quy trình với ứng dụng đơn giản xây dựng dựa MuleESB Phần tổng kết tóm tắt kết đạt được, điểm hạn chế định hướng phát triển tương lai 4 CHƯƠNG CƠ SỞ LÝ THUYẾT VÀ CÁC KHÁI NIỆM LIÊN QUAN Ngày nay, việc phát triển phần mềm trở nên phức tạp khó kiểm sốt xuất nhiều công nghệ tạo nên môi trường phát triển tảng không đồng nhất, nhu cầu trao đổi, chia sẻ tương tác ứng dụng ngày tăng Trong năm gần đây, việc phát triển hệ thống phần mềm dần chuyển sang xu hướng dịch vụ đó, cơng nghệ trục tích hợp giải pháp sử dụng để cung cấp cổng giao tiếp thành phần hệ thống hướng dịch vụ Tuy nhiên vấn đề đặt cần đảm bảo khả kiểm sốt lỗi tốt song song với q trình phát triển mà lúc có nhiều thành phần tích hợp thêm Những kỹ thuật kiểm thử quy trình tích hợp, triển khai liên tục cần áp dụng để hỗ trợ quy trình kiểm thử Để giúp làm rõ nội dung chương tiếp theo, chương giới thiệu khái niệm kiến trúc hướng dịch vụ, công nghệ trục tích hợp, giới thiệu tảng trục tích hợp MuleSoft phát triển - MuleESB, quy trình tích hợp, triển khai liên tục, số cơng cụ hỗ trợ khái niệm kiểm thử 1.1 Kiến trúc hệ thống 1.1.1 Kiến trúc hướng dịch vụ Kiến trúc hướng dịch vụ (Service Oriented Architecture - SOA) [1] [2] chiến lược xây dựng kiến trúc phần mềm Đây q trình tích hợp thành phần độc lập kết nối với cách linh động thông qua giao thức định nghĩa sẵn, tính tái sử dụng cao SOA giúp cho cơng việc phát triển phần mềm trở nên dễ dàng nhanh chóng Khái niệm dịch vụ hệ thống SOA hiểu chức xác định rõ ràng, khép kín khơng phụ thuộc vào ngữ cảnh trạng thái dịch vụ khác 1.1.2 Cơng nghệ trục tích hợp Cơng nghệ trục tích hợp (Enterprise Service Bus - ESB) [4] [5] kiến trúc phần mềm, chứa tập luật nguyên tắc cho việc tích hợp nhiều ứng dụng khác tảng, ngôn ngữ vào hay nhiều hệ thống Xây dựng hệ thống tảng trục tích hợp cho doanh nghiệp từ đầu đòi hỏi nhiều thời gian, công sức tiền bạc Hệ thống dịch vụ sử dụng cơng nghệ trục tích hợp có tính tái sử dụng cao, chi phí cho việc phát triển tích hợp ứng dụng ngồi hay ứng dụng bên thứ ba thấp Hình 1.1: Kiến trúc hệ thống sử dụng cơng nghệ trục tích hợp 1.1.3 Xây dựng ứng dụng trục tích hợp dựa tảng MuleESB Mule framework Mule [7] dự án mã nguồn mở cung cấp giải pháp tổng thể đủ lớn để xây dựng nên hệ thống SOA Mule cung cấp đầy đủ tính tích hợp cần thiết cho doanh nghiệp Mule tảng tích hợp dựa Java, cho phép nhà phát triển kết nối ứng dụng với cách nhanh chóng dễ dàng, giúp ứng dụng trao đổi liệu với Mule cho phép tích hợp hệ thống có, cơng nghệ khác mà ứng dụng sử dụng, bao gồm JMS, dịch vụ Web, JDBC, HTTP, nhiều MuleESB thư viện cung cấp MuleSoft cho phép phát triển ứng dụng ESB Việc triển khai ứng dụng phân tán môi trường mạng giúp cho việc kết nối ứng dụng dễ dàng, nhiên lại gây khó khăn giao tiếp ứng dụng việc khác biệt công nghệ, tảng MuleESB giải vấn đề việc cung cấp trục tích hợp có chức nhận định tuyến thông điệp ứng dụng với Kiến trúc MuleESB Hình 1.2 mơ tả kiến trúc MuleESB Trong luồng xử lý, chuyển đổi (Transformer) có vai trò chuyển đổi định dạng thông điệp thành loại định dạng phù hợp với nơi nhận thông điệp, trước xử lý định tuyến Các chuyển đổi (Transformer) chìa khố để trao đổi liệu, liệu chuyển đổi cần thiết thay chuyển đổi thành định dạng chung, thơng điệp gửi qua kênh truyền khác Hình 1.2: Kiến trúc MuleESB [6] Việc tách biệt luồng logic nghiệp vụ cách thức truyền nhận liệu cho phép mở rộng kiến trúc hệ thống dễ dàng tuỳ biến luồng nghiệp vụ Khi thông điệp gửi ứng dụng, MuleESB tiếp nhận thông điệp, chuyển đổi định dạng thông điệp, phân loại điều hướng sang dịch vụ nhận cần thiết việc sử dụng chuyển đổi (Transformer) Ứng dụng thực tế sử dụng MuleESB MuleESB sử dụng rộng rãi để phát triển ứng dụng ESB, đặc biệt ngành tài chính, ngân hàng Ví dụ sau trình bày hệ thống ngân hàng điện tử sử dụng MuleESB để phát triển ứng dụng ESB, giúp giảm thiểu chi phí phát triển bảo trì, nâng cao chất lượng sản phẩm Internet Banking (IB) hệ thống ngân hàng điện tử dành cho khách hàng doanh nghiệp sử dụng dịch vụ VietinBank như: chuyển tiền, chi lương, tốn chuỗi hóa đơn, nộp ngân sách nhà nước, báo cáo Hệ thống bao gồm ứng dụng phía khách hàng, ứng dụng quản trị ngân hàng hệ thống lõi ngân hàng (core banking) Các ứng dụng hệ thống xây dựng tảng khác NET, java, M… chí có ứng dụng xây dựng tảng công nghệ cũ Visual Basic Kiến trúc hệ thống Internet Banking xây dựng theo mơ hình kết nối điểm-điểm (point-to-point) Với kiến trúc này, hệ thống bao gồm nhiều kết nối ứng dụng khác Việc dẫn đến trình bảo trì mở rộng hệ thống gặp nhiều khó khăn, khả kiểm soát lỗi Sau phát triển sử dụng lớp ESB thực điều hướng thông điệp xử lý kết hợp với quy trình nghiệp vụ để giảm thiểu việc phát triển chồng chéo nhiều chức giống nhau, đồng thời giảm thiểu số lượng kết nối ứng dụng 1.2 Tích hợp triển khai liên tục 1.2.1 Tích hợp liên tục Theo định nghĩa Martin Fowler [9], tích hợp liên tục – Continuous Intergration phương pháp phát triển phần mềm đòi hỏi lập trình viên nhóm tích hợp ứng dụng thường xuyên Mỗi ngày, thành viên phải theo dõi phát triển cơng việc họ lần Việc nhóm khác kiểm tra tự động, nhóm tiến hành kiểm thử truy hồi để phát lỗi nhanh Các nhóm phát triển sử dụng phương pháp Agile thường dùng tích hợp liên tục để đảm bảo mã nguồn tồn dự án ln dịch chạy 1.2.2 Chuyển giao liên tục Trong tích hợp liên tục quy trình để dịch kiểm thử tự động, việc chuyển giao liên tục (Continuous Delivery) cao mức, triển khai ứng dụng sau kiểm thử thành công lên môi trường kiểm thử staging Chuyển giao liên tục cho phép lập trình viên tự động hóa phần kiểm thử bên cạnh việc sử dụng kiểm thử đơn vị để kiểm tra phần mềm qua nhiều thước đo trước triển khai cho khách hàng Những kiểm thử bao gồm: kiểm thử giao diện, kiểm thử tải, kiểm thử tích hợp kiểm thử giao diện API 1.2.3 Một số công cụ hỗ trợ Github Git Hệ thống quản lý phiên phân tán (Distributed Version Control System - DVCS) Github số kho quản lý mã nguồn phân tán phổ biến Maven Maven công cụ quản lý mã nguồn thư viện phụ thuộc cách tự động, sử dụng cho ứng dụng tảng Java, ngồi có tảng khác C#, Ruby, Scala… Được phát triển với mục đích tương tự Apache Ant có khái niệm cách hoạt động khác, Maven hỗ trợ việc tự động hóa trình quản lý dự án phần mềm như: khởi tạo, biên dịch, kiểm thử, đóng gói triển khai sản phẩm Jenkins Jenkins thư viện mã nguồn mở cho phép quản lý mã nguồn triển khai cách tự động, dự án giai đoạn phát triển Nó giúp khép kín quy trình phát triển phần mềm cách tự động theo mơ hình Agile nói chung việc tích hợp liên tục nói riêng Jenkins phát triển tảng Java, hỗ trợ nhiều tảng khác Windows, Linux, Mac OS, Solaris… kết hợp nhiều cơng cụ khác 1.3 Kiểm thử Kiểm thử phần mềm hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần mềm môi trường dự định triển khai phần mềm đó, nhằm cung cấp cho bên liên quan thông tin chất lượng sản phẩm hay dịch vụ phần mềm Mục đích kiểm thử phần mềm tìm lỗi hay khiếm khuyết nhằm đảm bảo chương trình hoạt động đạt hiệu tối đa “Kiểm thử phần mềm trình thực thi chương trình với mục đích tìm lỗi” [11] 1.3.1 Các loại kiểm thử Kiểm thử hộp đen Kiểm thử hộp đen xem chương trình hộp đen, kiểm thử viên không cần quan tâm đến việc cấu trúc hoạt động bên chương trình, thay vào đó, kiểm thử viên tập trung tìm đặc điểm mà chương trình thực khơng đặc tả Các ca kiểm thử sinh từ đặc tả người dùng (user requirement) chương trình Kiểm thử hộp trắng Kiểm thử hộp trắng chiến lược kiểm thử khác, trái ngược với kiểm thử hộp đen Kiểm thử hộp trắng cho phép khảo sát cấu trúc bên chương trình Chiến lược xuất phát từ liệu kiểm thử kiểm thử tính logic chương trình Người kiểm thử viên (thường lập trình viên) truy cập vào cấu trúc liệu giải thuật với mã nguồn chương trình Kiểm thử hộp xám Kiểm thử hộp xám đòi hỏi phải có truy cập tới cấu trúc liệu giải thuật bên cho mục đích thiết kế ca kiểm thử, kiểm thử mức người sử dụng hay mức hộp đen 1.3.2 Các cấp độ kiểm thử Kiểm thử đơn vị Kiểm thử đơn vị (Unit Test) việc kiểm thử thành phần cụ thể chương trình, lập trình viên thực Một đơn vị phương thức, thủ tục hay lớp chương trình, thành phần có kích thước nhỏ hoạt động đơn giản Do đó, kiểm thử đơn vị khơng có phức tạp, kết lỗi xảy dễ dàng khắc phục Kiểm thử tích hợp Kiểm thử tích hợp (Intergration Test) kết hợp thành phần ứng dụng kiểm thử ứng dụng hoàn thành Trong kiểm thử đơn vị kiểm tra thành phần đơn vị riêng lẻ kiểm thử tích hợp kết hợp chúng lại với kiểm tra chức giao tiếp chúng Kiểm thử hệ thống Kiểm thử hệ thống bắt đầu sau tích hợp thành cơng thành phần hệ thống với Ở mức độ này, kiểm thử viên trọng vào việc đánh giá hoạt động, thao tác, độ tin cậy yêu cầu khác liên quan đến chất lượng toàn hệ thống yêu cầu phi chức Kiểm thử chấp nhận Thông thường, sau giai đoạn kiểm thử hệ thống kiểm thử chấp nhận (Acceptance Test) Bước khách hàng đưa yêu cầu thực Q trình kiểm thử có ý nghĩa quan trọng việc xác định xem chương trình có đáp ứng mong đợi khách hàng hay không 1.3.3 Công cụ hỗ trợ kiểm thử ứng dụng API Quá trình kiểm thử hệ thống sử dụng kiến trúc ESB chủ yếu tập trung vào giao tiếp thành phần hệ thống Vì vậy, quy trình kiểm thử không trọng vào phần kiểm thử giao diện người dùng mà tập trung vào API thành phần hệ thống Hiện nay, công cụ hỗ trợ kiểm thử API phổ biến SoapUI Postman 10 Postman Postman công cụ cho phép kết nối với API, đặc biệt ứng dụng viết theo giao thức RESTful Lập trình viên thực truyền trực tiếp tham số dạng text, json, xml, html… thay việc phải viết đoạn mã nguồn nh SOAPUI Ngồi Postman, SOAPUI [13] cơng cụ hỗ trợ kiểm thử API sử dụng phổ biến Đây cơng cụ kiểm thử có tảng mã nguồn mở hàng đầu cho phép kiểm thử viên thực loại kiểm thử như: kiểm thử chức năng, hồi quy, thử tải cách tự động Web API khác JUnit JUnit thư viện mã nguồn mở sinh nhằm hỗ trợ việc viết chạy mã nguồn kiểm thử ngôn ngữ Java Được phát triển Erich Gamma Kent Beck, JUnit bước tiến hóa quan trọng phát triển hướng kiểm thử (Test Driven Development) MUnit MUnit thư viện hỗ trợ kiểm thử ứng dụng Mule, cho phép xây dựng ca kiểm thử tự động để kiểm thử việc tích hợp API ứng dụng ESB phát triển tảng Mule Như vậy, thấy, Postman tuý cung cấp khả thực lời gọi đến API ứng dung, SoapUI cơng cụ nâng cao tập trung vào tạo ca kiểm thử, tích hợp với cơng cụ hỗ trợ khác Tuy nhiên tính xuất báo cáo ca kiểm thử chạy lại phiên phí cơng cụ chưa có khả tự sinh ca kiểm thử Trong đó, MUnit túy thư viện hỗ trợ tạo ca kiểm thử cho ứng dụng xây dựng dựa MuleESB, JUnit tảng hỗ trợ chạy ca kiểm thử viết Java Những công cụ sử dụng đơn lẻ sinh ca kiểm thử, vấn đề tự động hóa chưa giải cách tối ưu 11 CHƯƠNG KHÓ KHĂN VÀ ĐỀ XUẤT GIẢI PHÁP Các giải pháp tích hợp tạo nên xương sống hệ thống dịch vụ với tiến trình xử lý liệu thời gian thực Tuy nhiên, giải pháp tích hợp thường kiểm thử bỏ qua kiểm thử, có làm thủ cơng khơng mang tính thường xun Tình trạng xuất phát từ nhiều nguyên nhân Chương giới thiệu phân tích khó khăn gặp phải đưa đề xuất giải pháp khó khăn 2.1 Khó khăn Kiến trúc trục tích hợp cung cấp kết nối thành phần khác biệt hệ thống hệ thống khác thông qua hạ tầng thông tin chung Kiến trúc bao gồm số lượng lớn thành phần tính Để kiểm thử hiệu hệ thống sử dụng kiến trúc trục tích hợp, tất thành phần tính hệ thống phải bao quát đến Tuy nhiên thành phần hệ thống lại xây dựng từ ngôn ngữ khác nhau, chí nằm hạ tầng cơng ty khác dẫn đến khó khăn nhiều trường hợp việc giả lập môi trường kiểm thử giống với mơi trường triển khai thực tế Ngồi ra, hệ thống truyền tin có chế gửi tin bất đồng bộ, gặp phải vấn đề tính tốn song song, vấn đề khó kiểm thử phát Một khó khăn khác mơi trường kiểm thử sở hạ tầng Khi thành phần hệ thống nhiều có yêu cầu cao phần cứng số lượng lớn thực thể hay nhiều dịch vụ, việc đáp ứng môi trường kiểm thử giống môi trường triển khai thực tế khó khăn với phần lớn đội phát triển Với đặc điểm kiến trúc trục tích hợp cấu thành từ nhiều thành phần, ta cần chiến lược kiểm thử bao quát giao tiếp nội hệ thống Chính vậy, ta cần phải thực kiểm thử riêng lẻ (kiểm thử đơn vị) thành phần nhiều tốt nhằm tránh lỗi gây thành phần thành phần kiểm thử ca kiểm thử tích hợp Sau đảm bảo chức hoạt động riêng biệt thành phần hoạt động đúng, ta tiến hành kiểm thử tích hợp thành phần Q trình lặp lại có thay đổi thành phần (kiểm thử hồi quy) 12 2.2 Quy trình kiểm thử ứng dụng ESB Hình 2.1 thể quy trình đề xuất kiểm thử tự động cho ứng dụng ESB Hình 2.1: Quy trình kiểm thử ứng dụng ESB Quy trình xây dựng hướng đến theo quy trình tích hợp liên tục Để kích hoạt quy trình, cơng cụ Jenkins, sử dụng kích (trigger) có chức kích hoạt q trình chạy tự động có thay đổi kho mã nguồn SVN git Khi có thay đổi mã nguồn, Jenkins thực lấy mã nguồn máy chủ gọi trình sinh mã kiểm thử Sau sinh mã nguồn kiểm thử thành công, Jenkins gọi trình biên dịch, chạy ca kiểm thử, đóng gói triển khai ứng dụng Q trình biên dịch đóng gói ứng dụng thực thư viện Maven, thư viện mã nguồn mở để quản lý thư viện phụ thuộc phần mềm, cung cấp khả build đóng gói phần mềm Maven kích hoạt q trình biên dịch mã nguồn, kiểm thử chức kiểm thử đơn vị cho ứng dụng Nếu trình kiểm thử thành cơng, Maven tự động đóng gói ứng dụng lên thư mục cài đặt sẵn Từ đó, cơng cụ Jenkins triển khai ứng dụng lên máy chủ Để đảm bảo quy trình diễn tự động luận văn đề xuất thêm việc xây dựng công cụ thực sinh mã nguồn kiểm thử chức cho ứng dụng xây dựng dựa tảng MuleESB, cơng cụ có tên AsenAPIDriver AsenAPIDriver xây dựng tảng Java, thực 13 quét mã nguồn danh sách ca kiểm thử, từ sinh mã nguồn kiểm thử tự động cho ứng dụng Như vậy, toàn trình kiểm thử triển khai thực tự động việc tích hợp cơng cụ mã nguồn mở: Jenkins, Maven, JUnit, MUnit, Git công cụ sinh mã kiểm thử tự động AsenAPIDriver 2.3 Xây dựng công cụ AsenAPIDriver AsenAPIDriver xây dựng tảng Java Mục tiêu thư viện sinh ca kiểm thử tự động cho ứng dụng xây dựng dựa tảng MuleESB Các ứng dụng xây dựng dựa MuleESB định nghĩa khối, luồng tệp cấu hình xml Trong thành phần tương ứng với thẻ tệp xml Dựa thơng tin thẻ này, ta lấy thông tin thành phần ứng dụng Dựa cấu trúc tệp cấu hình xml, ứng dụng AsenAPIDriver có chức đọc luồng xử lý tập tin cấu hình ứng dụng MuleESB, kết hợp với danh sách ca kiểm thử, thực sinh mã nguồn kiểm thử Việc chạy ca kiểm thử qua AsenAPIDriver quản lý thực cách cấu hình qua Maven Quá trình kiểm thử kết hợp sử dụng JUnit hỗ trợ việc quản lý chiết xuất báo cáo kiểm thử Các bước thực sinh mã nguồn kiểm thử tự động: Bước 1: Với ứng dụng, kể ứng dụng web hay ứng dụng máy chủ, ln có tập tin cấu hình khởi tạo thời điểm khởi động ứng dụng, đây, ứng dụng xây dựng MuleE tập tin có tên muledeploy.properties Tập tin cấu hình nơi chứa luồng xử lý nghiệp vụ ứng dụng Bước 2: Từ tập tin định nghĩa luồng xử lý (muleesbbegin.xml), công cụ AsenAPIDriver thực đọc xác định luồng, tên luồng, đường dẫn gọi vào luồng cụ thể (xem hình 2.8) Bước 3: Với luồng tương ứng, có thẻ xml với thuộc tính quy định đường dẫn gọi tới chức (xem hình 2.9) Từ cơng cụ AsenAPIDriver xác định đọc tập tin dạng xml, csv excel chứa ca kiểm thử Các tập tin lưu trữ sẵn thư mục tài nguyên kiểm thử (test/resources) ứng dụng 14 Bước 4: Trước sinh mã nguồn kiểm thử tự động, công cụ thực dọn dẹp thư mục mã nguồn kiểm thử Bước 5: Từ luồng xác định danh sách ca kiểm thử, công cụ thực sinh mã nguồn kiểm thử tương ứng Mỗi luồng có tập tin mã nguồn kiểm thử, số lượng phương thức cách thức chạy ca kiểm thử phụ thuộc vào số lượng ca kiểm thử, tuỳ vào luồng cụ thể Mã nguồn kiểm thử sinh AsenAPIDriver mã nguồn sử dụng MUnit để gọi luồng truyền vào tham số cho trước Kết trả so sánh với kết đầu mong đợi lấy từ danh sách ca kiểm thử Các đoạn mã nguồn sử dụng MUnit thích ký pháp JUnit, trình chạy đoạn mã nguồn kiểm thử cho kết hình IDE xuất thành báo cáo Quá trình sinh mã tự động xảy có thay đổi kho chứa mã nguồn việc thay đổi mã nguồn có thực làm ảnh hưởng đến kết trả chương trình hay khơng Ngồi ra, q trình kiểm thử thực luồng xử lý khơng quan tâm đến việc luồng có ảnh hưởng hay khơng Mỗi có thay đổi luồng xử lý nghiệp vụ (bussiness) mà có mang lại thay đổi kết đầu lập trình viên cần cập nhật lại tập tin chứa danh sách ca kiểm thử cho phù hợp với luồng xử lý Tại chương này, tác giả đề xuất quy trình kiểm thử cho ứng dụng ESB áp dụng quy trình tích hợp chuyển giao liên tục Tác giả giới thiệu chi tiết cách thức hoạt động công cụ AsenAPIDriver tự động sinh mã kiểm thử, vai trò cơng cụ quy trình Chương tiếp theo, luận văn tiến hành đánh giá quy trình đề xuất dựa ứng dụng MuleESB cụ thể 15 CHƯƠNG THỰC NGHIỆM Trong chương này, luận văn xây dựng hệ thống phần mềm nhỏ dựa vào tảng MuleESB ví dụ Từ ứng dụng đó, dựa vào quy trình thực phần trước, luận văn đưa cách thức cài đặt, sinh mã kiểm thử tích hợp liên tục hồn chỉnh Thơng qua phần cài đặt triển khai, luận văn đánh giá kết đạt điểm cần phải bổ sung 3.1 Ứng dụng MuleESB mẫu Để kiểm tra thực nghiệm quy trình kiểm thử chương trước, luận văn xây dựng ứng dụng ESB tảng MuleESB Ứng dụng có tên IBESB, ứng dụng ngân hàng điện tử, có chức cung cấp đầu dịch vụ (end-point) cho ứng dụng phía ngồi sau: tra cứu thơng tin doanh nghiệp, tra cứu thông tin người dùng, chuyển khoản hệ thống, vấn tin tài khoản Cách thức tổ chức mã nguồn ứng dụng mẫu Mã nguồn ứng dụng mẫu chia thành gói (package), thư mục tương ứng với mã nguồn mẫu, mã nguồn ca kiểm thử, Hình 3.1 Hình 3.1: Cách phân chia thư mục ứng dụng MuleESB Theo đó, mã nguồn ứng dụng quản lý kho quản lý mã nguồn github đường dẫn https://github.com/Loandt1/TestMuleESB.git Các thư viện phụ thuộc ứng dụng quản lý maven 16 3.2 Tích hợp quy trình kiểm thử Bước 1: Tại hình chính, chọn “New Item” Bước 2: Chọn tên ứng dụng loại ứng dụng, đây, ta chọn “Maven Project” hình tạo Bước 3: nhập thơng tin cấu hình cho ứng dụng bao gồm: kho mã nguồn, môi trường dịch, bước dịch… Tại hình cấu hình, Jenkins cho phép cấu hình thêm câu lệnh để hỗ trợ trình dịch qua shell, Windows batch command Tại đây, ta chọn “window command shell” để tích hợp với q trình sinh mã nguồn kiểm thử tự động từ thư viện AsenAPIDriver Bước 4: Sau thực lưu cấu hình, ta chọn “Build now” để thực chạy tác vụ Jenkin thực lấy mã nguồn cuối máy từ Github Trước biên dịch mã nguồn, Jenkins tự động gọi câu lệnh sinh mã nguồn từ thư viện AsenAPIDriver, sau đó, sử dụng maven-plugin thực đóng gói triển khai ứng dụng lên kho chứa Quá trình đóng gói maven bao gồm biên dịch mã nguồn, chạy ca kiểm thử, đóng gói ứng dụng đẩy lên kho chứa tập trung theo cấu hình định sẵn Ngồi bước trình bày trên, có nhiều cách để tạo công việc xây dựng, tùy chọn có sẵn nhiều, điều khiến Jenkins trở thành công cụ triển khai liên tục 3.3 Sinh mã kiểm thử Từ nguồn liệu để sinh mã kiểm thử (Hình 3.2 Hình 3.3), cơng cụ AsenAPIDriver sinh mã nguồn kiểm thử tương ứng với luồng nghiệp vụ ứng dụng Hình 3.2: Dữ liệu đầu vào 17 Hình 3.3: Dữ liệu đầu mong đợi Mã nguồn kiểm thử sinh tự động chạy Anypoint Studio cho kết kiểm thử Hình 3.4, ca kiểm thử thất bại ghi lịch sử lại rõ đâu khác biệt kết mong muốn kết thực tế (Hình 3.5) Hình 3.4: Kết chạy ca kiểm thử Hình 3.5: Chi tiết ca kiểm thử bị thất bại 3.4 Kết Qua việc áp dụng quy trình tích hợp liên tục cơng cụ Jenkins, kết hợp với công cụ AsenAPIDriver tự động sinh ca kiểm thử, ta thấy rõ ưu điểm mà mang lại Quy trình giúp giảm thời gian kiểm thử mà đảm bảo chất lượng mã nguồn Bằng chế liên kết Jenkins github, thay đổi mã nguồn kiểm tra lại với ca kiểm thử lập tức, sau thơng báo đến đội phát triển thông qua email Điều giúp cho quy trình phát triển tự động hóa khép kín Ngồi ra, hiệu làm việc đội phát triển 18 cải thiện đáng kể Với việc thay đổi kiểm tra liên tục, vấn đề xảy sớm phát hiện, thơng báo lại để sớm tìm giải pháp khắc phục, hạn chế lỗi tiềm tàng triển khai Qua trình thực nghiệm ứng dụng MuleESB cụ thể giải nghiệp vụ ngân hàng, luận văn bước tích hợp thực tế quy trình đánh giá hiệu quy trình đề xuất Chương tiếp theo, luận văn tổng kết lại nội dung trình bày đưa kết đạt được, điểm hạn chế đề xuất hướng tương lai 19 KẾT LUẬN Luận văn tìm hiểu khái niệm kiến trúc hướng dịch vụ, cơng nghệ trục tích hợp cầu nối thành phần hệ thống Cơng nghệ trục tích hợp giải tốt toán quản lý kết nối điều hướng, chuyển đổi tin so với phương thức kết nối point-to-point truyền thống Mặt khác, luận văn đặt tốn quy trình kiểm thử cho hệ thống sử dụng cơng nghệ trục tích hợp với khó khăn mơi trường kiểm thử hạn chế công cụ kiểm thử Theo đó, quy trình kiểm thử cần phải tự động kiểm tra với thay đổi hệ thống trước đưa đến môi trường triển khai thực tế nhằm tăng hiệu suất làm việc trình phát triển, tránh lỗi tiềm ẩn pha lập trình Vì vậy, quy trình tích hợp triển khai liên tục tác giả đưa áp dụng Mục tiêu luận văn xây dựng cơng cụ sinh mã kiểm thử tự động để hỗ trợ cho quy trình đề xuất Cơng cụ sinh có khả quét mã nguồn dự án sinh mã nguồn kiểm thử (test script) cho ứng dụng Kết hợp với công cụ quản lý dự án tự động, cơng cụ giúp hồn thiện quy trình kiểm thử từ tự động hóa tồn q trình kiểm thử triển khai ứng dụng lên máy chủ Quy trình kiểm thử hệ thống nêu luận văn hỗ trợ trình kiểm thử phần mềm kiểm soát tốt lỗi xảy hệ thống Quá trình kiểm thử diễn tự động liên tục giúp giảm thiểu thời gian lập trình cho lập trình viên, lỗi phát sớm trước triển khai môi trường thật, đặc biệt khiếm khuyết phần chỉnh sửa liên đới tới nhau, lỗi kiểm thử thông thường thủ công dễ bị bỏ qua Sau trình thực hiện, tác giả hồn thiện quy trình kiểm thử tích hợp triển khai tự động ứng dụng xây dựng dựa tảng MuleESB việc xây dựng công cụ sinh ca kiểm thử tự động AsenAPIDriver, kết hợp với công cụ mã nguồn mở Jenkins, Github, JUnit, MUnit, Maven Việc xây dựng tích hợp cơng cụ AsenAPIDriver đáp ứng yêu cầu đặt cho quy trình kiểm thử ứng dụng ESB xây dựng tảng MuleESB Tuy nhiên, giới hạn thời gian, công cụ AsenAPIDriver đáp ứng loại luồng nghiệp vụ ứng dụng xây dựng tảng MuleESB Ngồi ra, cơng cụ hỗ trợ sinh ca kiểm thử chức năng, chưa bao quát ca kiểm thử 20 phi chức bảo mật hiệu hệ thống Việc hỗ trợ kiểm thử loại luồng nghiệp vụ phức tạp khác, thực quét mã dò lỗi bảo mật XSS, SQL-injection… ứng dụng ESB, thực tích hợp đẩy tải để kiểm thử hiệu ứng dụng phát triển phiên Để hỗ trợ việc kiểm thử ứng dụng ESB hoàn thiện, tác giả cần phải triển khai thêm việc hỗ trợ kiểm thử loại luồng nghiệp vụ phức tạp khác Ngoài ra, công cụ cần phát triển thêm phần hỗ trợ kiểm thử hệ thống xây dựng tảng trục tích hợp khác: ServiceMix, JbossESB Đồng thời, tác giả cần kết hợp nghiên cứu quy trình phần mềm để đưa chiến thuật kiểm thử tốt Trong tương lai, công cụ phát triển tích hợp với IDE Eclipse, Anypoint Studio… để thực sinh mã kiểm thử thời điểm lập trình, hỗ trợ cho lập trình viên kiểm tra ứng dụng thời điểm phát triển ứng dụng 21 TÀI LIỆU THAM KHẢO Dirk Slama, Dirk Krafzig and Karl Banke (2004), Enterprise SOA: Service-Oriented Architecture Best Practices, Prentice Hall Pulier, E., Taylor (2006), Understanding Enterprise SOA, Manning Dirk Krafzig (2005), "Enterprise SOA: Service-Oriented Architecture Best Practices," Falko Menge (2007), "Enterprise Service Bus," Free and open source software conference Srinivas Shenoy (2013), "Approach to ESB Testing” – An Experience Sharing" MuleSoft - "What is MuleESB", https://www.mulesoft.com/resources/esb/what-mule-esb Mule official website, https://www.mulesoft.com/ Gartner, "Gartner Magic quandrant leader”, https://www.mulesoft.com/lp/reports/gartner-magic-quadrant-leader Martin Fowler, "Continuous Integration", https://www.martinfowler.com/articles/continuousIntegration.html 10 Git, "Getting started - About version control,", https://gitscm.com/book/en/v1/Getting-Started-About-Version-Control 11 Glenford J Myers, Corey Sandler and Tom Badgett (2015), The Art of Software Testing 3rd Edition 12 Phạm Ngọc Hùng, Trương Anh Hoàng and Đặng Văn Hưng (2014), Giáo trình kiểm thử phần mềm 13 SoapUI, "SoapUI Getting started”, https://www.soapui.org/soap-andwsdl/getting-started.html 14 Gregor Hohpe and Wendy Istanick (2002), "Test-Driven Development in Enterprise Integration Projects," 15 Maven official website, https://maven.apache.org/ 16 JUnit official website, https://junit.org/junit5/ 17 Jenkins official website, https://jenkins.io/ 18 Gregor Hohpe and Bobby Woolf (2004), Enterprise Integration Patterns, Pearson Education, 19 David A Chappell (2004), Enterprise Service Bus, O’Reilly 20 Git, "Getting started - About version control",https://gitscm.com/book/en/v1/Getting-Started-About-Version-Control ... 1.3.3 Công cụ hỗ trợ kiểm thử ứng dụng API Quá trình kiểm thử hệ thống sử dụng kiến trúc ESB chủ yếu tập trung vào giao tiếp thành phần hệ thống Vì vậy, quy trình kiểm thử không trọng vào phần kiểm. .. truyền thống Mặt khác, luận văn đặt tốn quy trình kiểm thử cho hệ thống sử dụng cơng nghệ trục tích hợp với khó khăn mơi trường kiểm thử hạn chế công cụ kiểm thử Theo đó, quy trình kiểm thử cần... [13] cơng cụ hỗ trợ kiểm thử API sử dụng phổ biến Đây cơng cụ kiểm thử có tảng mã nguồn mở hàng đầu cho phép kiểm thử viên thực loại kiểm thử như: kiểm thử chức năng, hồi quy, thử tải cách tự động