Kiểm thử phần mềm Hướng đối tượng trên Biểu đồ lớp

Ngày nay, ngôn ngữ mô hình hóa hợp nhất (UML) đã trở thành công cụ quen thuộc trong tiến trình phát triển hệ thống hướng đối tượng (Hệ thống hướng đối tượng). Một trong những dạng biểu đồ thường dùng để thực hiện việc mô hình hóa là biểu đồ lớp. Biểu đồ lớp không những cho ta cách nhìn tổng quan về cấu trúc mà còn thể hiện hành vi của hệ thống. Một cách chủ quan rằng, hoạt động kiểm thử dựa trên biểu đồ lớp sẽ tối ưu và mang lại hiệu quả cao cho nguồn tài nguyên cần chi phí trong hoạt động này. Bởi vậy, chúng em tiến hành tìm hiểu về vấn đề kiểm thử hệ thống hướng đối tượng trên biểu đồ lớp

MỞ ĐẦU

Cùng với sự phát triển vượt bậc của Công nghệthông tin, đặc biệt trong lĩnh vực Công nghệ phần mềm,hoạt động kiểm thử đã được đặc biệt chú trọng, thu hút sựtập trung nghiên cứu của các nhà khoa học, các học giảtrên toàn thế giới Song, bên cạnh những thành tựu khoahọc, hoạt động kiểm thử vẫn chưa thể khẳng định đượcrằng một sản phẩm phần mềm ra đời có chắc chắn đảmbảo tính đúng đắn, có lỗi hay không

Ngày nay, với sự phổ dụng và tính ưu việt của kỹthuật lập trình hướng đối tượng, sản phẩm phần mềm đã

có những bước đột phá về chất lượng Tuy nhiên, vấn đềkiểm soát lỗi và hoàn thiện sản phẩm vẫn gặp rất nhiềukhó khăn Một trong những nguyên nhân dẫn đến tìnhtrạng trên là do chúng ta chưa nhận thức đầy đủ ý nghĩacủa hoạt động kiểm thử khi thực hiện các giai đoạn trongtiến trình phát triển phần mềm; các phương pháp kiểmthử truyền thống vẫn được sử dụng phổ biến Hơn nữa,

độ phức tạp của phần mềm ngày càng cao; sự linh hoạt,mềm dẻo và những đặc điểm đa dạng của kỹ thuật lập

1

trình hướng đối tượng, nếu người phát triển phần mềmkhông cẩn thận, đôi khi sẽ trở nên nhập nhằng, dễ phátsinh lỗi.

Với thực trạng và yêu cầu trên, việc kiểm thử các

hệ thống hướng đối tượng cần phải được nghiên cứu kỹ,

có chiều sâu; trong đó kiểm thử hệ thống hướng đốitượng dựa trên các mô hình hợp nhất là một trong nhữngphương pháp có thể tiếp cận nghiên cứu

Mô hình hợp nhất có tính ưu việt về mặt mô hìnhhóa một cách trực quan Ngày nay, ngôn ngữ mô hìnhhóa hợp nhất (UML) đã trở thành công cụ quen thuộctrong tiến trình phát triển hệ thống hướng đối tượng(HTHĐT) Một trong những dạng biểu đồ thường

dùng để thực hiện việc mô hình hóa là biểu đồ lớp Biểu

đồ lớp không những cho ta cách nhìn tổng quan về cấu trúc

mà còn thể hiện hành vi của hệ thống Một cách chủ quan rằng, hoạt động kiểm thử dựa trên biểu đồ lớp sẽ tối ưu và mang lại hiệu quả cao cho nguồn tài nguyên cần chi phí trong hoạt động này Bởi vậy, chúng em tiến hành tìm hiểu

về vấn đề kiểm thử HTHĐT trên biểu đồ lớp

Hưng Yên, ngày…tháng…năm 2013

2

Nhóm sv thực hiện

