Luận Văn: Nghiên Cứu Kiểm Thử Dựa Trên Mô Hình và Ứng Dụng - ĐH Quốc Gia Hà Nội

Luận văn thạc sĩ: Nghiên cứu chuyên sâu về kiểm thử dựa trên mô hình, khám phá các ứng dụng thực tế và hiệu quả. Tìm hiểu phương pháp kiểm thử tiên tiến.

Chuyên ngành

Công Nghệ Thông Tin

Người đăng

Ẩn danh

Thể loại

Luận Văn Thạc Sĩ

2015

58
1
0

Phí lưu trữ

30 Point

Mục lục chi tiết

LỜI CAM ĐOAN

DANH MỤC THUẬT NGỮ VIẾT TẮT

DANH MỤC HÌNH VẼ

DANH MỤC BẢNG

1. Chương 1: Giới thiệu

2. Chương 2: Phương pháp đặc tả tương tác giao diện cho các ứng dụng Web

2.1. Đặc tả tương tác giao diện của từng trang Web bằng ôtômát hữu hạn trạng thái

2.2. Xây dựng mô hình đặc tả tương tác giao diện cho toàn bộ ứng dụng Web

3. Chương 3: Sinh và thực thi các ca kiểm thử tự động

3.1. Sinh các ca kiểm thử từ mô hình đặc tả hình thức

3.1.1. Đường dẫn kiểm thử

3.1.2. Thuật toán sinh tự động các đường dẫn kiểm thử

3.2. Thực hiện các ca kiểm thử

3.3. Đánh giá phương pháp

4. Chương 4: Công cụ và thực nghiệm

4.1. Giới thiệu các công cụ bổ trợ

4.1.1. Giới thiệu Selenium và một số API WebDriver được sử dụng

4.1.2. Giới thiệu Jsoup

4.2. Giới thiệu công cụ kiểm thử tự động tương tác giao diện cho các ứng dụng Web

4.2.1. Kiến trúc của công cụ

4.2.2. Đầu vào của công cụ

4.2.3. Đầu ra của công cụ

4.2.4. Kết quả cải tiến công cụ

4.2.5. Ý nghĩa của công cụ thực nghiệm

5. Chương 5: KẾT LUẬN

TÀI LIỆU THAM KHẢO

LỜI CẢM ƠN

Tóm tắt

I. Tổng Quan Kiểm Thử Dựa Trên Mô Hình Nghiên Cứu Ứng Dụng

Trong ngành công nghiệp phát triển phần mềm ngày nay, hầu hết các phần mềm ứng dụng đều được phát triển trên nền Web. Do đó, 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 quan trọng. Tuy nhiên, các ứng dụng Web ngày càng trở nên phức tạp, việc kiểm thử thủ công bao gồm cả tạo các ca kiểm thử và thực thi chúng trên các trang Web, là công việc rất tốn kém về thời gian và công sức. Hơn nữa, mỗi khi có sự cập nhật lại phiên bản của phần mềm, để tránh rủi ro phát sinh lỗi trong khi thay đổi mã nguồn thì các kiểm thử viên phải kiểm thử lại toàn bộ phần mềm, kể cả các tính năng đã được kiểm thử tốt. Vì vậy, để hoàn thành công việc kiểm thử đúng tín độ, 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ự động hóa các hoạt động kiểm thử. Kiểm thử tự động là một giải pháp hữu hiệu nhằm nâng cao tính chính xác và hiệu quả, cũng như giảm kinh 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 [1]. Kiểm thử dựa trên mô hình đang được xem như là một phương pháp kiểm thử có khả năng tự động hóa cao. Kiểm thử dựa trên mô hình là một phương pháp kiểm thử, trong đó các ca kiểm thử được sinh ra từ mô hình đặc tả hành vi của hệ thống đang được kiểm thử [1]. Vì vậy, kiểm thử dựa trên mô hình được ứng dụng để giải quyết một số vấn đề khó khăn trong hoạt động kiểm thử các sản phẩm phần mềm. Một trong những ứng dụng của nó là kiểm thử tương tác giao diện người dùng cho các ứng dụng Web. Để ứng dụng phương pháp kiểm thử này, trước tiên chúng ta cần xây dựng mô hình đặc tả hành vi tương tác giao diện của ứng dụng Web. Mô hình này thường được biểu diễn bằng máy hữu hạn trạng thái hoặc ôtômát hữu hạn trạng thái. Tiếp đến, các ca kiểm thử được tự động sinh ra từ mô hình. Cuối cùng, các ca kiểm thử này được thực thi trên ứng dụng nhằm phát hiện các lỗi lập trình liên quan đến tương tác giao diện người dùng. Trong thực tế, có rất nhiều hướng nghiên cứu về kiểm thử dựa trên mô hình cho ứng dụng Web như kiểm thử khả năng chịu tải, tính bảo mật, hiệu năng, kiểm thử chức năng, v. Tuy nhiên, việc kiểm thử chức năng (theo luồng tương tác giao diện người dùng) vẫn 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 kiểm thử chức năng ứng dụng Web [4,5,9]. Mặc dù vậy, các nghiên cứu này mới chỉ thực hiện kiểm thử tự động cho từng trang Web, hoặc cho các Website tĩnh [5] mà chưa có nhiều nghiên cứu hỗ trợ cho kiểm thử luồng tương tác người dùng. Trong số đó, phương pháp và công cụ kiểm thử tự động cho các ứng dụng Web được đề xuất bởi [5] đã giải quyết được một phần vấn đề nêu trên. Tuy nhiên, phương pháp này chỉ thực hiện kiểm thử được cho một số phần tử Web cơ bản và chúng phải có thuộc tính id định danh. Trong khi, các hệ thống ứng dụng Web thực tế cần một công cụ kiểm thử tự động, có khả năng kiểm thử được cho nhiều loại phần tử Web và các phần tử Web đó được thiết kế một cách linh động.

1.1. Tầm Quan Trọng của Kiểm Thử Tự Động Ứng Dụng Web

Kiểm thử tự động mang lại nhiều lợi ích đáng kể cho quá trình phát triển phần mềm. Thay vì kiểm thử thủ công tốn thời gian và công sức, kiểm thử tự động giúp tăng tốc độ kiểm thử, giảm chi phí, và cải thiện độ chính xác. Điều này đặc biệt quan trọng đối với các ứng dụng Web phức tạp, nơi mà việc kiểm thử toàn diện có thể gặp nhiều khó khăn. Bên cạnh đó, kiểm thử tự động còn giúp các nhà phát triển dễ dàng phát hiện và sửa lỗi sớm trong quá trình phát triển, từ đó giảm thiểu rủi ro và nâng cao chất lượng sản phẩm. Trong bối cảnh các ứng dụng Web ngày càng trở nên quan trọng và phức tạp, việc áp dụng kiểm thử tự động là một yếu tố then chốt để đảm bảo sự thành công của dự án.

1.2. Giới Thiệu Phương Pháp Kiểm Thử Dựa Trên Mô Hình MBT

Kiểm thử dựa trên mô hình (MBT) là một phương pháp kiểm thử mạnh mẽ, trong đó các ca kiểm thử được tự động sinh ra từ một mô hình đặc tả hành vi của hệ thống. Mô hình này thường được xây dựng bằng các công cụ như máy hữu hạn trạng thái (FSA) hoặc ôtômát hữu hạn trạng thái. Ưu điểm của MBT là khả năng tự động hóa cao, giúp giảm thiểu công sức thủ công và tăng độ bao phủ kiểm thử. MBT cũng cho phép các nhà kiểm thử dễ dàng tạo ra các ca kiểm thử phức tạp và đa dạng, giúp phát hiện các lỗi tiềm ẩn mà kiểm thử thủ công có thể bỏ sót. Phương pháp này đặc biệt hữu ích trong việc kiểm thử tương tác giao diện người dùng cho các ứng dụng Web, nơi mà các hành vi tương tác có thể rất phức tạp và khó kiểm soát.

II. Cách Xây Dựng Mô Hình Kiểm Thử Dựa Trên Ôtômát Trạng Thái

Để áp dụng phương pháp kiểm thử dựa trên mô hình, chúng ta cần xây dựng mô hình đặc tả chính xác hành vi của hệ thống cần kiểm thử. Mô hình là một sự biểu đồ hóa, mô tả chi tiết hệ thống, đồng thời mô tả chi tiết các khía cạnh, các đặc tính của hệ thống. Mô hình cần phải đủ chi tiết để giúp ta hiểu và đoán nhận được hành vi của hệ thống. Có nhiều phương pháp đặc tả mô hình như: máy hữu hạn trạng thái, ôtômát trạng thái, máy trạng thái UML, chuỗi Markov, văn phạm, bảng quyết định, v. Phụ thuộc vào phương pháp và công cụ kiểm thử, chúng ta sẽ lựa chọn phương pháp đặc tả hệ thống tương ứng. Trong chương 2, chúng tôi chỉ trình bày một phương pháp đặc tả tương tác giao diện ứng dụng Web được sử dụng cho nghiên cứu này. Theo quy trình kiểm thử dựa trên mô hình [1] thì việc đầu tiên chúng ta phải làm trong số các hoạt động kiểm thử tự động ứng dụng Web đó là xây dựng mô hình đặc tả hành vi của ứng dụng Web. Có nhiều hành vi có thể được sử dụng để đặc tả nhưng trong luận văn này, chỉ đề cập đến hành vi tương tác của người dùng đối với hệ thống ứng dụng Web, thông qua sự thay đổi trạng thái (hay sự thay đổi giao diện) của ứng dụng Web [5]. Chúng tôi dùng ôtômát trạng thái làm phương pháp đặc tả hình thức giao diện ứng dụng Web. Khi đó, mỗi giao diện người dùng của một trang Web, tại một thời điểm được mô hình hóa như là một trạng thái. Mỗi yêu cầu của người dùng được mô hình hóa như là một hành động tạo ra hàm chuyển trạng thái. Vậy, để mô hình hóa các hành vi tương tác giao diện người dùng ứng dụng Web như là một ôtômát trạng thái, chúng tôi cần thực hiện các bước sau: (1) Chia nhỏ hệ thống thành các mô-đun; (2) với mỗi mô-đun chúng ta cần xác định các giao diện người dùng; (3) với mỗi giao diện người dùng được đặc tả bằng một ôtômát trạng thái; (4) nối các ôtômát trạng thái đó lại thành một bản đặc tả hoàn chỉnh cho cả hệ thống.

2.1. Các Bước Xây Dựng Mô Hình Ôtômát Hữu Hạn Trạng Thái FSA

Để xây dựng mô hình FSA cho một ứng dụng Web, bạn cần thực hiện các bước sau: (1) Chia nhỏ hệ thống thành các mô-đun nhỏ hơn. (2) Xác định các giao diện người dùng (trang Web) trong mỗi mô-đun. (3) Đặc tả mỗi giao diện người dùng bằng một FSA. Mỗi giao diện người dùng tại một thời điểm được mô hình hóa như là một trạng thái. Mỗi hành động của người dùng được mô hình hóa như là một sự kiện gây ra sự thay đổi trạng thái. (4) Ghép nối các FSA của từng giao diện lại với nhau để tạo thành một bản đặc tả hoàn chỉnh cho toàn bộ hệ thống.

2.2. Cách Biểu Diễn Mô Hình FSA Bằng Các Tệp Tin MS Excel

Để biểu diễn mô hình FSA một cách trực quan và dễ quản lý, bạn có thể sử dụng các tệp tin MS Excel. Mỗi tệp tin Excel sẽ tương ứng với một FSA đặc tả cho một trang Web. Trong mỗi tệp tin Excel, bạn cần tạo các bảng sau: (1) Bảng Element_html: Mô tả các phần tử Web của trang Web. (2) Bảng State: Mô tả các trạng thái của trang Web, mỗi trạng thái là tập hợp các trạng thái của các phần tử Web. (3) Bảng Event: Mô tả các sự kiện, mỗi sự kiện là một hành vi tương tác của người dùng. (4) Bảng Transition: Mô tả các hàm chuyển trạng thái giữa các trạng thái.

2.3. Ví Dụ Minh Họa Trang Tìm Kiếm Cán Bộ

Xét ví dụ về trang tìm kiếm cán bộ. Bảng Element_html sẽ chứa các thông tin về các phần tử như ô nhập họ tên, ô nhập số hiệu, nút tìm kiếm. Bảng State sẽ chứa các trạng thái như "trạng thái ban đầu", "đã nhập họ tên", "đã nhập số hiệu", và "kết quả tìm kiếm". Bảng Event sẽ chứa các sự kiện như "nhập họ tên", "nhập số hiệu", "click tìm kiếm". Bảng Transition sẽ mô tả cách các trạng thái thay đổi khi các sự kiện xảy ra, ví dụ, khi người dùng nhập họ tên (sự kiện "nhập họ tên") từ "trạng thái ban đầu" sẽ chuyển sang "đã nhập họ tên".

III. Thuật Toán Sinh Ca Kiểm Thử Tự Động Từ Mô Hình FSA

Khi chúng ta đã xây dựng được mô hình đặc tả chính xác hành vi của hệ thống, một trong những công việc khó khăn còn lại là làm thế nào để sinh được các ca kiểm thử từ mô hình này [1]. Để làm việc này, với mỗi mô hình được đặc tả bằng FSA, chúng ta có thể coi nó như là một đồ thị chuyển trạng thái và áp dụng một trong các phương pháp: duyệt ngẫu nhiên, duyệt theo chiều sâu hoặc duyệt theo chiều rộng trên đồ thị đó, thông qua các trạng thái và các chuyển trạng thái giữa chúng. Một đường đi từ trạng thái khởi tạo đến một trạng thái kết thúc tương ứng với một ca kiểm thử chúng ta muốn tạo ra [1]. Để đảm bảo tất cả các đường đi có thể trong FSA phải được kiểm thử, chúng ta có thể áp dụng các thuật toán duyệt FSA theo chiều rộng hoặc theo chiều sâu [1]. Trong nghiên cứu này, chúng tôi áp dụng thuật toán duyệt đồ thị theo chiều sâu nhằm liệt kê tất cả các đường đi có thể trong FSA. Chi tiết các bước của thuật toán tìm kiếm theo chiều sâu (Depth First Search) được trình bày trong thuật toán 1 [5].

