Mô hình áp dụng cho kiểm thử tích hợp phần mềm cấu phần

Một phần của tài liệu Nghiên cứu kỹ thuật kiểm thử phần mềm trên cơ sở mô hình UML (Trang 62)

Kiểm thử phần mềm trên cơ sở cấu phần tập trung vào tính hiệu quả. Ở đây, ta mô tả lại một mô hình kiểm thử. Đây là một sự mở rộng của cách tiếp cận trên cơ sở đồ họa. Trong mô hình này, ta định nghĩa về các nhân tố kiểm thử có khả năng làm bộc lộ các khiếm khuyết tích hợp.

Các phần tử kiểm thử:

Trong quá trình kiểm thử tích hợp, mô hình kiểm thử của ta nhấn mạnh vào sự tương tác giữa các cấu phần trong các hệ thống phần mềm cấu phần để phát hiện ra các khiếm khuyết dạng 1 hoặc 2. Một cấu phần có thể tương tác trực tiếp với các cấu phần khác thông qua lời gọi giao diện từ các cấu phần đó, một trường hợp ngoại lệ đó xuất hiện khi người dùng kích hoạt một sự kiện. Một cấu phần cũng có thể tương tác với các cấu phần khác một cách gián tiếp thông qua các sự kiện tuần tự. Giao diện là cách chung nhất để kích hoạt các cấu phần. Như vậy kiểm thử từng giao diện trong môi trường tích hợp ít nhất một lần là cần thiết. Mặt khác, mỗi giao diện có thể được gọi khi tiến hành triển khai kiểm thử ít nhất một lần. Mục tiêu này là giống với tiêu chí kiểm thử truyền thống, nó đòi hỏi mỗi chức năng/thủ tục phải được kiểm thử ít nhất một lần. Tuy nhiên, cùng 1 lời gọi giao diện trên các cấu phần khác nhau, sẽ cho ra kết quả khác nhau. Như vậy, để quan sát các hành vi có thể có của mỗi giao diện trong thời gian thực hiện, mỗi lời gọi duy nhất của các giao diện cần được kiểm thử ít nhất một lần. Một số sự kiện không được kích hoạt thông qua giao diện vẫn có thể có những ảnh hưởng trên các cấu phần, cũng cần được kiểm thử. Như vậy, mỗi sự kiện trong hệ thống dù là dạng nào đều cần được kiểm thử.

Các mối quan hệ phụ thuộc ngữ cảnh

Kiểm thử giao diện và sự kiện đảm bảo rằng tương tác giữa hai cấu phần – client và server được thực hiện. Tuy nhiên, sự thực thi hệ thống phần mềm trên cơ sở cấu phần bao gồm tương tác trong nhóm cấu phần, sự kiện tuần tự được kích hoạt có thể đem lại kết quả đầu ra không như mong đợi. Để nắm được quan hệ bên trong các sự kiện, ta định nghĩa một quan hệ phụ thuộc bối cảnh giống với quan hệ phụ thuộc luồng điều khiển trong phần mềm truyền thống. Một sự

kiện e2 có quan hệ phụ thuộc bối cảnh với sự kiện e1 nếu tồn tại một cách thực

hiện ở đó sự kiện e1 tác động trực tiếp hoặc gián tiếp lên e2. Với một sự kiện đưa

ra e, cần thiết kiểm thử e với mỗi sự kiện có mối quan hệ phụ thuộc bối cảnh với e, để quan sát diễn biến ảnh hưởng trên đầu ra của thực hiện e. Các quan hệ phụ thuộc bối cảnh cũng bao gồm các quan hệ cộng tác không trực tiếp giữa các giao

diện và sự kiện. Như vậy, kiểm thử các mối quan hệ phụ thuộc bối cảnh có thể phát hiện các lỗi thao tác sai khi tương tác các cấu phần khác nhau.

Các quan hệ phụ thuộc về nội dung ( content-dependence relationships)

Khái niệm quan hệ phụ thuộc về nội dung giữa 2 giao diện v1 và v2 cho rằng

trên 2 giao diện đó có một mối quan hệ phụ thuộc dữ liệu. Một giao diện đóng gói một hoặc một số ký hiệu (signature) mà ở đó mỗi ký hiệu được gọi thông qua các lời gọi, mỗi lời gọi mô tả một chức năng. Khi một giao diện được gọi, một hoặc một số chức năng sẽ được thực thi để đáp ứng dịch vụ yêu cầu. Như vậy, mối quan hệ phụ thuộc giao diện có thể nhận được từ quan hệ phụ thuộc chức năng, nó chỉ ra thông tin có lợi trong kiểm thử lớp hướng đối tượng và

kiểm thử hồi quy. Một cách chính xác hơn, một chức năng f2 phụ thuộc vào một

chức năng f1 nếu và chỉ nếu giá trị của một biến được định nghĩa trong f1 và

được sử dụng trong f2. Như vậy, một quan hệ phụ thuộc về nội dung được định