Phạm Thị Thanh Hải Nguyễn Thị Dung

Đỗ Thj Giang

3

Mục tiêu của đề tài là trình bày một cách tổng quan

về kiểm thử HTHĐT dựa trên lớp và đưa ra quy trình ápdụng thực tế

Để đạt được mục tiêu, đề tài cần thực hiện các nhiệm vụ sau:

- Tìm hiểu HTHĐT; UML và biểu đồ lớp (Class Diagram)

- Nghiên cứu về kiểm thử hướng đối tượng (OOT)

- Xây dựng quy trình kiểm thử HTHĐT dựa trên biểu đồ lớp

- Ứng dụng quy trình vào HTHĐT cụ thể, từ đó đưa rađánh giá tính hiệu quả của quy trình đề xuất

2 Đối tượng và phạm vi nghiên cứu

2.1 Đối tượng nghiên cứu

- Lý thuyết về HTHĐT, UML và biểu đồ lớp.

- Kiểm thử hướng đối tượng (OOT), kiểm thử lớp

- Một số kỹ thuật kiểm thử hướng đối tượng (OOT)

1.1.1.1 Đối tượng (Object)

Đối tượng là sự kết hợp giữa dữ liệu và thủ tục ( haycòn gọi là các phương thức – method) thao tác trên dữ liệu

đó Có thể đưa ra công thức phản ánh bản chất kỹ thuật lậptrình hướng đối tượng như sau:

Đối tượng=Dữ liệu + Phương thức

1.1.1.2 Lớp (Class)

Lớp là một tập các đối tượng có cấu trúc dữ liệu và cácphương thức giống nhau( hay nói cách khác là một tập cácđối tượng cùng loại) Như vậy khi có một lớp thì chúng ta sẽbiết được một mô ta cấu trúc dữ liệu và phương thức của cácđối tượng thuộc lớp đó Một đối tượng sẽ là một thể hiện cụthể của lớp đó Trong lập trình, chúng ta có thể coi một lớpnhư là một kiểu dữ liệu, còn các đối tượng sẽ là các biến cókiểu là lớp

1.1.1.3 Lớp con (SubClass)

Lớp con là một lớp thông thường nhưng có thêm tính chất

kế thừa một phần hay toàn bộ các đặc tính của một lớp

khác Lớp chia sẻ sự kế thừa gọi là lớp cha (parent class) ll

1.1.1.4 Lớp trừu tượng (Abstract Class)

Lớp trừu tượng là một lớp mà nó không thể thực thể hóa

thành một đối tượng thực dụng được Lớp này được thiết

kế nhằm tạo ra một lớp có các đặc tính tổng quát nhưng bảnthân lớp đó chưa có ý nghĩa (hay không đủ ý nghĩa) để có thể tiến hành viết mã cho việc thực thể hóa

Thí dụ: Lớp "hinh" được định nghĩa không có dữ liệu nội tại

và chỉ có các phương thức "tinh_chu_vi", "tinh_dien_tich" Nhưng vì lớp hinh này chưa xác định được đầy đủ các đặc tính của nó (cụ thể các biến nội tại là tọa độ các đỉnh nếu là

đa giác, là đường bán kính và toạ độ tâm nếu là hình tròn, )nên nó chỉ có thể được viết thành một lớp trừu tượng Sau

đó, người lập trình có thể tạo ra các lớp con chẳng hạn như

là lớp "tam_giac", lớp "hinh_tron", lớp "tu_giac", Và trong các lớp con này người viết mã sẽ cung cấp các dữ liệu nội tại (như là biến nội tại r làm bán kính và hằng số nội tại

Pi cho lớp "hinh_tron" và sau đó viết mã cụ thể cho các phương thức "tinh_chu_vi" và "tinh_dien_tich")

1.1.2 Các tính chất cơ bản

