Giáo trình

Đảm bảo chất lượng phần mềm

Science and Technology

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

Kiểm thử phần mềm truyền thống

Hướng tiếp cận kiểm thử phần mềm truyền thống thường bắt đầu kiểm thử từ các Module chương trình độc lập sau đó mới tiến hành kiểm thử tích hợp dần các Module chương trình đó lại. Các chiến lược kiểm thử trong phần này gồm:

Kiểm thử đơn vị (Unit Testing)

Kiểm thử tích hợp (Integration Testing)

Kiểm thử hệ thống (System Testing)

Kiểm thử thẩm định (Validation Testing)

Nội dung chi tiết những kiểm thử trên đã có trong tài liệu [1]

Hướng tiếp cận theo Module chương trình

Kiểm thử phần mềm hướng đối tượng

Ở phần mềm hướng đối tượng, chương trình được thực hiện dựa trên sự thực thi phương thức của đối tượng nào đó là thể hiện cụ thể của một lớp mỗi khi có một sự kiện được kích hoạt. Hướng tiếp cận tập trung vào kiểm thử các đối tượng thuộc các lớp và sự tương tác giữa các đối tượng thuộc các lớp khác nhau. Sự phức tạp của lớp đối tượng đó chính là: tính bao gói về mặt giữ liệu, sự thừa kế các lớp với nhau, tính đa hình… điều đó dẫn đến hoạt động kiểm thử phức tạp hơn. Có thể đưa ra 3 cấp độ khác nhau cho kiểm thử phần mềm hướng đối tượng như sau:

Kiểm thử lớp (Class Testing)

Kiểm thử tích hợp đối tượng (Object Integration Testing)

Kiểm thử toàn bộ hệ thống (System Testing)

Hướng tiếp cận theo Class

Kiểm thử tích hợp hướng đối tượng (Object Oriented Integration Testing)

Đị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 A1 và B1, nếu có đối tượng thứ 3 là A2 được thừa kế từ A1. Khi kiểm thử đối tượng A2, tester không phải kiểm thử đối tượng A1 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.

Kiểm thử kịch bản

Phần này bài viết sẽ thảo luận chi tiết hơn về 2 kỹ thuật kiểm thử kịch bản.

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.

Ca kiểm thử

Việc thực hiện ca kiểm thử được thực hiện bình thường trong khi kiểm thử toàn bộ hệ thống. Với ASF, ca kiểm thử là một phần của một ca kiểm thử lớn hơn được đề nghị là kiểm thử tích hợp. Ví dụ, ca kiểm thử giao thức truyền thông xuyên suốt tất cả các tầng trong mô hình OSI được đề nghị là kiểm thử hệ thống. Một ca sử dụng mà kiểm thử sự truyền thông giữa giao thức TCP và IP được đề nghị là kiểm thử tích hợp.

Ca kiểm thử là một cuộc đối thoại giữa hệ thống và tác nhân bên trong. Tác nhân có thể là một hệ thống khác hoặc con người. Một kịch bản là một thể hiện rõ ràng của một ca kiểm thử. Một ca kiểm thử xác định rõ các bước bên trong đó, nhưng kịch bản xác định rõ sự việc xảy ra ở mỗi bước, các thông tin đầu vào và các thông tin đầu ra.

Kiểm thử MM-Path và ASF thuộc kiểm thử hộp đen của phần mềm hướng đối tượng bởi Tester sẽ tiến hành việc kiểm thử từ khung nhìn của người dùng và chỉ quan tâm đến thông tin đầu vào và đầu ra của hệ thống. Một ca kiểm thử cho số PIN dùng cho ASF có thể được xác định như sau:

Ca kiểm thử 1

Input: Khách hàng đút thẻ rút tiền của họ vào máy ATM

Output: Hệ thống hiển thị thông báo trên màn hình máy ATM hỏi khách hàng số PIN

Ca kiểm thử 2

Input: Khách hàng nhập số PIN của họ

Output: Hệ thống hiển thị thông báo trên màn hình máy ATM hỏi khách hàng về số tiền mà khách hàng muốn rút.

Như đã đề cập ở trên, kiểm thử phần mềm hướng đối tượng là rất phức tạp. Tester không thể thực hiện được tất cả các ca kiểm thử. Một cách để giải quyết vấn đề này là thực hiện kiểm thử sử dụng sác xuất thống kê.

Kết luận

Kiểm thử tích hợp hướng đối tượng có vai trò quan trọng trong việc phát triển phần mềm hướng đối tượng. Phần mềm hướng đối tượng được phát triển gia tăng trong các chu kỳ có tính hồi quy. Sau mỗi chu kỳ, các thành phần hướng đói tượng của phần mềm được sắp đặt cùng nhau và kiểm thử tích hợp được thực hiện.

Không có một cấu trúc rõ ràng trong phần mềm hướng đối tượng. Có thể không có thành phần ở mức cao nhất hoặc mức thấp nhất. Các thành phần có thể gửi thông báo tới các thành phần khác. Mỗi thông báo làm thay đổi trạng thái của thành phần, điều này gần như dẫn đến một số lượng vô tận các ca kiểm thử. Có quá nhiều trạng thái có thể xảy ra và sự tương tác lần nhau trong hệ thống. Sự phức tạp này dẫn đến một chi phí rất lớn trong việc kiểm thử.

Kiểm thử kịch bản là một kỹ thuật tốt cho việc kiểm thử phần mềm hướng đối tượng. Bài viết đã trình bày được các vấn đề liên quan đến kiểm thử phần mềm hướng đối tượng và đề xuất kỹ thuật kịch bản như một phương pháp luận cho kiểm thử tích hợp phần mềm hướng đối tượng.

Mục lục
Đánh giá:
0 dựa trên 0 đánh giá
Nội dung cùng tác giả
 
Nội dung tương tự