Thảo luận và kiểm thử hướng đối tượng

Định nghĩa

Kiểm thử tích hợp hướng đối tượng (OOTT) là kiểm thử tập hợp các thành phần hướng đối tượng (set of object oriented components).

Như vậy, có thể hiểu OOTT là kiểm thử sự tương tác giữa các thành phần hướng đối tượng. Hiểu các thành phần hướng đối tượng theo nghĩa hẹp là các đối tượng sinh ra bởi mã lệnh chương trình, theo nghĩa rộng là các đối tượng của chương trình phần mềm và các thiết bị phần cứng khác hỗ trợ việc thực thi một phiên làm việc trong hệ thống. Ví dụ, hệ thống thanh toán thẻ rút tiền tự động ATM (Automated Teller Machine), các thành phần hướng đối tượng được hiểu là các đối tượng chương trình phần mềm và thiết bị của máy ATM.

Theo sự phân cấp độ trong mục 1.2, kiểm thử tích hợp được thực hiện sau hoạt động kiểm thử lớp (kiểm thử đối tượng), các thành phần lỗi độc lập được tích hợp lại. Mục đích kiểm thử tích hợp là tìm ra các khiếm khuyết phát sinh khi những thành phần lỗi ảnh hưởng lẫn nhau trong một trường hợp cụ thể.

OOTT kiểm thử sự tương tác giữa hai đối tượng nảy sinhkhi một đối tượng gọi phương thức của các đối tượng khác bằng cơ chế gửi thông báo. Những đối tượng này cần phải là thể hiện của các lớp khác nhau. Nếu các đối tượng đều là thể hiện của cùng một lớp, khi đó kiểm thử được đề nghị là kiểm thử lớp (kiểm thử đối tượng).

Phần mềm hướng đối tượng được phát triển một cách gia tăng với vòng đời của việc lập kế hoạch, phân tích, thiết kế, thực hiện và kiểm thử. Kiểm thử tích hợp có vai trò đặc biệt ở đây khi nó được thực hịên sau mỗi bước phát triển.

Một số điểm khác biệt trong phần mềm hướng đối tượng

Phần mềm hướng đối tượng có cấu trúc và hành vi khác so với phần mềm thực hiện bằng ngôn ngữ hướng thủ tục. Phần mềm hướng đối tượng không phân rã chức năng trong các thủ tục riêng biệt, nó có các đối tượng và các lớp, sự tương tác với nhau thông qua gửi thông báo và dùng chung các định nghĩa thông qua sự thừa kế. Một đối tượng có thể ở trong một vài trạng thái khác nhau và có một số quan hệ với các đối tượng khác. Đối tượng phản hồi với một thông báo như thế nào còn phụ thuộc vào trạng thái hiện tại của nó.

Phần mềm hướng đối tượng không được phát triển với vòng đời phát triển theo mô hình thác nước truyền thống. Nó được phát triển tăng trưởng với chu kỳ có tính hồi quy của việc phân tích, thiết kế, thực hiện và kiểm thử. Những sự khác nhau căn bản này có ảnh hưởng lớn đến hoạt động kiểm thử.

Các ngôn ngữ lập trình hướng đối tượng đều trả lại điều khiển tới lời gọi đối tượng khi một thông báo được kết thúc. Không có vết thực thi đơn (single execution trace) trong phần mềm hướng đối tượng, một vết thực thi (execution trace) có thể được chia thành nhiều vết thực thi nhỏ hơn, quá trình cứ như vậy...

Những khó khăn cho hoạt động kiểm thử

Không có sự định nghĩa rõ ràng về cấu trúc tích hợp, không có cây quyết định thứ tự việc kiểm thử tích hợp các đối tượng bởi có thể không có một thành phần ở mức cao nhất hoặc mức thấp nhất trong phần mềm hướng đối tượng.

Kiểm thử phức tạp hơn nhiều so với kiểm thử phần mềm truyền thống. Các đối tượng giao tiếp và ảnh hưởng lẫn nhau thông qua các thông báo. Một thông báo thay đổi trạng thái của một đối tượng. Một đối tượng phản hồi với một thông báo như thế nào là phụ thuộc vào trạng thái của nó. Các đối tượng luôn được tạo ra và bị buỷ bỏ, những quan hệ qua lại giữa chúng luôn được tạo dần lên trong suốt thời gian thực thi chương trình. Những tương tác khả thi giữa các đối tượng (thành phần hướng đối tượng) tăng theo cấp số 2 khi đem so sánh với phần mềm truyền thống như thể hiện minh hoạ trong hình 3.