1.1.2.1 Tính trừu tượng (Abstraction

Đây là khả năng của chương trình bỏ qua hay không chú

ý đến một số khía cạnh của thông tin mà nó đang trực tiếp làm việc lên, nghĩa là nó có khả năng tập trung vào những cốt lõi cần thiết Mỗi đối tượng phục vụ như là một "động tử" có thể hoàn tất các công việc một cách nội bộ, báo cáo, thay đổi trạng thái của nó và liên lạc với các đối tượng khác

mà không cần cho biết làm cách nào đối tượng tiến hành

được các thao tác Tính chất này thường được gọi là sự

trừu tượng của dữ liệu.

Tính trừu tượng còn thể hiện qua việc một đối tượng ban đầu có thể có một số đặc điểm chung cho nhiều đối tượng khác như là sự mở rộng của nó nhưng bản thân đối tượng ban đầu này có thể không có các biện pháp thi hành

1.1.2.2 Tính thừa kế (Inheritance)

Đặc tính này cho phép một đối tượng có thể có sẵn các

đặc tính mà đối tượng khác đã có thông qua kế thừa Điều này cho phép các đối tượng chia sẻ hay mở rộng các đặc tính sẵn có mà không phải tiến hành định nghĩa lại Tuy nhiên, không phải ngôn ngữ định hướng đối tượng nào cũng có tính chất này

1.1.2.3 Tính đa hình (Polymorphism)

Thể hiện thông qua việc gửi các thông điệp (message)

Việc gửi các thông điệp này có thể so sánh như việc gọi các

hàm bên trong của một đối tượng Các phương thức dùng trảlời cho một thông điệp sẽ tùy theo đối tượng mà thông điệp

đó được gửi tới sẽ có phản ứng khác nhau Người lập trình

có thể định nghĩa một đặc tính (chẳng hạn thông qua tên của các phương thức) cho một loạt các đối tượng gần nhau nhưng khi thi hành thì dùng cùng một tên gọi mà sự thi hànhcủa mỗi đối tượng sẽ tự động xảy ra tương ứng theo đặc tínhcủa từng đối tượng mà không bị nhầm lẫn

Thí dụ khi định nghĩa hai đối tượng "hinh_vuong" và

"hinh_tron" thì có một phương thức chung là "chu_vi" Khi gọi phương thức này thì nếu đối tượng là "hinh_vuong" nó

sẽ tính theo công thức khác với khi đối tượng là "hinh_tron"

1.1.2.4 Tính đóng gói (Encapsulation)

Tính chất này không cho phép người sử dụng các đối tượng thay đổi trạng thái nội tại của một đối tượng Chỉ có các phương thức nội tại của đối tượng cho phép thay đổi trạng thái của nó Việc cho phép môi trường bên ngoài tác động lên các dữ liệu nội tại của một đối tượng theo cách nào là hoàn toàn tùy thuộc vào người viết mã Đây là tính chất đảm bảo sự toàn vẹn của đối tượng

1.1.3 Ngôn ngữ mô hình hóa hợp nhất (UML)

1.1.3.1 Định nghĩa

UML là ngôn ngữ mô hình hóa thống nhất có phần chính

bao gồm những kí hiệu hình học được các phương pháp hướng đối tượng sử dụng để thể hiện và miêu tả thiết kế của một hệ thống.

1.1.3.2 Ý nghĩa của UML

 UML là ngôn ngữ dùng để trực quan hóa

 UML là ngôn ngữ đặc tả

 UML là ngôn ngữ dùng để xây dựng

 UML là ngôn ngữ dùng để lập tài liệu

1.1.4.2 Các thành phần của biểu đồ lớp

 Lớp (Class): Thuộc tính (attribute), Phương thức

Phát triểnTest script

Thực hiện kiểm thử

 Xác định phạm vi và rủi ro khi thực hiện test

 Xác định hướng tiếp cận (techniques, test items, coverage…)

 Xác định chính sách và chiến lược test

 Xác định nguồn tài nguyên cho test (e.g people, test environment,

 PCs)

 Lập kế hoạch cho nhiệm vụ tiếp theo: phân tích

và thiết kế test, triển khai và thực thi test, đánh giá test

 Xác định điều kiện dừng test

1.2.2.2 Phân tích và thiết kế test

Đầu vào: SRS, Detail design,Test plan

Đầu ra: Tài liệu Test design

Xem xét lại toàn bộ tài liệu dự án (phân tích rủi ro sảnphẩm, yêu cầu, kiến trúc, thiết kế )

Xác định các điều kiện test dựa trên việc phân tích các danh mục test, đặc tả của chúng…

Thiết kế test: xác định test case

Đánh giá khả năng test được của yêu cầu và hệ thống

Thiết lập môi trường kiểm thử và xác định cơ sở vật chất và các công cụ cho test

1.2.2.3 Triển khai và thực thi test

- Triển khai test:

Đầu vào: SRS, Use case, Test Design document

Đầu ra: Test case, Test script, Test data

- Thực thi test:

Đầu vào: Software/Product, Test case, Test script, Test dataĐầu ra: Defect list, Issue list, Test log

1.2.2.4 Đánh giá điều kiện kết thúc và báo cáo test

- Đầu vào: Test Log, Test Plan

- Đầu ra: Test Report

Đánh giá điều kiện kết thúc là hoạt động để đánh giá

thực thi kiểm thử với mục tiêu đặt ra

1.2.3.1 Kiểm thử chức năng (Functional Testing)

Kiểm thử chức năng là phương pháp kiểm thử chủyếu dựa vào đặc tả chức năng của hệ thống Các ca kiểmthử hay dữ liệu kiểm thử được dẫn xuất từ đặc tả Bởi

vậy, kiểm thử chức năng còn được gọi là kiểm thử dựatrên đặc tả hay kỹ thuật kiểm thử hộp đen (Black-BoxTesting) Kiểm thử chức năng là giải pháp tốt nhất để

tìm ra lỗi thiết kế Hoạt động kiểm thử được áp dụng chocác mức độ kiểm thử: Kiểm thử đơn vị, kiểm thử tíchhợp, kiểm thử hệ thống, kiểm thử hồi quy và kiểm thửchấp nhận

1.2.3.2 Kiểm thử cấu trúc (Structural

Testing)

Kiểm thử cấu trúc còn gọi là kiểm thử hộp trăng(White-Box Testing) chủ yếu dựa vào mã nguồn và cấutrúc chương trình Kiểm thử cấu trúc cho phép chúng takiểm thử cấu trúc bên trong của phần mềm, với mục đíchkiểm tra tất cả các câu lệnh và điều kiện tồn tại trongphần mềm đó Kiểm thử cấu trúc thường phát hiện lỗi lậptrình Tuy nhiên, đây là phương pháp kiểm thử khó thựchiện, chi phí cao

Chương này trình bày tổng quan về HTHĐT Bêncạnh đó, chúng tôi cũng tìm hiểu một cách chi tiết về

UML và biểu đồ lớp Nhiều khái niệm về kiểm thử cũngđược đề cập, đặc biệt QTKT và các kỹ thuật kiểm thử(kiểm thử chức năng và kiểm thử cấu trúc).

CHƯƠNG 2 KIỂM THỬ HỆ THỐNG HƯỚNG ĐỐI TƯỢNG DỰA TRÊN BIỂU ĐỒ LỚP

2.1 KIỂM THỬ HỆ THỐNG HƯỚNG ĐỐI TƯỢNG

2.1.1 Tổng quan về kiểm thử HTHĐT

Ở 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ỗikhi có một sự kiện được kích hoạt Hướng tiếp cậntậ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ớpkhác nhau Sự phức tạp của lớp đối tượng đó chínhlà: tính bao gói về mặt giữ liệu, sự thừa kế các lớpvới nhau, tính đa hình… điều đó dẫn đến hoạt độngkiểm thử phức tạp hơn Có thể đưa ra 3 cấp độ khácnhau 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

2.1.2 Các chiến lược kiểm thử HTHĐT

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

- Unit testing đề cập đến các kiểm thử để chứng thực chức

năng của một phần riêng biệt của code, thường ở mức hàm Trong một môi trường hướng đối tượng, kiểm thử đơn vị thường được sử dụng ở mức lớp và kiểm thử các đơn vị nhỏ nhất bao gồm các hàm constructor và destructor

- Loại liểm thử này thường được viết bởi các DEV như côngviêc của họ trong việc code (loại tét white- box), để đảm bảorằng từng hàm riêng biệt hoạt động đúng theo mong muốn một hàm có thể có nhiều kiểm thử, để bắt được các trường

hợp hoặc các nhánh code Unit testing một mình không thể bảo đảm chúc năng của một bộ phận của phần mềm mà là sửdụng để bảo đảm rằng các khối kiến trúc của phần mềm làm việcđộc lập với nhau.

- Unit testing(kiểm thử đơn vị)cũng được gọi là component testing(kiểm thử thành phần)

2.1.2.2 Kiểm thử tích hợp hướng đối tượng

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

OOTT kiểm thử sự tương tác giữa hai đối tượng nảy sinhkhimộ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)

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

