Bối cảnh và vấn đề nghiên cứu

Trong kỹ thuật phần mềm, kiểm thử là hoạt động giữ vai trò then chốt nhằm thẩm định chất lượng và quyết định trực tiếp đến độ tin cậy cũng như sự tồn tại của hệ thống phần mềm. Cùng với sự gia tăng nhanh chóng về quy mô và độ phức tạp của các ứng dụng, khối lượng công sức và thời gian dành cho việc kiểm thử cũng tăng theo tỷ lệ thuận. Các kết quả nghiên cứu trong ngành chỉ ra rằng chi phí dành cho hoạt động kiểm thử thường chiếm trên 50% tổng chi phí phát triển phần mềm. Trong đó, khâu thiết kế kịch bản và sinh các ca kiểm thử (test cases) là bài toán tốn nhiều thời gian, nhân lực nhất. Việc thiết kế các ca kiểm thử bằng phương pháp thủ công không chỉ gây lãng phí nguồn lực mà còn rất dễ phát sinh sai sót chủ quan. Do đó, việc nghiên cứu các kỹ thuật tự động hóa quá trình sinh kịch bản kiểm thử là một đòi hỏi cấp thiết trong thực tiễn công nghệ.

Hiện nay, việc tự động hóa sinh ca kiểm thử chủ yếu phân thành hai hướng tiếp cận chính:

  1. Hướng tiếp cận sinh ca kiểm thử từ mã nguồn (source code): Hướng tiếp cận này gặp nhiều trở ngại do cấu trúc mã nguồn thường phức tạp, lộn xộn và rất khó để thực hiện tự động hóa một cách hoàn chỉnh.
  2. Hướng tiếp cận sinh ca kiểm thử dựa trên yêu cầu, đặc tả và mô hình thiết kế phần mềm: Kỹ thuật này sử dụng các ký hiệu thiết kế làm cơ sở kiểm tra đầu ra, giúp phát hiện sớm các điểm thiếu nhất quán, nhập nhằng trong tài liệu đặc tả ngay trước khi tiến hành viết mã nguồn. Qua đó, các lỗi thiết kế được loại bỏ từ giai đoạn đầu, giảm thiểu đáng kể chi phí sửa đổi và cho phép lập trình viên cùng kiểm thử viên làm việc song song.

Đặc biệt, đối với các hệ thống hướng đối tượng, việc kiểm thử dựa trên mô hình thiết kế xuất phát từ ba lý do cốt lõi:

  • Kỹ thuật kiểm thử truyền thống chủ yếu xem xét trạng thái tĩnh của mã nguồn, không đủ khả năng bao quát và kiểm soát các hành vi động phức tạp của đối tượng.
  • Việc dò tìm lỗi trực tiếp trên mã nguồn hướng đối tượng là công việc phức tạp, trong khi các mô hình trực quan giúp kiểm thử viên nắm bắt bản chất hệ thống tốt hơn.
  • Sinh ca kiểm thử từ mô hình cho phép hoạch định sớm kịch bản kiểm thử ngay từ những bước đầu tiên của vòng đời phát triển phần mềm.

Mặc dù ngôn ngữ mô hình hóa thống nhất UML (Unified Modeling Language) được ứng dụng rộng rãi để thiết kế phần mềm hướng đối tượng, số lượng nghiên cứu khai thác sâu các biểu đồ UML phục vụ mục đích kiểm thử tự động vẫn còn hạn chế. Nhằm giải quyết vấn đề này, luận văn tập trung nghiên cứu phương pháp sinh ca kiểm thử tự động thông qua sự kết hợp giữa biểu đồ tuần tự (Sequence Diagram) và biểu đồ trạng thái (State Diagram) trong UML.

Nhiệm vụ nghiên cứu cụ thể của đề tài bao gồm:

  1. Nghiên cứu tổng quan lý thuyết về kiểm thử phần mềm và các phương pháp kiểm thử cơ bản.
  2. Nghiên cứu tổng quan về ngôn ngữ UML, trọng tâm là cơ chế hoạt động của biểu đồ tuần tự và biểu đồ trạng thái.
  3. Đề xuất quy trình và thuật toán chuyển đổi biểu đồ tuần tự sang đồ thị tuần tự, tích hợp với biểu đồ trạng thái để tạo đồ thị kiểm thử chung và trích xuất đường kiểm thử (test paths).
  4. Thiết kế, xây dựng công cụ thử nghiệm dưới dạng module mở rộng trên môi trường Modelio và thực nghiệm kiểm chứng trên ca sử dụng của hệ thống máy rút tiền tự động (ATM).