a) Sự tương tác giữa các đối tượng b) Quan hệ giữa các Module

So sánh mức độ phức tạp giữa phần mềm hướng đối tượng

và truyền thống

Sự phức tạp đó dẫn đến không có khả năng kiểm thử hết được tất cả các tương tác giữa các đối tượng, chi phí dành cho kiểm thử là quá lớn (cả về thời gian và công sức). Để giảm tối thiểu chi phí, người kiểm thử (Tester) cần phải chọn phương pháp “thông minh”. Ví dụ xét sự thừa kế lớp, giả sử tester đã kiểm thử sự tương tác giữa hai đối tượng A₁ và B₁, nếu có đối tượng thứ 3 là A₂ được thừa kế từ A₁. Khi kiểm thử đối tượng A_2, tester không phải kiểm thử đối tượng A₁ nữa mà chỉ phải kiểm thử những phương thức mới và đã được định nghĩa lại.

OOTT sau mỗi lần tăng trưởng có thể làm tăng thêm một chi phí rất lớn. Có nhiều chiến lược khác nhau mà có thể làm tối thiểu chí phí này, một số câu hỏi đặt ra là:

Việc kiểm thử bắt đầu từ đâu ?

Việc kiểm thử kết thúc ở đâu ?

Hoạt động kiểm thử như thế nào ?

Kiểm thử cái gì ?,.vv

Lựa chọn ca kiểm thử

Ca kiểm thử có thể rất nhiều khi có nhiều tương tác phức tạp giữa các đối tượng, câu hỏi đặt ra là tester phải chọn được ca kiểm thử tốt. Một ca kiểm thử được coi là “tốt” cần thoả mãn các yêu cầu sau: Có hiệu quả cao trong việc phát hiện lỗi, không rườm rà, cần phải là “tốt nhất” trong số các kỹ thuật cùng loại áp dụng, không đơn giản và cũng không phức tạp,v.v

Giải pháp (Solution) là lựa chọn ca kiểm thử thoả mãn được các yêu cầu về sự bao phủ (Covering) các đường cơ bản trong biểu đồ thông báo lớp (Class message diagram). Một lược đồ thông báo lớp bao gồm các nút và các cung, các nút (Node) thể hiện các phương thức và các cung thể hiện thông báo giữa hai phương thức như chỉ ra trong hình 4.

Biểu đồ thông báo lớp

Có nhiều tiêu chuẩn về sự bao phủ trong phần mềm hướng đối tượng, bài viết này đề xuất đến 2 tiêu chuẩn sau:

1. Bao phủ phương thức- Tất cả các nút phương thức của một lược đồ thông báo lớp phải được viếng thăm ít nhất một lần, nghĩa là mỗi phương thức trong hệ thống phải được thực hịên ít nhất một lần.
2. Bao phủ thông báo – Các thông báo có thể được chia thành các phần theo nguồn của thông báo. Ít nhất một thông báo từ mỗi nguồn cần phải được thực hịên.

Có thể sẽ không khả thi để bao phủ và thực hiện tất cả các ca kiểm thử. Tuy nhiên, các ca kiểm thử quan trọng và then chốt nhất cần phải được thực hiện. Một phân tích những ca kiểm thử cần phải được thực hiện để phát hiện ra các ca kiểm thử đó. Sự lựa chọn các ca kiểm thử có thể giựa vào việc trả lời các câu hỏi sau:

1. Ca kiểm thử quan trọng như thế nào đối với khách hàng ?
2. Độ xâu vết của ca kiểm thử trong phần mềm như thế nào ?,v.v

Một số kỹ thuật kiểm thử tích hợp

Nhiều kỹ thuật kiểm thử có thể được sử dụng trong suốt quá trình kiểm thử tích hợp. Các kỹ thuật kiểm thử khác nhau tìm ra sự khác biệt khác nhau của các lỗi, một số kỹ thuật phổ biến là:

1. Kiểm thử sự phân lớp (Classification Testing) - Kiểm thử mối quan hệ giữa các thể hiện của các lớp.
2. Kiểm thử kịch bản (Scenario Testing) - Kiểm thử sự tương tác của các đối tượng khác nhau mà đáp ứng được sự mong đợi của một ca kiểm thử đã được đặc tả.
3. Kiểm thử chấp nhận (Acceptance Testing) - Tìm ra các lỗi và các mâu thuẫn trong sự tích hợp của các thành phần.
4. Kiểm thử dựa trên sự kiện (Event – Based Testing) - Tìm ra các luồng điều khiển mà có thể không được thực hiện.
5. Kiểm thử dựa trên UML (UML – Based Testing) - Kết hợp đặc tả phân tích thiết kế phần mềm bằng ngôn ngữ mô hình hoá thống nhất UML (Unified Modeling Language) bởi các biểu đồ: biểu đồ ca sử dụng (use case diagram), biểu đồ lớp (class diagram), biểu đồ tuần tự (sequence diagram), v.v. với công cụ kiểm thử Rational Rose để sinh mã suôi và ngược.

