Thuật ngữ “Tích hợp” liên quan mật thiết đến hoạt động phát triển phần mềm, ở đó các cấu phần phần mềm được kết hợp với nhau làm nên hệ thống tổng thể. Việc tích hợp được tiến hành ở rất nhiều mức, trong nhiều giai đoạn triển khai như:
Tích hợp các công việc của một nhóm triển khai hệ thống con, trước
khi giao hệ thống con đó cho đối tượng tích hợp.
Tích hợp các hệ thống con vào thành một hệ thống hoàn chỉnh.
UML được sử dụng hỗ trợ thiết kế các hệ thống trên cơ sở cấu phần. Một số các lược đồ UML được sử dụng để sinh các tình huống kiểm thử tự động.
Theo J. Offutt và A. Abdurazik lần đầu tiên đã đề xuất cơ chế để đáp ứng tiêu
chí sinh dữ liệu kiểm thử trên cơ sở đặc tả trạng thái để tạo ra các tình huống kiểm thử từ các lược đồ trạng thái UML. Cùng lúc đó, L.Briand và Y.Labiche đã đề xuất sử dụng lược đồ lớp, lược đồ cộng tác (OCL) để mô tả các yêu cầu kiểm thử. Với các lợi ích mà kiểm thử mang lại, các phần tử kiểm thử trên cơ sở UML cũng được sử dụng vào các quy trình công nghệ trên cơ sở cấu phần khác. Ví dụ, chúng có thể được sử dụng trong việc lựa chọn cấu phần, quy trình định nghĩa chất lượng cấu phần tương ứng kiến trúc cấu phần, đặc tả, tùy biến và bảo trì cấu phần. Như vậy, các phần tử này có thể trở thành một phần của các hướng dẫn mà nhà cung cấp cấu phần bàn giao để đảm bảo rằng công nghệ trên cơ sở cấu phần là ổn định và các cấu phần là thực thi tốt trong hệ thống.
Khi các cấu phần được tích hợp, lập trình viên dựa vào các giao diện đặc tả cấu phần và sự kiện xác định được các tương tác giữa chúng. Nhưng làm thế nào để các giao diện và sự kiện này tương tác được với nhau, và các rủi ro tiềm ẩn với hệ thống tích hợp thường không được xét tới. Các quan hệ phụ thuộc bối cảnh, mô hình thể hiện tương tác các giao diện và sự kiện nhận được dựa trên một trong các tiếp cận sau:
1. Tiếp cận trên cơ sở mô hình usecase
Một trong các lợi ích khi áp dụng kiểm thử cấu trúc vào việc thể hiện lại các đoạn code để tìm ra các lỗi mà nếu chỉ áp dụng kiểm thử chức năng không phát
hiện được. Trong UML các use case được thể hiện dưới dạng lược đồ đồ họa, lược đồ chỉ ra mối quan hệ giữa các use case đó. Các quan hệ này xác định cấu trúc của lược đồ. Lý do để áp dụng tập các điều kiện mới là để đảm bảo việc kiểm thử được tối ưu.
Trong khi tiến hành quy trình kiểm thử, ta hướng tới 2 mục tiêu đó là: đánh giá chất lượng các tình huống chức năng thu được từ mô hình use case; và kiểm thử theo chính các đặc tả của use case đó. Để hỗ trợ các điều kiện kiểm thử cấu trúc use case trong ứng dụng, ta có thể triển khai sử dụng công cụ bao quát kiểm thử gọi là UCT – Use case tester. Công cụ này xác định yêu cầu kiểm thử theo cấu trúc điều kiện mới, xem xét hành vi thực hiện trên các use case, phân tích lại toàn bộ các điều kiện.
2. Tiếp cận trên cơ sở mô hình cộng tác/ tuần tự.
Các biểu đồ cộng tác UML và biểu đồ tuần tự thể hiện sự tương tác giữa các đối tượng khác nhau trong một use case (trong nghiên cứu này, chúng ta hiểu mỗi use case là 1 cấu phần.) Nếu một cấu phần bao gồm nhiều use cases, ta cần phát triển mở rộng lược đồ cộng tác. Nếu 1 use case phủ nhiều cấu phần, ta phát triển một tập con của lược đồ cộng tác. Trong các biểu đồ tuần tự UML, các tương tác được sắp xếp theo thời gian; trong biểu đồ cộng tác, cũng thông tin đó được xếp tuần tự theo các thông điệp. Dưới đây là ví dụ về biểu đồ cộng tác, biểu đồ tuần tự của một cấu phần phục vụ ATM.
Hình 14. Mô hình cộng tác mô tả hoạt động giao dịch của máy ATM
Tài khoản
Thẻ ATM
Giao dịch ATM <<Nghiệp vụ>>
Quản lý giao dịch rút tiền
Client component * * * * * * * * * * * * W3 W1 W8 W4A.1 W5A.2 W5B.2 W8 W4 W5 W5A W5B W2 W6 W7 W4A W5A1 W5B1 ATM server component
Hình 15. Mô hình tuần tự mô tả giao dịch ATM [3]
Thẻ ATM Tài khoản ATM Giao dịch ATM
Object4
Client component <Logic nghiệp vụ>
W1 W2 W3 W4 W5 W6 W7 W8
W1: Yêu cầu rút tiền ( chi tiết giao dịch)
W5A.1: Ghi giao dịch kiểm tra tài khoản
W2: Kiểm tra giới hạn thẻ (mã thẻ, số tiền)
W5A2: Trả lời khách ( sai tài khoản)
W3: Trả lời về giới hạn thẻ W5B: Quỹ thiếu
W4: Trừ tiền giao dịch (tài khoản, số tiền)
W5B.1: Ghi giao dịch quỹ
W4A: Ghi giao dịch kiểm tra thẻ W5B.2: Trả lời khách (quỹ thiếu)
W4A1: Trả lời khách (vượt quá giới hạn rút)
W6: Cập nhật giới hạn thẻ (card id, số tiền)
W5: Dữ liệu tài khoản W7: Ghi giao dịch.
W5A: Sai tài khoản W8: Trả lời khách
Hình trên mô tả 1 phần biểu đồ cộng tác và luồng biểu đồ tuần tự của một máy ATM. Biểu đồ tuần tự chỉ đưa ra một trong số chuỗi khả năng theo thứ tự thời gian, trong khi sự cộng tác kết hợp với tất cả các chuỗi theo thứ tự. Trong hình 14, W5, W5A và W5B tập trung vào 3 luồng đảo và có thể xảy ra sau khi thông điệp W4 truyền qua bởi đối tượng là nhà quản lý giao dịch, quản lý giao dịch rút tiền từ hệ thống ATM.
Với các biểu đồ cộng tác, chúng ta có thể sàng lọc các quan hệ phụ thuộc ngữ cảnh, như hình 14 thể hiện được các giao diện và sự kiện tương tác với nhau một cách chính xác.
2. Tiếp cận dựa trên biểu đồ trạng thái
Để mô hình hóa sự tương tác các cấu phần ta tiến hành liên hệ biểu đồ cộng tác với các biểu đồ trạng thái, vì biểu đồ cộng tác bản thân nó không đảm bảo mô tả hết. Biểu đồ trạng thái được sử dụng để mô tả các đối tượng điều khiển phụ thuộc trạng thái trong các cấu phần.
Hình 16. Mô hình trạng thái phục vụ của máy ATM [3]
2.6[Xác thực]: Xác thực PIN 2.6A [Hủy hiệu lực]: PIN không có hiệu lực 2.6B: Hủy tính hiệu lực thứ 3 của PIN
<<Thiết bị đọc I/O>>: Đầu đọc thẻ
<<Giao diện thiết bị I/O>>: Giao diện đọc thẻ
<<Thực thể>> Thẻ ATM
<<Giao diện người dùng>> Thẻ ATM
<<Thực thể>> Giao dịch ATM <<Điều khiển trạng thái>>
Bộ điều khiển ATM Ngân hàng phục vụ
* *
1. Thẻ đưa vào đầu đọc
1.1A Không nhận diện được thẻ: Từ chối
* *
1.1 Dữ liệu thẻ: Dữ liệu đọc
* * 1.2 Thẻ được đưa vào
*
*
1.3: Tiếp nhận PIN 2,6A.1: Thông báo số Pin sai 2.7: Hiển thị menu 2A.2a: Từ chối hiển thị
Khách hàng ATM
* *
1.4: Yêu cầu Pin 2.6A.2: Thông báo số Pin sai 2.8: Menu lựa chọn 2A.2a.1: Thông báo từ chối
2; 2.6A.3: Nhập số Pin 2A: Từ chối nhập * * 2.1; 2.6A.4: Yêu cầu đọc thẻ 2,2; 2.6A5: Dữ liệu thẻ * * 2,3; 2.6A6: Thông tin khách hàng 2A.1: Từ chối 2.4; 2.6A7: Dữ liệu thẻ, PIN 2.5; 2.6A8: Xác thực tính hợp lệ PIN * * * *
2.6A.1a; 2.6.1a; 2.7a: Cập nhật trạng thái 2A.2: Hủy 2.6B.1: sung công 2A.2: Hủy 2.6B.1: sung công
Các bước chỉ ra trong lược đồ trạng thái bao gồm:
1 - 1.1 - 1.2 - 1.3 - 1.4 1 - 1.1A
2 - 2.1 - 2.2 - 2.3 - 2.4 - 2.5 - 2.6 - 2.7, 2.7a - 2.8 2.6A - 2.6A.1, 2.6A.1a - 2.6A.2
2.6B - 2.6B.1, 2.6B.1a - 2.6B.2
2A - 2A.1 - 2A.2, 2A.2a - 2A.3, 2A.2a.1
2.6A3 - 2.6A4 - 2.6A5 - 2.6A6 - 2.6A7 - 2.6A8
Như ta thấy, tuần tự “ 2A – 2A.1 – 2A.2, 2A.2a – 2A.3, 2A.2a.1( 2A.2 và 2A.2a là 2 thông điệp tồn tại cùng lúc) chỉ chuỗi cho phép người dùng hủy. Tuy thế, chuỗi này có thể xảy ra trong hoàn cảnh khác, như khi người dùng hủy giao dịch hiện tại sau khi đã nhập số PIN, hoặc người dùng hủy giao dịch hiện thời
sau khi nhập sai số PIN. Với việc sử dụng biểu đồ trạng thái, ta có thể thấy rõ chuỗi các chuỗi thực hiện như sau:
(1) chờ nhập PIN, (2) xác thực PIN, và (3) chờ khách hàng lựa chọn.
Bằng cách sử dụng biểu đồ trạng thái, các giao tiếp giữa giao diện với các sự kiện có thể được làm rõ hơn.
Các mối quan hệ phụ thuộc về nội dung, mối quan hệ phụ thuộc ngữ cảnh phản ánh các chuỗi điều khiển của đối tượng trong một cấu phần với các tương tác giữa actors và cấu phần đó. Tuy nhiên, các mối quan hệ phụ thuộc nội dung khác với các tương tác là nó không thể chứa thông tin luồng điều khiển.Ví dụ, xem hình mô phỏng giao dịch phục vụ của máy ATM. Cấu phần gồm 2 giao diện – rút tiền và gửi tiền. Các quan hệ phụ thuộc ngữ cảnh có thể mô tả tương tác giữa các giao diện, nhưng các quan hệ phụ thuộc nội dung giữa các giao diện không thể hiện được. Theo đó, giao diện rút tiền phụ thuộc giao diện gửi tiền bởi vì giao dịch gửi tiền sẽ cập nhật vào đối tượng tài khoản, trong khi giao dịch rút tiền sẽ sử dụng nó để kiểm tra xem còn đủ tiền trong tài khoản không. Nhưng mặt khác, các quan hệ phụ thuộc nội dung không được đặc tả một cách trực tiếp trong chương trình cũng như trong bất cứ lược đồ nào. Để đặc tả các quan hệ phụ thuộc nội dung, thêm nữa là việc xử lý của các lược đồ UML là cần thiết. Rất nhiều các tiếp cận có thể bỏ qua.
Để mô hình hóa các mối quan hệ phụ thuộc về nội dung, chúng ta loại ra các quan hệ phụ thuộc không có hiệu lực:
Nếu I2 vẫn còn lại trong trạng thái ban đầu, S1m sau lời gọi I1, mối quan hệ phụ thuộc không ảnh hưởng đến hoạt động cuả phần mềm; mối quan hệ phụ thuộc đó là không hiệu quả.
Từ một trạng thái S, nếu lời gọi của I2 cho trạng thái S2 , sẽ không ảnh hưởng gì đến việc giao diện I1 có được gọi hay không. Trạng thái chuyển đổi chính là yếu tố xác định các quan hệ phụ thuộc.
Ưu điểm của các cách tiếp cận trên cơ sở UML có thể thấy được qua:
Các lược đồ UML thường được sử dụng đến trong pha phân tích và chịu sự tích hợp với cấu phần cung ứng. Hơn nữa, người dùng cấu phàn có thể nhận được các mẩu thông tin thông qua các lược đồ thể hiện. Điều này thể hiện tính mềm dẻo, khả năng mở rộng và tính hiệu quả trên sự phát triển phần mềm cấu phần.
Các mối quan hệ phụ thuộc ngữ cảnh và phụ thuộc về nội dung, điều kiện kiểm thử cung cấp trong mô hình của chúng ta sẽ được cập nhật theo:
Mỗi bước chuyển tiếp trong lược đồ cộng tác phải được kiểm thử ít nhất một lần.
Mỗi luồng đúng trong lược đồ cộng tác phải được kiểm thử ít nhất 1 lần. Mỗi quan hệ phụ thuộc về nội dung nhận được từ lược đồ cộng tác phải được kiểm thử ít nhất 1 lần.
Mỗi quan hệ phụ thuộc nội dung một cách hiệu quả nhận được từ lược đồ trạng thái phải kiểm thử ít nhất 1lần.
Hình 17. Mô hình cấu phần phục vụ giao dịch gửi/rút tiền ATM
Tài khoản
Thẻ ATM
Giao dịch ATM <<Nghiệp vụ>>
Quản lý giao dịch rút tiền * * * * * * Ai ATM server component
<<Nghiệp vụ>>
Quản lý giao gửi tiền
* * Ai+1 * * Bj ** Bj+1
Chương 4: Thực nghiệm kiểm thử phần mềm