Đối tượng nghiên cứu của luận văn là các biểu đồ hành vi UML (biểu đồ tuần tự, biểu đồ trạng thái) và kỹ thuật sinh ca kiểm thử tự động. Phạm vi nghiên cứu giới hạn ở việc trích xuất luồng tương tác và chuyển đổi trạng thái của các đối tượng trong ca sử dụng, ứng dụng thuật toán tìm kiếm theo chiều sâu để sinh ca kiểm thử và cài đặt công cụ thực nghiệm trên nền tảng Modelio bằng Apache Maven.

Cơ sở lý thuyết và phương pháp

Luận văn xây dựng hệ thống cơ sở lý thuyết dựa trên các nguyên lý chuẩn của kỹ thuật kiểm thử phần mềm và chuẩn mô hình hóa UML:

1. Khái niệm và quy trình kiểm thử phần mềm

Văn bản phân định rõ 4 khái niệm nền tảng trong kiểm thử:

  • Lỗi (Error): Sai sót do con người (lập trình viên) phạm phải trong quá trình phân tích, thiết kế hoặc viết mã nguồn.
  • Sai (Fault): Kết quả phát sinh từ lỗi, là trạng thái sai lệch tồn tại bên trong phần mềm. Fault gồm hai dạng: sai sót do đưa ra thừa (đưa thông tin không chính xác vào tài liệu yêu cầu) và sai do bỏ sót (thiếu các thành phần cần thiết theo yêu cầu).
  • Thất bại (Failure): Hiện tượng xảy ra khi một Fault được thực thi, dẫn đến việc phần mềm không thực hiện đúng chức năng như mong đợi.
  • Sự cố (Incident): Biểu hiện bên ngoài của thất bại mà người sử dụng hoặc kiểm thử viên quan sát thấy.

Quy trình kiểm thử được thực hiện qua các bước tuần tự: Lập kế hoạch kiểm thử $\rightarrow$ Thiết kế ca kiểm thử dựa trên đặc tả $\rightarrow$ Tạo dữ liệu kiểm tra $\rightarrow$ Thực thi chương trình theo kịch bản $\rightarrow$ So sánh kết quả thực tế với đầu ra mong muốn (đánh giá Pass hoặc Fail) $\rightarrow$ Lập báo cáo kết quả kiểm thử (Test Report). Quá trình này bao gồm hai khía cạnh: kiểm chứng (Verification - đảm bảo phần mềm xây dựng đúng đặc tả kỹ thuật) và thẩm định (Validation - đảm bảo phần mềm đáp ứng đúng nhu cầu của khách hàng).

Về mặt kỹ thuật, kiểm thử được chia thành:

  • Kiểm thử tĩnh (Static Testing): Khảo sát tài liệu đặc tả, mô hình và mã nguồn mà không cần thực thi chương trình; sử dụng các kỹ thuật phân tích hình thức như kiểm chứng mô hình (model checking) hoặc chứng minh định lý.
  • Kiểm thử động (Dynamic Testing): Biên dịch và thực thi chương trình trên máy tính để kiểm tra phản ứng và hành vi chức năng thực tế.