3.1. Mô Tả Thuật Toán Duyệt Đồ Thị Theo Chiều Sâu DFS

Thuật toán DFS (Depth First Search) là một thuật toán duyệt đồ thị phổ biến, được sử dụng để tìm kiếm tất cả các đường đi có thể trong một đồ thị. Trong ngữ cảnh kiểm thử dựa trên mô hình, đồ thị là mô hình FSA, các đỉnh là các trạng thái, và các cạnh là các chuyển trạng thái. Thuật toán DFS bắt đầu từ trạng thái khởi tạo và đi sâu vào từng nhánh của đồ thị cho đến khi không còn đường đi nào nữa. Sau đó, thuật toán quay lại và tiếp tục duyệt các nhánh khác. Bằng cách này, DFS đảm bảo rằng tất cả các trạng thái và chuyển trạng thái trong FSA đều được duyệt qua, giúp tạo ra các ca kiểm thử bao phủ toàn bộ hệ thống.

3.2. Cách Hoàn Thiện Đường Dẫn Kiểm Thử Với Thuật Toán ADD_Path

Thuật toán DFS có thể tạo ra các đường dẫn kiểm thử mà trạng thái kết thúc không phải là trạng thái kết thúc của đồ thị. Để giải quyết vấn đề này, thuật toán ADD_Path được sử dụng để hoàn thiện các đường dẫn kiểm thử. Thuật toán ADD_Path duyệt qua từng đường dẫn kiểm thử và kiểm tra xem trạng thái cuối cùng có phải là trạng thái kết thúc hay không. Nếu không, thuật toán sẽ tìm các cạnh của đồ thị có đỉnh bắt đầu là trạng thái cuối cùng của đường dẫn kiểm thử và thêm các cạnh này vào đường dẫn cho đến khi trạng thái cuối cùng là trạng thái kết thúc.

3.3. Ví Dụ Về Sinh Đường Dẫn Kiểm Thử cho Trang Tìm Kiếm Cán Bộ

Sử dụng thuật toán DFS, ta có thể sinh các đường dẫn như: INDEX -> add_hoten -> TEN -> Timkiem -> KETQUA_TK. Nếu KETQUA_TK không phải trạng thái kết thúc, thuật toán ADD_Path sẽ tìm và thêm các chuyển tiếp từ KETQUA_TK đến trạng thái kết thúc khác. Kết quả là một tập hợp các đường dẫn kiểm thử bao phủ các chức năng tìm kiếm theo họ tên, số hiệu và đơn vị.

IV. Thực Thi Ca Kiểm Thử Tự Động và Đánh Giá Phương Pháp

Chúng ta sẽ thực thi các ca kiểm thử được sinh ra từ thuật toán trên nhằm phát hiện các lỗi lập trình so với đặc tả (mô hình hệ thống). Đầu tiên, chúng ta phải cài đặt hệ thống dựa trên mô hình đã được đặc tả. Khi đã cài đặt xong chương trình, chúng ta sẽ tiến hành thực thi các ca kiểm thử. Chúng ta có thể thực hiện công việc này một cách thủ công hoặc tự động dựa vào các công cụ hỗ trợ sẵn có. Dưới sự hỗ trợ của hai công cụ Selenium và Jsoup (chi tiết về việc sử dụng hai công cụ hỗ trợ này sẽ được giới thiệu trong chương 4), chúng tôi thực hiện các ca kiểm thử một cách tự động theo các bước sau: Bước 1: Tách đường dẫn kiểm thử thành các đường dẫn kiểm thử nhỏ (transition). Mỗi đường dẫn kiểm thử nhỏ chỉ bao gồm: * = . Bước 2: Thực hiện từng đường dẫn nhỏ. Phương pháp sẽ kết nối với trang Web thông qua Selenium, dùng Selenium và Jsoup để xác định trạng tháii của trang Web. Nếu xác định trạng thái thành công, tiếp tục dùng hai công cụ bổ trợ trên để xác định vị trí phần tử Web và thực hiện sự kiện. Cuối cùng, xác định trạng thái của trang Web sau khi đã thực hiện sự kiện, bằng cách lấy các giá trị của các phần tử Web tương ứng với trạng thái này (trạng thái Web thực tế), so sánh với giá trị trạng thái của trang Web trong bản đặc tả (trạng thái Web mong muốn) và chuyển sang bước 3. Ngược lại thì dừng thực hiện và chuyển sang bước 4. Bước 3: Nếu kết quả so sánh trên trùng nhau thì tiếp tục lặp lại hai bước trên cho đường dẫn con tiếp theo. Ngược lại, thì kết thúc việc thực hiện đường dẫn lớn và chuyển sang bước 4. Bước 4: Kết luận về kết quả thực hiện đường dẫn kiểm thử.

