TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM
Kiểm thử phần mềm
Kiểm thử phần mềm là quá trình phân tích để phát hiện sự khác biệt giữa kết quả thực tế và đầu ra mong muốn, nhằm đánh giá các chức năng của phần mềm Quá trình này cần được thực hiện xuyên suốt trong giai đoạn phát triển phần mềm Kiểm thử phần mềm không chỉ quan trọng mà còn là một phần thiết yếu, giúp đánh giá và cải thiện chất lượng sản phẩm bằng cách xác định lỗi và các vấn đề phát sinh.
Phân loại kiểm thử
Ta phân loại kiểm thử dựa vào các yếu tố: Chiến lược kiểm thử, phương pháp kiểm thử và kỹ thuật kiểm thử
Dựa vào chiến lược kiểm thử ta có thể phân chia kiểm thử thành hai loại: kiểm thử thủ công và kiểm thử tự động
Theo phương pháp tiến hành kiểm thử ta chia kiểm thử làm hai loại: kiểm thử tĩnh và kiểm thử động
Dựa vào kỹ thuật kiểm thử ta có thể phân chia kiểm thử thành hai loại: kiểm thử hộp đen, kiểm thử hộp trắng [1].
Các phương pháp kiểm thử
Kiểm thử tĩnh là phương pháp kiểm tra phần mềm bằng cách sử dụng giấy và bút để kiểm tra logic và các chi tiết ngay sau khi lập trình hoàn tất, tập trung vào mã nguồn và tài liệu đặc tả Phương pháp này cho phép phân tích tất cả các kết quả có thể xảy ra trong quá trình chạy chương trình, với tiêu chuẩn tối ưu hóa trình biên dịch.
Kiểm thử động là phương pháp thử phần mềm thông qua việc chạy chương trình để kiểm tra trạng thái của từng động tác Phương pháp này dựa trên các ca kiểm thử xác định và thực hiện chương trình Kiểm thử động tập trung vào việc kiểm tra cách thức hoạt động của mã lệnh, tức là phản ứng vật lý của hệ thống với các biến thay đổi theo thời gian Trong quá trình kiểm thử, phần mềm cần được biên dịch và chạy thực tế Các bước trong kiểm thử động bao gồm việc nhập giá trị đầu vào và xác minh xem đầu ra có đúng với kết quả mong muốn hay không.
Dynamic testing methods include Unit Testing, Integration Testing, System Testing, and Acceptance Testing.
Việc thực hiện kiểm thử tĩnh và kiểm thử động giúp phát hiện lỗi sớm, từ đó hạn chế lỗi trong quá trình phát triển phần mềm Thực tế cho thấy, kiểm thử tĩnh và động nên được thực hiện liên tục và xen kẽ Các kiểm thử viên và nhà nghiên cứu cần xóa bỏ ranh giới giữa hai phương pháp này và phát triển một kiểm thử hỗn hợp để kết hợp những ưu điểm của cả hai cách tiếp cận.
Các kỹ thuật kiểm thử
Quá trình thiết kế trường hợp thử là việc phát triển các phương pháp kiểm thử nhằm phát hiện lỗi, sai sót và khiếm khuyết trong phần mềm, từ đó đảm bảo phần mềm đạt tiêu chuẩn chất lượng.
Thiết kê các trường hợp kiểm thử có vai trò:
- Tạo ra các trường hợp kiểm thử tốt nhất có khả năng phát hiện ra lỗi, sai sót của phần mềm một cách nhiều nhất
- Tạo ra các trường hợp kiểm thử có chi phí rẻ nhất đồng thời tốn ít thời gian và công sức nhất.[2]
Ba chiến lược kiểm thử phổ biến bao gồm kiểm thử hộp đen, kiểm thử hộp trắng và kiểm thử hộp xám Trong bài viết này, chúng ta sẽ khám phá chi tiết về kỹ thuật kiểm thử hộp trắng và kiểm thử hộp đen.
1.4.1 Kiểm thử hộp trắng – White box testing
Kiểm thử hộp trắng, hay còn gọi là kiểm thử hướng logic, là phương pháp kiểm tra cấu trúc nội bộ của phần mềm Mục tiêu của kiểm thử này là đảm bảo rằng tất cả các câu lệnh và điều kiện trong mã nguồn được thực hiện ít nhất một lần.
Hộp trắng thực sự là hộp trong suốt, và kỹ thuật này còn được gọi là kiểm thử hộp thủy tinh (Glass-Box Testing) hay kiểm thử hộp trong suốt (Clear-Box Testing) Trong phương pháp này, người kiểm thử có quyền truy cập vào mã nguồn chương trình, điều này tạo điều kiện thuận lợi cho quá trình kiểm thử.
Nguyên tắc của kỹ thuật kiểm thử hộp trắng là:
- Thực hiện mọi đường dẫn độc lập ít nhất một lần
- Thực hiện mọi điều kiện logic (if-then-else) trên các giá trị true và false của chúng
- Thực hiện mọi vòng lặp (các vòng lặp for, while-do) tại các biên và trong phạm vi hoạt động của chúng
- Thực hiện mọi cấu trúc dữ liệu bên trong để đảm bảo tính hợp lệ của chúng
Hình 1.1 Ví dụ chu trình điều khiển
Trong phương pháp kiểm thử hộp trắng, ta đi vào tìm hiểu các kỹ thuật kiểm thử hộp trắng đó là:
- Kiểm thử bao phủ chu trình cơ sở
- Kiểm thử cấu trúc điều khiển
1.4.1.1 Kiểm thử đường dẫn cơ sở (Basic Path Testing) Kiểm thử đường dẫn cơ sở là một kỹ thuật kiểm thử hộp trắng do Tom McCabe đề xuất, là việc thiết kế các trường hợp kiểm thử trên từng câu lệnh trong chương trình được sẽ được thực hiện ít nhất một lần không quan tâm đến ảnh hưởng lên các đường quyết định
Phương pháp đường dẫn cơ sở giúp người thiết kế kiểm thử đo lường độ phức tạp logic của thiết kế thủ tục Sử dụng các phép đo này, người thiết kế có thể tạo ra một tập cơ sở các đường dẫn thực hiện Các trường hợp kiểm thử được suy diễn từ tập cơ sở này, đảm bảo rằng mỗi lệnh trong chương trình được thực hiện ít nhất một lần trong quá trình kiểm thử.
Các bước tiến hành xây dựng một tập hợp kiểm thử như sau:
- Dùng tài liệu thiết kế hay mã nguồn để vẽ thuật toán của chương trình hay hàm
- Từ đồ thị xác định tập đường độc lập tuyến tính lẫn nhau
- Xây dựng trường hợp kiểm thử dựa trên tập đường xác định ở trên
1.4.1.2 Kiểm thử cấu trúc điều khiển Phương pháp kiểm thử đường dẫn cơ sở là phương pháp đơn giản và hiệu quả, nhưng nó vẫn chưa đủ Chúng ta sẽ xem xét các biến thể trên kiểm thử cấu trúc điều khiển mà phủ kiểm thử mở rộng và hoàn thiện chất lượng của kỹ thuật kiểm thử hộp trắng
Kiểm thử điều kiện là phương pháp thiết kế trường hợp kiểm thử dựa trên các điều kiện logic của hàm hay module chương trình [1]
Các lỗi phát hiện được:
- Lỗi do giá trị của biến
- Lỗi do phép toán quan hệ
- Lỗi trong biểu thức toán học Một số định nghĩa:
- Điều kiện đơn: là một biến logic hoặc một biểu thức quan hệ, có thể có toán tử NOT (!) đứng trước, ví dụ, NOT (a>b)
Biểu thức quan hệ là một dạng biểu thức có cấu trúc E1 E2, trong đó E1 và E2 là các biểu thức số học, và là toán tử quan hệ, bao gồm các loại như =, ==, và != Ví dụ về biểu thức quan hệ là a > b + 1.
- Điều kiện phức: gồm hai hay nhiều điều kiện đơn, toán tử logic AND (&&) hoặc OR (||) hoặc NOT (!) và các dấu ngoặc đơn „(„ và „)‟, ví dụ, (a > b +
Các thành phần của một điều kiện bao gồm phép toán logic, biến logic, cặp dấu ngoặc logic, phép toán quan hệ và biểu thức toán học Kiểm thử điều kiện nhằm phát hiện lỗi trong điều kiện và các lỗi khác trong chương trình Nhiều phương pháp kiểm thử điều kiện đã được đề xuất để nâng cao hiệu quả kiểm tra.
Kiểm thử nhánh (Branch Testing): là phương pháp kiểm thử điều kiện đơn giản nhất
Kiểm thử miền (Domain Testing) yêu cầu thực hiện 3 hoặc 4 kiểm thử cho mỗi biểu thức quan hệ Đối với một biểu thức quan hệ có dạng E1 E2, cần thiết kế 3 kiểm thử với E1 được xác định cụ thể.
1.4.1.2.2 Kiểm thử luồng dữ liệu
Phương pháp kiểm thử luồng dữ liệu tập trung vào việc lựa chọn các đường dẫn kiểm thử của chương trình dựa trên vị trí khai báo và sử dụng các biến Trong kiểm thử này, mỗi câu lệnh trong chương trình được gán một số hiệu lệnh duy nhất, và mỗi hàm không thay đổi tham số của nó cũng như biến toàn cục Đối với một lệnh có số hiệu S, chúng ta có thể định nghĩa các quy tắc kiểm thử cụ thể.
DEF(S) = là tập các biến được khai báo trong S
USE(S) = là tập các biến được sử dụng trong S
Chiến lược kiểm thử luồng dữ liệu cơ bản đảm bảo rằng mỗi chuỗi dữ liệu (DU) được kiểm tra ít nhất một lần Chiến lược này được gọi là kiểm thử DU, đóng vai trò quan trọng trong việc xác minh tính chính xác và độ tin cậy của dữ liệu trong quá trình phát triển phần mềm.
Kiểm thử dữ liệu không đảm bảo phủ hết tất cả các nhánh của một chương trình Chỉ trong một số ít tình huống, như cấu trúc if-then-else mà phần then không có khai báo biến và không có phần else, nhánh else của lệnh if không cần thiết phải được kiểm thử.
Chiến lược kiểm thử luồng dữ liệu giúp xác định các đường dẫn kiểm thử hiệu quả trong chương trình, đặc biệt là những chương trình có lệnh if hoặc vòng lặp lồng nhau.
Vòng lặp đóng vai trò quan trọng trong hầu hết các thuật toán phần mềm, nhưng thường bị bỏ qua trong quá trình kiểm thử Kiểm thử vòng lặp là một kỹ thuật kiểm thử hộp trắng, tập trung vào việc xác minh tính hợp lệ của các cấu trúc lặp.
Vòng lặp đơn Vòng lặp lồng nhau
Vòng lặp phi cấu trúc
Hình 1.2 Các kiểu vòng lặp
1.4.2 Kiểm thử hộp đen – Black box testing
Kỹ thuật kiểm thử hộp đen còn được gọi là kiểm thử hướng dữ liệu (data-driven) hay là kiểm thử hướng vào/ra (input/output driven)
Quy trình kiểm thử phần mềm
Trước khi tìm hiểu một quy trình kiểm thử phần mềm, ta cần hiểu khái niệm Testcase
Testcase là một trường hợp thử nghiệm bao gồm một cặp đơn giản Nó có thể bao gồm một chuỗi các trường hợp thử nghiệm đầu vào với đầu ra mong muốn Thông thường, một testcase bao gồm ba phần cơ bản.
Phẩn 1: Mục đích kiểm thử: Mô tả các điều kiện cần để tiến hành kiểm tra Phần 2: Các bước thực hiện: Mô tả các bước thực hiện để kiểm tra một testcase
Phần 3: Kết quả mong muốn: Kết quả trả về từ đối tượng kiểm tra, chứng tỏ đối tượng đạt yêu cầu.[1] Để kiểm tra một chương trình thì nhân viên kiểm thử phải thực hiện các trường hợp thử nghiệm trên để tìm ra lỗi chương trình và đảm bảo chương trình hoạt động đúng
Trong quá trình phát triển phần mềm, có bốn giai đoạn thử nghiệm hệ thống cần thực hiện trước khi triển khai: 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 Kiểm thử đơn vị, thường do lập trình viên thực hiện, tập trung vào việc kiểm tra các hàm và thủ tục Tiếp theo là kiểm thử tích hợp, do nhân viên kiểm thử thực hiện, nhằm kiểm tra sự tích hợp giữa các module Sau đó, kiểm thử hệ thống được tiến hành để đảm bảo tính chính xác của toàn bộ phần mềm Cuối cùng, giai đoạn kiểm thử chấp nhận, còn gọi là kiểm thử nghiệm thu, được thực hiện dành cho khách hàng để xác nhận sản phẩm.
Hình 1.3 Giai đoạn kiểm thử trong xử lý phần mềm
Kiểm thử tự động
Kiểm thử phần mềm là một công việc tốn nhiều công sức, chủ yếu thực hiện bằng tay Tuy nhiên, việc sử dụng các công cụ có thể rút ngắn thời gian thực hiện kiểm thử Các công cụ này mang lại nhiều lợi ích, bao gồm tăng hiệu quả và giảm thiểu sai sót trong quá trình kiểm thử.
- Tăng năng suất kiểm thử
- Bảo đảm hơn các trường hợp kiểm thử hồi quy
- Giảm thời gian thực hiện kiểm thử
- Giảm chi phí bảo trì phần mềm
- Tăng hiệu quả cho các trường hợp kiểm thử
Mục tiêu chính của kiểm thử tự động là nâng cao năng suất và chất lượng kiểm thử, không phải chỉ đơn giản là giảm số lượng trường hợp thử nghiệm đầu vào Trước khi triển khai một dự án kiểm thử tự động, tổ chức cần thực hiện đánh giá và cân nhắc kỹ lưỡng Dưới đây là danh sách các điều kiện tiên quyết cần xem xét để đánh giá sự sẵn sàng của tổ chức cho việc thử nghiệm tự động.
- Các trường hợp kiểm thử được định nghĩa tốt
- Kiểm tra điều kiện công cụ và cơ sở hạ tầng đảm bảo
- Các chuyên gia kiểm thử phải có kinh nghiệm trong thực hiện kiểm thử tự động
- Ngân sách đã đầy đủ cho việc đầu tư công cụ
TỔNG QUAN VỀ CÔNG NGHỆ DỊCH VỤ WEB
Định nghĩa
Theo W3C, dịch vụ Web là một hệ thống phần mềm hỗ trợ tương tác giữa các ứng dụng trên máy tính khác nhau qua Internet Giao diện của dịch vụ này được mô tả bằng định dạng có thể xử lý (chủ yếu là WSDL) Các hệ thống khác tương tác với dịch vụ Web theo mô tả đó, sử dụng thông điệp SOAP, thường được truyền qua HTML với định dạng XML và các chuẩn liên quan khác.
2.1.2 Đặc điểm của dịch vụ Web
Dịch vụ Web tạo điều kiện cho việc tương tác giữa client và server trong các môi trường khác nhau, ví dụ như một ứng dụng chạy trên máy chủ Linux có thể phục vụ người dùng sử dụng hệ điều hành Windows mà không cần yêu cầu tương thích đặc biệt.
Phần lớn công nghệ trong Dịch vụ Web được phát triển dựa trên mã nguồn mở và các tiêu chuẩn đã được công nhận, chẳng hạn như XML.
Một Dịch vụ Web bao gồm có nhiều mô-đun và có thể công bố lên mạng Internet
Sự kết hợp giữa phát triển theo từng thành phần và cơ sở hạ tầng Web mang lại lợi ích cho doanh nghiệp, khách hàng, nhà cung cấp và cá nhân thông qua Internet.
Một ứng dụng khi triển khai sẽ hoạt động theo mô hình client-server, sử dụng phần mềm ứng dụng phía server như PHP, Oracle Application Server hoặc Microsoft Net.
2.1.3 Ƣu điểm và hạn chế của dịch vụ Web
Dịch vụ Web cung cấp khả năng hoạt động rộng lớn với các ứng dụng phần mềm khác nhau chạy trên những nền tảng khác nhau
Sử dụng các giao thức và chuẩn mở Giao thức và định dạng dữ liệu dựa trên văn bản (text), giúp các lập trình viên dễ dàng hiểu được
Nâng cao khả năng tái sử dụng
Để tối ưu hóa đầu tư vào các hệ thống phần mềm hiện có, cần thiết phải cho phép các quy trình và chức năng nghiệp vụ được đóng gói trong giao diện Dịch vụ Web Điều này không chỉ nâng cao khả năng tương tác giữa các ứng dụng mà còn cải thiện hiệu quả hoạt động và khả năng mở rộng của hệ thống.
Tạo mối quan hệ tương tác lẫn nhau và mềm dẻo giữa các thành phần trong hệ thống, dễ dàng cho việc phát triển các ứng dụng phân tán
Thúc đẩy tích hợp hệ thống giúp giảm thiểu sự phức tạp, hạ giá thành hoạt động và phát triển nhanh chóng, đồng thời tương tác hiệu quả với hệ thống của các doanh nghiệp khác.
Trong thời gian ngừng hoạt động của Dịch vụ Web, sẽ xảy ra những thiệt hại nghiêm trọng do giao diện không được cập nhật và khả năng lỗi nếu máy khách không được nâng cấp Hơn nữa, việc thiếu các giao thức cần thiết cho quá trình vận hành cũng sẽ gây ra nhiều vấn đề.
Có quá nhiều chuẩn cho Dịch vụ Web khiến người dùng khó nắm bắt
Phải quan tâm nhiều hơn đến vấn đề an toàn và bảo mật
2.1.4 Ứng dụng của dịch vụ Web
Dịch vụ Web đóng vai trò quan trọng trong việc tích hợp các hệ thống, là một hoạt động thiết yếu trong phát triển hệ thống Các ứng dụng cần liên kết với cơ sở dữ liệu và các ứng dụng khác, cho phép người dùng truy cập và phân tích dữ liệu Gần đây, sự phát triển mạnh mẽ của thương mại điện tử và B2B yêu cầu các hệ thống phải có khả năng tích hợp với cơ sở dữ liệu của đối tác kinh doanh, nhằm tương tác không chỉ với các thành phần nội bộ mà còn với hệ thống bên ngoài.
Kiến trúc chung của dịch vụ Web
Dịch vụ Web bao gồm ba chuẩn chính: SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) và UDDI (Universal Description, Discovery, and Integration) UDDI đóng vai trò quan trọng trong việc đăng ký và khám phá các dịch vụ web được mô tả trong WSDL Giao thức UDDI sử dụng SOAP để giao tiếp với máy chủ UDDI, sau đó các ứng dụng SOAP sẽ yêu cầu dịch vụ web Các thông điệp SOAP được truyền tải chính xác qua giao thức HTTP và TCP/IP.
Hình 2.1 Kiến trúc chung của dịch vụ web
Chồng giao thức dịch vụ web bao gồm các giao thức mạng máy tính cần thiết để định nghĩa, xác định vị trí, thực thi và xây dựng các dịch vụ web tương tác với ứng dụng hoặc dịch vụ khác Chồng giao thức này được cấu thành từ bốn thành phần chính.
Dịch vụ vận chuyển đóng vai trò quan trọng trong việc truyền tải thông điệp giữa các ứng dụng mạng, sử dụng nhiều giao thức khác nhau như HTTP, SMTP, FTP, JSM và gần đây nhất là giao thức Blocks Extensible Exchange Protocol (BEEP).
Thông điệp XML đóng vai trò quan trọng trong việc giải mã các dữ liệu theo định dạng XML, giúp người dùng tương tác với ứng dụng một cách hiệu quả Hiện nay, các giao thức phổ biến để thực hiện nhiệm vụ này bao gồm XML-RPC, SOAP và REST.
Dịch vụ web được mô tả thông qua các giao diện chung, thường sử dụng WSDL, một ngôn ngữ mô tả giao tiếp và thực thi dựa trên XML WSDL cho phép dịch vụ web truyền tham số và các loại dữ liệu cần thiết cho các thao tác và chức năng mà nó cung cấp, giúp cải thiện khả năng tương tác và tích hợp giữa các hệ thống.
Khám phá dịch vụ là quá trình tập trung các dịch vụ vào một nền tảng đã được đăng ký, giúp dễ dàng phát hiện và tìm kiếm các dịch vụ trực tuyến khác để tương tác Để các dịch vụ có thể truy cập và giao tiếp với nhau, việc đăng ký là cần thiết Hiện nay, UDDI API thường được sử dụng để thực hiện các chức năng này.
Hình 2.2 Mô hình tương tác
Tầng giao thức tương tác dịch vụ (Service Communication Protocol) sử dụng công nghệ chuẩn SOAP, cho phép người dùng triệu gọi dịch vụ từ xa thông qua thông điệp XML Để đảm bảo tính an toàn, toàn vẹn và bảo mật thông tin trong kiến trúc dịch vụ web, các tầng Policy, Security, Transaction và Management cũng được bổ sung.
Các thành phần của dịch vụ web
XML là một chuẩn mở do W3C phát triển, được sử dụng để mô tả dữ liệu và định nghĩa các thành phần trên trang web cũng như tài liệu B2B Cấu trúc của XML tương tự như HTML, nhưng trong khi HTML tập trung vào cách hiển thị, XML chú trọng vào nội dung bên trong các thành phần Các thẻ trong XML có thể được lập trình viên tự tạo, giúp nó trở thành định dạng thông điệp chuẩn nhờ tính phổ biến và hiệu quả của mã nguồn mở.
Dịch vụ web là sự kết hợp của nhiều thành phần khác nhau, sử dụng các tính năng của chúng để giao tiếp XML đóng vai trò quan trọng trong việc xây dựng dịch vụ web, với tất cả dữ liệu được chuyển sang định dạng thẻ XML Nhờ đó, thông tin mã hóa hoàn toàn tương thích với các chuẩn SOAP hoặc XML-RPC, cho phép tương tác thống nhất giữa các thành phần.
2.3.2 WSDL – Web Service Description Language
WSDL định nghĩa cách mô tả dịch vụ web theo cú pháp tổng quát của XML [6], bao gồm các thông tin:
- Giao thức và kiểu mã hóa sẽ được sử dụng khi gọi các hàm của dịch vụ web
- Loại thông tin: thao tác, tham số, những kiểu dữ liệu (có thể là giao diện của dịch vụ web cộng với tên cho giao diện này)
Hình 2.3 Thành phần của WSDL
Một WSDL hợp lệ bao gồm hai phần chính: phần giao diện, mô tả cách thức kết nối và phần thi hành, cung cấp thông tin truy xuất CSDL Hai phần này được lưu trong hai tập tin XML riêng biệt, bao gồm tập tin giao diện dịch vụ và tập tin thi hành dịch vụ Phần giao diện của dịch vụ web mô tả cách thức giao tiếp qua dịch vụ, bao gồm tên, giao thức liên kết và định dạng thông điệp yêu cầu cần thiết để tương tác với dịch vụ web.
WSDL thường được kết hợp với XML schema và SOAP để cung cấp dịch vụ web qua Internet Khi một client kết nối tới dịch vụ web, nó có thể tham khảo WSDL để xác định các chức năng có sẵn trên server Sau đó, client sử dụng SOAP để truy xuất các chức năng cụ thể được định nghĩa trong WSDL.
Hình 2.4 Một tài liệu WSDL
Tài liệu WSDL luôn có phần tử gốc là , thành phần bên trong bao gồm các phần tử:
Hình 2.5 Cấu trúc tài liệu WSDL
2.3.2.1 Types: Định nghĩa các kiểu dữ liệu của thông điệp gửi Kiểu dữ liệu có thể là kiểu đơn giản (int, string,…) hoặc kiểu phức hợp (các đối tượng do dịch vụ web định nghĩa, ví dụ đối tượng SubInfo như hình dưới đây)
Hình 2.6 Kiểu dữ liệu trong tài liệu WSDL 2.3.2.2 Messages
Thông điệp giữa client và server được mô tả rõ ràng, với các message được sử dụng bởi phần tử thực thi dịch vụ Nhiều thao tác có thể tham chiếu đến cùng một định nghĩa message, giúp tăng tính linh hoạt và đơn giản hóa việc tái sử dụng Ví dụ, hai thao tác với cùng tham số có thể chia sẻ một định nghĩa message, tạo điều kiện thuận lợi cho việc quản lý và phát triển hệ thống.
Hình 2.7 Messages trong tài liệu WSDL
Các thành phần của messages:
- Message name: tên của message được tham chiếu đến phần tử thi hành của Dịch vụ web
- Message part: chỉ ra định dạng thực tế của message
2.3.2.3 Operations (phần tử thi hành hay thao tác)
Operation là hành động của dịch vụ web, xác định thông điệp đầu vào, đầu ra và thông điệp lỗi Operation tương tự như khái niệm hàm (function) hoặc thủ tục (procedure) trong lập trình truyền thống.
Hình 2.8 Operations trong tài liệu WSDL
- One-way: Cổng nhâ ̣n mô ̣t message, message đó là message nhâ ̣p
- Request-response : Cổng nhâ ̣n mô ̣t message và gửi mô ̣t message phản hồi
- Solicit-response: Cổng gư ̉ i mô ̣t message và nhâ ̣n về mô ̣t message
- Notification: Cổng gư ̉ i mô ̣t message, message đó là message xuất
Là tập hợp các operations, dùng để tham chiếu tới phần tử ràng buộc của tài liệu WSDL (bindings)
Hình 2.9 Port Type trong tài liệu WSDL 2.3.2.5 Bindings Định nghĩa cách kết hợp các thành phần dịch vụ web với nhau
Mô ̣t kết hợp bao gồm :
- Những giao thức mở rô ̣ng cho những gia o tác và những message bao gồm thông tin URN và mã hóa cho SOAP
Mỗi kết hợp đều tham chiếu đến một loại cổng (portType) có thể được sử dụng trong nhiều mối kết hợp khác nhau Tất cả các thao tác được định nghĩa bên trong kiểu cổng cần phải nằm trong phạm vi của mối kết hợp đó.
Hình 2.10 Bindings trong tài liệu WSDL 2.3.2.6 Service và port
Port: định nghĩa địa chỉ hoặc điểm kết nối vào dịch vụ web Thông thường đó là một địa chỉ HTTP
Dịch vụ là việc thực hiện các định nghĩa có trong tập tin giao diện, bao gồm cách gọi dịch vụ web theo các thủ tục và phương thức cụ thể Nó bao gồm một tập hợp các cổng (port) liên quan.
Hình 2.11 Service và port trong tài liệu WSDL
2.3.3 Universal Description, Discovery, and Integration (UDDI) Để có thể sử dụng các dịch vụ, trước tiên client phải tìm dịch vụ, ghi nhận thông tin về cách sử dụng và biết được đối tượng nào cung cấp dịch vụ UDDI định nghĩa một số thành phần cho biết các thông tin này, cho phép các client truy tìm và nhận những thông tin được yêu cầu khi sử dụng dịch vụ web [8][9]
Trang trắng, hay White pages, bao gồm thông tin liên hệ và các định dạng chính yếu của dịch vụ web như tên giao dịch, địa chỉ và thông tin nhận dạng Những thông tin này giúp các đối tượng khác nhận diện và xác định dịch vụ một cách dễ dàng.
Trang vàng – danh bạ điện tử, cung cấp thông tin chi tiết về các dịch vụ web phân loại theo từng loại khác nhau Thông tin này giúp người dùng dễ dàng tìm kiếm và nhận diện các dịch vụ web phù hợp với nhu cầu của họ.
- Trang xanh – Green pages: chứa thông tin kỹ thuật mô tả các hành vi và các chức năng của dịch vụ web
Dịch vụ tModel chứa thông tin về loại dịch vụ được sử dụng, bao gồm các chi tiết về dịch vụ web được công bố qua giao thức này Nó kích hoạt các ứng dụng tìm kiếm thông tin từ các dịch vụ web khác để xác định dịch vụ nào cần thiết.
2.3.4 SOAP – Simple Object Access Protocol
Web services can be accessed using a protocol known as Simple Object Access Protocol (SOAP) In other words, it is possible to retrieve information from the UDDI registry through SOAP-compliant calls.
SOAP là một giao thức giao tiếp dựa trên XML, đóng vai trò là xương sống cho các ứng dụng phân tán được phát triển từ nhiều ngôn ngữ và hệ điều hành khác nhau Giao thức này cho phép truyền tải các thông điệp XML qua mạng máy tính, thường sử dụng giao thức HTTP.
Bảo mật dịch vụ web
Dịch vụ web kết nối và tương tác với các ứng dụng qua Internet, do đó, bảo mật trở thành mối quan tâm hàng đầu khi các công ty tích hợp ứng dụng với dịch vụ web Đảm bảo an toàn cho dịch vụ web là điều thiết yếu, đặc biệt đối với những dịch vụ liên quan đến giao dịch tiền tệ, thông tin thị trường chứng khoán, hoặc dịch vụ bán hàng trực tuyến yêu cầu thanh toán qua tài khoản và thông tin cá nhân của người dùng.
Trước khi WS-Security ra đời, an toàn dịch vụ web chủ yếu chỉ là bảo mật kênh truyền dữ liệu Hiện nay, bảo mật này được thực hiện cho các dịch vụ SOAP/HTTP thông qua việc sử dụng giao thức HTTPS HTTPS không chỉ đảm bảo an toàn cho từng thông điệp mà còn cung cấp bảo mật cho toàn bộ gói dữ liệu HTTP.
Mặc dù HTTPS không bao quát tất cả các yếu tố trong tiêu chuẩn an toàn cho Dịch vụ web, nhưng nó vẫn cung cấp một lớp bảo mật đáng tin cậy, bao gồm định danh, chứng thực, tính toàn vẹn thông điệp và độ tin cậy cao.
WS-Security là một chuẩn an toàn cho SOAP, giúp xây dựng dịch vụ web tin cậy và toàn vẹn Nó đảm bảo rằng thông tin và giao dịch không bị chặn hay đánh cắp trong quá trình truyền tải Được thiết kế mở, WS-Security hỗ trợ nhiều mô hình an toàn khác như PKI, Kerberos và SSL, đồng thời cung cấp các cơ chế an toàn, khuôn dạng chữ ký và công nghệ mã hóa để bảo vệ tính toàn vẹn và tin cậy của thông điệp Tuy nhiên, WS-Security không thể đáp ứng tất cả yêu cầu về bảo mật, mà chỉ là một lớp trong giải pháp an toàn cho dịch vụ web.
Tính toàn vẹn của chữ ký số hóa XML phụ thuộc vào nội dung của thông điệp; nếu dữ liệu bị thay đổi trái phép, chữ ký sẽ không còn hợp lệ Chữ ký này được tạo ra bằng khóa của người gửi, đảm bảo rằng người nhận chỉ chấp nhận thông điệp khi có chữ ký và nội dung khớp nhau, ngược lại sẽ nhận thông báo lỗi Việc chứng thực giữa client và server là phương pháp cơ bản, sử dụng định danh người dùng và mật khẩu WS-security là một lớp bảo mật cho dịch vụ web, tuy nhiên cần có một mô hình an toàn tổng thể hơn để bao quát các khía cạnh khác Các thành phần bổ sung như WS-Secure Conversation, WS-Authentication, WS-Policy và WS-Trust sẽ tăng cường an toàn cho hệ thống trong quá trình trao đổi dữ liệu, quản lý phiên làm việc và chính sách chứng thực.
Triển khai và tích hợp dịch vụ web
2.5.1 Triển khai dịch vụ web
Có 4 giai đoạn chính để xây dựng một dịch vụ web là xây dựng, triển khai, tiến hành và quản lý [10], trong đó:
Giai đoạn xây dựng ứng dụng dịch vụ web bao gồm phát triển và thử nghiệm, cùng với việc xây dựng các chức năng và định nghĩa dịch vụ Có hai phương pháp chính để thực hiện trong giai đoạn này: Red-path-solid và Blue-path-dashed Phương pháp Red-path-solid tập trung vào việc xây dựng một dịch vụ web mới từ đầu hoặc dựa trên một dịch vụ hiện có, từ đó tạo ra định nghĩa dịch vụ (WSDL) với các đối tượng và hàm chức năng mong muốn Ngược lại, phương pháp Blue-path-dashed cho phép xây dựng dịch vụ web từ một định nghĩa WSDL có sẵn, từ đó điều chỉnh hoặc phát triển mã nguồn để đáp ứng các yêu cầu của dịch vụ.
Giai đoạn triển khai dịch vụ web bao gồm việc công bố định nghĩa dịch vụ, xây dựng WSDL và triển khai mã thực thi Sau khi triển khai dịch vụ web trên ứng dụng phía server, dịch vụ sẽ được công bố trên Internet để các client có thể truy cập Để thực hiện việc này, UDDI registry sẽ được sử dụng để công bố dịch vụ lên mạng.
- Giai đoạn tiến hành: tìm kiếm và gọi thực thi dịch vụ web bởi những người dùng muốn sử dụng dịch vụ
- Quản lý: Quản lý và quản trị dịch vụ, duy trì sự ổn định của dịch vụ, cập nhật thông tin mới, sửa lỗi khi nó xảy ra…
Có 3 cách tiếp cận chủ yếu để xây dựng nên một dịch vụ web, có thể từ một ứng dụng đã có (bottom-up); từ một định nghĩa dịch vụ, WSDL để phát sinh một ứng dụng mới (top-down) hoặc có thể từ một nhóm các dịch vụ web hiện có, kết hợp lại với nhau để tạo nên các chức năng mới hoặc mở rộng thêm chức năng
Quy trình xây dựng một dịch vụ web bao gồm các bước sau:
1 Định nghĩa và xây dựng các chức năng, các dịch vụ mà dịch vụ sẽ cung cấp (sử dụng ngôn ngữ Java chẳng hạn)
2 Tạo WSDL cho dịch vụ
4 Đăng ký WSDL với UDDI registry để cho phép các client có thể tìm thấy và truy xuất
5 Client nhận file WSDL và từ đó xây dựng SOAP client để có thể kết nối với SOAP server
6 Xây dựng ứng dụng phía client (chẳng hạn sử dụng Java) và sau đó gọi thực hiện dịch vụ thông qua việc kết nối tới SOAP server
2.5.2 Tích hợp dịch vụ web Để có thể thành công với dịch vụ web phải quan tâm đến khá nhiều vấn đề, bao gồm việc triển khai, giám sát và tích hợp hệ thống [10]
Giám sát dịch vụ web là một yếu tố quan trọng, đòi hỏi hỗ trợ từ cả công cụ lẫn cơ sở hạ tầng để theo dõi hiệu suất hoạt động trên toàn mạng Điều này bao gồm việc giám sát từ các chi nhánh con của công ty đến các chi nhánh khác và giao tiếp với các doanh nghiệp bên ngoài Việc kết hợp thông báo theo sự kiện với các lỗi trong luồng nghiệp vụ giúp người dùng không có kinh nghiệm cũng có thể theo dõi và quản lý hiệu quả các dịch vụ web và dịch vụ kế thừa khác.
Xác định đường đi dữ liệu trong dịch vụ web là quá trình thiết lập cách thức dữ liệu di chuyển giữa các thành phần, nhằm tối đa hóa khả năng tái sử dụng Mỗi thành phần được coi như một đối tượng, và các thể hiện của nó hoạt động độc lập, không phụ thuộc vào nhau Điều này cho phép các thể hiện của cùng một thành phần dễ dàng được sử dụng lại trong các ứng dụng phân tán khác.
- Triển khai (Deployment): Triển khai các dịch vụ web có khả năng nâng cấp, điều khiển và cấu hình các thành phần từ xa thông qua mạng phân tán
Quản lý trong kiến trúc P2P (Peer-to-Peer) cho phép thực hiện các hoạt động như thực thi thành phần, định tuyến dữ liệu, xử lý luồng công việc và chuyển đổi dữ liệu tại các điểm cuối của mạng Trong khi đó, server tập trung vào các nhiệm vụ quan trọng như quản lý, điều khiển sự kiện, chứng thực bảo mật và quản trị, đảm bảo hệ thống hoạt động hiệu quả và an toàn.
Quản lý cấu hình và phiên bản là quá trình sử dụng các công cụ linh hoạt để kiểm soát các phiên bản khác nhau của dịch vụ web, cho phép nâng cấp và điều khiển từ một công cụ quản lý tập trung Việc kết hợp giữa ứng dụng và mạng giúp các kỹ sư triển khai có khả năng điều khiển các thành phần hoạt động trên nền tảng hệ thống phần cứng cụ thể trong mạng.
Bảo mật trong các ứng dụng web ngày nay được đảm bảo nhờ vào các chuẩn mở như HTTP, XML, SOAP, WSDL và chuẩn bảo mật JSM Các dịch vụ web sử dụng công nghệ như firewall, SSL và chứng nhận số để bảo vệ thông tin Trong tương lai, các dịch vụ web thế hệ mới sẽ tích hợp các công nghệ bảo mật tiên tiến hơn, bao gồm mã hóa XML và chứng nhận số XML, nhằm nâng cao mức độ an toàn cho người dùng.
Dịch vụ web giúp giao tiếp và truyền nhận dữ liệu trở nên hiệu quả và dễ dàng hơn, đồng thời giảm chi phí và nâng cao khả năng giao tiếp thời gian thực, kết nối mọi người trên toàn cầu Kiến trúc hướng dịch vụ là bản chất của nền tảng công nghệ này, cho thấy sự phát triển của dịch vụ web có triển vọng rất sáng sủa trong tương lai.
Kiểm thử dịch vụ web
Kiểm thử dịch vụ web là một phần quan trọng trong kiểm thử phần mềm, bao gồm kiểm thử chức năng cơ bản, khả năng liên kết và tương tác với các hệ thống khác, cũng như kiểm thử bảo mật và khả năng chịu tải.
Phương pháp kiểm thử dịch vụ web (WS) tương tự như kiểm thử phần mềm đã đề cập trong chương 1, nhưng cần chú ý đến kiểm thử bảo mật và khả năng chịu tải Kiểm thử bảo mật là một yếu tố quan trọng trong quy trình này.
Kiểm thử bảo mật và kiểm soát truy cập WS tập trung vào hai lĩnh vực bảo mật chính:
Bảo mật ở mức ứng dụng, bao gồm truy cập dữ liệu và các chức năng nghiệp vụ
Bảo mật hệ thống và ứng dụng là rất quan trọng trong việc quản lý quyền truy cập Bảo mật ở mức hệ thống đảm bảo rằng chỉ những người dùng được phép mới có thể truy cập vào hệ thống hoặc từ xa Trong khi đó, bảo mật ở mức ứng dụng quy định rằng người dùng sẽ bị hạn chế trong việc sử dụng các chức năng hoặc dữ liệu phù hợp với quyền của họ Ví dụ, khi khai báo WS, hệ thống cần xác định các quyền khác nhau: hệ thống A có quyền Admin có thể thêm mới và cập nhật dữ liệu, trong khi hệ thống B chỉ có quyền User và chỉ có thể xem dữ liệu.
Bảo mật hệ thống đảm bảo rằng chỉ những người dùng được cấp quyền mới có thể truy cập ứng dụng thông qua các cổng thích hợp Chẳng hạn, WS sẽ khai báo địa chỉ IP tương ứng với các hệ thống được phép gọi đến WS.
Khi thực hiện kiểm thử Web Service (WS), cần xây dựng các trường hợp kiểm thử để đảm bảo hai mức bảo mật đã đề cập Ngoài ra, nên bổ sung các trường hợp kiểm tra độ mạnh của user và password, yêu cầu tối thiểu 6 ký tự và bao gồm chữ cái, số, cùng ký tự đặc biệt Đối với những user và password được mã hóa, cần kiểm tra tính chính xác của quá trình mã hóa.
Kiểm thử khả năng chịu tải của Web Service (WS) đo lường thời gian phản hồi từ server khi client gửi request, cùng với số lượng giao dịch thực hiện trong một khoảng thời gian nhất định Hiện nay, có nhiều công cụ hỗ trợ kiểm thử hiệu năng cho WS, bao gồm Testload trên Soap UI, JMeter và Load Runner Các công cụ này giúp đưa ra kết quả cho các tiêu chí về hiệu năng.
Thời gian phản hồi được tính bằng tổng thời gian truyền tải, thời gian chờ và thời gian xử lý Trong đó, thời gian truyền tải là khoảng thời gian để dữ liệu di chuyển qua đường truyền, thời gian chờ là thời gian mà yêu cầu đợi trong hàng đợi, và thời gian xử lý là thời gian thực tế để xử lý yêu cầu Để tính toán, chúng ta lấy 90% giá trị, tức là sắp xếp 100 mẫu từ nhỏ đến lớn và lấy giá trị trung bình của 90 mẫu đầu tiên Đơn vị thời gian có thể là giây, phút hoặc mili giây.
Thông lượng hệ thống, hay throughput, được định nghĩa là số lượng giao dịch mà hệ thống có thể xử lý trong một khoảng thời gian nhất định Đơn vị đo lường thông dụng cho thông lượng là giao dịch trên một khoảng thời gian, ví dụ như giao dịch mỗi giây (transactions per second) hoặc cuộc gọi mỗi ngày (calls per day).
Concurrency là số lượng giao dịch đồng thời mà hệ thống có khả năng xử lý, được đo bằng số giao dịch thực hiện cùng lúc Ví dụ, hệ thống có thể đáp ứng 200 giao dịch đồng thời hoặc 300 giao dịch đồng thời.
CPU usage: Hiệu suất sử dụng CPU Đơn vị là %
RAM usage: Hiệu suất sử dụng RAM Đơn vị là %
Tỉ lệ lỗi là tỷ lệ giữa số giao dịch không thành công và tổng số giao dịch đã thực hiện, được tính bằng phần trăm (%) Đây là một chỉ số quan trọng để đánh giá hiệu suất và là điều kiện cần thiết cho việc đạt được các mục tiêu đề ra.
Sau khi xác định các tham số tiêu chí kiểm thử hiệu năng, cần dựa vào chức năng của WS để xác định các mục tiêu quan trọng cần đánh giá.
Những chức năng có mật độ sử dụng cao: Trọng tâm vào cả 6 mục tiêu kiểm thử
Những chức năng có xử lý logic phức tạp: Trọng tâm vào mục tiêu CPU usage và Response time
Những chức năng là nghiệp vụ quan trọng: Trọng tâm vào cả 6 mục tiêu kiểm thử
Những chức năng chiếm dụng và tranh chấp tài nguyên cao.: Trọng tâm vào mục tiêu RAM usage và Throughput
Những chức năng sử dụng nhiều giao tiếp với các hệ thống ngoài: Trọng tâm vào mục tiêu Response time và Throughput
Lịch biểu kiểm thử: Thời gian và nguồn lực tham gia vào việc kiểm thử hiệu năng
Tiêu chuẩn thành công của một trường hợp kiểm thử hiệu năng là các tham số:
Response time, Throughput, Concurrency, CPU usage, RAM usage, Fail rate có thể chấp nhận được
Phải được tham khảo từ yêu cầu khách hàng, mô hình thiết kế, mô hình triển khai của ứng dụng
Phải thỏa mãn luật cơ sở: Concurrency ~ (xấp xỉ bằng) Throughput * Response time Trong đó Throughput và Response time phải có cùng thứ nguyên về thời gian
Khi kiểm thử hiệu năng, cần thực hiện ít nhất 5 lần với từng bộ dữ liệu khác nhau Sau mỗi lần kiểm thử, môi trường kiểm thử (bao gồm dữ liệu, ứng dụng và các yếu tố có thể ảnh hưởng đến hiệu năng) phải được reset Giá trị cuối cùng được tính theo công thức 90%.
Các giá trị như Think time và Pacing time trong kịch bản kiểm thử hiệu năng cần được xác định dựa trên khảo sát hoạt động thực tế hoặc dự báo hoạt động thực của ứng dụng.
XÂY DỰNG CÔNG CỤ HỖ TRỢ KIỂM THỬ DỊCH VỤ WEB
Mô tả và xây dựng bài toán
Hiện nay qua khảo sát ở một số công ty phần mềm thì việc thực hiện kiểm thử
WS chủ yếu được thực hiện thủ công với sự hỗ trợ của các công cụ như Soap UI, Jmeter và các công cụ do nhà phát triển WS tự xây dựng Một số công cụ hỗ trợ kiểm thử tự động WS bao gồm Parasoft SOAtest, Soapsonar và Quick Test Pro Tuy nhiên, việc áp dụng các phần mềm này gặp khó khăn do mã nguồn đóng và chi phí sử dụng cao.
Qua nghiên cứu về các kỹ thuật kiểm thử và lý thuyết kiểm thử dịch vụ web, tôi nhận thấy rằng hiện nay, việc kiểm thử dịch vụ web chủ yếu được thực hiện thủ công thông qua các công cụ có sẵn, nhưng hiệu quả chưa cao Đặc biệt, nhiều công ty vẫn đang sử dụng SoapUI mà không có công cụ hỗ trợ nào thực sự hiệu quả cho việc kiểm thử dịch vụ web.
Bước 1: Nhân viên kiểm thử viết testcase
Tại Trung tâm phần mềm Viễn thông Viettel, nhân viên kiểm thử phải phân tích tài liệu mô tả yêu cầu của cán bộ giải pháp để tạo ra các testcase theo luồng xử lý Hiện tại, việc này là bắt buộc và chưa có công cụ hỗ trợ tự động hóa quá trình tạo testcase, vì tài liệu mô tả hoàn toàn được viết bằng ngôn ngữ tự nhiên.
Bước 2: Thực hiện test thủ công bằng công cụ SoapUI
Hình ảnh dưới đây mô tả quy trình kiểm thử WS, trong đó kiểm tra các tham số đầu vào và xác minh xem các tham số đầu ra có đáp ứng yêu cầu của khách hàng hay không, sử dụng công cụ Soap UI.
Hình 3.1 Mô tả kiểm thử WS qua SoapUI
Bước 3: Kiểm tra kết quả và log lỗi nếu có
Nhân viên kiểm thử so sánh kết quả từ giao diện SoapUI với kết quả trong kịch bản testcase Nếu kết quả đúng, họ sẽ cập nhật kịch bản với trạng thái PASS Ngược lại, nếu phát hiện sai sót, lỗi sẽ được ghi lại trên hệ thống quản lý lỗi như Mantis, và nhân viên kiểm thử sẽ chờ đợi đội phát triển sửa lỗi.
Bước 4: Test lại sau khi fix lỗi
Thực hiện lại từ bước 2 cho đến khi tất cả lỗi đều được fix xong
Quá trình kiểm thử phần mềm thường phải lặp đi lặp lại cho đến khi không còn lỗi, điều này không chỉ tốn thời gian mà còn có thể gây ra sự nhàm chán Hơn nữa, việc lặp lại này không đảm bảo tính chính xác trong quá trình kiểm thử.
Kiểm thử dịch vụ web chủ yếu tập trung vào việc tạo dữ liệu đầu vào và xác minh dữ liệu đầu ra để đảm bảo đáp ứng đúng yêu cầu của khách hàng Quá trình này tương tự như kiểm thử hộp đen, trong đó kết quả đầu vào và đầu ra được định lượng một cách rõ ràng.
Việc phát triển công cụ hỗ trợ kiểm thử và kiểm thử lại là rất quan trọng Để đảm bảo dịch vụ web hoạt động hiệu quả, cần phải có bộ dữ liệu testcase chính xác và đầy đủ theo yêu cầu.
Hiện nay có khá nhiều nghiên cứu về việc xây dựng công cụ kiểm thử tự động cho
Các trường đại học trên thế giới, như Đại học Thanh Hoa Bắc Kinh và Đại học Ottawa, Canada, đang áp dụng những công cụ tiên tiến để cải thiện chất lượng giáo dục Cơ chế hoạt động chung của các công cụ này tập trung vào việc tối ưu hóa quy trình học tập và giảng dạy, nhằm mang lại hiệu quả cao hơn cho sinh viên và giảng viên.
Hình 3.2 Mô tả luồng xử lý công cụ tự động
Test Case Generator là công cụ tự động tạo test case dựa trên tài liệu WSDL, với khả năng lưu trữ các test case này trong một cơ sở dữ liệu tập trung Công cụ này cũng có thể mở rộng để hỗ trợ các chuẩn khác như BPEL4WS và OWL-S.
Test Execution Controller là công cụ quản lý quá trình thực thi các bài kiểm tra trong môi trường phân tán Nó thực hiện việc lấy các test case từ cơ sở dữ liệu, phân phối chúng đến các test agent, giám sát quá trình chạy test và thu thập kết quả một cách hiệu quả.
- Test Agents: là một proxy thực hiện test từ xa trên dịch vụ đích với dữ liệu test cho trước
- Test Analyzer: phân tích kết quả test, phỏng đoán chất lượng của dịch vụ và tạo báo cáo kết quả test
Mặc dù đã có nhiều nghiên cứu về kiểm thử tự động dịch vụ web (WS), nhưng vẫn thiếu một công cụ hiệu quả để thực hiện điều này Nhằm đáp ứng nhu cầu thực tế trong kiểm thử WS, luận văn này đề xuất xây dựng một công cụ hỗ trợ kiểm thử dịch vụ web trên nền tảng NET.
3.1.3 Sơ đồ chức năng hệ thống
Hình 3.3 Sơ đồ chức năng
Gồm 4 chức năng chính: a Quản lý Webservice: o Thêm mới: thêm Web service cần thực hiện test Thông tin bao gồm link Web service và mô tả o Sửa: cập nhật lại link hoặc mô tả về Web service hiện có o Xóa: xóa Web service hiện có o Xuất file testcase mẫu: tạo file excel chứa testcase mẫu của mỗi hàm Web service Người dùng sẽ sửa trên file này để tạo bộ testcase hoàn chỉnh rồi import lại Ở đây sẽ mô tả cho người dùng tham số đầu vào thuộc kiểu dữ liệu nào b Quản lý Testcase: o Thêm mới: thêm testcase cần thực hiện với từng Web service Có thể thêm trên giao diện, hoặc import từ file excel Thông tin testcase bao gồm:
Mã Web service tương ứng
Tham số đầu ra mong muốn
Độ quan trọng của testcase
Trong bài viết này, chúng tôi mô tả các chức năng quản lý testcase, bao gồm sửa thông tin testcase hiện có từ giao diện, xóa testcase không cần thiết và nhập testcase từ file Excel Để đảm bảo tính chính xác, file Excel cần được xuất từ chức năng quản lý Web service Ngoài ra, việc quản lý dữ liệu test cũng rất quan trọng, với các kiểu dữ liệu được gán với tham số trong testcase nhằm tự động sinh testcase Chức năng thêm mới cho phép người dùng bổ sung các kiểu dữ liệu mới vào hệ thống.
Mẫu dữ liệu (pattern): theo mẫu của regular expression và quy định của bộ thư viện Xeger [17]
Giá trị không thỏa mãn độ dài
Giá trị không thỏa mãn mẫu dữ liệu
Giá trị chứa ký tự đặc biệt
Giá trị thay đổi hoa bao gồm các thao tác như sửa thông tin các kiểu dữ liệu hiện tại, xóa kiểu dữ liệu và tạo testcase tự động Việc tạo testcase tự động liên quan đến việc gán các giá trị của kiểu dữ liệu cho tham số của testcase, trong đó các testcase được hình thành từ sự kết hợp của các trường hợp gán giá trị cho từng tham số.
Phân tích và đánh giá hệ thống
Người dùng có thể nhập, chỉnh sửa và xóa các liên kết dịch vụ web, cũng như quản lý các testcase bằng cách nhập, chỉnh sửa và xóa chúng Họ có khả năng chọn các testcase để thực hiện kiểm thử và xuất báo cáo kết quả kiểm thử một cách dễ dàng.
3.2.1.1.2 Danh sách các Use Case :
Use Case đối với người sử dụng:
Quản lý thông tin link Web service
Hình 3.5 Use Case quản lý thông tin web service
Hình 3.6 Quản lý thông tin testcase
Quản lý kiểu dữ liệu
Hình 3.7 Quản lý thông tin kiểu dữ liệu
Thực hiện kiểm thử và xuất ra kết quả
Hình 3.8 Use case thực hiện kiểm thử và xuất kết quả
3.2.1.2 Xây dựng biểu đồ Use Case của toàn hệ thống
Dựa trên danh sách diễn viên và các trường hợp sử dụng đã nêu, sơ đồ use case tổng quát của hệ thống thể hiện mối quan hệ giữa người sử dụng, người quản trị và các chức năng chính của hệ thống, bao gồm nhiều trường hợp sử dụng nhỏ bên trong.
3.2.1.3 Đặc tả danh sách các Use Case
3.2.1.3.1 Use Case Thêm mới thông tin Web service
Use case này cho phép người dùng có thể nhập và lưu lại thông tin về Web service bao gồm link, mô tả về Web service sẽ nhập
Thông tin link và nội dung Web service được người dùng nhập từ textbox
Dữ liệu link, mô tả Web service được lưu vào cơ sở dữ liệu
Kiểm tra nếu text nhập Webservice_id trên giao diện trống thì insert mới bản ghi vào database (bảng WEBSERVICE) Lúc đó button btnUpdate sẽ chuyển sang text =
- Link Web service: tương ứng với trường content của bảng WEBSERVICE
- Mô tả về Web service: tương ứng với trường description của bảng WEBSERVICE
- Câu lệnh insert: insert into Webservice values (@content, @description)
3.2.1.3.2 Use Case Chỉnh sửa thông tin Web service
Use case này cho phép người dùng có thể chỉnh sửa và lưu lại thông tin về Web service bao gồm link, mô tả về Web service chỉnh sửa
Thông tin link Web service người dùng chọn từ giao diện
Dữ liệu link, mô tả Web service thay đổi được lưu vào cơ sở dữ liệu
Kiểm tra trường Webservice_id, nếu không rỗng, tiến hành cập nhật liên kết và mô tả Web service theo Webservice_id trên giao diện vào bảng WEBSERVICE Khi đó, nút btnUpdate sẽ chuyển đổi văn bản thành „Cập nhật‟.
Câu lệnh update: update Webservice set content = @content, description =
@description where Webservice_id = @Webservice_id
3.2.1.3.3 Usecase Xóa thông tin Web service
Use case này cho phép người dùng có thể xóa thông tin về Web service bao gồm link, mô tả về Web service
Thông tin link Web service người dùng chọn từ giao diện
Dữ liệu link, mô tả Web service xóa khỏi cơ sở dữ liệu
Xóa thông tin Web service theo trường Webservice_id (bảng WEBSERVICE) Câu lệnh xóa: delete from Webservice where Webservice_id = @Webservice_id
3.2.1.3.4 Use case xuất mẫu import testcase
Use case này cho phép người dùng có thể xuất ra file mẫu để lập testcase
Thông tin Web service người dùng chọn từ giao diện
File excel lưu testcase mẫu của từng method
Bước 1: Từ thông tin địa chỉ Web service nhập vào, chương trình thực hiện đọc tài liệu wsdl để lấy thông tin của Web service bao gồm:
- Danh sách các hàm (operation)
- Tham số vào và kiểu dữ liệu
- Tham số ra và kiểu dữ liệu
Bước 2: lấy thông tin tên cột trong bảng INFORMATION_INPUT để tạo cột trong file mẫu excel Câu lệnh lấy tên cột:
Bước 3: Tạo testcase mẫu cho từng hàm Mỗi testcase cần nhập thông tin vào các cột: o Method: tên hàm; o Input: tham số đầu vào với định dạng tên_tham_số=kiểu_dữ_liệu, ghép nhiều tham số bằng dấu |; o Output_desirable: tham số đầu ra mong muốn, cũng theo định dạng tên_tham_số=kiểu_dữ_liệu, và ghép nhiều tham số bằng dấu |.
Bước 4: Xuất ra file excel cho nhân viên kiểm thử tạo testcase
3.2.1.3.5 Use case Thêm mới testcase
Use case này cho phép người dùng có thể thêm mới testcase vào hệ thống
Thông tin testcase nhập trên giao diện
Dữ liệu các testcase được lưu vào cơ sở dữ liệu
To add a new testcase to the database (INFORMATION_INPUT table) when the id field is empty, the button btnUpdate will change its text to "Add." The information to be inserted includes selecting ID, METHOD, INPUT, OUTPUT_RESULTS, OUTPUT_DESIRABLE, RESULTS, LEVEL, and DESCRIPTION from the information_input table The Webservice ID is chosen from a comboBox populated by the WEBSERVICE table The Method refers to the function name, while the Level indicates the importance of the testcase, selectable from a comboBox with two options: IMPORTANT and NOT IMPORTANT The Input consists of a list of parameters entered in a listView with two columns: param_name (parameter name) and param_value (parameter value), which will be concatenated according to the standard of the testcase template for database updates The Output represents the desired output parameters, also entered through a listView.
The article discusses the process of updating a database by using two columns: param_name (parameter name) and param_value (parameter value) These parameters are concatenated according to the format of a sample testcase file The insertion into the database is executed with the following SQL command: "INSERT INTO information_input (method, input, output_desirable, level, description, Webservice_id) VALUES (@method, @input, @output_desirable, @level, @description, @Webservice_id)."
3.2.1.3.6 Use case Chỉnh sửa Testcase
Use case này cho phép người dùng có thể chỉnh sữa dữ liệu các testcase trên hệ thống
Thông tin testcase người dùng chọn trên giao diện
Dữ liệu testcase chỉnh sửa được lưu vào cơ sở dữ liệu select Webservice_id, content, cast(Webservice_id as nvarchar(10)) + ' ' + description display from Webservice
Kiểm tra nếu trường id khác rỗng thì cập nhật lại các thông tin test case (bảng INFORMATION_INPUT) theo id Lúc đó button btnUpdate chuyển sang Text =
Câu lệnh update: update information_input set method = @method, input = @input, output_desirable = @output_desirable, level = @level, description = @description, Webservice_id = @Webservice_id where id = @id
Use case này cho phép người dùng có thể xóa dữ liệu các testcase trên hệ thống
Thông tin testcase người dùng chọn trên giao diện
Dữ liệu testcase được xóa khỏi cơ sở dữ liệu
Xóa testcase trong database (bảng INFORMATION_INPUT) theo testcase id Câu lệnh xóa: delete from information_input where id = @id
Use case này cho phép người dùng có thể import dữ liệu các testcase từ file excel vào hệ thống
File excel lưu danh sách testcase của một Web service
Dữ liệu testcase được insert và cơ sở dữ liệu
Giải thuật đọc file Excel theo đường dẫn và tên sheet yêu cầu dòng đầu tiên chứa tên cột tương ứng với tên cột trong cơ sở dữ liệu Kết quả import sẽ được hiển thị và kiểm tra các lỗi như: tên sheet không tồn tại, không có dữ liệu trong sheet, và các lỗi khác.
3.2.1.3.9 Use case Thêm mới kiểu dữ liệu
Use case này cho phép người dùng thêm kiểu dữ liệu mới vào hệ thống
Thông tin kiểu dữ liệu nhập trên giao diện
Các kiểu dữ liệu được lưu vào cơ sở dữ liệu
To add a new data type to the database table TYPES when the id field is empty, the button btnUpdate will change its text to "Add." The information to be inserted includes: Type_name (the name of the data type), Sub_type (the base data type), Pattern (the data format following the regular expression standard and the Xeger library guidelines), Default_value (the default value), Wrong_length (the value that does not meet the length requirement), Wrong_type (the value that does not conform to the data pattern), Special_char (the value containing special characters), and Change_case (the value that changes between uppercase and lowercase) The insert command will be structured as follows: insert into [types] (type_name, sub_type, pattern, default_value, wrong_length, wrong_type, special_char, change_case) values.
(@type_name,@sub_type,@pattern,@default_value,@wrong_length,@wrong_ty pe,@special_char,@change_case)
3.2.1.3.10 Use case Chỉnh sửa kiểu dữ liệu
Use case này cho phép người dùng có thể chỉnh sửa cấu hình kiểu dữ liệu trên hệ thống
Thông tin kiểu dữ liệu người dùng chọn trên giao diện
Cấu hình kiểu dữ liệu được chỉnh sửa được lưu vào database
Kiểm tra trường id, nếu không rỗng, tiến hành cập nhật thông tin kiểu dữ liệu trong bảng TYPES theo type_id Khi đó, nút btnUpdate sẽ chuyển sang văn bản "Cập nhật".
The SQL update command allows you to modify specific fields in a database table, such as type_name, sub_type, pattern, default_value, wrong_length, wrong_type, special_char, and change_case, by specifying the corresponding values This command targets a particular record identified by its type_id, ensuring that the intended entry is updated accurately.
3.2.1.3.11 Use case Xóa kiểu dữ liệu
Use case này cho phép người dùng có thể xóa các kiểu dữ liệu cấu hình trên hệ thống
Thông tin kiểu dữ liệu người dùng chọn trên giao diện
Cấu hình kiểu dữ liệu được xóa khỏi cơ sở dữ liệu
Xóa kiểu dữ liệu trong database (bảng TYPES) theo type_id Câu lệnh xóa:
3.2.1.3.12 Use case tạo testcase tự động
Use case này cho phép người dùng gán giá trị của kiểu dữ liệu trong cấu hình cho các tham số của Web service, từ đó tạo ra bộ testcase tự động hiệu quả.
Thông tin kiểu dữ liệu và tham số đầu vào của web service
Dữ liệu bộ testcase có giá trị của tham số đầu vào
Để tạo ra các giá trị cho từng tham số đầu vào của Web service, cần thực hiện theo các bước sau: đầu tiên, xác định giá trị mặc định nếu có; tiếp theo, tạo giá trị ngẫu nhiên dựa trên quy tắc của pattern bằng cách sử dụng thư viện xeger; cuối cùng, xác định giá trị biên để đảm bảo tính toàn diện trong kiểm thử.
Kiểu String: biên là giá trị ngẫu nhiên có độ dài min và max
Kiểu số bao gồm giá trị tối thiểu và tối đa, đồng thời cần kiểm tra độ dài và kiểu dữ liệu nếu có cấu hình Khi thay đổi giữa chữ hoa và chữ thường, cũng như khi bao gồm ký tự đặc biệt, các giá trị này cần được xác định rõ Ghép nối các giá trị đầu vào này một cách tuần tự sẽ tạo thành bộ testcase hoàn chỉnh.
Sau khi tạo bộ testcase được lưu vào database (bảng INFORMATION_INPUT) thêm vào các testcase hiện có delete from [types] where type_id = @ type_id
3.2.1.3.13 Use case Thực hiện kiểm thử
Use case này cho phép người dùng có thể chọn link Web service và bộ testcase để thực hiện kiểm thử tự động
Thông tin Web service và bộ testcase được chọn trên giao diện
Dữ liệu bộ testcase có kết quả sau khi thực hiện kiểm thử tự động
Quét toàn bộ testcase được tích chọn trên giao diện, thực hiện nạp giá trị cho các input để gửi request lên Web service
Kết quả trả về lọc lấy các giá trị output, so sánh với trường output_desirable để cho kết quả PASS hay NOT PASS
Tổng hợp kết quả test: tổng số testcase thực hiện test, số testcase không test, số testcase PASS, số testcase NOT PASS
Dữ liệu sau khi test được lưu lại trên database (bảng INFORMATION_INPUT)
3.2.1.3.14 Use case Xuất báo cáo
Use case này cho phép người dùng có thể chọn các testcase sau khi thực hiện kiểm thử để xuất ra fie excel
Thông tin các testcase được chọn trên giao diện
File excel xuất ra khớp với dữ liệu hiển thị trên giao diện được chọn
Export test results to an Excel file (xls or xlsx) by retrieving data from the INFORMATION_INPUT table using the query: select ID, METHOD, INPUT, OUTPUT_RESULTS, OUTPUT_DESIRABLE, RESULTS, LEVEL, DESCRIPTION from information_input where Webservice_id = @wsId.
3.2.2 Thiết kế một số giao diện của hệ thống 3.2.2.2 Giao diện chính của phần mềm
Hình 3.9 Giao diện chính của phần mềm
3.2.2.3 Giao diện danh mục quản lý Web service
Hình 3.10 Giao diện danh mục quản lý Web service
3.2.2.4 Giao diện danh mục quản lý testcase
Hình 3.11 Giao diện danh mục quản lý testcase
3.2.2.5 Giao diện màn hình import testcase
Hình 3.12 Giao diện màn hình import testcase
3.2.2.6 Giao diện màn hình cấu hình kiểu dữ liệu
Hình 3.13 Giao diện màn hình cấu hình kiểu dữ liệu
3.2.2.7 Giao diện màn hình tạo testcase tự động
Hình 3.14 Giao diện màn hình tạo testcase tự động
3.2.3 Cài đặt, triển khai hệ thống 3.2.3.2 Mô hình triển khai hệ thống
Sử dụng chung SQL server để cấu hình testcase và Web service
Mỗi tester có kết nối để test đồng thời nhiều Web service
Hình 3.15 Mô hình triển khai
- Cài đặt SQL Server trên máy chủ dữ liệu
- Cài đặt NET và phần mềm test trên máy cá nhân
1 máy chủ để lưu cơ sở dữ liệu testcase và Web service
- Các máy cá nhân dành cho tester
- Các máy chủ cài đặt Web service cần test
Dựa trên phân tích và xây dựng công cụ, tôi đã thử nghiệm với một số Web service như cộng trừ và xem thông tin, cho kết quả chính xác Hiện tại, tôi đã áp dụng thực tế tại Trung tâm phần mềm viễn thông Viettel với các Web service đơn giản như kiểm tra thông tin thuê bao và lấy danh sách gói dịch vụ thuê bao hưởng khuyến mãi Bài viết này sẽ trình bày chi tiết về bài toán kiểm tra thông tin thuê bao.
Kết luận
Chương này trình bày chi tiết các yêu cầu và tính năng cần có của công cụ kiểm thử Web service, bao gồm các thành phần, đầu vào và đầu ra giúp người nghiên cứu và phát triển hệ thống hiểu rõ luồng thực hiện và chức năng tổng quan Công cụ này khác biệt so với các công cụ hiện có, do đó người dùng cần thời gian và kiến thức đào tạo để sử dụng hiệu quả Sau khi nắm vững tính năng, người dùng sẽ tiến hành thử nghiệm và đánh giá hệ thống thực tế, nhằm đưa ra nhận xét khách quan dựa trên kinh nghiệm và quá trình đào tạo Kết quả khảo sát sẽ giúp nhà phát triển nhận phản hồi để cải thiện và điều chỉnh tính năng của hệ thống, đáp ứng tốt hơn nhu cầu người dùng.
KẾT LUẬN VÀ ĐỀ XUẤT
Sau thời gian làm việc chăm chỉ và dưới sự hướng dẫn tận tình của TS Nguyễn Đức Dũng, tôi đã hoàn thành Luận văn của mình.
Những nội dung chính đã đƣợc giải quyết trong luận văn:
Kiểm thử phần mềm là hoạt động thiết yếu để đảm bảo chất lượng sản phẩm Nghiên cứu và lựa chọn các kỹ thuật cùng chiến lược kiểm thử phù hợp không chỉ nâng cao hiệu quả kiểm thử mà còn giúp tiết kiệm chi phí và thời gian Đặc biệt, kiểm thử bảo mật và hiệu năng là những yếu tố quan trọng cần được chú trọng khi thực hiện kiểm thử dịch vụ web.
Công nghệ dịch vụ web đang ngày càng phát triển mạnh mẽ, mang lại nhiều lợi ích cho doanh nghiệp và người dùng Tuy nhiên, việc kiểm thử thủ công truyền thống gặp nhiều khó khăn và tốn thời gian Do đó, cần thiết phải có một công cụ hỗ trợ kiểm thử hiệu quả hơn, nhằm nâng cao chất lượng dịch vụ và giảm thiểu rủi ro trong quá trình phát triển ứng dụng web.
Xây dựng công cụ hỗ trợ kiểm thử tự động cho dịch vụ web đơn giản, cung cấp phương pháp tạo testcase tự động Công cụ này hỗ trợ các công ty, tổ chức giải quyết bài toán kiểm thử dịch vụ web và đã được áp dụng thực tiễn tại Trung tâm phần mềm viễn thông Viettel.
Hiện nay, việc kiểm thử phần mềm vẫn chưa được đầu tư đúng mức tại Việt Nam, điều này có thể dẫn đến xác suất thất bại cao và tổn thất lớn trong ngành công nghiệp phần mềm đang phát triển Các công ty phần mềm uy tín yêu cầu phần mềm phải được kiểm thử và có tài liệu kiểm thử kèm theo, do đó, việc phát triển các công cụ hỗ trợ kiểm thử để nâng cao chất lượng phần mềm là rất cần thiết.
Việc ứng dụng công cụ phần mềm tự động trong kiểm thử dịch vụ web sẽ giảm bớt công sức cho nhân viên kiểm thử và nâng cao chất lượng phần mềm Trong bối cảnh Việt Nam, với sự gia tăng tỷ trọng gia công phần mềm tại các công ty, các doanh nghiệp phần mềm nên chú trọng nghiên cứu, đầu tư và áp dụng các công cụ hỗ trợ kiểm thử để cải thiện hiệu quả công việc.