- System testing kiểm thử một hệ thống đãđược tích hợphoàn chỉnh để xác minh rằng nó đáp ứng được yêu cầu

- Kiêm thử tích hợp hệ thống chứng thực rằng hệ thống đãđược tích hợp với các hệ thống bên ngoài hoặc hệ thống thứ

ba đã được xác định trong các yêu cầu hệ thống.

2.2 KIỂM THỬ HTHĐT DỰA TRÊN BIỂU ĐỒ LỚP 2.2.1 Ý nghĩa của biểu đồ lớp trong hoạt động

kiểm thử

2.2.1.1 Xây dựng tập các lớp

- Xây dựng lớp

- Đặc tả lớp

2.2.2 Kiểm thử Lớp (Class Testing)

2.2.2.1 Kiểm thử phương thức (Method Testing)

Trong hệ thống hướng đối tượng, phương thứcđược xem là đơn vị nhỏ nhất nên kiểm thử phương thức(method testing) có thể được xem là kiểm thử đơn vị(Unit Testing) Kiểm thử phương thức tập trung vàotừng chi tiết bên trong của mỗi phương thức Do vậy,những kỹ thuật kiểm thử đơn vị truyền thống hoàn toànphù hợp cho kiểm thử phương thức trong HTHĐT như kỹthuật kiểm thử dựa vào đồ thị luồng dữ liệu (DFG), kiểmthử dựa vào đồ thị luồng điều khiển (CFG), kiểm thử giátrị biên (BVT),

2.2.2.2 Kiểm thử lớp đơn (Intra-Class Testing)

 Kiểm thử dựa vào phân tích hợp nhất

Kỹ thuật được xây dựng gồm ba bước chính:

- Phân tích luồng dữ liệu (Data flow analysis)

- Thực thi thành phần tiêu biểu (Symbolic Execution)

- Tinh giảm tự động (Automated deduction)

 Kiểm thử lớp tương đương (Equivalence Classes Testing) Việc đầu tiên của kỹ thuật kiểm thử này là phân hoạch không gian trạng thái, từ đó xác định tập ca kiểm thử

- Đối với mỗi dữ liệu vào, xác định các lớp

tương đương từ miền dữ liệu vào

- Chọn dữ liệu đại diện cho mỗi lớp tương

đương

- Kết hợp các dữ liệu thử bởi tích đề-các để

tạo ra bộ dữ liệu kiểm thử

 Nguyên tắc phân hoạch các lớp tương đương

- Nếu dữ liệu vào thuộc một khoảng, xây dựng: