Xây dựng test case kiểm thử hộp trắng cho chương trình Eiffel ứng dụng nguyên lý design by contract

Xây dựng test case kiểm thử hộp trắng cho chương trình Eiffel ứng dụng nguyên lý design by contract Xây dựng test case kiểm thử hộp trắng cho chương trình Eiffel ứng dụng nguyên lý design by contract Xây dựng test case kiểm thử hộp trắng cho chương trình Eiffel ứng dụng nguyên lý design by contract luận văn tốt nghiệp,luận văn thạc sĩ, luận văn cao học, luận văn đại học, luận án tiến sĩ, đồ án tốt nghiệp luận văn tốt nghiệp,luận văn thạc sĩ, luận văn cao học, luận văn đại học, luận án tiến sĩ, đồ án tốt nghiệp

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

MỤC LỤC

MỤC LỤC 2

LỜI CAM ĐOAN 5

LỜI CẢM ƠN 6

NHẬN XÉT CỦA NGƯỜI HƯỚNG DẪN KHOA HỌC 7

DANH MỤC CÁC HÌNH VẼ 8

MỞ ĐẦU 9

CHƯƠNG 1 NGÔN NGỮ LẬP TRÌNH EIFFEL VÀ NGUYÊN LÝ DESIGN BY CONTRACT 11

1.1 Ngôn ngữ lập trình Eiffel và môi trường làm việc EiffelStudio 11

1.1.1 Lịch sử 11

1.1.2 Các phiên bản EiffelStudio 14

1.1.3 Các đặc điểm cơ bản của ngôn ngữ lập trình Eiffel 15

1.1.3.1 Cấu trúc một lớp của ngôn ngữ lập trình Eiffel 17

1.1.3.2 Các kiểu dữ liệu cơ bản 19

1.2 Nguyên lý Design by Contract 22

1.2.1 Một số cơ chế mang lại tính tin cậy cho phần mềm 22

1.2.2 Tính đúng đắn của phần mềm 23

1.2.3 Công thức của tính đúng đắn 25

1.2.4 Nội dung nguyên lý Design by Contract 26

Tóm tắt chương 1 29

CHƯƠNG 2 KIỂM THỬ PHẦN MỀM - KIỂM THỬ HỘP TRẮNG 30

2.1 Kiểm thử phần mềm và xây dựng test case từ use case 30

2.1.1 Giới thiệu về kiểm thử 30

2.1.1.1 Các nguyên lý trong kiểm thử phần mềm 30

2.1.1.2 Các cấp độ kiểm thử phần mềm 32

2.1.2 Use case và test case 37

2.1.3 Xây dựng test case từ use case 38

2.2 Kiểm thử hộp trắng 38

2.2.1 Kiểm thử dòng lệnh 39

2.2.2 Kiểm thử với các module rẽ nhánh 39

2.2.3 Kiểm thử các module điều kiện phức hợp 39

2.2.4 Kiểm thử đường dẫn lệnh (path codes) 40

2.2.5 Kiểm thử vòng lặp 41

2.3 So sánh kiểm thử hộp trắng - hộp đen 42

2.4 Kiểm thử hộp trắng với hệ thống hướng đối tượng ứng dụng Design by Contract 42

Tóm tắt chương 2 45

CHƯƠNG 3 XÂY DỰNG TEST CASE KIỂM THỬ HỘP TRẮNG CHO CHƯƠNG TRÌNH EIFFEL ỨNG DỤNG NGUYÊN LÝ DESIGN BY CONTRACT 46

3.1 Chương trình Eiffel cài đặt các thuật toán trên một số cấu trúc dữ liệu cơ bản 46

3.1.1 Giới thiệu 46

3.1.2 Cấu trúc chương trình 48

3.2 Xây dựng test case kiểm thử hộp trắng cho chương trình thao tác trên một số cấu trúc dữ liệu cơ bản 49

3.2.1 Lớp DRIVER_DEMO và thủ tục add_entry 51

3.2.1.1 Dữ liệu được ràng buộc trong contract 53

3.2.1.2 Dữ liệu bên trong thủ tục 55

3.2.2 Lớp BINARY_SEARCH_TREE_DEMO 57

3.2.2.1 Dữ liệu ràng buộc trong contract 59

3.2.2.2 Dữ liệu bên trong 60

Tóm tắt chương 3 64

CHƯƠNG 4 KẾT QUẢ VÀ BÀN LUẬN 65

Nhiệm vụ đã hoàn thành 65

Các đóng góp khoa học 66

Hướng phát triển luận văn 66

TÀI LIỆU THAM KHẢO 67

LỜI CAM ĐOAN

Tôi xin cam đoan đây là công trình nghiên cứu của riêng tôi

Các số liệu, kết quả nêu trong luận văn là trung thực và chưa từng được ai công

bố trong bất kỳ công trình nào khác

Tác giả luận văn

Nguyễn Hùng Cường

LỜI CẢM ƠN

Đầu tiên em xin gửi lời cảm ơn tới các thầy cô giáo trong trường Bách Khoa nói chung và khoa công nghệ thông tin nói riêng, những người đã truyền thụ cho chúng em những kiến thức cơ bản nhất, giúp chúng em có được nền tảng trong quá trình làm việc

và công tác sau này

Em xin gửi lời cảm ơn đến PGS.TS Huỳnh Quyết Thắng, người không những truyền thụ kiến thức cho em mà còn giúp đỡ tận tình trong suốt quá trình em thực hiện luận văn này: giúp đỡ chọn lựa hướng thực hiện cũng như đề tài luận văn, cung cấp tài liệu, hướng dẫn kiến thức

Và cuối cùng tôi muốn gửi lời cảm ơn chân thành nhất tới bạn bè và đặc biệt