Về cấp độ thực hiện, quy trình kiểm thử gồm:

  • Kiểm thử đơn vị (Unit Test): Mức độ thấp nhất, kiểm tra độc lập từng hàm, phương thức, lớp hoặc nhánh lệnh (if...then...else) do lập trình viên thực hiện.
  • Kiểm thử tích hợp (Integration Test): Kiểm tra giao tiếp và sự tương tác giữa các module/thành phần khi ghép nối. Gồm 4 loại: kiểm thử cấu trúc, kiểm thử chức năng, kiểm thử hiệu năng, kiểm thử khả năng chịu tải; áp dụng các chiến lược như tích hợp từ trên xuống (top-down).
  • Kiểm thử hệ thống (System Test): Kiểm tra toàn bộ hệ thống trong môi trường tương đương thực tế. Bao gồm 13 loại kiểm thử:
    • Kiểm thử cơ bản (Basic test)
    • Kiểm thử chức năng (Functionality test)
    • Kiểm thử khả năng chịu lỗi (Robustness test)
    • Kiểm thử tương thích (Interoperability test)
    • Kiểm thử hiệu năng (Performance test)
    • Kiểm thử khả năng mở rộng (Scalability test)
    • Kiểm thử khả năng chịu tải (Stress test)
    • Kiểm thử khả năng ổn định quá tải (Load and stability test)
    • Kiểm thử độ tin cậy (Reliability test)
    • Kiểm thử tài liệu (Documentation test)
    • Kiểm thử tính pháp lý (Regulatory test)
    • Kiểm tra khả năng bảo mật (Security test)
    • Kiểm tra khả năng phục hồi (Recovery test)
  • Kiểm thử chấp nhận (Acceptance Test): Thực hiện độc lập bởi khách hàng nhằm xác nhận phần mềm đủ điều kiện triển khai thực tế.
  • Kiểm thử hồi quy (Regression Test): Thực hiện lặp lại các ca kiểm thử cũ khi có thay đổi trong mã nguồn hoặc yêu cầu nhằm đảm bảo không phát sinh lỗi mới.

Về phương pháp thiết kế ca kiểm thử, tác giả phân tích hai cách tiếp cận: Kiểm thử hộp đen (Black-box testing - chỉ quan tâm dữ liệu đầu vào và đầu ra chức năng, không xét mã nguồn) và Kiểm thử hộp trắng (White-box testing - phân tích thuật toán, luồng điều khiển, luồng dữ liệu động và kiểm thử miền bên trong mã nguồn).

2. Ngôn ngữ mô hình hóa UML

Ngôn ngữ UML cung cấp 5 hướng nhìn (views) để mô tả toàn diện hệ thống:

  • Hướng nhìn ca sử dụng (Use case view)
  • Hướng nhìn logic (Logic view)
  • Hướng nhìn thành phần (Component view)
  • Hướng nhìn song song (Concurrent view)
  • Hướng nhìn triển khai (Deployment view)

Hệ thống ký hiệu của UML gồm 9 loại biểu đồ, các phần tử mô hình hóa, các mối quan hệ (Kết nối - Association, Khái quát hóa - Generalization, Phụ thuộc - Dependency, Kết tập - Aggregation) và các cơ chế mở rộng chung (General Mechanism). Trong đó, hai biểu đồ được sử dụng chính là:

  • Biểu đồ trạng thái (State Diagram): Mô tả chu kỳ tồn tại của một đối tượng từ khi khởi tạo đến khi bị hủy bỏ, ghi nhận các trạng thái, hành vi và sự kiện chuyển trạng thái.
  • Biểu đồ tuần tự (Sequence Diagram): Mô hình hóa khía cạnh hành vi tương tác giữa các đối tượng theo trục thời gian từ trên xuống dưới. Biểu đồ chứa các đường đời đối tượng (lifelines), thông điệp trao đổi (sự kiện gửi và sự kiện nhận) và các phân đoạn tương tác kết hợp (Combined Fragments) với các toán tử tương tác (Interaction Operator) như alt (rẽ nhánh điều kiện alternative tương tự cấu trúc if...then...else), opt (tùy chọn option), break (ngắt kịch bản), loop (vòng lặp).

3. Phương pháp nghiên cứu

Tác giả kết hợp phương pháp nghiên cứu lý thuyết (tổng hợp tài liệu chuẩn về kiểm thử và UML), phương pháp mô hình hóa hình thức (chuyển đổi biểu đồ UML sang cấu trúc đồ thị $G(N, E)$), phương pháp thuật toán (áp dụng thuật toán tìm kiếm theo chiều sâu - DFS) và phương pháp thực nghiệm công nghệ (phát triển module mở rộng trên công cụ Modelio bằng Maven).

Thiết kế và triển khai giải pháp

Để giải quyết bài toán sinh ca kiểm thử tự động, tác giả đã thiết kế cấu trúc hình thức cho ca kiểm thử, xây dựng quy trình tích hợp đồ thị và cài đặt module thực nghiệm.

1. Định nghĩa cấu trúc hình thức

Tác giả định nghĩa một ca kiểm thử là một bộ gồm 4 phần tử: $$\text{Test Case} = {\text{ID}, \text{Start State}, \text{Set of Message}, \text{End State}}$$