nghĩa theo: một giao diện v2 có một quan hệ phụ thuộc về nội dung với giao diện

v1 nếu và chỉ nếu v1 chứa lời gọi (signature) của f1, v2 chứa lời gọi (signature) của f2, và f2 phụ thuộc vào f1.

Tương tác giữa giao diện và sự kiện và các quan hệ phụ thuộc về nội dung bao hàm trong tương tác của hệ thống trên cơ sở cấu phần trong bối cảnh luồng điều khiển. Mặt khác, phụ thuộc về nội dung (content – sensitive dependence) có thể cung cấp thêm thông tin khi sinh các tình huống và tìm ra các khiếm khuyết.

Lược đồ tương tác cấu phần

Lược đồ tương tác cấu phần (CIG - Component Interaction graph) mô tả các chuỗi tương tác được sử dụng để mô hình hóa sự tương tác giữa các cấu phần. Các tương tác có thể diễn ra trực tiếp hoặc gián tiếp. Các tương tác trực tiếp được tiến hành thông qua một sự kiện đơn, trong khi các tương tác gián tiếp được tiến hành thông qua nhiều sự kiện trong yêu cầu thực thi, và các quan hệ phụ thuộc dữ liệu sẽ đem lại các giá trị đầu ra khác nhau.

Ta thể hiện CIG bằng CIG = (V, E); V=VI* VE là tập các nút, với VI là tập

các nút giao diện, VE là tập các nút sự kiện, E là tập các cạnh. Lược đồ tương tác

thể hiện các tiếp cận trực tiếp được áp dụng.

Giữa hai loại đối tượng cần có một cách hành xử nào đó: quan hệ phụ thuộc bối cảnh và các quan hệ phụ thuộc về nội dung. Để định nghĩa các quan hệ phụ thuộc bối cảnh trong CIG, ta cần sử dụng đến một hướng tiếp cận cơ bản. Trong khi để định nghĩa các mối quan hệ phụ thuộc về nội dung, thì các mối quan hệ phụ thuộc dữ liệu cần được thể hiện.

Tiêu chí thỏa mãn kiểm thử

Chi phí phát triển phần mềm và lịch trình chứa đựng quy trình chất lượng phát triển phần mềm thường là các vấn đề rất khó thỏa hiệp. Sự cân nhắc giữa mục tiêu, lịch trình, và chất lượng là một nhiệm vụ khó thực hiện và quản lý. Kiểm thử là một quy trình được tiến hành theo các giai đoạn, và được thực hiện ở các mức chi tiết khác nhau nhằm thỏa mãn yêu cầu đảm bảo chất lượng.

Các mức cơ bản trong mô hình này gồm các giao diệnsự kiện được gắn

vào tất cả các nút. Mỗi lần các giao diện và sự kiện được kiểm thử, tương tác trực tiếp với các cấu phần cũng được kiểm thử. Để kiểm thử các các phụ thuộc bối cảnh chung, các lời gọi giao diện được định nghĩa theo các các dẫn xuất bối

cảnh (context-sensitive paths), các đường nối e1 và e2 trong CIG. Thông thường,

tất cả các đường p = {ei, ei+1, ei+2, ..., ej} trong đó (ei, ei+1) ϵ CIG. Một sự kiện e1

tác động lên e2; như vậy tất cả các tương quan trong p đều tồn tại và cần được

kiểm thử.

Hình 13. Tập điều kiện kiểm tra phụ thuộc [3]

Tất cả các phụ thuộc nội dung

Tất cả các phụ thuộc bối cảnh / Một số phụ thuộc nội dung

Tất cả các phụ thuộc bối cảnh

Tất cả các sự kiện

Tất cả các giao diện

Bao quát các quan hệ

Phụ thuộc bối cảnh chung (all-context dependency) sẽ kiểm thử tất cả các chuỗi điều khiển trong một hệ thống cấu phần. Để thêm các tương tác không trực tiếp giữa các cấu phần, các nguyên nhân tương tác dữ liệu này cần được xem xét. Phụ thuộc về mặt nội dung chung cần được thỏa mãn. Các dẫn xuất về nội dung có thể được sử dụng để mô tả các quan hệ phụ thuộc này. Các dẫn xuất

về nội dung được định nghĩa bởi tập các dẫn xuất bối cảnh (pa, pb) với pa và pb là

các dẫn xuất bối cảnh, giao diện I1 ϵ pa và I2 ϵ pb có 1 quan hệ phụ thuộc về nội

dung. Mỗi dẫn xuất bối cảnh cần được thực thi, và cần thiết để đảm bảo rằng sự

thực thi của I1 đến trước của I2 để thấy được khiếm khuyết xảy ra trong quan hệ

phụ thuộc nội dung.

Một phần của tài liệu Nghiên cứu kỹ thuật kiểm thử phần mềm trên cơ sở mô hình UML (Trang 62)