là những người thân trong gia đình đã luôn quan tâm, động viên và giúp đỡ tôi trong quá trình hoàn thành đồ án tốt nghiệp này

Do kiến thức cũng như khả năng làm việc có hạn, luận văn không tránh khỏi những thiếu sót, những điều chưa tối ưu, mong các thầy cô giáo giúp đỡ và chỉ bảo thêm để sau này em có thể tiếp tục hoàn thiện đề tài này

Xin cảm ơn!

Hà Nội ngày 26 tháng 10 năm 2010

NHẬN XÉT CỦA NGƯỜI HƯỚNG DẪN KHOA HỌC

DANH MỤC CÁC HÌNH VẼ

Hình 1: Môi trường lập trình EiffelStudio 13

Hình 2: Mô hình phân cấp cluster của Eiffel 16

Hình 3: Cấu trúc một chương trình viết bằng Eiffel 17

Hình 4: EiffelStudio chú thích các thuộc tính và thủ tục của một lớp 19

Hình 5: Cấu trúc lớp LINKED_LIST được hỗ trợ bởi EiffelStudio 21

Hình 6: Contract trong DbC và contract trong kinh doanh 27

Hình 7: Cài đặt nguyên lý Design by Contract trong ngôn ngữ Eiffel 28

Hình 8: Kiểm thử phần mềm 30

Hình 9: Kiểm thử hộp trắng 38

Hình 10: Bảng chân lý của điều kiện phức hợp 40

Hình 11: Một ví dụ vòng lặp không xác định 40

Hình 12: Cấu trúc đường lệnh của vòng lặp không xác định 41

Hình 13: Lựa chọn một chương trình Eiffel mẫu 47

Hình 14: Giao diện và danh sách các lớp chương trình Structure 47

Hình 15: Cấu trúc các lớp chương trình Structure 49

Hình 16: Cấu trúc lớp DRIVER_DEMO 51

Hình 17: Mã nguồn thủ tục add_entry của lớp DRIVER_DEMO 52

Hình 18: Số lượng menu lệnh của các thuật toán 53

Hình 19: EiffelStudio dừng dịch và báo lỗi khi tiền điều kiện bị vi phạm 54

Hình 20: Các bộ test case cho hai contract name_not_void và real_help 55

Hình 21: Các dữ liệu của thủ tục add_entry được kiểm thử 55

Hình 22: các bộ test case cho đầu vào thủ tục add_entry 56

Hình 23: Các trường hợp biến menu_size có thể xảy ra 57

Hình 24: Cấu trúc lớp BINARY_SEARCH_TREE_DEMO 58

Hình 25: Mã nguồn thủ tục excute của lớp BINARY_SEARCH_TREE_DEMO 59

Hình 26: Các bộ test case cho contract valid_command 60

Hình 27: Cấu trúc đường dẫn lệnh thủ tục excute 61

MỞ ĐẦU

i Lý do chọn đề tài

- Tìm hiểu về ngôn ngữ lập trình Eiffel, nguyên lý Design by Contract và lý thuyết kiểm thử hộp trắng

- Xây dựng thực tế một bộ test case cho chương trình Eiffel có ứng dụng nguyên

lý Design by Contract và đánh giá ảnh hưởng của nguyên lý đến việc kiểm thử

ii Lịch sử nghiên cứu

- Tháng 11/2009: nhận giáo viên hướng dẫn và đề tài

- Từ 12/2009 → 2/2010: tìm hiểu ngôn ngữ lập trình Eiffel và lý thuyết nguyên

lý Design by Contract

- Từ 3/2010 → 5/2010: tìm hiểu lý thuyết kiểm thử phần mềm

- Từ 6/2010 → 7/2010: tìm hiểu một chương trình Eiffel mẫu có ứng dụng nguyên lý Design by Contract và xây dựng test case kiểm thử hộp trắng cho chương trình này

- Từ 8/2010 → 10/2010: tổng hợp kết quả nghiên cứu và hoàn thành quyển luận văn

iii Mục đích, đối tƣợng và phạm vi nghiên cứu

- Mục đích: tìm hiểu lý thuyết và ứng dụng của ngôn ngữ lập trình Eiffel, nguyên lý Design by Contract và kiểm thử hộp trắng Nghiên cứu và đề xuất các hướng

mở rộng phát triển của lý thuyết đã tìm hiểu

- Đối tượng: ngôn ngữ lập trình Eiffel, nguyên lý Design by Contract và kiểm thử hộp trắng

- Phạm vi nghiên cứu: thuộc lĩnh vực con kiểm thử phần mềm, lĩnh vực Công nghệ phần mềm ngành Công nghệ thông tin

iv Các luận điểm cơ bản và đóng góp mới của tác giả

- Các luận điểm cơ bản:

v Phương pháp nghiên cứu

- Tìm hiểu và thực hành ngôn ngữ lập trình Eiffel trên EiffelStudio

- Tìm hiểu lý thuyết về kiểm thử phần mềm và Design by Contract thông qua các tài liệu hướng dẫn

- Tìm hiểu, chạy thử và xây dựng test case kiểm thử hộp trắng cho chương trình Eiffel Structure

CHƯƠNG 1 NGÔN NGỮ LẬP TRÌNH EIFFEL VÀ NGUYÊN

LÝ DESIGN BY CONTRACT 1.1 Ngôn ngữ lập trình Eiffel và môi trường làm việc EiffelStudio 1.1.1 Lịch sử

Eiffel là một ngôn ngữ lập trình hướng đối tượng đạt tiêu chuẩn ISO được thiết