Trong đó:

  • ID: Mã định danh duy nhất của từng kịch bản kiểm thử.
  • Start State: Trạng thái bắt đầu của đối tượng cần kiểm thử trong kịch bản.
  • Set of Message: Tập hợp các sự kiện/thông điệp xảy ra theo trình tự trong kịch bản. Mỗi sự kiện thông điệp được biểu diễn bằng một bộ 3 phần tử: $$\text{Message} = {\text{messageName}, \text{fromObject}, \text{toObject}}$$ với messageName là tên thông điệp, fromObject là đối tượng gửi và toObject là đối tượng nhận.
  • End State: Trạng thái kết thúc của đối tượng (mỗi kịch bản có một trạng thái bắt đầu nhưng có thể có một hoặc nhiều trạng thái kết thúc tùy theo nhánh rẽ).

2. Quy trình 3 bước sinh ca kiểm thử tự động

Bước thực hiện Thao tác kỹ thuật Đầu vào Đầu ra
Bước 1: Chuyển đổi biểu đồ tuần tự sang đồ thị tuần tự Trích xuất các thông điệp giữa các đối tượng trong biểu đồ tuần tự. Mỗi thông điệp tạo thành một đỉnh trong đồ thị. Hai thông điệp xuất hiện liên tiếp theo trục thời gian được nối với nhau bằng một cạnh có hướng. Biểu đồ tuần tự UML Đồ thị tuần tự $G(N, E)$
Bước 2: Kết hợp đồ thị tuần tự với biểu đồ trạng thái Duyệt từng thông điệp trong đồ thị tuần tự, đối chiếu với biểu đồ trạng thái của đối tượng để kiểm tra xem thông điệp có kích hoạt sự kiện chuyển trạng thái hay không. Nếu có, bổ sung thông tin trạng thái mới vào đỉnh tương ứng. Đồ thị tuần tự và Biểu đồ trạng thái UML Đồ thị chung (đồ thị tuần tự đã bổ sung trạng thái)
Bước 3: Duyệt đồ thị chung sinh đường kiểm thử Áp dụng thuật toán tìm kiếm theo chiều sâu (DFS) duyệt từ đỉnh gốc (thông điệp bắt đầu) đến các đỉnh lá (thông điệp kết thúc) để trích xuất các đường kiểm thử (test paths). Đồ thị chung Danh sách các ca kiểm thử dạng ${\text{ID}, \text{Start State}, \text{Set of Message}, \text{End State}}$

Tiêu chí chất lượng: Phương pháp đảm bảo đạt được độ bao phủ thông điệp (Message Coverage) và độ bao phủ trạng thái đối tượng (State Coverage).

3. Triển khai công cụ thực nghiệm trên Modelio

Giải pháp được hiện thực hóa dưới dạng một module mở rộng (Modelio Module) cho công cụ mô hình hóa mã nguồn mở Modelio:

  • Môi trường phát triển: Sử dụng Apache Maven kết hợp với Modelio Archetype Catalog để cấu hình và khởi tạo khung dự án module (mvn archetype:generate).
  • Cấu hình: Chọn Archetype tương ứng với phiên bản Modelio, khai báo các phụ thuộc và thông số cấu hình module.
  • Triển khai: Đóng gói mã nguồn thành tệp module và tích hợp trực tiếp vào Module Catalog của giao diện cấu hình Modelio, cho phép người dùng kích hoạt công cụ để tự động đọc mô hình biểu đồ tuần tự/trạng thái và sinh ra danh sách ca kiểm thử.

Nội dung chính theo từng chương

Chương 1: Mở đầu

Chương 1 thiết lập nền tảng và tính cấp thiết của đề tài. Tác giả chỉ ra rằng kiểm thử phần mềm chiếm trên 50% chi phí phát triển và việc thiết kế ca kiểm thử thủ công thường gây lãng phí, dễ phát sinh sai sót. Luận văn phân tích ưu - nhược điểm của hai hướng tiếp cận: sinh ca kiểm thử từ mã nguồn (phức tạp, khó tự động hóa) và sinh ca kiểm thử từ mô hình thiết kế (độc lập mã nguồn, phát hiện lỗi sớm trong đặc tả).

Chương này cũng tổng quan các nghiên cứu liên quan tiêu biểu:

  • Nghiên cứu của Bertolino và Basanieri: Kết hợp Use Case và biểu đồ tương tác để sinh ca kiểm thử bán tự động bao phủ kịch bản theo luồng thông điệp.
  • Nghiên cứu của Sharma: Chuyển đổi biểu đồ Use Case và biểu đồ tuần tự thành đồ thị tương ứng, tích hợp thành đồ thị kiểm thử hệ thống để duyệt tìm ca kiểm thử.

