4. Ý nghĩa lý luận và thực tiễn của đề tài
2.1.2. Các tính chất của lập trình hướng đối tượng
2.1.2.1. Sự đóng gói
Sự đóng gói(Encapsulation) là cơ chế ràng buộc dữ liệu và thao tác trên dữ liệu đó thành một thể thống nhất gọi là đối tượng, tránh được các tác động ngẫu nhiên từ bên ngoài. Trong một đối tượng, cả dữ liệu và thao tác có thể là riêng (private) hoặc chung (public) của đối tượng đó. Thao tác hay dữ liệu riêng là chỉ thuộc về đối tượng đó, điều này nghĩa là các phần khác của chương trình tồn tại ngoài đối tượng không thể truy cập đến nó. Khi thao tác hay dữ liệu là chung, các phần khác của chương trình có thể truy cập đến nó, mặc dù nó được định nghĩa trong một đối tượng. Các thành phần chung của một đối tượng dùng để cung cấp như một giao diện có điều khiển cho các thành phần ngoài đối tượng giao tiếp với đối tượng. Cơ chế đóng gói là cách tốt nhất để che dấu thông tin và là sự khác biệt cơ bản so lập trình hướng cấu trúc.
2.1.2.2 Tính kế thừa
Tính kế thừa (Inheritance) là một trong những điểm đặc biệt của lập trình hướng đối tượng. Tạo ra những kiểu mới dựa trên những kiểu đã có với những kỹ năng mới thực hiện bằng cách tạo ra lớp con từ lớp có sẵn. Chúng ta có thể xây dựng các lớp mới từ các lớp cũ thông qua sự kế thừa. Một lớp mới còn gọi là lớp dẫn xuất, có thể thừa hưởng dữ liệu và các phương thức của một lớp cơ sở. Nó có thể được bổ sung các thành phần dữ liệu và các phương thức mới. Một lớp có thể có một số lượng bất kỳ các lớp dẫn xuất. Đến lượt mình, một lớp dẫn xuất lại có thể có những lớp dẫn xuất của nó. Cấu trúc kế thừa cho ta dạng hình cây của các lớp được hình thành. Trong cấu trúc này, các lớp cơ sở được gọi là lớp cha, và các lớp dẫn xuất được gọi là lớp con (hình 2.1).
Hình 2.1: Lớp ấn phẩm và các lớp dẫn xuất của nó
2.1.2.3 Tính đa hình
Tính đa hình (Polymorphism) là khả năng để một thông điệp có thể thay đổi cách thực hiện của đối tượng nhận thông điệp ở lớp dẫn xuất. Khi một lớp dẫn xuất được tạo ra, nó có thể thay đổi phương thức nào đó mà nó kế từ lớp cơ sở. Khi một lớp dẫn xuất đã định nghĩa lại một phương thức thừa hưởng từ lớp cơ sở, một thông điệp gọi một phương thức cùng tên gửi tới một đối tượng của lớp dẫn xuất, thì phương thức đã định nghĩa cho lớp dẫn xuất sẽ được thực hiện.
2.2. Kiểm thử phần mềm hƣớng đối tƣợng
Kiểm thử phần mềm hướng đối tượng là phương pháp kiểm thử dành cho các phần mềm được viết bằng ngôn ngữ lập trình hướng đối tượng. Mục tiêu cơ bản của kiểm thử vẫn không thay đổi, nhưng do bản chất của các chương trình hướng đối tượng đã làm thay đổi cả về chiến lược và các phương pháp kiểm thử ở đây. Việc định nghĩa và các phương pháp kiểm thử cần được mở rộng để bao
Tên
Số kỳ phát hànht Đặt mua
Tạp chí
Tên của các tác giả Loại bìa ISBN Sách Số trang Mã số tra cứu Ngày tháng xuất bản Bản quyền Nhà xuất bản Lấy ra Cất đi Đọc Ấn phẩm
tượng.
Do tính kế thừa và sự đa dạng của các mối quan hệ tương tác (như trình bày ở trên) giữa các đối tượng nên việc phân tích và thiết kế, tính đúng đắn và tính nhất quán của chương trình có vị trí quan trọng hơn nhiều. Vì vậy, tất cả các mô hình hướng đối tượng trước hết nên được kiểm thử tính đúng đắn, đầy đủ và nhất quán.
2.3. Điểm khác biệt trong kiểm thử phần mềm hƣớng đối tƣợng
Kiểm thử phần mềm hướng đối tượng về cơ bản thì không khác so với kiểm thử các phần mềm truyền thống. Trong kiểm thử phần mềm hướng đối tượng, về nguyên tắc vẫn phải kiểm thử đơn vị (mức kiểm thử thấp nhất), mặc dù ngữ nghĩa của từ “đơn vị” đã bị thay đổi ít nhiều; vẫn cần phải kiểm thử tích hợp
để đảm bảo các hệ thống con khác nhau có thể hoạt động phối hợp chính xác với nhau; vẫn phải kiểm thử hệ thống để xác minh là phần mềm đã đáp ứng được các yêu cầu ở mức toàn hệ thống. Ngoài ra vẫn cần kiểm thử hồi quy để chắc chắn là những thay đổi mới nhất không làm ảnh hưởng tới các hoạt động đã có của phần mềm. Tuy nhiên, do những đặc trưng của lập trình hướng đối tượng, nên sẽ có một số điểm khác biệt cả về khái niệm và phương pháp tiến hành.
Khác biệt lớn nhất đó là một phần mềm hướng đối tượng được thiết kế như là một tập các đối tượng (được mô hình hóa từ các vấn đề) được phối hợp với nhau để tạo ra các giải pháp cho phần mềm. Cách tiếp cận này cho thấy, các giải pháp có thể thay đổi thường xuyên, nhưng cấu trúc và các thành phần của bản thân vấn đề không bị thay đổi nhiều hoặc thường xuyên. Do đó, một lập trình viên biết rõ các vấn đề và các thành phần của nó thì có thể nhận biết được chúng trong phần mềm, và tạo được chương trình thuận lợi trong việc bảo trì về sau. Mặt khác, bởi vì các thành phần nhận được từ các vấn đề, nên chúng có thể được dùng lại trong việc phát triển các chương trình khác để giải quyết các vấn đề tương tự hoặc liên quan. Bằng cách này, sẽ nâng cao việc dùng lại các thành phần của phần mềm.
Một lợi ích lớn của cách tiếp cận thiết kế này là có thể dễ dàng phân tích các mô hình và chuyển đổi thành mô hình thiết kế, sau đó chuyển đổi thành mã
các kiểm thử đã thực hiện trong pha phân tích để kiểm thử cho pha thiết kế. Các kiểm thử cho pha thiết kế lại có thể được cải tiến để kiểm thử cho việc thực thi. Điều này có nghĩa là quá trình kiểm thử có thể thực hiện đồng thời cùng quá trình phát triển. Phương pháp này có ba lợi ích như sau:
− Các ca kiểm thử có thể được hình thành từ ngay khi xác định được các yêu cầu. Kiểm thử sớm sẽ giúp các nhà phân tích và thiết kế hiểu rõ hơn về các yêu cầu cũng như việc đặc tả yêu cầu được rõ ràng.
− Tính chính xác của ca kiểm thử có thể được kiểm tra từ rất sớm trong dự án. Nếu ca kiểm thử được tạo từ sớm và áp dụng cho các mô hình trong dự án, thì các hiểu lầm về yêu cầu đối với kiểm thử có thể được sửa chữa sớm. Mặt khác, mô hình kiểm thử giúp người kiểm thử và người phát triển thống nhất được nội dung yêu cầu dự án.
− Một điểm khác nhau nữa là công nghệ hướng đối tượng có thể hướng đến mục đích của phần mềm ngay trong quá trình phát triển. chẳng hạn định hướng của phần mềm là có thể là tái sử dụng. Các thiết kế có thể dùng các mẫu hoặc định hướng đến các khung làm việc để có khả năng tái sử dụng. Kiểm thử có thể cần phát hiện được các thất bại theo các mục tiêu này. Phương pháp kiểm thử và công nghệ truyền thống thường không thể đáp ứng được yêu cầu trên đây.
2.4. Những khó khăn kiểm thử phần mềm hƣớng đối tƣợng
Phần mềm hướng đối tượng không có kiến trúc phân cấp ở mức toàn chương trình như các phần mềm phát triển theo hướng cấu trúc, vì thế không có được một sự định hướng rõ ràng cho việc kiểm thử tích hợp, không có cây quyết định cho thứ tự kiểm thử tích hợp các đối tượng. Việc tích hợp được tiến hành theo những sơ đồ riêng phụ thuộc vào cấu trúc tương tác giữa các lớp của hệ thống đối với từng bài toán cụ thể.
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 lại 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ị huỷ bỏ, những mỗi quan hệ qua lại giữa chúng được hình thành dần
thể của đối tượng tại thời điểm tương tác. Những tương tác khả thi giữa các đối tượng tăng trưởng theo cấp số 2, và sẽ gấp nhiều lần so với phần mềm truyền thống (hình 2.2).
a) Sự tương tác giữa các đối tượng b) Quan hệ giữa các môđun
Hình 2.2: Sơ đồ tương tác của phần mềm hướng đối tượng và truyền thống
Sự phân tích trên đây cho thấy, 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. Để giảm tối thiểu chi phí, người kiểm thử cần phải chọn một phương pháp “thông minh” trước mỗi tính huống được xét. Ví dụ, xét sự thừa kế lớp, giả sử ta đã kiểm thử sự tương tác giữa hai đối tượng A1 và B1, nếu có đối tượng A2 được thừa kế từ A1, thi khi kiểm thử đối tượng A2, không phải kiểm thử đối tượng thuộc A1 nữa mà chỉ kiểm thử những gì mới được định nghĩa lại trong A2. Vì thế, việc kiểm thử tích hợp đối với phần mềm hướng đối tượng cần có các chiến lược khác với những gì áp dụng cho phần mềm truyền thống.
2.5. Tiến trình kiểm thử hƣớng đối tƣợng
2.5.1. Kiểm thử đơn vị trong mô hình hướng đối tượng
Trong mô hình hướng đối tượng, sự bao gói quy định việc định nghĩa lớp và đối tượng. Điều này có nghĩa là, mỗi lớp và mỗi thể hiện của lớp bao gói các thuộc tính (dữ liệu) và các thao tác (phương thức, tác vụ) thực hiện trên những dữ liệu đó. Đơn vị nhỏ nhất có thể kiểm thử được là lớp (đối tượng được đóng gói). Trong một lớp có nhiều thao tác khác nhau và một số thao tác đặc biệt có thể tồn tại như một phần của các lớp khác (gọi đến nó), nên ý nghĩa của kiểm thử đơn vị thay đổi nhiều.
độ đơn vị, cấp độ chức năng và cấp độ toàn hệ thống. Tại cấp độ đơn vị, lớp là đơn vị kiểm thử. Các lớp được tích hợp dựa trên mối quan hệ như kế thừa và kết hợp để hình thành đơn vị lớn hơn tạo thành chức năng. Kiểm thử tích hợp nhận biết những lỗi trong quá trình tích hợp các phần tử đơn vị. Kiểm thử hệ thống bao gồm kiểm thử toàn bộ phần mềm.
Kiểm thử lớp bao gồm kiểm thử các phương thức được định nghĩa trong lớp và sự tác động của chúng lên trạng thái của lớp hoặc các đối tượng. Những mô hình khác nhau được sử dụng để kiểm thử các phương thức của lớp. Tương tự, trạng thái của lớp hoặc các đối tượng cần phải được theo dõi cả trước và sau khi lớp thực thi xong. Ở cấp độ này, có thể áp dụng tất cả những gì đã dùng cho kiểm thử đơn vị truyền thống.
Trong phần mềm hướng đối tượng, một ứng dụng được cài đặt bằng việc gọi các phương thức theo trật tự thực hiện các chức năng của nó. Các phương thức của lớp có độ phức tạp hơn ít hơn và kích thước nhỏ hơn so với các mô đun trong chương trình cấu trúc, tuy nhiên chúng có nhiều phương thức và sự tương tác giữa các phương thức thông qua thông báo xuất hiện tùy thuộc vào từng trường hợp cụ thể khi vận hành. Vì thể, các phương pháp và kỹ thuật kiểm thử môđun đối với phần mềm thông thường không thể đem lại hiệu quả khi áp dụng cho các phương thức của phần mềm hướng đối tượng. Trong trường hợp số phương thức ít và thức có quy nhỏ, thì việc áp dụng là có thể.
Có 3 phương pháp để kiểm thử đơn vị trong phần mềm hướng đối tượng: 1. Kiểm thử hộp trắng dựa trên việc kiểm tra chặt chẽ các chi tiết thủ tục của
đơn vị đó. Nó kiểm thử câu lệnh, rẽ nhánh, luồng dữ liệu và luồng điều khiển của mã chương trình mà không có bất kỳ sự tham chiếu nào đối với đặc tả. Đường dẫn cơ bản kiểm thử và cấu trúc điều khiển kiểm thử là một số trong những phương pháp kiểm thử hộp trắng. Lớp được kiểm thử như một đơn vị riêng rẽ, không phải đi vào chi tiết cấp độ câu lệnh của các phương thức thì sử dụng các kỹ thuật kiểm thử hộp đen.
2. Kiểm thử hộp đen xác định liệu chương trình có đạt được yêu cầu về chức năng và không phải chức năng của nó không loại trừ những cài đặt của nó. Nó cũng kiểm tra ảnh hưởng của phương thức được gọi lên trạng thái của
đơn vị. Sự bao phủ được sử dụng để xác định phần trăm của lớp đặc tả được thực hiện trong kiểm thử. Phân tích giá trị biên, phân chia lớp tương đương, biều đồ kiểm thử cơ sở là một số trong những phương pháp kiềm thử hộp đen có thể sử dụng.
3. Chỉ có kiểm thử hộp trắng hoặc kiểm thử hộp đen là chưa đủ cho kiểm thử đơn vị của phần mềm hướng đối tượng. Kiểm thử hộp trắng kiểm tra mã chương trình liệu làm việc tốt hay chưa nhưng không kiểm tra cho mã chương trình hoặc chức năng chưa dùng đến. Mặt khác, kiểm thử hộp đen kiểm tra liệu các đơn vị làm việc đúng theo đặc tả hay chưa nhưng không đảm bảo liệu tất cả các phần của mã chương trình đã được kiểm tra. Cách tốt và hiệu quả hơn nhiều để kiểm tra lớp là sử dụng kết hợp kỹ thuật hộp đen và hộp trắng, mà còn được gọi là kiểm thử hộp xám (gray-box testing). Kiểm thử hộp xám dựa trên kiểm tra đặc tả phần mềm.
2.5.2. Kiểm thử tích hợp hướng đối tượng - OOIT
Một hệ thống được chia thành các hệ thống nhỏ với mục đích phân tán và phát triển song song các hệ thống nhỏ đó. Một hệ thống nhỏ là tập hợp logic các lớp mà tương tác với nhau theo cách cài đặt các chức năng của hệ thống con. Hệ thống con có giao diện được định nghĩa đầy đủ thông qua đó, các dịch vụ của hệ thống được gọi và sử dụng. Kiểm thử tích hợp hướng đối tượng (Object Oriented Integration Testing - OOIT) kiểm tra các lỗi nảy sinh trong qua trình tương tác giữa các phần tử đơn vị của hệ thống nhỏ.
Hệ thống nhỏ trong một phần mềm hướng đối tượng là tập hợp các lớp liên quan với nhau thông qua mối quan hệ như kế thừa, kết hợp và ràng buộc động. Các phần tử tương tác của hệ thống nhỏ trong một phần mềm hướng đối tượng kết nối thông qua các mối quan hệ khác nhau lại hợp thành một đơn vị phần mềm lớn hơn. Hệ thống nhỏ trong phần mềm hướng đối tượng do vậy được quan sát như một phần tử đơn vị tích hợp lớn hơn bao gồm những phần tử lớp khác và các phần tử được tích hợp. Do đó, hệ thống con được phát triển, có kiến trúc khác đáng kể so với phần mềm thông thường. Vì thiếu kiến trúc điều khiển phân cấp, các chiến lược tích hợp trên xuống hay dưới lên không còn có ý nghĩa trong phần mềm hướng đối tượng.
thông qua các mối quan hệ khác nhau. Khi kiểm thử tích hợp các đơn vị phần mềm liên quan cần kiểm tra trình tự đúng của việc gọi phương thức và cập nhật trạng thái chính xác cho việc cài đặt một chức năng đơn lẻ. Các lớp liên quan thông qua sự kế thừa thường đòi hỏi kiểm thử lại các phương thức dẫn xuất khi chúng được sử dụng trong lớp con.
Kiểm thử tích hợp của việc cài đặt ràng buộc động cần kiểm tra các ràng buộc của phương thức liên quan tại thời điểm chạy chương trình. Vì mô hình lặp và tăng dần đối với sự phát triển phần mềm hướng đối tượng đưa đến sự phát triển tăng dần của các đối tượng phần mềm, các hệ thống con trong phần mềm và quy mô kiểm thử cũng phải tăng lên.
OOIT là kiểm thử tập hợp các thành phần hướng đối tượng. Như vậy, có thể hiểu OOIT 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