kế hướng đến tính mở rộng, tái sử dụng, tin cậy và hiệu quả của lập trình phần mềm Thiết kế của ngôn ngữ lập trình Eiffel gắn liền với một số thủ tục đặc thù dựa trên một tập hợp các nguyên tắc: design by contract, command-query separation, uniform-access principle, single-choice principle, open-closed principl , and option-operand separation Eiffel được sử dụng như một ngôn ngữ học thuật để giảng dạy lập trình máy tính trong một số trường Đại học

Eiffel được sử dụng trong các lĩnh vực tài chính, hàng không, chăm sóc sức khỏe, video game, và các ngành công nghiệp khác như là một nền tảng để phát triển

các ứng dụng Nhiều khái niệm được giới thiệu đầu tiên trong ngôn ngữ lập trình Eiffel

sau đó đã được tích hợp vào các ngôn ngữ lập trình khác như Java, C#, vv Từ năm

1985, nhiều nhà cung cấp đã tham gia phát triển môi trường lập trình cho ngôn ngữ lập

trình Eiffel

Các đặc điểm chính của ngôn ngữ Eiffel bao gồm: [5]

+ Cấu trúc chương trình Eiffel là cấu trúc hướng đối tượng

+ Sử dụng chặt chẽ nguyên lý Design by contract trong thiết kế phần mềm so với các ngôn ngữ lập trình khác hỗ trợ nguyên lý này

+ Tự động quản lý bộ nhớ và dọn rác nhớ

+ Kế thừa; bao gồm đa kế thừa, đổi tên, tái định nghĩa và các cơ chế khác phục

vụ tính kế thừa trong ngôn ngữ lập trình hướng đối tượng

+ Một hệ thống thống nhất hỗ trợ xử lý cả hai loại tham chiếu: tham biến và tham trị trên tất cả các kiểu dữ liệu, từ kiểu dữ liệu cơ bản như INTEGER đến kiểu phức tạp như dữ liệu kiểu lớp

+ Cơ chế bảo vệ tĩnh chống lại các lời triệu gọi tới các dữ liệu NULL, thông qua

cơ chế attached-types

+ Hệ thống từ khoá dựa trên cú pháp trong ALGOL/Pascal truyền thống nhưng

có một vài thay đổi trong cách thức trình bày code liên quan đến các block và dấu chấm phẩy ";"

EiffelStudio là môi trường phát triển của ngôn ngữ lập trình Eiffel được phát

triển bởi công ty Eiffel Software do GS Bertrand Meyer của đại học ETH Zurich thành lập từ năm 1989

EiffelStudio là môi trường có thể sử dụng trong các hệ điều hành như: Windows, Linux, Mac OS, Solaris,…

EiffelStudio bao gồm cả phiên bản mở và phiên bản thương mại Phiên bản mở mới nhất EiffelsStudio 6.5 được download miễn phí tại địa chỉ: www.dev.eiffel.com

EiffelStudio bao gồm bộ các thư viện được viết sẵn để hỗ trợ cho việc sử dụng lại của mã nguồn dành cho người phát triển

EiffelStudio bao gồm các công cụ tích hợp cùng với giao diện của chúng như:

bộ dịch, trình thông dịch, trình gỡ lỗi, các công cụ đo, công cụ hiển thị đồ họa

Hình 1: Môi trường lập trình EiffelStudio

EiffelStudio sử dụng một trình biên dịch đặc biệt gọi là Melting Ice Đây là trình biên dịch tích hợp các thành phần để thông dịch các dịch các đoạn chương trình thay đổi so với lần dịch trước Mặc dù sử dụng trình biên dịch “melt” nhưng trước khi chương trình cuối sẽ được dịch lại toàn bộ sử dụng thành phần “finalization” Khi mã nguồn viết bằng Eiffel được dịch thì ban đầu, bộ dịch của chương trình sẽ dịch mã nguồn viết bằng Eiffel sang chương trình viết bằng C Sau đó, sẽ dịch chương trình viết bằng ngôn ngữ C sang mã máy Mã nguồn viết bằng C được lưu trong những file đặc biệt tạo ra bởi hệ thống, vì vậy chương trình dịch sẽ tạo ra rất nhiều file trong quá trình dịch mã nguồn Eiffel Do sử dụng chương trình dịch Melting Ice nên khi chương trình

có chút thay đổi thì chỉ cần dịch phần thay đổi đó và phần còn lại sẽ dùng cơ chế “đóng băng”

1.1.2 Các phiên bản EiffelStudio

Tiền thân của EiffelStudio được giới thiệu đầu tiên bởi Interactive Software Engineering Inc (tiền thân của Eiffel Software), phát hành vào năm 1986 Bắt đầu vào năm 1990, EiffelBench xuất hiện và kết nối với các thiết kế của ngôn ngữ lập trình Eiffel phiên bản 3 EiffelBench được đổi tên thành "EiffelStudio" khoảng năm 2001; đây cũng là thời gian khi môi trường thực thi được mở rộng ngoài Unix nhắm tới mục tiêu Windows và các nền tảng khác

Các phiên bản phát hành từ năm 2001, đi kèm một số tính năng mới cho từng phiên bản [5]

+ 5.0, tháng 7 năm 2001: phiên bản "EiffelStudio" chính thức đầu tiên; tích hợp công cụ thiết kế đồ họa "EiffelCase", theo hình thức của EiffelStudio's Diagram Tool

+ 5.1, tháng 12 năm 2001: phiên bản đầu tiên hỗ trợ NET Trước khi phát hành, phiên bản này được gọi là "Eiffel #"

+ 5.2, tháng 11 năm 2002: thành phần mới EiffelBuild hỗ trợ thiết kế giao diện, cải tiến trình gỡ lỗi, cung cấp các cơ chế mới hỗ trợ cho tích hợp các đoạn mã viết bằng