4.1. Các Bước Thực Hiện Kiểm Thử Tự Động Với Selenium và Jsoup

Để thực hiện kiểm thử tự động, bạn cần (1) Tách đường dẫn kiểm thử thành các transition nhỏ. (2) Với mỗi transition, sử dụng Selenium kết nối tới trang Web. (3) Sử dụng Selenium và Jsoup để xác định trạng thái của trang Web. (4) Nếu trạng thái khớp, sử dụng Selenium thực hiện sự kiện. (5) Sử dụng Selenium và Jsoup xác định trạng thái mới sau sự kiện. (6) So sánh trạng thái thực tế với trạng thái mong muốn từ mô hình. (7) Nếu khớp, tiếp tục với transition tiếp theo; nếu không, báo lỗi.

4.2. Đánh Giá Ưu Nhược Điểm của Phương Pháp Sử Dụng FSA

Phương pháp đặc tả bằng FSA là phổ biến, nhưng có nhược điểm là trở nên phức tạp với ứng dụng lớn. Việc quản lý số lượng lớn trạng thái và chuyển trạng thái có thể gây khó khăn. Cần có chuyên gia phân tích hệ thống tốt. Sinh số lượng lớn các testpath không có lỗi.

4.3. So sánh với đặc tả mô hình bằng UML state machine

Với các hệ thống lớn, đặc tả mô hình bằng UML state machine là một giải pháp thay thế tốt hơn do khả năng biểu diễn các hệ thống phức tạp một cách có cấu trúc và trực quan hơn. UML state machine cho phép mô hình hóa các hệ thống có nhiều trạng thái, các sự kiện kích hoạt chuyển đổi và các điều kiện để chuyển đổi giữa các trạng thái. Mặc dù việc sử dụng UML state machine có thể đòi hỏi một số kiến thức về UML và các công cụ hỗ trợ, nó mang lại nhiều lợi ích trong việc quản lý sự phức tạp và đảm bảo tính chính xác của mô hình.

V. Công Cụ Kiểm Thử Tự Động Giao Diện Web Kiến Trúc và Kết Quả

Chương 2, chương 3 đã trình bày phương pháp đặc tả hình thức giao diện ứng dụng Web bằng ôtômát hữu hạn trạng thái, phương pháp sinh tự động các ca kiểm thử bằng cách duyệt đồ thị trạng thái. Nội dung của chương 4 sẽ trình bày về công cụ kiểm thử tự động tương tác giao diện các ứng dụng Web được xây dựng từ các phương pháp trong chương 2, 3 và trình bày kết quả thực nghiệm. Trước tiên, chúng tôi sẽ giới thiệu về hai công cụ bổ trợ chính. Một là, giới thiệu về Selenium, một số API WebDriver chính của Selenium được sử dụng để thực hiện tương tác với các phần tử Web. Hai là, giới thiệu Jsoup và các hàm chính được sử dụng. Tiếp theo, chúng tôi sẽ trình bày về công cụ kiểm thử tự động tương tác giao diện ứng dụng Web. Cuối chương sẽ đưa ra một ứng dụng Web và kết quả kiểm thử ứng dụng này bằng công cụ kiểm thử tự động của chúng tôi.

5.1. Kiến Trúc và Quy Trình Hoạt Động của Công Cụ Kiểm Thử

Công cụ nhận đầu vào là địa chỉ của ứng dụng Web và thư mục chứa các tệp tin Excel đặc tả. Sau đó, công cụ mô hình hóa hệ thống thành các FSA, ghép nối chúng, sinh ca kiểm thử, kết nối với ứng dụng Web bằng Selenium, và chạy các ca kiểm thử. Kết quả được xuất ra tệp Excel báo cáo thành công/thất bại.

5.2. Cách Tổ Chức và Sử Dụng Tệp Tin Excel Làm Đầu Vào

Ứng dụng Web được đặc tả thành nhiều tệp Excel, mỗi tệp cho một giao diện tương tác. Các tệp được đánh số thứ tự thực hiện. Công cụ đọc và xây dựng FSA từ các tệp này.Việc xây dựng các tệp tin đầu vào yêu cầu người thiết kế phải có kỹ năng về phân tích, thiết kế hệ thống và phải hiểu rõ chi tiết hoạt động của hệ thống thì mới xây dựng được các tệp tin tốt (có khả năng tìm được tối đa lỗi của ứng dụng Web).

5.3. Ứng Dụng Web Quản Lý Thông Tin Cán Bộ Thử Nghiệm Thực Tế

Một ứng dụng Web Quản lý thông tin cán bộ sẽ được sử dụng để thử nghiệm. Ứng dụng này bao gồm các trang: Đăng nhập, Quản trị, Danh sách User, Quản lý TTCB, Tìm kiếm TTCB, Thêm mới TTCB, Cập nhật TTCB. Các trang được mô hình hóa bằng FSA và kết quả kiểm thử được đánh giá.

