Mở đầu 10 ca sử dụng của luận án đề xuất trong Chương 3 và 4. Trong phần này luận án cũng trình bày một công cụ hỗ trợ giải các ràng buộc trong OCL mà luận án có sử dụng như công cụ trung gian cho các đề xuất trong Chương 4. Chương 3 đề xuất một ngôn ngữ đặc tả chuyên biệt miền cho miền đặc tả các ca sử dụng tên là USL. Ngôn ngữ USL với mục đích để đặc tả rõ ràng các thông tin trong các ca sử dụng cho mục đích đặc tả yêu cầu và sinh tự động các đầu ra từ mô hình ca sử dụng.
Phương pháp đặc tả USL cho phép tích hợp ca sử dụng vào trong phương pháp phát triển phần mềm hướng mô hình. Chương 4 trình bày phương pháp sinh tự động các ca kiểm thử chức năng từ mô hình ca sử dụng và mô hình khái niệm miền của hệ thống. Trong chương này, trước hết luận án đề xuất một ngôn ngữ đặc tả các ca kiểm thử hệ thống theo phương pháp mô hình hóa chuyên biệt miền tên là TCSL. Sau đó, luận án đề xuất một phương pháp cho phép chuyển tự động các ca sử dụng được đặc tả trong các mô hình USL và mô hình lớp các khái niệm miền sang các ca kiểm thử được đặc tả trong một mô hình TCSL.
Phương pháp sinh tự động mô hình TCSL từ các mô hình USL được đề xuất trong chương này thể hiện tính thống nhất về mặt phương pháp luận và tính khả thi trong quá trình thực nghiệm. Chương 5 trình bày về công cụ hỗ trợ và các đánh giá của phương pháp đã đề xuất. Đầu tiên, luận án hiện thực hóa các đề xuất trong các Chương 3 và 4 bằng một công cụ hỗ trợ USL. Sau đó, luận án sử dụng công cụ đã đề xuất để thực nghiệm trên một số ca sử dụng.
Sau đó, luận án trình bày các so sánh và đánh giá các kết quả đã đề xuất. Công cụ hỗ trợ USL cho phép tích hợp các ca sử dụng vào trong phương pháp phát triển hướng mô hình. Trong đó, công cụ cho phép tạo ra các mô hình đặc tả ca sử dụng trong ngôn ngữ đặc tả USL. Công cụ cũng cung cấp các bộ sinh khác nhau cho phép sinh tự động các đầu ra khác nhau từ các mô hình USL.
Cụ thể, luận án hiện thực hóa hai bộ sinh là sinh các đặc tả ca sử dụng trong ngôn ngữ tự nhiên dựa trên mẫu được gọi là USL2TUCD và sinh các ca kiểm thử được đặc tả trong mô hình TCSL. Cuối cùng, Chương 6 phân tích về các đóng góp chính của luận án và thảo luận về các nghiên cứu trong tương lai từ các kết quả ban đầu đã đạt được. LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com Chương 2 KIẾN THỨC CƠ SỞ Trong chương này, luận án sẽ trình bày về những kiến thức cơ sở được sử dụng trong các chương tiếp theo. 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]. 11 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com Chương 2. 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ộ lỗ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 lỗ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ữ liệu đã chọn) được xác định chỉ rõ là đầu vào để thực hiện các ca kiểm thử LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com Chương 2. Kiến thức cơ sở 13 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ể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 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com Chương 2. Kiến thức cơ sở 14 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ể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.