C và C++

+ 5.3, tháng 3 năm 2003: Eiffel NET có những cải tiến lớn: phát triển công nghệ của trình biên dịch Eiffel NET, thêm giao diện Java Eiffel2Java và cơ sở dữ liệu quan hệ giao diện EiffelStore EiffelStudio được cải tiến hiệu năng và xuất hiện phiên bản dành cho hệ điều hành MacOS

+ 5.4, Tháng 11 Năm 2003: cải thiện hiệu suất, hỗ trợ đa luồng, cải tiến lớn EiffelBuild, lần đầu tiên hỗ trợ cơ chế ECMA Eiffel committee, hỗ trợ cho tiền điều kiện và hậu điều kiện của các đoạn mã C được tích hợp thêm vào

+ 5.5, tháng 9 năm 2004: cải tiến trình gỡ lỗi Cách bố trí giao diện môi trường lập trình của EiffelStudio có sự thay đổi: người dùng có thể thêm bớt, thay đổi vị trí các cửa sổ con nhằm tạo ra giao diện môi trường lập trình cho riêng từng cá nhân, thuận tiện trong quản lý tài nguyên và lập trình

+ 5.6, tháng 8 năm 2005: tăng cường công cụ lược đồ UML, thêm trình thuật sĩ EiffelCOM hỗ trợ lập trình các thành phần Microsoft COM, cải thiện tốc độ sinh mã NET

+ 5.7, tháng 10 năm 2006: hỗ trợ Unicode, đưa ra cách mới để cấu hình một dự

án khi lập trình

+ 6.0, tháng 6 năm 2007: hỗ trợ làm việc theo tab: người dùng có thể mở nhiều tab, mỗi tab chứa mã nguồn của một lớp trong hệ thống Hỗ trợ kéo thả trong khi lập trình

+ 6.6, tháng 5 năm 2010: phiên bản chính thức mới nhất tính đến thời điểm hiện

tại

1.1.3 Các đặc điểm cơ bản của ngôn ngữ lập trình Eiffel

Một hệ thống hay chương trình Eiffel là một tập hợp các lớp - class Ở mức cao hơn, một nhóm các lớp được gọi là một cụm - cluster Cụm không phải là một cú pháp ngôn ngữ mà là một qui ước tiêu chuẩn để tổ chức chương trình Thông thường, Eiffel

tổ chức mỗi lớp trong một file riêng biệt và thư mực chứa các file này sẽ tương ứng với cụm Một lớp bao gồm các thành phần - feature và có chức năng tương tự như member, attribute hay method trong các ngôn ngữ lập trình hướng đối tượng khác Các thành phần của một lớp trong chương trình Eiffel có thể là các biến toàn cục hoặc các thủ tục Các kiểu dữ liệu tiêu chuẩn của Eiffel như INTEGER, STRING, ARRAY cũng là các lớp

Mỗi hệ thống có một lớp được chỉ định là "gốc - root", với một thủ tục khởi tạo của nó được xem như là "thủ tục gốc - root procedure" Thực thi một hệ thống chính là tạo ra một thể hiện của lớp gốc và thực thi thủ tục gốc, sau đó từ thể hiện gốc này sẽ thực thi các thao tác tạo ra các đối tượng khác, triệu gọi các thành phần khác của hệ thống

Hình 2: Mô hình phân cấp cluster của Eiffel

Như trong cây mô tả tài nguyên được trình bày ở hình hình 2, chúng ta thấy thư mục gốc Clusters chứa cluster project Project là tên dự án chương trình đồng thời là cluster gốc của chương trình Trong cluster project có chứa cluster con cluster_1 và lớp APPLICATION là lớp gốc của chuơng trình, chứa mã nguồn để khởi tạo chương trình

và được bộ dịch Eiffel tham chiếu đến đầu tiên khi dịch chưong trình Trong cluster_1 lại có cluster con là cluster_2 và lớp CLASS_2 Tương tự, cluster_2 chứa lớp CLASS_1

Eiffel có năm chỉ dẫn thực thi cơ bản: assignment, object creation, routine call, condition, và iteration Việc kiểm tra và thực thi của chương trình Eiffel nghiêm ngặt như trong ngôn ngữ lập trình cấu trúc: mỗi khối - block chỉ có đúng một đầu vào và một đầu ra

1.1.3.1 Cấu trúc một lớp của ngôn ngữ lập trình Eiffel

Hình 3: Cấu trúc một chương trình viết bằng Eiffel

Trong đó [7]

- note: các lời giới thiệu, chú thích, mô tả về lớp được người lập trình cung cấp giúp người đọc mã nguồn biết các thông tin cơ bản về cấu trúc, chức năng của lớp Khi chú thích trong đoạn chú giải này, người dùng không cần sử dụng kí tự đánh dấu

note

comment about class class

CLASS_NAME inherit

list of classes that it is inherited BASED_CLASS_1

redefine list of attributes that be redefined

redefine_attribute_1

end

list of Methods method1(var:VAR_TYPE) is

comment “ ” vì trình dịch của EiffelStudio nếu bắt được từ khóa note sẽ bỏ qua các chú thích cho tới khi gặp từ khóa class

- feature

Var1

… Routine1

…

Danh sách các thuộc tính và thủ tục của lớp Trong giao diện của EiffelStudio, khi chúng ta chia các thuộc tính và các thủ tục vào các block features khác nhau thì khi nhìn lớp đó dưới góc nhìn features, các block đó cũng sẽ được chú thích:

Hình 4: EiffelStudio chú thích các thuộc tính và thủ tục của một lớp

Như trong ví dụ lớp BINARY_SEARCH_TREE được trình bày ở hình 4, chúng

ta có 3 block feature:

+ block Creation gồm thủ tục make là thủ tục khởi tạo của lớp

+ block Attributes gồm các biến put, has, show, quit, tree_root

+ block Implementation gồm các thủ tục cycle, tree_trace,

fill_menu, excue, get_element

1.1.3.2 Các kiểu dữ liệu cơ bản

Trong phần này, chúng ta sẽ tìm hiểu một số kiểu dữ liệu cơ bản của một ngôn ngữ lập trình Eiffel xem tất cả các kiểu dữ liệu cơ bản là các lớp và có hai sự khác biệt [7]: kiểu lớp INTERGER, REAL, DOUBLE, CHARACTER và kiểu lớp thư viện STRING, ARRAY, LINKED_LIST Có một trường hợp đặc biệt với kiểu dữ liệu BOOLEAN

a BOOLEAN

Kiểu dữ liệu logic là kiểu duy nhất không nằm ở dạng lớp trong Eiffel Khi chúng ta khai báo ok: BOOLEAN thì biến ok chỉ có thể nhận một trong hai giá trị

TRUE hoặc FALSE, điều này giống như trong C hoặc PASCAL

Các toán tử: ngoài các toán tử AND, OR, XOR thông thường thì Eiffel hỗ trợ thêm 3 toán tử: OR ELSE, AND THEN, IMPLIES

b INTEGER

Kích thước lưu trữ: 32 bits

Dải số: - 231 + 1 → 231 - 1 hay 2, 147, 483, 647 → 2, 147,483, 647

Giá trị khởi tạo: 0

Các toán tử: + - ^ * / //(divisor) \\(modulus)

Là kiểu dữ liệu tương tự các ngôn ngữ lập trình khác và dựa trên bảng mã chuẩn ASCII

Hình 5: Cấu trúc lớp LINKED_LIST đƣợc hỗ trợ bởi EiffelStudio

Tương tự hai lớp STRING và ARRAY, EiffelStudio cũng cung cấp các thủ tục

xử lý cơ bản nhất cho lớp LINKED_LIST

1.2 Nguyên lý Design by Contract

Design by contract là một nguyên lý ứng dụng trong thiết kế, thực thi và hoàn thiện phần mềm được giới thiệu bởi giáo sư Bertrand Meyer Ý tưởng chính của nguyên lý nhấn mạnh vào sự kiểm tra thành phần đầu vào và đầu ra của mỗi module phần mềm, đảm bảo rằng module đó thực thi đúng công việc và chức năng của nó, nhằm đảm bảo toàn bộ hệ thống vận hành trơn tru, chính xác và ổn định Nguyên lý Design by Contract được đề xuất nhằm nâng cao tính tin cậy và tính đúng đắn của hệ thống phần mềm

1.2.1 Một số cơ chế mang lại tính tin cậy cho phần mềm

Để xây dựng một hệ thống phần mềm đáng tin cậy và bền vững, chúng ta nên ứng dụng ba cơ chế chính trong quá trình phát triển [5]:

- Kiến trúc phần mềm đơn giản, riêng biệt và có khả năng mở rộng sẽ có tính tin cậy cao hơn các kiến trúc khác Bên cạnh đó, kĩ thuật định nghĩa thuộc tính của một đối tượng liên quan tới cấu trúc của những hệ thống phần mềm Đặc biệt, để đảm bảo tính riêng biệt chúng ta nên cố gắng giới hạn sự liên quan giữa các module với nhau ở mức tối thiểu nhất Điều này giúp ngăn chặn những rủi ro thông thường, ví dụ như những biến toàn cục, những cơ chế liên lạc bị giới hạn, client và những mối quan hệ kế thừa Tuy rằng dạng kiến trúc của một phần mềm chưa đủ đảm bảo cho tính đáng tin cậy của phần mềm nhưng nó là một đặc điểm quan trọng để nâng cao tính tin cậy cho phần mềm đó

- Yếu tố thứ hai ảnh hưởng đến tính đáng tin cậy là sự tối ưu và dễ đọc của mã nguồn Văn bản phần mềm bao gồm mã nguồn và các tài liệu kĩ thuật kèm theo không những được viết một lần mà còn phải được đọc đi đọc lại và viết đi viết lại nhiều lần trong suốt quá trình phát triển, cài đặt, sử dụng, bảo trì và tái sử dụng hệ thống phần mềm đó Do đó chúng ta cần trình bày, bố trí mã nguồn và các tài nguyên một cách

hợp lý, theo một qui chuẩn nhất định để có thể tái sử dụng và tham khảo Ngoài ra, các câu chú thích trong sáng và đơn giản cũng giúp nâng cao tính đáng tin cậy của phần mềm

- Việc quản lý bộ nhớ một cách tự động, đặc biệt là bộ thu gom rác (garbage collection) giúp tăng độ tin cậy của hệ thống phần mềm Bất kỳ hệ thống nào có khởi tạo và thao tác với cấu trúc dữ liệu động mà lại thực hiện thu hồi bộ nhớ bằng tay (tức

là do người lập trình điều khiển) hoặc không thu hồi bộ nhớ sẽ gây ra các mối nguy hiểm: hệ thống sẽ bị quá tải bộ nhớ hoặc các dữ liệu khác, thậm chí là dữ liệu hệ thống,

sẽ bị tác động trái phép Do mức độ quan trọng của hệ thống quản lý rác nhớ nên trong các ngôn ngữ lập trình hướng đối tượng, nó được coi như một bộ phận quan trọng và

thiết yếu nhằm đảm bảo sự ổn định

1.2.2 Tính đúng đắn của phần mềm

Hệ thống hay thành phần phần mềm chỉ đúng hay sai khi có liên quan với một đặc tả nào đó [5]: hệ thống có thực thi đúng chức năng của nó hay không? Do đó thuật ngữ “tính đúng đắn” không được dùng cho những thành phần phần mềm riêng biệt mà được dùng cho cặp bao gồm một thành phần phần mềm và một đặc tả của thành phần

đó

Để có thể kiểm tra tính đúng đắn của một chương trình phần mềm, các nhà kiểm thử cần có: bản thân chương trình đó để chạy thử và các mô tả về chức năng của chương trình hay còn gọi là đặc tả chương trình Khi đó họ sẽ kiểm tra xem chương trình có chạy đúng với chức năng của nó không: thực thi một công việc, xử lý một khối

dữ liệu, vv Trong thực tế thường không thể xác định được tính đúng đắn của một chương trình ứng dụng được viết trên ngôn ngữ C với 300.000 dòng lệnh, tuy nhiên thông thường thì những chương trình với kích thước như thế luôn chứa những lỗi sai: chương trình chạy đúng trong một số trường hợp hoặc với một vài bộ dữ liệu thông thường nhưng chạy sai ở một vài trường hợp đặc biệt khác

Ví dụ, câu lệnh x := y+1 không đúng cũng không sai, vì đúng hay sai chỉ có ý nghĩa khi xét câu lệnh đó với một yêu cầu thực thi nào đó Do đó, câu lệnh trên sẽ đúng với đặc tả:

- Thiết kế đúng cấu trúc và chức năng giúp phát triển được một phần mềm đúng

- Giúp lập trình viên hiểu rõ hơn và đưa ra các cách giải quyết vấn đề sẽ được cài đặt trong chương trình

- Hỗ trợ xây dựng các tài liệu liên quan đến chương trình: tài liệu kĩ thuật, hướng dẫn sử dụng, vv…

- Hỗ trợ gỡ lỗi trong quá trình lập trình

Trong C, C++ và một số ngôn ngữ khác, các lập trình viên thường sử dụng các biến “cờ” để đánh dấu trạng thái hiện tại của chương trình, nhằm kiểm tra xem chương trình chạy đúng hay sai Khi chương trình chạy sai, lập trình viên sẽ truy vết theo giá trị các biến đó để xác định vị trí lỗi và gỡ lỗi Tuy nhiên, vì lập trình viên không thể cài đặt để kiểm tra tất cả các biến trạng thái của chương trình mà chỉ tập trung vào những điểm nghi ngờ nên họ rất dễ bỏ sót các lỗi sai của hệ thống Ngoài ra, việc thêm vào

các dòng lệnh để kiểm tra trạng thái chạy của hệ thống sẽ khiến lập trình viên gặp khó

khăn khi đọc mã nguồn và loại bỏ các dòng lệnh này khi chương trình đã chạy đúng

P được gọi là tiền điều kiện (precondition) và Q được gọi là hậu điều kiện (postcondition)

Ví dụ, ta có một công thức bình thường của tính đúng đắn như sau với giả sử rằng x là một số nguyên:

{x ≥ 9} x := x + 5 {x ≥ 13}

Trong công thức trên, P = {x ≥ 9} là tiền điều kiện, Q = {x ≥ 13} là hậu điều kiện, x:= x+5 là một thao tác trên biến x Công thức trên tương đương với một mệnh đề đúng: nếu x >= 9 thì sau khi thực hiện câu lệnh x := x + 5 chắc chắn sẽ có x >= 13 Tuy nhiên:

− Với tiền điều kiện x >= 9 và thao tác x := x + 5, hậu điều kiện tốt nhất phải là

x >= 14

− Với hậu điều kiện x >= 13 và thao tác x := x + 5, tiền điều kiện tốt nhất phải là

x >= 9

Nếu chung ta nhìn chương trình phần mềm dưới góc độ tương tự như một module trong lập trình với đầu vào và đầu ra, công thức của tính đúng đắn phản ánh đầy đủ chức năng của hệ thống phần mềm: khi đầu vào của hệ thống thỏa mãn một tập các ràng buộc (nhằm giúp hệ thống có đủ dữ liệu để thực thi công việc) thì hệ thống sẽ trả lại một đầu ra thỏa mãn một tập các ràng buộc khác: kết quả là chính xác Đó chính

là ý tưởng của nguyên lý Design by Contract được trình bày dưới đây

1.2.4 Nội dung nguyên lý Design by Contract

Tương tự như tiền điều kiện và hậu điều kiện trong công thức về tính đúng đắn, nguyên lý Design by Contract đề xuất việc ràng buộc các module trong một hệ thống với nhau bằng các xác nhận Với một module phần mềm, chúng ta đưa vào các tiền điều kiện và hậu điều kiện:

- Tiền điều kiện của một module là hệ điều kiện mà hệ thống bắt buộc phải tuân theo khi bắt đầu thực hiện module đó

- Hậu điều kiện của một module là hệ điều kiện mà hệ thống sẽ tuân thủ phải tuân theo khi kết thúc thực thi module đó

Tư tưởng chính của nguyên lý Design by Contract là ràng buộc các thành phần của một hệ thống phần mềm cộng tác với nhau trên cơ sở nghĩa vụ và lợi ích của mỗi thành phần Các nhà thiết kế phần mềm phải xác định giao diện cho các thành phần phần mềm một cách chính thức, chính xác và có thể kiểm chứng được, trong đó định nghĩa thông thường của các loại dữ liệu trừu tượng được mở rộng với tiền điều kiện, hậu điều kiện và điều kiện bất biến Những đặc điểm này được gọi là "hợp đồng", theo một phép ẩn dụ về khái niệm với các điều kiện và nghĩa vụ của các hợp đồng kinh doanh