VI. Kết Luận và Hướng Phát Triển Kiểm Thử Dựa Trên Mô Hình

Trong luận văn này, chúng tôi đã trình bày về phương pháp kiểm thử dựa trên mô hình cho các ứng dụng Web. Phương pháp này sử dụng ôtômát hữu hạn trạng thái (FSA) để đặc tả hành vi tương tác của người dùng trên giao diện Web. Các ca kiểm thử được sinh tự động từ mô hình FSA, giúp giảm thiểu công sức thủ công và tăng độ bao phủ kiểm thử. Chúng tôi cũng đã xây dựng một công cụ kiểm thử tự động tương tác giao diện, sử dụng Selenium và Jsoup để thực thi các ca kiểm thử và phát hiện các lỗi lập trình. Tuy nhiên, phương pháp này vẫn còn một số hạn chế, đặc biệt là đối với các ứng dụng Web lớn và phức tạp. Trong tương lai, chúng tôi sẽ tập trung vào việc cải tiến phương pháp đặc tả mô hình, sử dụng các công cụ hỗ trợ biểu diễn FSA và tạo tự động các bảng Transition. Chúng tôi cũng sẽ nghiên cứu các phương pháp sinh ca kiểm thử hiệu quả hơn, tập trung vào việc tìm kiếm các lỗi tiềm ẩn trong ứng dụng Web.

6.1. Tổng Kết Các Kết Quả Đạt Được và Hạn Chế Của Nghiên Cứu

Nghiên cứu đã xây dựng được phương pháp và công cụ kiểm thử tự động giao diện Web dựa trên FSA. Công cụ giúp tự động sinh ca kiểm thử và thực thi. Hạn chế là khó khăn trong việc đặc tả hệ thống phức tạp, số lượng test path lớn.

6.2. Các Hướng Nghiên Cứu Phát Triển và Ứng Dụng Trong Tương Lai

Hướng nghiên cứu trong tương lai là cải tiến phương pháp đặc tả, sử dụng các công cụ hỗ trợ biểu diễn và tạo Transition, nghiên cứu các phương pháp sinh ca kiểm thử hiệu quả hơn, tập trung vào các lỗi tiềm ẩn.

6.3. Vấn đề mở rộng công cụ với mô hình UML state machine

Mở rộng công cụ hỗ trợ UML state machine để quản lý sự phức tạp của hệ thống một cách hiệu quả hơn. Điều này đòi hỏi việc tích hợp các thư viện hỗ trợ UML, xây dựng các thuật toán để chuyển đổi mô hình UML sang các ca kiểm thử tự động và phát triển giao diện người dùng để quản lý và cấu hình mô hình UML.

24/09/2025

Trích đoạn nội dung tài liệu

Chương 1: Giới thiệu Trong ngành công nghiệp phát triển phần mềm ngày nay, hầu hết các phần mềm ứng dụng đều được phát triển trên nền Web. Do đó, 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 quan trọng. Tuy nhiên, các ứng dụng Web ngày càng trở nên phức tạp, việc kiểm thử thủ công bao gồm cả tạo các ca kiểm thử và thực thi chúng trên các trang Web, là công việc rất tốn kém về thời gian và công sức. Hơn nữa, mỗi khi có sự cập nhật lại phiên bản của phần mềm, để tránh rủi ro phát sinh lỗi trong khi thay đổi mã nguồn thì các kiểm thử viên phải kiểm thử lại toàn bộ phần mềm, kể cả các tính năng đã được kiểm thử tốt.

Vì vậy, để hoàn thành công việc kiểm thử đúng tín độ, 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ự động hóa các hoạt động kiểm thử. Kiểm thử tự động là một giải pháp hữu hiệu nhằm nâng cao tính chính xác và hiệu quả, cũng như giảm kinh 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 [1]. Kiểm thử dựa trên mô hình đang được xem như là một phương pháp kiểm thử có khả năng tự động hóa cao. Kiểm thử dựa trên mô hình là một phương pháp kiểm thử, trong đó các ca kiểm thử được sinh ra từ mô hình đặc tả hành vi của hệ thống đang được kiểm thử [1].

Vì vậy, kiểm thử dựa trên mô hình được ứng dụng để giải quyết một số vấn đề khó khăn trong hoạt động kiểm thử các sản phẩm phần mềm. Một trong những ứng dụng của nó là kiểm thử tương tác giao diện người dùng cho các ứng dụng Web. Để ứng dụng phương pháp kiểm thử này, trước tiên chúng ta cần xây dựng mô hình đặc tả hành vi tương tác giao diện của ứng dụng Web. Mô hình này thường được biểu diễn bằng máy hữu hạn trạng thái hoặc ôtômát hữu hạn trạng thái.

