Chương 3 : Kiểm thử trên cơ sở các mô hình UML
3.6. UML trong pha kiểm thử tích hợp
Để phát triển một hệ thống phần mềm trên cơ sở cấu phần, trước hết chúng ta cần kiểm thử từng cấu phần riêng rẽ. Vậy tại sao chúng ta nên xem xét đến khả năng gắn kết của các cấu phần này? Thực tế, các cấu phần có thể được phát triển bởi các đối tượng khác nhau, trên các ngôn ngữ lập trình khác nhau, và thực hiện trên nền hệ điều hành khác nhau. Như vậy, kiểm thử tích hợp là cần thiết để đảm bảo giao tiếp giữa các cấu phần là đúng. Chuẩn IEEE định nghĩa giao tiếp giữa các cấu phần đó như sau:
Kiểm thử trong đó các cấu phần phần mềm, cấu phần phần cứng hoặc cả hai được kết hợp. Kiểm thử để đánh giá sự tương tác giữa chúng.
Khi ta phát triển phần mềm trên cơ sở cấu phần, ta phát triển và kiểm thử từng cấu phần riêng rẽ. Tại sao các vấn đề có thể phát sinh khi ta thực hiện tích hợp các cấu phần đó? Cách thức thực hiện kiểm thử tích hợp như thế nào để xác định được các vấn đề? Tiếp sau là mô hình đặc tả các khả năng phát hiện khiếm khuyết trong suốt kiểm thử mức đơn vị. Các khiếm khuyết này liên quan đến sự tương tác, có thể được phân loại thành các dạng khiếm khuyết liên quan đến ngôn ngữ lập trình. Đó là các khiếm khuyết bên trong cấu phần, và các khiếm khuyết không liên quan đến ngôn ngữ lập trình, các khiếm khuyết có khả năng xuất hiện trong khi người dùng thao tác hệ thống. Các khiếm khuyết được phát hiện khi kiểm thử đơn vị, kiểm thử tích hợp và được phân loại theo các dạng khiếm khuyết cơ bản.
Dạng 1: Các khiếm khuyết trong cấu phần
Khiếm khuyết có thể được phát hiện khi các cấu phần trong hệ thống tương tác với nhau. Các khiếm khuyết này liên quan đến ngôn ngữ lập trình, khi phần tử cấu phần được kết hợp với một hoặc nhiều phần tử trong cấu phần và nó được
coi là khiếm khuyết bên trong cấu phần. Ví dụ, trong một đoạn code được chỉ ra
như sau: sau khi thêm i=0 vào hàm I1của cấu phần C1, và kiểm tra các hàm I1, I2,
ta không phát hiện ra lỗi. Nhưng khi triển khai cấu phần C1,C2, C3 và I1 được gọi
bởi I2, lỗi xảy ra trong cấu phần C3.
C1: I1 → i = 0; I2 → return i;
C2: I1 → C1: :I1(); C3: I4 → j = 1/C1: :I2();
Rất nhiều khả năng gây khiếm khuyết khác có thể được phân loại là khiếm khuyết trong cấu phần. Ví dụ lỗi làm trì trệ hệ thống (deadlock), hoặc tác vụ đang thực hiện rơi vào vòng lặp vô hạn(livelock). Mục tiêu chính của kiểm thử tích hợp là tìm ra những khiếm khuyết đó trong hệ thống.
Dạng 2: Các khiếm khuyết trong thao tác (Interoperability)
Với hệ thống xây dựng trên cơ sở cấu phần có thể phát sinh rất nhiều đặc điểm bất lợi, chẳng hạn như tính không đồng nhất, mã nguồn không có sẵn, khả năng sử dụng lại sẽ gây ra các vấn đề bên trong thao tác. Các lỗi do thao tác được phân loại ở mức hệ thống, mức ngôn ngữ lập trình, thao tác mức đặc tả.
Các khiếm khuyết mức hệ thống: Trong một hệ thống phần mềm trên cơ sở cấu phần, các cấu phần khác nhau có thể được xây dựng dưới các hạ tầng khác nhau, và các hạ tầng đó có thể là 100% không tương thích. Ví dụ, sự không tương thích giữa các sản phẩm CORBA khác nhau có thể ảnh hưởng đến tương tác trong bản thân các cấu phần CORBA.
Các khiếm khuyết mức ngôn ngữ lập trình: Khi các cấu phần được viết bằng các ngôn ngữ lập trình khác nhau, sự không tương thích giữa các ngôn ngữ có thể là nguyên nhân gây lỗi. Ví dụ như, Microsoft hỗ trợ sự tích hợp các cấu phần VC và VB. Nhưng sự không tương thích lại xảy ra khi thao tác với các số thực.
Các khiếm khuyết mức đặc tả: Lập trình viên có thể có những hiểu biết về đặc tả không đúng, và sự thiếu hiểu biết về đặc tả thể hiện theo nhiều cách khác nhau. Loại lỗi này có thể phát sinh khi truyền dữ liệu vào từ giao diện hoặc các mẫu tương tác cấu phần.
Dạng 3: Các khiếm khuyết căn bản và các khiếm khuyết khác
Thông qua kiểm thử truyền thống và các kỹ thuật bảo trì có thể phát hiện các khiếm khuyết trong 1 cấu phần độc lập. Các khiếm khuyết này có thể được định nghĩa dưới dạng khiếm khuyết căn bản. Các khiếm khuyết khác chẳng hạn khiếm khuyết liên quan đến đặc tả đầu vào, hoặc môi trường thực thi theo đặc tả.