Hình 6: Contract trong DbC và contract trong kinh doanh

Mục đích của contract trong nguyên lý Design by Contract là nâng cao tính chính xác của phần mềm thông qua cải thiện quá trình phát triển phần mềm: phân tích, thiết kế, thực hiện và hỗ trợ các quá trình sử dụng phần mềm: bảo trì, tái cấu trúc Khi nắm được các contract, người phát triển hoặc người dùng có thể biết được cấu trúc và chức năng của module, qua đó dễ dàng thực hiện các công việc của mình Cụ thể, các contract sẽ được ứng dụng trong:

+ Các tài liệu liên quan của phần mềm Các tài liệu này có thể là các mô tả kĩ thuật hoặc hướng dẫn sử dụng phần mềm, được sử dụng

+ Tái sử dụng các module

+ Kiểm soát thừa kế

+ Hỗ trợ công việc của các nhà phát triển

+ Đảm bảo chất lượng, kiểm tra, gỡ lỗi (đặc biệt là trong kết nối với việc sử dụng thư viện)

định và ràng buộc về đầu vào và đầu ra của mỗi thành phần trong hệ thống, qua đó giúp người thiết kế hiểu sâu hơn về hệ thống và đảm bảo sự tương thích giữa các thành phần Còn trong viết mã cho phần mềm, nguyên lý Design by Contract có thể được hiểu như việc tách biệt riêng công việc kiểm tra các ràng buộc của một block nhằm hỗ trợ cho người lập trình Sau đây là một ví dụ cho cài đặt nguyên lý Design by Contract trong ngôn ngữ lập trình Eiffel:

Hình 7: Cài đặt nguyên lý Design by Contract trong ngôn ngữ Eiffel

Ở ví dụ trên:

+ tiền điều kiện: x >= 0

+ hậu điều kiện: Result * Result = x

Với tiền điều kiện và hậu điều kiện được cài đặt trong thủ tục tính căn bậc hai trên, chúng ta đã tách biệt được công việc kiểm tra tính hợp lệ của đầu vào thủ tục: hàm căn bậc hai chỉ nhận đối số không âm và việc kiểm tra lại đầu ra của thủ tục có đúng như chúng ta mong đợi hay không Với một ví dụ ngắn như trên, chúng ta sẽ không thấy rõ được lợi ích của nguyên lý Tuy nhiên, khi mà một thủ tục với hàng trăm dòng mã, bao gồm rất nhiều vòng lặp và các khối rẽ nhánh đan xen, việc đảm bảo được tính chính xác của dữ liệu là vô cùng vất vả và khó khăn Ngoài ra, nếu không cài đặt tiền điều kiện và hậu điều kiện cho module, chúng ta sẽ phải sử dụng các biến cờ để đánh dấu nhằm phát hiện và khắc phục lỗi khi thực thi module

Tóm tắt chương 1

Chương 1 trình bày về ngôn ngữ lập trình Eiffel và nguyên lý Design by Contract, đều được giới thiệu bởi Giáo sư Bertrand Meyer Design by Contract là một nguyên lý mà trong đó các module phần mềm phải có sự ràng buộc chặt chẽ với nhau, nhằm đảm bảo hệ thống vận hành trơn tru và giảm thiểu ngoại lệ Nguyên lý nhấn mạnh việc khi các module triệu gọi nhau cần biết được đặc điểm cụ thể của đầu vào: tiền điều kiện, đầu ra: hậu điều kiện và các nguyên tắc phải đảm bảo khi vận hành: điều kiện bất biến Eiffel là một ngôn ngữ lập trình hướng đối tượng thuần túy, có lịch sử hơn 20 năm và hỗ trợ hoàn toàn nguyên lý Design by Contract EiffelStudio là một môi trường lập trình cho ngôn ngữ lập trình Eiffel

CHƯƠNG 2 KIỂM THỬ PHẦN MỀM - KIỂM THỬ HỘP

TRẮNG 2.1 Kiểm thử phần mềm và xây dựng test case từ use case

2.1.1 Giới thiệu về kiểm thử

Kiểm thử phần mềm [5] là một cuộc điều tra được tiến hành để cung cấp cho

các bên liên quan thông tin về chất lượng của sản phẩm được thử nghiệm Kiểm thử phần mềm cũng cung cấp một cái nhìn cụ thể và độc lập về phần mềm nhằm giúp các doanh nghiệp đánh giá và hiểu được những rủi ro khi triển khai phần mềm Kĩ thuật kiểm tra bao gồm quá trình thực thi phần mềm nhằm tìm ra các lỗi của hệ thống Kiểm thử phần mềm chính là một bước sử dụng thử hệ thống, do vậy người kiểm thử phải

mô tả gần đúng nhất môi trường mà phần mềm phải làm việc: cấu hình hệ thống, thói quen và trình độ người dùng; đồng thời phải cố gắng vét cạn được các tình huống mà phần mềm phải đối mặt trong thực tế

Hình 8: Kiểm thử phần mềm 2.1.1.1 Các nguyên lý trong kiểm thử phần mềm

Sau đây là một số nguyên lý quan trọng trong lý thuyết kiểm thử phần mềm [8]:

• Chúng ta có thể giảm thiểu rủi ro bằng cách tìm ra và khắc phục các lỗi của hệ thống Kinh doanh có thể là kinh doanh phần mềm hoặc phần mềm ứng dụng vào trong

công việc kinh doanh Nếu một hệ thống tốt, ít lỗi, vận hành ổn định sẽ nâng cao tính tin cậy khi ứng dụng trong kinh doanh, do đó sẽ được tin tưởng va

