Luận án về kiểm thử dựa trên mô hình và phương pháp mô hình hóa chuyên biệt miền

Chuyên khảo phân tích Luận án kiểm thử dựa trên mô hình với cách tiếp cận mô hình hóa chuyên biệt miền, đánh giá các khía cạnh quan trọng, đề xuất hướng nghiên cứu tiếp theo.

• Trường học: Trường Đại Học
• Chuyên ngành: Kiểm Thử Phần Mềm
• Đề tài: Kiểm Thử Dựa Trên Mô Hình Với Phương Pháp Mô Hình Hóa Chuyên Biệt
• Loại tài liệu: Luận Án

Mục lục chi tiết

• 1. CHƯƠNG 1: MỞ ĐẦU
• 1.1. Đặt vấn đề
• 1.2. Mục tiêu nghiên cứu và các đóng góp chính của luận án
• 1.3. Cấu trúc luận án
• 2. CHƯƠNG 2: KIẾN THỨC NỀN
• 3. CHƯƠNG 3: NGÔN NGỮ ĐẶC TẢ CHUYÊN BIỆT MIỀN CHO CA SỬ DỤNG
• 4. CHƯƠNG 4: PHƯƠNG PHÁP SINH TỰ ĐỘNG CÁC CA KIỂM THỬ CHỨC NĂNG
• 5. CHƯƠNG 5: CÔNG CỤ HỖ TRỢ VÀ ĐÁNH GIÁ PHƯƠNG PHÁP

Tóm tắt

I. Giới thiệu về kiểm thử dựa trên mô hình

Kiểm thử phần mềm là một hoạt động thiết yếu trong quy trình phát triển phần mềm, nhằm đảm bảo chất lượng sản phẩm. Kiểm thử dựa trên mô hình (Model-Based Testing - MBT) đã nổi lên như một phương pháp hiệu quả, giúp tự động hóa không chỉ trong thực thi kiểm thử mà còn trong việc sinh các ca kiểm thử. MBT cho phép cập nhật tự động bộ kiểm thử khi có sự thay đổi trong yêu cầu phần mềm, từ đó giảm thiểu thời gian và công sức cho các kiểm thử viên. Theo nghiên cứu, MBT có thể giảm chi phí kiểm thử từ 30-60%, đồng thời nâng cao chất lượng sản phẩm. Việc áp dụng MBT trong thực tế đã cho thấy những lợi ích rõ rệt, đặc biệt trong việc duy trì và mở rộng bộ kiểm thử. Điều này cho thấy tầm quan trọng của việc phát triển các phương pháp và công cụ hỗ trợ cho MBT.

1.1. Lợi ích của kiểm thử dựa trên mô hình

MBT mang lại nhiều lợi ích cho quy trình phát triển phần mềm. Đầu tiên, nó giúp tăng cường tính tự động hóa trong việc sinh và thực thi các ca kiểm thử. Thứ hai, MBT cho phép các kiểm thử viên dễ dàng duy trì và cập nhật bộ kiểm thử khi có sự thay đổi trong yêu cầu phần mềm. Cuối cùng, MBT giúp giảm thiểu số lượng lỗi và sai sót trong quá trình kiểm thử, từ đó nâng cao chất lượng sản phẩm. Các nghiên cứu đã chỉ ra rằng việc áp dụng MBT có thể cải thiện hiệu suất kiểm thử lên đến 50%. Điều này chứng tỏ rằng MBT không chỉ là một phương pháp lý thuyết mà còn có giá trị thực tiễn cao trong ngành công nghiệp phần mềm.

II. Mô hình hóa trong kiểm thử phần mềm

Mô hình hóa là một bước quan trọng trong quy trình kiểm thử dựa trên mô hình. Mô hình hóa hóa phần mềm giúp xác định các yêu cầu chức năng và phi chức năng của hệ thống. Các mô hình này thường được biểu diễn dưới dạng biểu đồ hoặc tài liệu mô tả, giúp các bên liên quan dễ dàng hiểu và sử dụng. Việc sử dụng các ngôn ngữ mô hình hóa chuyên biệt như UML (Unified Modeling Language) cho phép tạo ra các mô hình rõ ràng và chính xác. Tuy nhiên, việc chuyển đổi từ mô hình sang ca kiểm thử vẫn còn nhiều thách thức. Các nghiên cứu đã chỉ ra rằng việc sử dụng ngôn ngữ mô hình hóa chuyên biệt có thể giúp cải thiện khả năng sinh ca kiểm thử tự động, từ đó nâng cao hiệu quả của quy trình kiểm thử.

2.1. Các phương pháp mô hình hóa