Tiếp đến, các ca kiểm thử được tự động sinh ra từ mô hình. Cuối cùng, các ca kiểm thử này được thực thi trên ứng dụng nhằm phát hiện các lỗi lập trình liên quan đến tương tác giao diện người dùng. Trong thực tế, có rất nhiều hướng nghiên cứu về kiểm thử dựa trên mô hình cho ứng dụng Web như kiểm thử khả năng chịu tải, tính bảo mật, hiệu năng, kiểm thử chức năng, v. Tuy nhiên, việc kiểm thử chức năng (theo luồng tương tác giao diện người dùng) vẫn 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 kiểm thử chức năng ứng dụng Web [4,5,9]. Mặc dù vậy, các nghiên cứu này mới chỉ thực hiện kiểm thử tự động cho từng trang Web, hoặc cho các Website tĩnh [5] mà chưa có nhiều nghiên cứu hỗ trợ cho kiểm thử luồng tương tác người dùng. Trong số đó, phương pháp và công cụ kiểm thử tự động cho các ứng dụng Web được đề xuất bởi [5] đã giải quyết được một phần vấn đề nêu trên. Tuy TIEU LUAN MOI download : skknchat@gmail.com 9 nhiên, phương pháp này chỉ thực hiện kiểm thử được cho một số phần tử Web cơ bản và chúng phải có thuộc tính id định danh.

Trong khi, các hệ thống ứng dụng Web thực tế cần một công cụ kiểm thử tự động, có khả năng kiểm thử được cho nhiều loại phần tử Web và các phần tử Web đó được thiết kế một cách linh động. Nghiên cứu này được đưa ra nhằm giải quyết vấn đề trên. Đề tài đưa ra phương pháp đặc tả hình thức giao diện cho các ứng dụng Web. Từ đó, chúng tôi xây dựng thuật toán sinh tự động các ca kiểm thử từ bản đặc tả trên.

Cuối cùng, đề tài dùng phương pháp đã được đề xuất trong [5] làm cơ sở để xây dựng một công cụ kiểm thử tự động tương tác giao diện các ứng dụng Web. Công cụ này kiểm thử được cho các ứng dụng Web có nhiều loại phần tử Web như: DropDownList, CheckBoxList, RadioList, DataGrid, v.; kể cả với các phần tử Web không có thuộc tính định danh (id) và các giao diện pop-up. 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 đặc tả giao diện cho các ứng dụng Web như là một ôtômát hữu hạn trạng thái và được biểu diễn dưới dạng các tệp tin MS Excel.

Ở chương 3, luận văn này trình bày phương pháp sinh tự động các ca kiểm thử từ ôtômát hữu hạn trạng thái và thực thi chúng trên trên ứng dụng Web. Tiếp đến, chương 4 trình bày công cụ và kết quả thực nghiệm. Cuối cùng, kết luận của luận văn và định hướng nghiên cứu tiếp theo được trình bày trong chương 5. TIEU LUAN MOI download : skknchat@gmail.com 10 Chương 2: Phương pháp đặc tả tương tác giao diện cho các ứng dụng Web Để áp dụng phương pháp kiểm thử dựa trên mô hình, chúng ta cần xây dựng mô hình đặc tả chính xác hành vi của hệ thống cần kiểm thử.

Mô hình là một sự biểu đồ hóa, mô tả chi tiết hệ thống, đồng thời mô tả chi tiết các khía cạnh, các đặc tính của hệ thống. Mô hình cần phải đủ chi tiết để giúp ta hiểu và đoán nhận được hành vi của hệ thống. Có nhiều phương pháp đặc tả mô hình như: máy hữu hạn trạng thái, ôtômát trạng thái, máy trạng thái UML, chuỗi Markov, văn phạm, bảng quyết định, v. Phụ thuộc vào phương pháp và công cụ kiểm thử, chúng ta sẽ lựa chọn phương pháp đặc tả hệ thống tương ứng.

Trong chương 2, chúng tôi chỉ trình bày một phương pháp đặc tả tương tác giao diện ứng dụng Web được sử dụng cho nghiên cứu này.1 Đặc tả tương tác giao diện của từng trang Web bằng ôtômát hữu hạn trạng thái Theo quy trình kiểm thử dựa trên mô hình [1] thì việc đầu tiên chúng ta phải làm trong số các hoạt động kiểm thử tự động ứng dụng Web đó là xây dựng mô hình đặc tả hành vi của ứng dụng Web. Có nhiều hành vi có thể được sử dụng để đặc tả nhưng trong luận văn này, chỉ đề cập đến hành vi tương tác của người dùng đối với hệ thống ứng dụng Web, thông qua sự thay đổi trạng thái (hay sự thay đổi giao diện) của ứng dụng Web [5]. Chúng tôi dùng ôtômát trạng thái làm phương pháp đặc tả hình thức giao diện ứng dụng Web. Khi đó, mỗi giao diện người dùng của một trang Web, tại một thời điểm được mô hình hóa như là một trạng thái.