Từ việc đánh giá các công trình trước, tác giả xác định mục tiêu và bố cục của luận văn gồm 4 chương.

Chương 2: Kiến thức chung

Chương 2 trình bày toàn diện cơ sở lý thuyết về kiểm thử phần mềm và ngôn ngữ UML:

  • Lý thuyết kiểm thử: Phân tích chi tiết các định nghĩa lỗi (Error), sai (Fault), thất bại (Failure), sự cố (Incident); quy trình kiểm chứng (Verification) và thẩm định (Validation); kỹ thuật kiểm thử tĩnh và kiểm thử động. Chương này phân loại chi tiết các mức độ kiểm thử: đơn vị, tích hợp (4 loại), hệ thống (13 loại chuyên biệt), chấp nhận và kiểm thử hồi quy; đồng thời so sánh phương pháp kiểm thử hộp đen và kiểm thử hộp trắng.
  • Ngôn ngữ UML: Giới thiệu 5 hướng nhìn (Use case, Logic, Component, Concurrent, Deployment), 9 loại biểu đồ và các mối quan hệ mô hình hóa. Đi sâu vào cấu trúc của biểu đồ trạng thái (chu kỳ sống, trạng thái, hành vi, sự kiện chuyển đổi) và biểu đồ tuần tự (đường đời lifeline, thông điệp gửi/nhận, các khối phân đoạn Combined Fragments với các toán tử alt, opt, break, loop). Cuối chương, tác giả định nghĩa cấu trúc hình thức của đồ thị tuần tự $G(N, E)$ với tập đỉnh $N$ đại diện cho thông điệp và tập cạnh $E$ đại diện cho thứ tự thời gian.

Chương 3: Phương pháp sinh ca kiểm thử từ biểu đồ tuần tự và biểu đồ trạng thái

Chương 3 là nội dung đóng góp trọng tâm của luận văn:

  • Phương pháp luận: Trình bày chi tiết quy trình 3 bước từ chuyển đổi biểu đồ tuần tự sang đồ thị tuần tự, tích hợp với biểu đồ trạng thái để tạo đồ thị chung, đến việc duyệt đồ thị chung bằng thuật toán DFS.
  • Hình thức hóa: Định nghĩa cấu trúc ca kiểm thử 4 thành phần ${\text{ID}, \text{Start State}, \text{Set of Message}, \text{End State}}$ và sự kiện thông điệp 3 thành phần ${\text{messageName}, \text{fromObject}, \text{toObject}}$.
  • Ví dụ minh họa: Tác giả sử dụng ca sử dụng chức năng "Rút tiền" trong hệ thống máy rút tiền tự động (ATM) để minh họa từng bước:
    1. Khách hàng đưa thẻ vào máy ATM.
    2. Máy ATM kiểm tra thẻ và yêu cầu nhập mã PIN.
    3. Khách hàng nhập mã PIN.
    4. Máy ATM xác thực mã PIN và yêu cầu chọn loại giao dịch.
    5. Khách hàng chọn giao dịch rút tiền.
    6. Hệ thống yêu cầu nhập số tiền cần rút.
    7. Khách hàng nhập số tiền cần rút.
    8. Hệ thống kiểm tra số dư tài khoản và đưa ra thông báo lỗi hoặc tiến hành chi tiền giao dịch.
  • Cài đặt công cụ: Trình bày chi tiết quy trình tạo và triển khai module trên Modelio thông qua Maven Project, cài đặt Archetype Catalog và tích hợp vào hệ thống.
  • Thuật toán: Đặc tả thuật toán chuyển đổi biểu đồ tuần tự sang đồ thị tuần tự, thuật toán duyệt đồ thị xác định đường kiểm thử (Test Path) và bảng mô tả quá trình duyệt các phần tử trong danh sách Interaction Fragment.

Chương 4: Kết luận

Chương 4 tổng kết toàn bộ các kết quả nghiên cứu đã đạt được trong luận văn, đánh giá mức độ hoàn thành so với mục tiêu ban đầu, đồng thời thẳng thắn chỉ ra các hạn chế kỹ thuật hiện tại và đề xuất các hướng phát triển mở rộng trong tương lai.