• Cần kiểm thử các thành phần bằng các test case tích cực và tiêu cực Việc kiểm thử bằng cả hai loại này sẽ giúp lập trình viên phát hiện được sự khác biệt về dữ liệu đầu vào, quá trình chạy cũng nhữ kết quả đầu ra của module nhằm tìm ra và khắc phục lỗi của hệ thống

• Kiểm thử tĩnh và kiểm thử động đều cần thiết cho đánh giá chất lượng một phần mềm Kiểm thử tĩnh giúp lập trình viên rà soát lại và có một cái nhìn tổng quát hơn về hệ thống, trong khi đó kiểm thử động sẽ giúp người phát triển biết được trong thực tế chương trình sẽ chạy như thế nào

• Chúng ta có thể sử dụng một số công cụ xây dựng test case tự động nhằm hỗ trợ quá trình kiểm thử Các công cụ này thực sự hữu ích nếu chúng ta cần kiểm thử hiệu năng của hệ thống phần mềm: phần mềm có thể thực hiện được khối lượng công việc bao nhiêu trong thời gian bao lâu

• Khi kiểm thử, hãy mô phỏng chân thực nhất môi trường thực tế mà phần mềm

sẽ chạy Môi trường này bao gồm cấu hình phần cứng, cách thức quản trị phần mềm và người dùng phần mềm

• Tất cả các kiểm thử phải liên quan tới các yêu cầu của khách hàng Như chúng

ta đã thấy, mục tiêu của kiểm thử phần mềm là để phát hiện ra lỗi, do đó các khiếm khuyết nghiêm trọng nhất (theo quan điểm của khách hàng) chính là việc chương trình không thực hiện được đúng chức năng của nó

• Cần sắp xếp lên kế hoạch trước khi bắt đầu kiểm thử Kế hoạch kiểm thử có thể được triển khai ngay sau khi các mô hình hệ thống được định hình Ngay sau khi hoàn chỉnh thiết kế của phần mềm, chúng ta có thể bắt tay vào xây dựng chi tiết các bộ

test case Nói chung, tốt nhất nên bắt đầu lên kế hoạch và thiết kế kiểm thử ngay sau khi hoàn thành phân tích thiết kế hệ thống và trước khi lập trình phần mềm

• Áp dụng nguyên tắc Pareto cho kiểm thử phần mềm: 80 phần trăm của các lỗi phát hiện trong quá trình thử nghiệm liên quan tới 20 phần trăm các thành phần chương trình Do đó, chúng ta nên ưu tiên cô lập các thành phần nghi ngờ và kiểm tra chúng kỹ lưỡng

• Qui mô kiểm thử nên được triển khai từ nhỏ đến lớn: ban đầu các công việc kiểm thử nên tập trung vào các module thành phần của hệ thống Sau đó mở rộng dần

ra cụm các thành phần và cuối cùng là toàn bộ hệ thống

• Chúng ta không thể kiểm thử vét cạn một phần mềm: đối với một phần mềm

cỡ trung bình thì số lượng các khả năng xảy ra của nó tăng theo hàm số mũ Tuy nhiên chúng ta có thể quan tâm tới logic của chương trình và chắc chắn rằng tất các điều kiện trong thiết kế mức thành phần được thỏa mãn

• Công việc kiểm thử phần mềm nên được thực hiện bởi bên thứ ba độc lập Do mục tiêu của kiểm thử là tìm ra lỗi của hệ thống nên những người phân tích thiết kế hệ thống và phát triển mã lệnh không nên là người cung cấp các kiểm thử

2.1.1.2 Các cấp độ kiểm thử phần mềm

● Kiểm thử hệ thống [4, 8]

Kiểm thử hệ thống được thực hiện trên toàn bộ hệ thống, nhằm đảm bảo sự vận hành của hệ thống Một hệ thống gồm hai hoặc nhiều thành phần được tích hợp với nhau nhằm thực hiện các chức năng của hệ thống Sau khi tích hợp các thành phần tạo nên hệ thống, quá trình kiểm thử hệ thống được tiến hành Trong quá trình phát triển

hệ thống theo mô hình lặp đi lặp lại, kiểm thử hệ thống liên quan với kiểm thử một lượng công việc ngày càng tăng để phân phối cho khách hàng; trong quá trình phát

triển hệ thống theo mô hình thác nước, kiểm thử hệ thống liên quan với kiểm thử toàn

bộ hệ thống Thường kiểm thử hệ thống bao gồm hai giai đoạn:

+ Trong quá trình phát triển: đánh giá hệ thống dưới góc độ một tổ hợp các module, nhằm tìm lỗi trong mối liên hệ các module để gỡ lỗi Đội kiểm thử nhận

mã nguồn của hệ thống sau đó thực hiện kiểm thử Khi một vấn đề được phát hiện, đội tích hợp thử tìm nguồn gốc của vấn đề và nhận biết thành phần cần phải gỡ lỗi

+ Khi phát hành: đánh giá sự vận hành của hệ thống hoàn chỉnh Một phiên bản của hệ thống có thể được phát hành tới người dùng được kiểm thử Đội kiểm thử tập trung vào việc hợp lệ các yêu cầu của hệ thống và đảm bảo tính tin cậy của hệ thống Kiểm thử phát hành thường là kiểm thử “hộp đen”, đội kiểm thử tập trung vào

mô tả các đặc tính hệ thống có thể làm được hoặc không làm được Các vấn đề được báo cáo lại cho đội phát triển để gỡ lỗi chương trình Khách hàng cũng là một tác nhân của công việc kiểm thử phát hành

số test case phải xây dựng ở mỗi bước, đồng thời dễ dàng khoanh vùng được vị trí nghi