Có nhiều phương pháp mô hình hóa khác nhau được áp dụng trong kiểm thử phần mềm. Một trong những phương pháp phổ biến là sử dụng biểu đồ ca sử dụng để mô tả các yêu cầu chức năng. Các biểu đồ này giúp xác định các tác nhân và hành động trong hệ thống, từ đó tạo điều kiện thuận lợi cho việc sinh ca kiểm thử. Ngoài ra, việc sử dụng các ngôn ngữ mô hình hóa chuyên biệt như DSL (Domain-Specific Language) cũng đã được đề xuất để cải thiện khả năng mô hình hóa. Các nghiên cứu cho thấy rằng việc áp dụng các phương pháp mô hình hóa này có thể giúp giảm thiểu sai sót trong quá trình kiểm thử và nâng cao chất lượng sản phẩm.

III. Quy trình kiểm thử dựa trên mô hình

Quy trình kiểm thử dựa trên mô hình bao gồm năm bước chính: (1) mô hình hóa, (2) sinh các ca kiểm thử, (3) sinh các tập lệnh thực thi kiểm thử, (4) thực thi kiểm thử, và (5) phân tích các ca kiểm thử. Mỗi bước trong quy trình này đều có vai trò quan trọng trong việc đảm bảo chất lượng phần mềm. Việc mô hình hóa chính xác các yêu cầu phần mềm là điều kiện tiên quyết để sinh ra các ca kiểm thử hiệu quả. Các công cụ hỗ trợ kiểm thử tự động hiện nay đã giải quyết tốt các bước cuối cùng trong quy trình, tuy nhiên, hai bước đầu tiên vẫn còn nhiều thách thức cần được nghiên cứu và cải tiến.

3.1. Các bước trong quy trình kiểm thử

Mỗi bước trong quy trình kiểm thử dựa trên mô hình đều có những yêu cầu và thách thức riêng. Bước mô hình hóa yêu cầu chức năng cần phải được thực hiện một cách chính xác để đảm bảo rằng các ca kiểm thử được sinh ra sẽ phản ánh đúng các yêu cầu của phần mềm. Bước sinh ca kiểm thử là bước quan trọng nhất, vì nó quyết định đến chất lượng của quá trình kiểm thử. Các nghiên cứu đã chỉ ra rằng việc áp dụng các ngôn ngữ mô hình hóa chuyên biệt có thể giúp cải thiện khả năng sinh ca kiểm thử tự động, từ đó nâng cao hiệu quả của quy trình kiểm thử.

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

Mở đầu, Mục 2.1 sẽ làm rõ các khái niệm trong kiểm thử phần mềm, ca sử dụng, và phương pháp xác định các ca kiểm thử từ các ca sử dụng. Các mục tiếp theo, luận án sẽ lần lượt mô tả về mô hình hóa chuyên biệt miền (Domain-Specific Modeling - DSM ), ngôn ngữ chuyển mô hình (model transformation language), và ngôn ngữ ràng buộc đối tượng OCL.1 Kiểm thử dựa trên ca sử dụng Phần này, luận án sẽ trình bày các kiến thức nền trong kiểm thử phần mềm, ca sử dụng, và kiểm thử dựa trên ca sử dụng. Các kiến thức này được luận án tìm hiểu khi nghiên cứu bài toán kiểm thử chức năng từ ca sử dụng.1 Kiểm thử phần mềm 2.1 Các khái niệm cơ bản Lỗi phần mềm là một khiếm khuyết trong một thành phần hoặc hệ thống mà nó có thể làm cho thành phần hoặc hệ thống này không thực hiện đúng chức năng yêu cầu của nó, ví dụ như thông báo sai hoặc định nghĩa dữ liệu không đúng [5]. Kiến thức cơ sở 12 Kiểm thử (Testing) là một quy trình thực hiện một chương trình với ý định tìm kiếm các lỗi.

Kiểm thử phần mềm bao gồm việc kiểm chứng động các hành vi của một chương trình trên một tập hữu hạn các ca kiểm thử (test case). Các ca kiểm thử được lựa chọn phù hợp từ các miền thực thi thường là vô hạn để có được hành vi được mong đợi [49]. Kiểm thử tĩnh (Static Testing) là hoạt động kiểm tra mà không thực hiện chương trình. Hoạt động này bao gồm kiểm tra phần mềm và một số dạng của phân tích [5].

Kiểm thử động (Dynamic Testing) là thực hiện chương trình với các giá trị đầu vào xác định để tìm các lỗi trong các hành vi của chương trình [5]. Hầu hết các tài liệu sử dụng thuật ngữ kiểm thử để chỉ kiểm thử động và kiểm thử tĩnh được gọi là hoạt động xác minh. Khi thực thi kiểm thử, việc kiểm thử toàn diện chương trình thực tế là không thể thực hiện được. Bởi vì, mỗi hoạt động trong chương trình thường có một số lượng lớn các dữ liệu đầu vào thỏa mãn.