Kết quả và đóng góp

1. Kết quả chính

  • Xây dựng thành công quy trình phương pháp luận tự động sinh ca kiểm thử từ sự kết hợp giữa biểu đồ tuần tự và biểu đồ trạng thái UML.
  • Đề xuất mô hình hình thức hóa chuẩn xác cho ca kiểm thử (bộ 4 phần tử) và sự kiện thông điệp (bộ 3 phần tử), giúp cấu trúc dữ liệu kiểm thử rõ ràng và độc lập với mã nguồn.
  • Thiết lập thuật toán chuyển đổi mô hình sang đồ thị tuần tự và thuật toán duyệt đồ thị theo chiều sâu (DFS) để tự động trích xuất các đường kiểm thử (test paths).
  • Đáp ứng đồng thời hai tiêu chuẩn bao phủ quan trọng trong kiểm thử phần mềm: bao phủ toàn bộ thông điệp trao đổi (Message Coverage) và bao phủ các chuyển đổi trạng thái của đối tượng (State Coverage).
  • Cài đặt thành công module thử nghiệm tích hợp trên công cụ Modelio thông qua Maven, kiểm chứng tính khả thi và chính xác của thuật toán thông qua ca sử dụng chức năng rút tiền của hệ thống máy ATM.

2. Đóng góp so với các nghiên cứu trước

  • Khắc phục hạn chế của việc kiểm thử đơn lẻ: So với các nghiên cứu chỉ sử dụng biểu đồ tuần tự (thiếu thông tin về trạng thái nội tại của đối tượng) hoặc chỉ sử dụng biểu đồ trạng thái (thiếu ngữ cảnh tương tác tổng thể giữa các đối tượng), giải pháp tích hợp của luận văn cung cấp đầy đủ cả luồng thông điệp lẫn sự biến đổi trạng thái trong cùng một kịch bản kiểm thử.
  • Nâng cao mức độ tự động hóa: So với phương pháp bán tự động của Bertolino và Basanieri, quy trình chuyển đổi và duyệt đồ thị trong luận văn được tự động hóa hoàn toàn thông qua thuật toán rõ ràng.
  • Tối ưu hóa quy trình phát triển phần mềm: Tạo điều kiện cho kiểm thử viên phát hiện sớm các điểm mâu thuẫn, nhập nhằng trong tài liệu thiết kế UML trước khi tiến hành viết mã nguồn, giảm thiểu chi phí khắc phục lỗi và hỗ trợ lập trình song song với kiểm thử.

Hạn chế và hướng nghiên cứu tiếp

1. Hạn chế

  • Quá trình thực nghiệm và kiểm chứng thuật toán mới chỉ dừng lại ở các ca sử dụng tiêu biểu của hệ thống máy rút tiền ATM; chưa được đánh giá trên các hệ thống công nghiệp quy mô lớn với nhiều tiến trình phân tán phức tạp.
  • Mức độ tự động hóa trong việc sinh dữ liệu kiểm thử cụ thể (Test Data Generation) gắn với các giá trị biên của điều kiện rẽ nhánh vẫn cần được hoàn thiện thêm.

2. Hướng nghiên cứu tiếp

  • Mở rộng thuật toán để xử lý tối ưu và toàn diện hơn các toán tử tương tác phức tạp trong chuẩn UML 2.0, đặc biệt là các cấu trúc lặp (loop), xử lý song song (par) và các phân đoạn ngắt (break).
  • Nghiên cứu kết hợp các kỹ thuật sinh dữ liệu kiểm thử tự động tương ứng với từng ca kiểm thử được tạo ra.
  • Tiếp tục hoàn thiện module trên Modelio thành một công cụ hoàn chỉnh, hỗ trợ xuất trực tiếp kịch bản kiểm thử sang mã kiểm thử tự động (như các framework kiểm thử đơn vị JUnit/TestNG).

Giá trị tham khảo

Luận văn là tài liệu tham khảo hữu ích cho các nhóm đối tượng:

  • Sinh viên, học viên cao học ngành Công nghệ thông tin và Kỹ thuật phần mềm: Tài liệu cung cấp hệ thống lý thuyết chuẩn mực về kiểm thử phần mềm, kiểm thử dựa trên mô hình (Model-Based Testing - MBT) và phương pháp hình thức hóa các biểu đồ thiết kế UML.
  • Kiểm thử viên (QA/QC) và kỹ sư phần mềm: Cung cấp phương pháp luận và thuật toán thực tế để thiết kế kịch bản kiểm thử tự động sớm từ tài liệu thiết kế, giúp tối ưu hóa chi phí và thời gian kiểm thử trong các dự án hướng đối tượng.