Method-Message Path (MM-Path)

MM-Path là một chuỗi các sự kiện thực hiện phương thức được liên kết bởi các thông báo như trong hình 5.

Object 3 Method 1 Method 2 Method 3 Method 1 Method 2 Object 2 3 Object 1 Method 3 Method 2 Method 1 1 Input port event B Output port event B Output port event A Input port event A 2

MM-PathMessagesChú thích

Lược đồ các đường Method-Message

Một MM-Path bắt đầu với một phương thức và kết thúc khi nó gặp một phương thức mà không gọi một phương thức khác. Sự thực hiện trong phần mềm hướng đối tượng được bắt đầu bởi một sự kiện, sự kiện này có thể được hiểu như một cổng vào cho phần mềm (Input port event), ví dụ sự kiện cổng vào B trong hình vẽ ở trên. Sự kiện cổng vào khởi sự (gây ra) một chuỗi thông báo phương thức của một MM-Path. Một MM-Path kết thúc với một sự kiện cổng ra (Output port event), sự kiện này có thể khởi sự một cửa sổ để mở hoặc thay đổi trạng thái của hệ thống.

Một MM-Path kiểm thử sự tích hợp và sự tương tác của nhiều đối tượng khác nhau, các phương thức khác nhau truyền thông báo lần nhau. MM-Path là một khối nhỏ được xây dựng trong một kịch bản, bởi vậy kiểm thử MM-Path chỉ dừng lại ở kiểm thử tích hợp chứ không thể là kiểm thử hệ thống.

Atomic System Function (ASF)

Một ASF là một sự kiện cổng vào được theo bởi một tập các MM-Path và kết thúc với nhiều sự kiện cổng ra. Có thể xem một ASF như một MM-Path bao gồm nhiều MM-Path khác.

Sự khác nhau giữa một ASF và một MM-Path là một ASF là một chức năng căn bản nhìn thấy được ở cấp độ hệ thống. Một ASF là một điểm gặp nhau của kiểm thử tích hợp và kiểm thử hệ thống. Hình 6 dưới đây là ví dụ về một ASF của một phiên giao dịch kiểm tra số PIN (Personal Identification Number) trên một thẻ (Card) rút tiền của khách hàng (Customer) tại một máy ATM.

Hình 20.6 . ASF của hệ thống ATM

Hình 20.6 cho thấy sự tương tác giữa các đối tượng và truyền thông báo khi khách hàng nhập vào một số PIN đúng. Trường hợp có lỗi, sau đó có thể có nhiều hơn cấu trúc phức tạp của các đối tượng với các sự kiện cổng ra khác nhau.

Số PIN làm đầu vào cho ASF gồm 6 MM-Paths, được bắt đầu bởi việc khách hàng đút thẻ của mình vào máy ATM. ATM kết thúc ASF bởi việc hiển thị cho khách hàng một thông báo OK xác nhận số PIN đã được chấp nhận. ASF bao gồm các bước sau đây:

1. Thẻ rút tiền là đúng và được kiểm tra nếu nó là một loại thẻ thành viên dành cho máy ATM
2. Một thông báo OK xuất hiện và ATM hỏi khách hàng về số PIN
3. Khách hàng nhập vào số PIN và ATM phân tích số PIN đó
4. Bằng cách gửi số tài khoản cá nhân (Personal Account Number - PAN) trên thẻ rút tiền tới ngân hàng, số PIN đúng nhận được bởi ATM
5. Số PIN khách hàng đã nhập được kiểm tra một lần nữa so với số PIN nhận được từ ngân hàng
6. ATM hiển thị một thông báo hỏi khách hàng số tiền muốn rút

Một phiên giao dịch kiểm tra PIN đơn giản dùng cho ASF trên đây là một phần nhỏ của cả một phiên giao dịch ATM lớn hơn. Nó kiểm thử sự tương tác của một phần nhỏ trong hệ thống với một số đối tượng có liên quan. Đó là lý do đề nghị của việc kiểm thử tích hợp. Khi Tester kiểm thử toàn bộ phiên giao dịch ATM, lúc đó Tester sẽ kiểm thử hệ thống.