Vì vậy khi kiểm thử, kiểm thử viên cần chọn một số lượng các ca kiểm thử đủ nhỏ để có thể thực thi các kiểm thử trong thời gian giới hạn. Vậy làm thế nào để chọn được các ca kiểm thử có nhiều khả năng để lộ thất bại trong hệ thống. Khi đó, một số chiến lược sẽ được áp dụng để xác định tập các đầu vào cho ca kiểm thử như phân lớp tương đương, kiểm thử giá trị biên. Sau mỗi lần thực hiện kiểm thử, chúng ta phải quyết định hành vi được quan sát của hệ thống là một thất bại hay không.

Vấn đề này được gọi là một lời tiên tri (oracle). Vấn đề oracle thường được giải quyết thông qua kiểm tra thủ công đầu ra thực tế. Nhưng để kiểm thử lặp lại và hiệu quả, oracle cần được tự động hóa. Ca kiểm thử (Test case) là tập của các dữ liệu kiểm thử (test data), các điều kiện thực hiện (pre-condition), các bước kiểm thử (test steps), và các kết quả đầu ra mong đợi (expected output) được phát triển cho một kịch bản kiểm thử (test scenario) cụ thể để kiểm chứng sự tuân thủ một yêu cầu kiểm thử xác định.

Một ca kiểm thử định nghĩa một thử nghiệm đơn lẻ sẽ được thực hiện để đạt được mục tiêu kiểm thử phần mềm cụ thể, chẳng hạn như đi qua một đường thực thi của chương trình cụ thể hoặc kiểm chứng tuân thủ một yêu cầu cụ thể [5]. Dữ liệu kiểm thử là tập các giá trị thực (thỏa mãn tiêu chí bao phủ dữ Chương 2. Kiến thức cơ sở 13 liệu đã chọn) được xác định chỉ rõ là đầu vào để thực hiện các ca kiểm thử trong quá trình kiểm thử [5]. Đầu ra mong đợi là các kết quả dự kiến sẽ được tạo ra khi thực hiện kiểm thử.

Chương trình thỏa mãn khi và chỉ khi đầu ra thực tế thỏa mãn đầu ra mong đợi của kiểm thử [5]. Các bước kiểm thử mô tả các bước thực hiện và kiểm tra kết quả đầu ra của hệ thống [5]. Các điều kiện thực hiện là các điều kiện cần thỏa mãn để ca kiểm thử được thực hiện [5]. Kịch bản kiểm thử (Test scenario) là một ca kiểm thử trừu tượng và nó thường bao gồm nhiều ca kiểm thử liên quan nhau.

Một kịch bản kiểm thử mô tả một thủ tục thực hiện kiểm thử bao gồm một tập các bước kiểm thử (test step). Mục đích của kịch bản kiểm thử là kiểm tra việc thực hiện chức năng từ đầu đến cuối của một chức năng phần mềm và đảm bảo luồng logic đang hoạt động là đúng. Với mỗi kịch bản kiểm thử, kiểm thử viên có thể xác định được một hoặc nhiều bộ dữ liệu kiểm thử thỏa mãn kịch bản kiểm thử. Một ca kiểm thử là sự kết hợp của một kịch bản kiểm thử với một bộ dữ liệu kiểm thử thỏa mãn kịch bản [5].2 Kỹ thuật kiểm thử Một hoạt động quan trọng trong kiểm thử phần mềm là thiết kế các ca kiểm thử.

Một quy trình phát triển phần mềm tạo ra một lượng lớn thông tin như đặc tả yêu cầu, tài liệu thiết kế và mã nguồn. Để tạo các ca kiểm thử hiệu quả với chi phí thấp, các nhà thiết kế kiểm thử sẽ phân tích một số nguồn thông tin như các đặc tả yêu cầu và đặc tả chức năng (requirements and functional specifications), mã nguồn, các miền đầu vào và đầu ra (input and output domains), hồ sơ hoạt động (operational profile), và mô hình lỗi. Tất cả các nguồn thông tin này cung cấp các thông tin bổ sung cho các nhà thiết kế kiểm thử. Dựa trên nguồn thông tin cho thiết kế kiểm thử, kỹ thuật kiểm thử được chia thành hai kỹ thuật chính là kiểm thử hộp trắng (white box testing) và kiểm thử hộp đen (black box testing) như được định nghĩa trong [5].