Các nội dung có giá trị tham khảo cao nhất:

  1. Phần tổng hợp lý thuyết kiểm thử ở Chương 2: Phân định rõ ràng các khái niệm Error, Fault, Failure, Incident và hệ thống 13 loại kiểm thử trong kiểm thử hệ thống.
  2. Định nghĩa hình thức bộ 4 phần tử của ca kiểm thử và quy trình 3 bước tích hợp đồ thị tuần tự - biểu đồ trạng thái ở Chương 3.
  3. Hướng dẫn từng bước cấu hình, xây dựng và triển khai module mở rộng trên công cụ Modelio sử dụng Apache Maven.

Câu hỏi thường gặp

1. Tại sao đề tài lại kết hợp cả biểu đồ tuần tự và biểu đồ trạng thái thay vì chỉ dùng một loại biểu đồ?

Biểu đồ tuần tự mô tả trực quan trình tự trao đổi thông điệp giữa các đối tượng theo thời gian nhưng không cung cấp thông tin về vòng đời, trạng thái nội tại và sự chuyển đổi trạng thái của từng đối tượng khi thực hiện hành vi. Ngược lại, biểu đồ trạng thái chỉ tập trung vào một đối tượng riêng lẻ mà thiếu ngữ cảnh tương tác toàn cục. Việc kết hợp cả hai biểu đồ giúp ca kiểm thử sinh ra vừa bao phủ được luồng thông điệp (Message Coverage) vừa bao phủ được các chuyển đổi trạng thái của đối tượng (State Coverage).

2. Cấu trúc của một ca kiểm thử được định nghĩa hình thức như thế nào trong luận văn?

Tác giả định nghĩa một ca kiểm thử là một bộ gồm 4 phần tử: $${\text{ID}, \text{Start State}, \text{Set of Message}, \text{End State}}$$ Trong đó: ID là mã định danh duy nhất; Start State là trạng thái bắt đầu; Set of Message là tập các sự kiện thông điệp dạng ${\text{messageName}, \text{fromObject}, \text{toObject}}$; và End State là trạng thái kết thúc của đối tượng sau kịch bản.

3. Thuật toán nào được tác giả sử dụng để trích xuất các đường kiểm thử (Test Paths)?

Sau khi kết hợp đồ thị tuần tự và biểu đồ trạng thái thành một "đồ thị chung", tác giả áp dụng thuật toán tìm kiếm theo chiều sâu (Depth-First Search - DFS) duyệt từ đỉnh gốc (thông điệp khởi đầu) đến các đỉnh lá (thông điệp kết thúc) để xác định toàn bộ các đường kiểm thử tương ứng với các kịch bản thực thi.

4. Công cụ nào được sử dụng để cài đặt thử nghiệm giải pháp của luận văn?

Tác giả sử dụng công cụ mô hình hóa Modelio và phát triển một module mở rộng (Modelio Module). Module này được khởi tạo, quản lý và đóng gói thông qua công cụ Apache Maven với Modelio Archetype Catalog, sau đó tích hợp trực tiếp vào Module Catalog của Modelio.

Kết luận

Luận văn thạc sĩ của tác giả Nguyễn Thị Bích Hà đã giải quyết hiệu quả bài toán tự động hóa sinh ca kiểm thử cho phần mềm hướng đối tượng dựa trên mô hình thiết kế UML. Bằng việc kết hợp biểu đồ tuần tự và biểu đồ trạng thái, tác giả đã xây dựng quy trình chuyển đổi đồ thị và áp dụng thuật toán tìm kiếm theo chiều sâu (DFS) để trích xuất các kịch bản kiểm thử đảm bảo độ bao phủ thông điệp lẫn trạng thái. Kết quả nghiên cứu được kiểm chứng thông qua việc cài đặt thành công một module mở rộng trên công cụ Modelio và áp dụng cho ca sử dụng rút tiền của hệ thống máy ATM, đóng góp một giải pháp khả thi giúp giảm thiểu chi phí và nâng cao chất lượng kiểm thử phần mềm ngay từ giai đoạn thiết kế.