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.