Kiến thức cơ sở 14 Kiểm thử hộp đen là kỹ thuật kiểm thử mà các ca kiểm thử được xác định từ các mô tả bên ngoài của phần mềm, bao gồm các đặc tả, các yêu cầu, và thiết kế. Kiểm thử hộp trắng là kỹ thuật kiểm thử mà các ca kiểm thử được xác định từ mã nguồn bên trong của phần mềm, đặc biệt bao gồm các nhánh, các điều kiện riêng, và các câu lệnh.3 Các mức trong kiểm thử phần mềm Kiểm thử được thực hiện tại các mức khác nhau liên quan tới các hoạt động phát triển phần mềm.1 là mô hình chữ V (V model), mô hình minh họa các mức kiểm thử và các hoạt động phát triển phần mềm. Các mức kiểm thử được trình bày trong [50, 64] gồm có 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. Các ca kiểm thử của các mức kiểm thử này sẽ được thiết kế dựa vào các chế tác tương ứng trong các quy trình khác nhau trong phát triển phần mềm.

Sau khi có mã chương trình, các mức kiểm thử khác nhau sẽ lần lượt được thực hiện. Trong kiểm thử đơn vị (Unit testing), các lập trình viên kiểm thử riêng lẻ các đơn vị chương trình như các hàm, thủ tục, phương thức, hoặc lớp một cách độc lập. Sau khi chắc chắn các đơn vị riêng lẻ làm việc thỏa mãn, các mô-đun được lắp ráp để xây dựng các hệ thống con lớn hơn bằng cách thực hiện các kỹ thuật kiểm tra tích hợp.1: Các pha kiểm thử và phát triển trong mô hình chữ V [50]. Kiến thức cơ sở 15 Kiểm thử tích hợp (Integration testing) được thực hiện bởi các nhà phát triển phần mềm và các kỹ sư kiểm thử tích hợp.

Mục tiêu của kiểm thử tích hợp là để xây dựng một hệ thống thỏa mãn ổn định có thể chịu được sự nghiêm ngặt của việc kiểm thử mức hệ thống. Kiểm thử mức hệ thống (System testing) gồm một phổ rộng các kiểm thử như kiểm thử chức năng (functionality testing), kiểm thử độ bền (ro- buntness), kiểm thử bảo mật (security testing), kiểm thử tải (load testing), kiểm thử hiệu năng (performamce testing), kiểm thử độ tin cậy (reliability testing), kiểm thử ổn đinh (stability), kiểm thử quá tải (stress testing). Kiểm thử mức hệ thống là một pha quan trọng trong quy trình phát triển phần mềm vì cần phải đáp ứng một kế hoạch chặt chẽ gần ngày chuyển giao, để khám phá hầu hết các lỗi, và kiểm chứng sản phẩm đang làm việc và không dẫn đến các lỗi mới. Kiểm thử hệ thống gồm các hoạt động phân biệt như tạo một kế hoạch kiểm thử (test plan), thiết kế một bộ kiểm thử (test suite), chuẩn bị môi trường kiểm thử, thực hiện các kiểm thử theo một chiến lược rõ ràng và giám sát quy trình thực hiện kiểm thử.

Sau khi hoàn thành việc kiểm thử mức hệ thống, sản phẩm sẽ được chuyển giao đến khách hàng. Khách hàng sẽ thực hiện một loạt các kiểm thử của họ, thường biết đến như là kiểm thử chấp nhận (acceptance testing).4 Kiểm thử dựa trên mô hình Kiểm thử dựa trên mô hình (Model-Based Testing - MBT) là một kỹ thuật kiểm thử với mục đích để sinh các ca kiểm thử tự động từ mô hình đặc tả các khía cạnh liên quan của hành vi hệ thống cần kiểm thử (System Under Testing - SUT ). Mô hình mô tả hệ thống cần kiểm thử từ góc nhìn của những vấn đề cần được kiểm thử. Ví dụ, một mô hình luồng điều khiển (control flow) của một phương thức sẽ mô hình khía cạnh luồng điều khiển đi qua các câu lệnh thực hiện của phương thức [56].

Cụ thể, thay vì thiết kế hàng trăm ca kiểm thử thủ công thì người thiết kế kiểm thử xây dựng mô hình trừu tượng của SUT, sau đó công cụ kiểm thử dựa trên mô hình sinh ra một tập các ca kiểm thử từ mô hình đó. Toàn bộ thời gian thiết kế kiểm thử được giảm xuống, và ưu điểm nữa là có thể sinh ra một loạt các tập ca kiểm thử khác nhau từ cùng một mô hình bằng việc sử dụng các tiêu Chương 2. Kiến thức cơ sở 16 chí lựa chọn kiểm thử khác nhau [9].2 thể hiện năm bước chính của quy trình kiểm thử dựa trên mô hình.2: Quy trình kiểm thử dựa trên mô hình [9]. Bước 1 Mô hình hóa: Người tạo mô hình sẽ tạo ra các mô hình cho hệ thống cần kiểm thử hoặc môi trường của hệ thống cần kiểm thử.

Sau khi mô hình được tạo ra, các mô hình cần được kiểm tra để đảm bảo tính nhất quán và có được các hành vi mong muốn.