Mỗi yêu cầu của người dùng được mô hình hóa như là một hành động tạo ra hàm chuyển trạng thái. Vậy, để mô hình hóa các hành vi tương tác giao diện người dùng ứng dụng Web như là một ôtômát trạng thái, chúng tôi cần thực hiện các bước sau: (1) Chia nhỏ hệ thống thành các mô-đun; (2) với mỗi mô-đun chúng ta cần xác định các giao diện người dùng; (3) với mỗi giao diện người dùng được đặc tả bằng một ôtômát trạng thái; (4) nối các ôtômát trạng thái đó lại thành một bản đặc tả hoàn chỉnh cho cả hệ thống. Phương pháp coi mỗi giao diện người dùng là một trang Web và được biểu diễn bằng một ôtômát trạng thái như định nghĩa 2.1: Hành vi tương tác giao diện của một trang Web được đặc tả bằng ôtômát trạng thái (Finite State Automaton - FSA) M = < S, s0, ∑, δ, F >, trong đó: TIEU LUAN MOI download : skknchat@gmail.com 11 - S là tập ập hữu hạn khác rỗng các trạng thái của trang Web, - s0 S là trạng ạng thái đầu tiên ti được tải lên của ủa trang Web, - ∑ ứng với tập sự kiện có dạng [điều kiện]sự kiện, - chuy trạng thái: δ: S × ∑→ S, và δ là hàm chuyển - là tập ập các trạng thái kết thúc, ttương ứng với các giao diện di xuất hiện cuối cùng ùng sau một m chuỗi các sự kiện liên tiếp.1: Dạng <[điềuều kiện]sự kiện> kiện có nghĩa là <sự kiện> ch chỉ xảy ra khi <điều kiện> được ợc thỏa mãn. m Ôtômát hữu hạn trạng ạng thái rỗng, ký hiệu llà M = ∏ là ôtômát hữu hạn trạng thái và có tập các trạng thái S = ∅ [5].

Sau đây là một ột số khái niệm căn bản giúp chúng ta đặc tả một trang Web như là một ôtômát hữu ữu hạn trạng thái. ần tử Web (Web Element). Phần tử Web là các thành phần Phần ần cơ c bản cấu tạo nên một trang Web. Mỗi ỗi phần tử Web có nhiều thành phần nhưng ưng để đặc tả một trang Web chúng ta cần ần mô tả một số các thành phần cơ bản như: th thẻ mở để khai báo bắt tính trong đó thuộc tính id, class, name ắt đầu một phần tử Web; các thuộc tính, thường đượcợc sử dụng để xác định vị trí của phần tử Web ttrênrên trang Web; nộin dung của ủa phần tử Web ththường được ợc sử dụng để xác định trạng thái của phần tử Web và thẻẻ đóng nằm ở vị trí cuối ccùng của phần tử Web.

Trạng thái trang Web. Trạng thái trang Web là giao diện ện của trang Web tại một ột thời điểm, mỗi trạng thái Web llà một ột tập hợp các trạng thái của từng phần tử trong một trang Web.1: Ví dụụ về trạng thái trang Web tìm kiếm ếm thông tin cán bộbộ. Giao diện trong hình 2.1 là một trạng Web (trạng thái index). Sau khi ngư ạng thái của trang We người dùng nhập thông tin tìmìm kiếm ki ếm (phần tử Web textbox hoặc vào các ô tìm kiếm dropdownlist) thì hệệ thống sẽ chuyển từ trạng thái bắt đầu sang trạng thái tiếp theo, như trong hình 2.2 là trạng thái người dùng đã nhập họ tênên ccần tìm kiếm (trạng thái TEN).

TIEU LUAN MOI download : skknchat@gmail. Trạng thái bắt đầu của trang tìm kiếm cán bộ Hình 2. Trạng thái đã nhập họ tên tìm kiếm Sự kiện. Sự kiện bao gồm các hành động (action) tác động lên các phần tử Web tại một thời điểm, làm thay đổi trạng thái của trang Web đó.

Có nhiều sự kiện tương tác người dùng trên giao diện Web, trong đó có 4 sự kiện chính được chúng tôi sử dụng để đặc tả hành vi Web như sau: sự kiện addtext dùng để nhập một đoạn ký tự vào ô textbox, sự kiện deltext dùng để xóa đoạn ký tự ở ô textbox, sự kiện click là sự kiện nhấp chuột vào một nút (button) hoặc một đường dẫn, sự kiện select dùng để chọn một hoặc nhiều, được sử dụng cho các phần tử combobox, checkbox, listbox, dropdown list, radio list. Như trong ví dụ TIEU LUAN MOI download : skknchat@gmail.

Nội dung được bảo vệ bản quyền — Tải xuống đầy đủ