Nghiên cứu mở rộng tính năng của công cụ satan, thử nghiệm ứng dụng trong môi trường scicos và simulink

BỘ KHOA HỌC VÀ CÔNG NGHỆ ĐẠI HỌC ĐÀ NẴNG NHIỆM VỤ HỢP TÁC QUỐC TẾ KHOA HỌC VÀ CÔNG NGHỆ THEO NGHỊ ĐỊNH THƯ BÁO CÁO TỔNG HỢP KẾT QUẢ KHOA HỌC CÔNG NGHỆ ĐỀ TÀI NGHIÊN CỨU KỸ THUẬT PHÂN T

BỘ KHOA HỌC VÀ CÔNG NGHỆ ĐẠI HỌC ĐÀ NẴNG

NHIỆM VỤ HỢP TÁC QUỐC TẾ KHOA HỌC VÀ CÔNG NGHỆ THEO NGHỊ ĐỊNH THƯ

BÁO CÁO TỔNG HỢP

KẾT QUẢ KHOA HỌC CÔNG NGHỆ ĐỀ TÀI NGHIÊN CỨU KỸ THUẬT PHÂN TÍCH KHẢ NĂNG KIỂM THỬ PHẦN MỀM VÀ MỞ RỘNG TÍNH NĂNG CỦA CÔNG CỤ SATAN, THỬ NGHIỆM ỨNG DỤNG TRONG

MÔI TRƯỜNG SCICOS VÀ SIMULINK

Cơ quan chủ trì đề tài: Đại học Đà Nẵng

Chủ nhiệm đề tài: TS Nguyễn Thanh Bình

Đà Nẵng - 2012

BỘ KHOA HỌC VÀ CÔNG NGHỆ ĐẠI HỌC ĐÀ NẴNG

NHIỆM VỤ HỢP TÁC QUỐC TẾ KHOA HỌC VÀ CÔNG NGHỆ THEO NGHỊ ĐỊNH THƯ

BÁO CÁO TỔNG HỢP

KẾT QUẢ KHOA HỌC CÔNG NGHỆ ĐỀ TÀI NGHIÊN CỨU KỸ THUẬT PHÂN TÍCH KHẢ NĂNG KIỂM THỬ PHẦN MỀM VÀ MỞ RỘNG TÍNH NĂNG CỦA CÔNG CỤ SATAN, THỬ NGHIỆM ỨNG DỤNG TRONG

MÔI TRƯỜNG SCICOS VÀ SIMULINK

Chủ nhiệm đề tài Cơ quan chủ trì đề tài

I THÔNG TIN CHUNG

1 Tên đề tài: Nghiên cứu kỹ thuật phân tích khả năng kiểm thử phần mềm và

mở rộng tính năng của công cụ SATAN, thử nghiệm ứng dụng trong môi trường Scicos và Simulink

2 Chủ nhiệm đề tài/dự án:

Họ và tên: Nguyễn Thanh Bình

Ngày, tháng, năm sinh: 16/06/1975 Nam/ Nữ: Nam

Học hàm, học vị: Tiến sỹ

Chức danh khoa học: Giảng viên Chức vụ: Trưởng Khoa

Điện thoại: Tổ chức: 0511 3 736 949 Nhà riêng: 0511 3 955 461 Mobile: 0914 74 79 74 E-mail: ntbinh@dut.udn.vn

Tên tổ chức đang công tác: Trường Đại học Bách Khoa, Đại học Đà Nẵng

Địa chỉ tổ chức: 54, Nguyễn Lương Bằng, Liên Chiểu, TP Đà Nẵng

Địa chỉ nhà riêng: Lô 202, Tổ 7, Mỹ An, Ngũ Hành Sơn, Đà Nẵng

3 Tổ chức chủ trì đề tài/dự án:

Tên tổ chức chủ trì đề tài: Đại học Đà Nẵng

Điện thoại: 0511 3 817 180 Fax: 0511 3 823 683

E-mail: vthung@ac.udn.vn

Website: http://www.ud.edu.vn/

Địa chỉ: 41, Lê Duẩn, TP Đà Nẵng

Họ và tên thủ trưởng tổ chức: Trần Văn Nam

Số tài khoản: Ngân hàng: Tên cơ quan chủ quản đề tài: Đại học Đà Nẵng

Thời gian

(Tháng, năm)

Kinh phí (Tr.đ)

Thời gian (Tháng, năm)

Kinh phí (Tr.đ)

c) Kết quả sử dụng kinh phí theo các khoản chi:

Đối với đề tài:

- Lý do thay đổi (nếu có):

1 Thiết bị máy móc: Do giá thực tế khi mua cao hơn so với giá lúc dự toán

2 Đoàn ra: Thay đổi số lượng người tham gia đoàn ra

3 Các văn bản hành chính trong quá trình thực hiện đề tài/dự án:

(Liệt kê các quyết định, văn bản của cơ quan quản lý từ công đoạn xác định nhiệm vụ, xét chọn, phê duyệt kinh phí, hợp đồng, điều chỉnh (thời gian, nội dung, kinh phí thực hiện nếu có); văn bản của tổ chức chủ trì đề tài, dự án (đơn, kiến nghị điều chỉnh nếu có)

Số

TT

Số, thời gian ban

hành văn bản Tên văn bản Ghi chú

1

2615/QĐ-BKHCN, 2009

Về việc phê duyệt danh mục

và kinh phí thực hiện các nhiệm vụ hợp tác quốc tế về Khoa học và Công nghệ theo Nghị định thư từ năm 2010

2

05/2010/HĐ-NĐT, 2010

Hợp đồng thực hiện nhiệm vụ hợp tác quốc tế về Khoa học

và Công nghệ theo Nghị định thư

4 Tổ chức phối hợp thực hiện đề tài, dự án:

Nội dung tham gia chủ yếu

Sản phẩm chủ yếu đạt được

Ghi chú*

Khoa, Đại học

Đà Nẵng

Tham gia nghiên cứu

đề tài và phát triển phần mềm

Báo cáo, bài báo, đào tạo, phần mềm

nghệ, Đại học Quốc gia Hà Nội

Tham gia nghiên cứu

Tham gia nghiên cứu

đề tài

Báo cáo

Cung cấp công cụ, hỗ trợ cùng nghiên cứu

và phát triển phần mềm

Bài báo, đào tạo, phần mềm

5 Cá nhân tham gia thực hiện đề tài, dự án:

(Người tham gia thực hiện đề tài thuộc tổ chức chủ trì và cơ quan phối hợp, không quá 10 người kể cả chủ nhiệm)

Nội dung tham gia chính

Sản phẩm chủ yếu đạt được

Ghi chú*

1 TS Nguyễn

Thanh Bình

TS Nguyễn Thanh Bình

Chủ trì nghiên cứu

Bài báo, Đào tạo, Phần mềm

2 ThS Đặng

Thiên Bình

ThS Đặng Thiên Bình

Tham gia nghiên cứu, viết phần mềm

Bài báo, Phần mềm

3 TS Đặng Văn

Hưng

TS Đặng Văn Hưng

Tham gia nghiên cứu

Báo cáo

4 ThS Nguyễn

Văn Khang

ThS Nguyễn Văn Khang

Tham gia nghiên cứu

Báo cáo

5 ThS Trịnh

Công Duy

ThS Trịnh Công Duy

Tham gia nghiên cứu, viết phần mềm

1 Trao đổi, tiếp nhận công cụ

SATAN, 6/2010, Kinh phí

40,000,000đ, Phòng thí

nghiệm LCIS, Valence,

Pháp, 01 đoàn ra, 02 người

Trao đổi, tiếp nhận công cụ SATAN, 6/2010, Kinh phí 35,606,000đ, Phòng thí nghiệm LCIS, Valence, Pháp, 01 đoàn ra, 01 người

2 Triển khai và chuyển giao

kết quả mở rộng công cụ

Triển khai và thực hiện mở rộng công cụ SATAN,

SATAN, 01/2012, Kinh phí

100,000,000đ, Phòng thí

nghiệm LCIS, Valence,

Pháp, 01 đoàn ra, 02 người

01/2012, Kinh phí 93,439,000đ, Phòng thí nghiệm LCIS, Valence, Pháp, 01 đoàn ra, 02 người

3 Trao đổi về triển khai đề tài,

4 Tư vấn kết quả thực hiện đề

7 Tình hình tổ chức hội thảo, hội nghị:

8 Tóm tắt các nội dung, công việc chủ yếu:

(Nêu tại mục 15 của thuyết minh, không bao gồm: Hội thảo khoa học, điều tra khảo sát trong nước và nước ngoài)

Số

TT

Các nội dung, công

việc chủ yếu

Theo kế hoạch

Thực tế đạt được

1 Nghiên cứu và đánh giá

tổng quan về các kỹ thuật

phân tích khả năng kiểm

thử hiện có.

1/1/2010 - 30/03/2010

1/1/2010 - 30/03/2010

Đặng Văn Hưng, Khoa Công nghệ Thông tin, Trường Đại học Công nghệ, Đại học Quốc gia

Hà Nội Nguyễn Thanh Bình, Phòng thí nghiệm DATIC

Nguyễn Văn Khang, Khoa Tin học, Trường Đại học Sư phạm Huế

2 Nghiên cứu công cụ phân

tích khả năng kiểm thử

SATAN.

01/04/2010

- 30/05/2010

01/04/2010

- 30/05/2010

Trịnh Công Duy, Đặng Thiên Bình, Phòng thí nghiệm DATIC

Michel Delaunay, Phòng thí nghiệm LCIS.

3 Tiếp thu công cụ phân tích

khả năng kiểm thử

SATAN

01/06/2010

- 30/06/2010

01/06/2010

- 30/06/2010

Trịnh Công Duy, Đặng Thiên Bình, Nguyễn Thanh Bình, Phòng thí nghiệm DATIC

Michel Delaunay, Phòng thí nghiệm LCIS.

4 Tìm hiểu các môi trường

hỗ trợ phát triển phần

mềm: Simulink và Scicos.

01/07/2010

- 31/08/2010

01/07/2010

- 31/08/2010

Đặng Thiên Bình, Phòng thí nghiệm DATIC.

5 Mở rộng tính năng của

công cụ SATAN để phân

tích khả năng kiểm thử của

01/09/2010

- 28/02/2011

Đặng Thiên Bình, Nguyễn Thanh Bình, Phòng thí nghiệm DATIC

Michel Delaunay, Chantal Robach, Phòng thí nghiệm LCIS.

6 Mở rộng tính năng của

công cụ SATAN để phân

tích khả năng kiểm thử của

01/03/2011

- 30/09/2011

Đặng Thiên Bình, Nguyễn Thanh Bình, Phòng thí nghiệm DATIC

Michel Delaunay, Chantal Robach, Phòng thí nghiệm LCIS.

01/09/2011

- 30/10/2011

Đặng Thiên Bình, Nguyễn Thanh Bình, Phòng thí nghiệm DATIC

III SẢN PHẨM KH&CN CỦA ĐỀ TÀI, DỰ ÁN

1 Sản phẩm KH&CN đã tạo ra:

a) Sản phẩm

1 Công cụ SATAN Toàn bộ mã

nguồn công cụ SATAN

Mã nguồn biên dịch và thực thi được

Tài liệu kỹ thuật

về công cụ SATAN

Toàn bộ mã nguồn công cụ SATAN

Mã nguồn biên dịch và thực thi được

Tài liệu kỹ thuật

về công cụ SATAN

2 Chương trình mở rộng

tính năng công cụ

SATAN phân tích khả

năng kiểm thử các thiết

kế trong môi trường

Scicos

Thiết kế rõ ràng, chặt chẽ

Mã nguồn dễ bảo trì

Được kiểm thử đầy đủ

Có tài liệu hướng dẫn sử dụng và hướng dẫn cài đặt

Tích hợp vào SATAN

Thiết kế rõ ràng, chặt chẽ

Mã nguồn dễ bảo trì

Được kiểm thử đầy đủ

Có tài liệu hướng dẫn sử dụng và hướng dẫn cài đặt

Tích hợp vào SATAN

3 Chương trình mở rộng

tính năng công cụ

SATAN phân tích khả

năng kiểm thử các thiết

kế trong môi trường

Simulink

Thiết kế rõ ràng, chặt chẽ

Mã nguồn dễ bảo trì

Được kiểm thử đầy đủ

Có tài liệu hướng dẫn sử dụng và hướng dẫn cài đặt

Tích hợp vào SATAN

Thiết kế rõ ràng, chặt chẽ

Mã nguồn dễ bảo trì

Được kiểm thử đầy đủ

Có tài liệu hướng dẫn sử dụng và hướng dẫn cài đặt

Tích hợp vào SATAN

4 Đào tạo sau đại học Góp phần đào

tạo 01 Nghiên cứu sinh và 02 học viên Cao học

Góp phần đào tạo 01 Nghiên cứu sinh và 04 học viên Cao học

5 Bài báo khoa học 01 bài báo đăng

trên kỷ yếu hội thảo khoa học quốc tế

01 bài báo đăng

01 bài báo đăng trên tạp chí quốc tế

02 bài báo đăng trên kỷ yếu hội

trên tạp chí hoặc

kỷ yếu hội thảo khoa học quốc gia

thảo khoa học quốc tế

01 bài báo đăng trên tạp chí khoa học và công nghệ (6 trường Đại học

Theo kế hoạch

Thực tế đạt được

Kết quả áp dụng mang lại thông tin hữu ích cho người kiểm thử

2 Đánh giá về hiệu quả do đề tài, dự án mang lại:

a) Hiệu quả về khoa học và công nghệ:

Nhóm nghiên cứu DATIC phối hợp với nhóm nghiên cứu CTSYS của phòng thí nghiệm LCIS đã nắm rỏ được tình hình nghiên cứu về lĩnh vực khả năng

kiểm thử trên thế giới, làm chủ và áp dụng được công cụ phân tích khả năng kiểm thử SATAN, mở rộng công cụ SATAN áp dụng cho các môi trường Simlink và Scicos Xây dựng được nhóm nghiên cứu chuyên sâu ở DATIC về khả năng kiểm thử phần mềm

b) Hiệu quả về kinh tế xã hội:

Kết quả nghiên cứu của đề tài có thể triển khai để đánh giá khả năng kiểm thử của các phần mềm được phát triển trong môi trường Simulink hay Scicos tại các doanh nghiệp

Trong quá trình thực hiện đề tài, nhóm cũng đã góp phần đào tạo các nghiên cứu sinh và học viên Cao học trong lĩnh vực kiểm thử và phân tích khả năng kiểm thử

3 Tình hình thực hiện chế độ báo cáo, kiểm tra của đề tài, dự án:

Số

TT Nội dung

Thời gian thực hiện

Ghi chú

I Báo cáo định kỳ

Lần 1 09/03/2011 Đề tài được thực hiện

theo đúng tiến độ đặt ra Bước đầu đã đạt được các kết quả tốt

Nhóm thực hiện đề tài sẽ tiếp tục phối hợp với phía đối tác để hoàn thành đúng tiến độ các mục công việc còn lại

Lần 2 14/09/2011 Đề tài thực hiện tốt, theo

đúng tiến độ đặt ra

II Nghiệm thu cơ sở 2/12/2011 Hội đồng đánh giá Đạt

Chủ nhiệm đề tài Thủ trưởng tổ chức chủ trì

(Họ tên, chữ ký và đóng dấu)

TS Nguyễn Thanh Bình

1

MỤC LỤC

MỤC LỤC 1

DANH MỤC CÁC BẢNG 5

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

MỞ ĐẦU 9

CHƯƠNG 1 KIỂM THỬ PHẦN MỀM VÀ PHÂN TÍCH TÍNH KHẢ KIỂM THỬ PHẦN MỀM 13

1.1 Giới thiệu 13

1.1.1 Kiểm chứng và hợp thức hóa 14

1.2 Kiểm thử phần mềm 15

1.2.1 Khái niệm kiểm thử 15

1.2.2 Các hoạt động kiểm thử 16

1.2.3 Các kỹ thuật kiểm thử 17

1.3 Tính khả kiểm thử phần mềm 18

1.3.1 Định nghĩa tính khả kiểm thử phần mềm 19

1.3.2 Phân loại các định nghĩa phân tích tính khả kiểm thử phần mềm 21 1.4 Các phương pháp phân tích tính khả kiểm thử phần mềm 22

1.4.1 Phương pháp phân tích tính khả kiểm thử truyền thống 23

1.4.2 Phương pháp phân tích tính khả kiểm thử hướng đối tượng 35

1.5 Tổng kết chương 1 43

CHƯƠNG 2 PHÂN TÍCH TÍNH KHẢ KIỂM THỬ VỚI SATAN 44

2.1 Giới thiệu 44

2.2 Đồ thị truyền tin 45

2

2.3 Luồng 49

2.4 Chiến lược kiểm thử 50

2.5 Độ đo tính khả kiểm thử 52

2.5.1 Lý thuyết thông tin 53

2.5.2 Mạng truyền tin 57

2.5.3 Độ đo tính khả kiểm thử 57

2.6 Công cụ SATAN 61

2.6.1 Kiến trúc tổng thể của SATAN 61

2.6.2 Mô-đun In-Mac 62

2.6.3 Mô-đun lõi SATAN 63

2.6.4 Thư viện In-Mac 65

2.7 Tổng kết chương 2 68

CHƯƠNG 3 MÔI TRƯỜNG SCICOS VÀ MÔI TRƯỜNG SIMULINK 69

3.1 Giới thiệu 69

3.2 Môi trường SCICOS 69

3.2.1 Giới thiệu 69

3.2.2 Xây dựng và mô phỏng các mô hình SCICOS 70

3.2.3 Thư viện các khối SCICOS 72

3.3 Môi trường SIMULINK 73

3.3.1 Giới thiệu 73

3.3.2 Các thư viện SIMULINK 74

3.3.3 Thiết kế và mô phỏng bằng SIMULINK 75

3.4 Tổng kết chương 3 77

CHƯƠNG 4 MỞ RỘNG CÔNG CỤ SATAN CHO CÁC MÔI TRƯỜNG SIMULINK VÀ SCICOS 78

4.1 Giới thiệu 78

4.2 Thiết kế mô-đun Simulink/Scicos2mac 79

4.2.1 Thiết kế tổng thể 79

4.2.2 Thiết kế chi tiết 80

4.2.3 Cài đặt 86

3

4.3 Xây dựng thư viện In-Mac cho SIMULINK/SCICOS 86

4.3.1 Xây dựng kiểu SATAN 87

4.3.2 Tính toán hệ số mất mát thông tin 91

4.4 Xây dựng mô-đun Out-Mac 91

4.4.1 Xử lý kết quả tính khả kiểm thử theo chiến lược Start-Small 93

4.4.2 Xử lý kết quả tính khả kiểm thử theo chiến lược Multi-Clue 95

4.5 Kết quả thử nghiệm 97

4.5.1 Phân tích tính khả kiểm thử của các mô hình SCICOS 98

4.5.2 Phân tích tính khả kiểm thử của các mô hình SIMULINK 100

4.6 Tổng kết chương 4 110

CHƯƠNG 5 PHÂN TÍCH TÍNH KHẢ KIỂM THỬ CÁC MÔ HÌNH MÁY TRẠNG THÁI HỮU HẠN 111

5.1 Giới thiệu 111

5.2 Ngữ cảnh 112

5.2.1 Hệ thống phản ứng 112

5.2.2 Hệ thống phản ứng đồng bộ 114

5.2.3 Tiếp cận luồng dữ liệu và luồng điều khiển 115

5.2.4 Môi trường phát triển 116

5.3 Khái niệm máy trạng thái hữu hạn 117

5.3.1 Máy trạng thái hữu hạn cơ bản 118

5.3.2 Máy trạng thái mở rộng 120

5.3.3 Hệ thống chuyển tiếp được gán nhãn 121

5.3.4 Statechart 121

5.4 Tiêu chí bao phủ dựa trên máy trạng thái 123

5.4.1 Định nghĩa 123

5.4.2 Thảo luận 124

5.5 Độ đo tính khả kiểm thử dựa trên máy trạng thái hữu hạn 125

5.5.1 Chuỗi Markov 125

5.5.2 Độ đo tính khả kiểm thử 127

5.6 Thử nghiệm 130

4

5.6.1 Tính khả kiểm thử của B01_AUTOMATON 131

5.6.2 Thử nghiệm với công cụ GATeL 135

5.7 Tổng kết chương 5 137

KẾT LUẬN 139

Kết quả đạt được 139

Hạn chế 141

Hướng phát triển 142

TÀI LIỆU THAM KHẢO 143

PHỤ LỤC I: NGÔN NGỮ MACDOT……….……… 148

PHỤ LỤC II: NGÔN NGỮ IN-MAC……….……… 161

PHỤ LỤC III: THƯ VIỆN IN-MAC……… ……… 174

PHỤ LỤC IV: BÁO CÁO ĐOÀN RA VÀ ĐOÀN VÀO……… ……… 186

PHỤ LỤC V: BÁO CÁO KẾT QUẢ THỬ NGHIỆM……… ……… 187

PHỤ LỤC VI: SẢN PHẨM CỦA ĐỀ TÀI……… ……… 188

5

DANH MỤC CÁC BẢNG

Bảng 1.1 Phân loại các định nghĩa tính khả kiểm thử 21 Bảng 1.2 Các luật tính khả năng điều khiển các phép gán 27 Bảng 4.1 Sự tương quan giữa SIMULINK/SCICOS và SATAN 80

Bảng 4.3 Danh sách các kiểu SATAN được xây dựng 88 Bảng 4.4 Các tệp tin chứa kết quả phân tích tính khả kiểm thử 92 Bảng 4.5 Kết quả tính khả kiểm thử của hệ thống Pil-dem 98 Bảng 4.6 Kết quả tính khả kiểm thử của hệ thống GRS 99 Bảng 4.7 Thông tin về hệ thống re_gy_2sw_anno 101 Bảng 4.8 Kết quả phân tích trong lớp 1 (luồng 1) 102 Bảng 4.9 Kết quả phân tích trong lớp 2 (luồng 2) 102 Bảng 4.10 Kết quả phân tích trong lớp 2 (luồng 4) 102 Bảng 4.11 Kết quả phân tích trong lớp 3 (luồng 3) 102

Bảng 4.13 Kết quả phân tích trong lớp 1 (luồng 1) 103 Bảng 4.14 Kết quả phân tích trong lớp 2 (luồng 2) 104 Bảng 4.15 Kết quả phân tích tính khả kiểm thử theo Multi-Clue 104 Bảng 4.16 Hệ thống B23_NAVIGATION_PROPAGATION 105 Bảng 4.17 Kết quả phân tích trong lớp 1 (luồng 8) 106 Bảng 4.18 Kết quả phân tích trong lớp 2 (luồng 7) 106 Bảng 4.19 Kết quả phân tích trong lớp 3 (luồng 5) 106 Bảng 4.20 Kết quả phân tích trong lớp 3 (luồng 2) 107 Bảng 4.21 Kết quả phân tích trong lớp 4 (luồng 1) 107 Bảng 4.22 Kết quả phân tích trong lớp 5 (luồng 9) 107

6

Bảng 4.23 Kết quả phân tích trong lớp 6 (luồng 13) 108 Bảng 4.24 Kết quả phân tích tính khả kiểm thử theo Multi-Clue 108 Bảng 5.1 Xác suất của các chuyển tiếp của B01_AUTOMATON 133 Bảng 5.2 Khả năng thực thi của trạng thái B01_AUTOMATON 134 Bảng 5.3 Khả năng thực thi các chuỗi chuyển tiếp được kiểm thử 135 Bảng 5.4 Chi phí kiểm thử bao phủ trạng thái 136 Bảng 5.5 Chi phí kiểm thử bao phủ chuỗi chuyển tiếp 137

7

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

Hình 1.1 Kiểm chứng và hợp thức hóa trong mô hình phát triển V 14

Hình 2.5 Phân tích kết quả kiểm thử khi áp dụng Multi-Clue 51

Hình 2.7 Khả năng điều khiển và khả năng quan sát mô-đun 58 Hình 2.8 Kiến trúc tổng thể công cụ SATAN 62 Hình 2.9 Các xử lý chính của mô-đun In-Mac 63

Hình 3.2 Mô phỏng hoạt động mô hình trong Hình 3.1 72

Hình 3.4 Kết quả mô phỏng mô hình trong Hình 3.3 77

Hình 4.9 Thuật toán xử lý kết quả tính khả kiểm thử theo Start-Small 94

8

Hình 4.10 Minh họa kết quả tính khả kiểm thử theo Start-Small 95 Hình 4.11 Thuật toán xử lý kết quả tính khả kiểm thử theo Multi-Clue 96 Hình 4.12 Minh họa kết quả tính khả kiểm thử theo Multi-Clue 97 Hình 4.13 Mô hình SCICOS của hệ thống Pil-dem 98

Hình 4.15 Mô hình Simulink của hệ thống re_gy_2sw_anno 101 Hình 4.16 Cây xác định lỗi theo chiến lược Multi-Clue 104 Hình 4.17 Cây xác định lỗi theo chiến lược Multi-Clue 109

Hình 5.5 B01_AUTOMATON với chuyển tiếp T10 134

9

MỞ ĐẦU

Các hệ thống phần mềm được phát triển ngày càng phức tạp Sự phức tạp này còn cao hơn đối với các hệ thống điều khiển và các hệ thống nhúng trong các thiết bị công nghiệp, như máy bay, vệ tinh… Các hoạt động kiểm thử đóng vai trò rất quan trọng nhằm đảm bảo chất lượng của các hệ thống phần mềm Các hoạt động này phải được tính đến trong suốt tiến trình phát triển hệ thống phần mềm Tuy nhiên, các hoạt động kiểm thử thường có chi phí rất cao, thường chiếm đến 40% toàn bộ chi phí phát triển phần mềm Các hoạt động kiểm thử nhằm mục đích phân tích các thành phần và cấu trúc của phần mềm để xác định số lượng lớn nhất các lỗi trong tiến trình phát triển: từ đặc tả cho đến mã hóa

Đối với các hệ thống phần mềm phức tạp, nguồn tài nguyên cần thiết cho các hoạt động kiểm thử thường rất quan trọng Vì vậy, cần nghiên cứu các phương pháp giảm chi phí kiểm thử, nhưng vẫn đảm bảo hợp thức hóa hiệu quả phần mềm Khái niệm tính khả kiểm thử phần mềm (software testability)

đã được ra đời trong ngữ cảnh như thế Một cách đơn giản, tính khả kiểm thử thể hiện khó khăn trong kiểm thử phần mềm Nghiên cứu tính khả kiểm thử cho phép đánh giá chi phí của các hoạt động kiểm thử: một phần mềm có tính khả kiểm thử cao, thì nó càng dễ dàng được kiểm thử Như thế, một phần mềm có tính khả kiểm thử cao, yêu cầu chi phí cho kiểm thử ít hơn Tính khả kiểm thử là một trong những yếu tố chất lượng quan trọng, bởi vì nó nhằm

kế có chi phí thấp hơn rất nhiều so với chỉnh sửa ở mức cài đặt (lập trình) Mục tiêu của đề tài nhằm nghiên cứu tính khả kiểm thử của các phần mềm được phát triển chủ yếu cho các lĩnh vực công nghiệp, đặc biệt trong lĩnh vực hàng không Các ứng dụng thử nghiệm trong đề tài chủ yếu được cung cấp bởi các đối tác công nghiệp

Nghiên cứu về tính khả kiểm thử phần mềm đã và đang được thực hiện trong lĩnh vực phần cứng, cũng như phần mềm Trong đó, công cụ SATAN (System’s Automatic Testability ANalysis) đã được thiết kế và phát triển bởi phòng thí nghiệm LCIS (Laboratoire de Conception et d’Intégration de Systèmes), đã có nhiều ứng dụng trong phân tích tính khả kiểm thử phần mềm của các hệ thống phần mềm luồng dữ liệu được phát triển trong các môi trường như SCADE và GALA Trong khuôn khổ hợp tác với nhóm nghiên cứu của phòng thí nghiệm LCIS, chúng tôi nghiên cứu về công cụ SATAN và

đề xuất sự mở rộng ứng dụng của công cụ trong các môi trường phát triển phần mềm SCICOS và SIMULINK Phương pháp phân tích tính khả kiểm thử này gồm bốn hoạt động cơ bản:

− Xây dựng mô hình tính khả kiểm thử, nhằm biểu diễn luồng thông tin trong hệ thống phần mềm

11

− Tính toán các luồng thông tin dựa trên mô hình tính khả kiểm thử

− Áp dụng các chiến lược kiểm thử nhằm giảm số luồng thông tin

− Tính toán các độ đo tính khả kiểm thử

Hơn nữa, các hệ thống phần mềm có thể được thiết kế gồm hai phần: phần tính toán và phần điều khiển Phần tính toán thường được biểu diễn bởi

mô hình luồng dữ liệu Phần điều khiển thường được biểu diễn bởi các mô hình máy trạng thái hữu hạn, như STATEFLOW trong SIMULINK Sự mở rộng của công cụ SATAN chỉ cho phép phân tích tính khả kiểm thử của các

mô hình luồng dữ liệu trong các môi trường SCICOS và SIMULINK Trong nghiên cứu này, chúng tôi đề xuất phương pháp phân tích tính khả kiểm thử của các mô hình máy trạng thái hữu hạn

Báo cáo này được tổ chức gồm năm chương

Trong chương 1, chúng tôi trình bày vai trò, mục đích và các khái niệm

cơ bản của kiểm thử phần mềm và phân tích tính khả kiểm thử phần mềm Trong chương này, chúng tôi cũng trình bày tổng quan về các nghiên cứu trong lĩnh vực phân tích tính khả kiểm thử phần mềm Chúng tôi tổng hợp, phân loại và trình bày về các công trình nghiên cứu liên quan

Trong chương 2, chúng tôi tập trung vào việc nghiên cứu phương pháp phân tích tính khả kiểm thử được cài đặt bởi công cụ SATAN và tính năng kỹ thuật của công cụ SATAN, nhằm chuẩn bị cho việc mở rộng công cụ trong các môi trường phát triển phần mềm khác

Chương 3 giới thiệu về hai môi trường phát triển phần mềm SCICOS và SIMULINK

Trong chương 4, chúng tôi trình bày các mở rộng của công cụ SATAN nhằm có thể phân tích tính khả kiểm thử của các mô hình luồng dữ liệu được

12

thiết kế trên môi trường SCICOS và SIMULINK Chúng tôi cũng thực hiện một số thử nghiệm trên các ứng dụng cụ thể được cung cấp bởi các đối tác doanh nghiệp

Chương 5 trình bày đề xuất phương pháp phân tích tính khả kiểm thử của các mô hình máy trạng thái hữu hạn và kết quả thử nghiệm

ý nghĩa khác nhau

Các phân tích và đánh giá độ đo khả năng năng kiểm thử phụ thuộc chủ yếu vào thực thể phần mềm (một đơn vị, một kiến trúc phần mềm, một đặc tả…) và kỹ thuật kiểm thử Việc phân tích thực thể phần mềm có thể được dựa trên các mô tả khác nhau của phần mềm, như luồng điều khiển, luồng dữ liệu, đặc tả chức năng và thậm chí là mã nguồn

Các kỹ thuật kiểm thử được sử dụng phổ biến gồm kiểm thử cấu trúc và kiểm thử chức năng Phương pháp phân tích và đánh giá độ đo tính khả kiểm thử gắn liền với kiểm thử cấu trúc dựa trên cấu trúc bên trong của phần mềm,

nó thường mang lại nhiều thông tin chi tiết hơn so với phương pháp phân tích

và đánh giá độ đo tính khả kiểm thử gắn liền với kiểm thử chức năng chỉ dựa trên đặc tả chức năng

14

Trong chương này, trước khi trình bày các phương pháp phân tích tính khả kiểm thử, chúng tôi trình bày ngắn gọn về kiểm chứng, hợp thức hóa và kiểm thử phần mềm Sau đó, chúng tôi giới thiệu các định nghĩa khác nhau về tính khả kiểm thử phần mềm cũng như các phương pháp phân tích và đánh giá độ đo tính khả kiểm thử phần mềm

1.1.1 Kiểm chứng và hợp thức hóa

Chất lượng phần mềm ảnh hưởng bởi tất cả các hoạt động của tiến trình phát triển, tuy nhiên, nó đặc biệt liên quan đến hai hoạt động: kiểm chứng (verification) và hợp thức hóa (validation) (Hình 1.1)

Hình 1.1 Kiểm chứng và hợp thức hóa trong mô hình phát triển V

− Kiểm chứng cho phép thiết lập sự tương quan giữa phần mềm và đặc tả của nó Trong tiến trình phát triển, kiểm chứng đảm bảo rằng phần mềm sau mỗi giai đoạn phát triển đạt các điều kiện đặt

ra để chuyển sang giai đoạn tiếp theo

Đặc tả

Thiết kế tổng thể

Thiết kế chi tiết

Mã hóa

Kiểm thử đơn vị

Kiểm thử tích hợp

15

− Hợp thức hóa cho phép đảm bảo rằng thực hiện tốt các chức năng

mà nó được thiết kế, nghĩa là phần mềm đáp ứng được yêu cầu của người sử dụng Hợp thức hóa được thực hiện ở cuối tiến trình phát triển phần mềm

Chúng ta có thể phân biệt kiểm chứng và hợp thức hóa qua phát biểu như sau: chúng ta kiểm chứng rằng chúng ta đã “làm tốt” một phần mềm; chúng ta hợp thức hóa rằng chúng ta đã làm một “phần mềm tốt” Kiểm chứng và hợp thức hóa được thực hiện bởi việc sử dụng các kỹ thuật kiểm thử, các kỹ thuật thẩm định và các kỹ thuật chứng minh sự đúng đắn Trong khuôn khổ của đề tài này, chúng tôi quan tâm chủ yếu đến các kỹ thuật kiểm thử

1.2 Kiểm thử phần mềm

1.2.1 Khái niệm kiểm thử

Mục đích của kiểm thử là thực thi phần mềm nhằm phát hiện lỗi [2] Nhiều kỹ thuật kiểm thử đã được nghiên cứu và đề xuất, mỗi kỹ thuật nhằm mục đích phát hiện một số lớp các lỗi tương ứng với các mô hình lỗi khác nhau Cho dù bất kỳ kỹ thuật kiểm thử nào, thì nó thường cũng phải bao gồm các giai đoạn cơ bản sau: tạo ra các bộ dữ liệu thử; thực thi chương trình cần kiểm thử và quan sát kết quả của chương trình

Tất cả các kỹ thuật kiểm thử đều cần phải giải quyết vấn đề tạo ra dữ liệu thử và vấn đề quan sát kết quả Vấn đề quan sát kết quả còn được gọi là “vấn

đề phán xét kiểm thử” (test oracle) Vấn đề này thường được giải quyết bởi sự quan sát thủ công, nghĩa là bởi con người Tuy nhiên, giải pháp này không luôn được thỏa mãn Cần thiết xây dựng một công cụ tự động, tức là phán xét kiểm thử tự động, cho phép đánh giá hành vi của chương trình Như thế, một phán xét kiểm thử cần phải nhận biết tất cả các hành vi đúng đắn của chương

16

trình Việc xây dựng một phán xét kiểm thử như thế cũng khó khăn như chính việc xây dựng phần mềm cần kiểm thử Vấn đề thứ hai được đặt ra đối với các

kỹ thuật kiểm thử thường liên quan đến việc định nghĩa các tiêu chí thích

đáng (adequacy criteria) và tiêu chí lựa chọn (selection criteria) của các bộ dữ

liệu thử Các tiêu chí lựa chọn cho phép chọn các bộ dữ liệu thử nhằm phát hiện một số lớp lỗi của phần mềm, trong khi các tiêu chí thích đáng cho phép đánh giá chất lượng của một bộ dữ liệu thử

1.2.2 Các hoạt động kiểm thử

Kiểm thử được tích hợp hoàn toàn vào tiến trình phát triển phần mềm Trong tiến trình phát triển, các hoạt động kiểm thử phụ thuộc vào đối tượng cần kiểm thử (một mô-đun, một tập hợp các mô-đun…)

Nếu chúng ta muốn kiểm thử một cách độc lập các mô-đun cấu thành

phần mềm, chúng ta gọi là kiểm thử đơn vị (unit testing) Vai trò của kiểm thử

đơn vị nhằm kiểm thử mỗi mô-đun một cách riêng rẽ trong một môi trường hoàn toàn điều khiển được nhằm đảm bảo rằng mô-đun đó phù hợp với thiết

kế chi tiết của nó Các kiểm thử đơn vị là những hoạt động kiểm thử đầu tiên được thực hiện trong tiến trình phát triển

Khi chúng ta quan tâm đến việc tích hợp các mô-đun và sự tương tác

giữa chúng, chúng ta gọi là kiểm thử tích hợp (integration testing) Mục đích

của kiểm thử tích hợp nhằm đảm bảo rằng sự gắn kết giữa các mô-đun chặt chẽ và kết quả của sự tích hợp cho phép thực hiện thực hiện các chức năng được đặc tả

Trong tiến trình phát triển, kiểm thử hệ thống (system testing) là một giai

đoạn mà trong đó các kiểm thử được thực hiện nhằm cho người sử dụng thấy rằng phần mềm có thể triển khai ứng dụng trong thực tế Kiểm thử hệ thống nhằm hợp thức hóa các chức năng được nêu trong đặc tả yêu cầu Kiểm thử

giai đoạn kiểm thử này gọi là kiểm thử hồi quy (regression testing) Kiểm thử

hồi quy thường tái sử dụng các bộ dữ liệu thử đã sử dụng trong các giai đoạn trước nhằm đảm bảo rằng không có các lỗi mới được đưa vào

1.2.3 Các kỹ thuật kiểm thử

Kiểm thử nhằm phát hiện lỗi của phần mềm Vì vậy, lý tưởng nhất là thực thi phần mềm với mọi dữ liệu vào và quan sát kết quả nhận được Kỹ

thuật kiểm thử như thế được gọi là kiểm thử vét cạn (complete testing) Tuy

nhiên, trong thực tế, kiểm thử vét cạn là không khả thi, bởi vì, thông thường

số dữ liệu vào của một phần mềm là vô hạn Vì vậy, các kỹ thuật kiểm thử được nghiên cứu và đề xuất nhằm thiết kế số lượng dữ liệu thử ít nhất, nhưng

có khả năng phát hiện lỗi cao nhất Như thế, các kỹ thuật kiểm thử nhằm giảm chi phí về nguồn lực và thời gian thực hiện kiểm thử, nhưng lại có khả năng phát hiện lỗi hiệu quả

Hiện nay, có nhiều kỹ thuật kiểm thử khác nhau được nghiên cứu và phát triển Tuy nhiên, chúng ta có thể chia thành hai nhóm cơ bản: kiểm thử hộp đen và kiểm thử hộp trắng Kiểm thử hộp đen (black box testing) hay còn được gọi là kiểm thử chức năng (functional testing) là nhóm kỹ thuật được sử dụng phổ biến nhất để kiểm thử phần mềm Bởi vì, chúng cho phép trả lời trực tiếp quan tâm của kiểm thử viên là “kiểm tra xem phần mềm có thực hiện

18

đúng chức năng của nó” Mục tiêu của các kỹ thuật kiểm thử này là kiểm thử tất cả các điều kiện hoạt động của phần mềm như là nó được đặc tả Kiểm thử chức năng xem phần mềm là “hộp đen”, việc tạo ra dữ liệu thử chỉ dựa trên đặc tả chức năng của phần mềm Các kỹ thuật kiểm thử hộp đen phổ biến gồm: kiểm thử giá trị biên (boundary value testing), kiểm thử giá trị đặc biệt (special value testing), kiểm thử lớp tương đương (equivalence class testing),

kiểm thử dựa trên bảng quyết định (decision table based testing)… Kiểm thử

hộp trắng (white box testing) hay còn được gọi là kiểm thử cấu trúc (structural testing) dựa trên cấu trúc bên trong của phần mềm để tạo ra dữ liệu thử Mục tiêu của các kỹ thuật kiểm thử cấu trúc là bao phủ cấu trúc mã nguồn Sự bao phủ có thể dựa trên nhiều tiêu chí khác nhau, như phủ các lệnh, phủ các điều kiện, phủ các đường đi…

Chúng ta có thể nhận thấy rằng mục tiêu của các nhóm kỹ thuật kiểm thử

là khác nhau Việc sử dụng kỹ thuật nào là phụ thuộc vào yêu cầu về kiểm thử đối với phần mềm hay độ tin cậy của phần mềm Các kỹ thuật kiểm thử này

bổ sung lẫn nhau để phát hiện ra các loại lỗi khác nhau nhằm tạo ra phần mềm

có chất lượng tốt nhất có thể

1.3 Tính khả kiểm thử phần mềm

Như đã trình bày ở mục trên, kiểm thử là hoạt động quan trọng cho phép xác định lỗi của phần mềm Tuy nhiên, kiểm thử thường là hoạt động chi phí rất cao trong tiến trình phát triển phần mềm Như thế, một phương tiện cho phép đánh giá khó khăn của hoạt động kiểm thử hay hỗ trợ thiết kế nhằm làm

dễ dàng hoạt động kiểm thử sẽ rất có ý nghĩa: đó chính là khái niệm tính khả

kiểm thử phần mềm (software testability) hay phân tích tính khả kiểm thử

(testability analysis) Nói chung, phân tích tính khả kiểm thử nhằm định nghĩa các nguyên tắc thiết kế làm dễ dàng việc kiểm thử (testable design rules) và

19

các độ đo tính khả kiểm thử Trong các mục tiếp theo, chúng tôi sẽ giới thiệu các định nghĩa khác nhau về tính khả kiểm thử cũng như các phương pháp khác nhau về đánh giá tính khả kiểm thử được nghiên cứu gần đây

1.3.1 Định nghĩa tính khả kiểm thử phần mềm

Tính khả kiểm thử phần mềm có thể được định nghĩa nhiều cách khác nhau tùy theo ngữ cảnh, mục đích và các yếu tố mà dựa trên đó nó được nghiên cứu Tuy nhiên, tất cả các định nghĩa này đều hướng đến nghiên cứu

độ phức tạp của tiến trình kiểm thử Dưới đây, chúng tôi trích dẫn các định nghĩa khác nhau về tính khả kiểm thử theo thứ tự thời gian xuất hiện

Định nghĩa 1.1 Mohanty [3] định nghĩa tính khả kiểm thử như là độ đo

về chi phí cần thiết để kiểm thử một mô-đun hay một chương trình

Định nghĩa 1.2 Clure và Martin [4] định nghĩa tính khả kiểm thử là khả năng dễ dàng chứng minh chương trình đúng đắn

Định nghĩa 1.3 Theo tổ chức IEEE, tính khả kiểm thử là: (1) khả năng

dễ dàng thiết lập các tiêu chí kiểm thử một hệ thống hay một thành phần của một hệ thống và các quy tắc để kiểm tra các tiêu chí đó có được thỏa mãn và (2) khả năng dễ dàng biểu diễn các mục tiêu nếu các các tiêu chí đó được thỏa mãn [5]

Định nghĩa 1.4 Bache và Müllerburg [6] định nghĩa tính khả kiểm thử

là số ca kiểm thử tối thiểu cho một sự bao phủ kiểm thử với giả thiết sự bao phủ như thế là thực hiện được

Định nghĩa 1.5 Freedman [7] định nghĩa một thành phần phần mềm là

dễ dàng kiểm thử nếu nó có các tính chất sau: bộ dữ liệu thử nhỏ và dễ dàng được sinh ra; bộ dữ liệu thử không dư thừa; dễ dàng giải thích các kết quả kiểm thử; và các lỗi dễ dàng được định vị

20

Định nghĩa 1.6 Voas định nghĩa tính khả kiểm thử của một phần mềm

là sự dự đoán khả năng che dấu lỗi khi phần mềm được kiểm thử bởi một kỹ thuật kiểm thử hộp đen với các dữ liệu được tạo ra một cách ngẫu nhiên [8]

Định nghĩa 1.7 Petrenko và các đồng nghiệp [9] định nghĩa một phần mềm là dễ dàng kiểm thử, nếu phần mềm dễ dàng cho phép áp dụng nhiều phương pháp kiểm thử, xác định, định vị lỗi và sửa các lỗi đó

Định nghĩa 1.8 Voas và Miller [10] định nghĩa tính khả kiểm thử phần mềm như là khả năng quan sát hỏng hóc (failure) trong quá trình kiểm thử có

sự hiện diện lỗi

Định nghĩa 1.9 Bach [1] định nghĩa tính khả kiểm thử như là sự dễ dàng kiểm thử một chương trình

Định nghĩa 1.10 Bertolino và Strigini [11] định nghĩa tính khả kiểm thử một chương trình như là khả năng một kiểm thử bị loại bỏ bởi một phán xét kiểm thử (test oracle) với giả thiết rằng tồn tại một phán xét kiểm thử như thế

và chương trình chứa lỗi

Định nghĩa 1.11 Le Traon [12] định nghĩa tính khả kiểm thử là khả năng dễ dàng để kiểm thử phần mềm bằng cách áp dụng các chiến lược kiểm thử cấu trúc, sự dễ dàng kiểm thử là một tính chất của phần mềm và đồng thời

là một tính chất gắn liền với chiến lược kiểm thử được sử dụng

Định nghĩa 1.12 Jungmayr [13, 14] định nghĩa tính khả kiểm thử như là

sự dễ dàng kiểm thử một phần mềm trong một ngữ cảnh kiểm thử cho trước Ngữ cảnh kiểm thử gồm các ràng buộc kiểm thử (như ngân sách cho phép và chất lượng yêu cầu), sự sử dụng các thành phần phần mềm (như mục tiêu đặc biệt hay tái sử dụng), các tiêu chí kiểm thử áp dụng và công cụ kiểm thử được

sử dụng

và 1.11 [12] Bảng 1.1 phân loại các định nghĩa tính khả kiểm thử theo các hoạt động trong tiến trình phát triển mà các định nghĩa này liên quan

Bảng 1.1 Phân loại các định nghĩa tính khả kiểm thử

Định nghĩa Các hoạt động trong tiến trình phát triển

Thiết kế Mã hóa Kiểm thử

1.4 Các phương pháp phân tích tính khả kiểm thử phần mềm

Nhiều công trình nghiên cứu đã được thực hiện về các phương pháp phân tích tính khả kiểm thử phần mềm Hơn nữa, bởi vì tính khả kiểm thử có quan hệ chặt chẽ với độ phức tạp phần mềm, một số độ đo phức tạp cũng được xem như là các độ đo tính khả kiểm thử, như phương pháp của McCabe [15] hay phương pháp NPATH [16] Các phương pháp phân tích tính khả kiểm thử có thể được phân loại theo các tiêu chí khác nhau Một số nhà nghiên cứu gọi các phương pháp phân tích tĩnh và các phương pháp phân tích động Phân tích tĩnh được thực hiện bằng cách dựa trên các tính chất của phần mềm mà không thực thi phần mềm Trong khi phân tích động xem xét các tính chất của phần mềm khi nó được thực thi Các phương pháp phân tích tính khả kiểm thử cũng có thể được phân loại theo đối tượng mà dựa trên đó phân tích tính khả kiểm thử được thực hiện, như đặc tả, thiết kế, mã nguồn… Mỗi đối tượng có thể mang lại các thông tin khác nhau về phần mềm

Chúng ta có thể phân loại các phương pháp phân tích tính khả kiểm thử theo loại phần mềm Trước đây, phần lớn các phương pháp cho phép phân tích tính khả kiểm thử của các phần mềm được thiết kế và lập trình theo hướng chức năng và hướng có cấu trúc, chúng ta gọi là phương pháp phân tích tính khả kiểm thử truyền thống Gần đây, nhiều phương pháp hướng đến nghiên cứu tính khả kiểm thử của các phần mềm được phát triển theo hướng đối tượng, chúng ta gọi phương pháp phân tích tính khả kiểm thử hướng đối

kỹ thuật đánh giá tính khả kiểm thử Độ đo McCabe được sử dụng cho hai mục đích trong kiểm thử Thứ nhất, nó cho phép xác định số các bộ dữ liệu thử Thứ hai, nó được sử dụng trong các giai đoạn của tiến trình phát triển để bảo đảm phần mềm dễ kiểm thử, nghĩa là có tính khả kiểm thử cao

Đánh giá độ phức tạp của McCabe dựa hoàn toàn trên đồ thị luồng điều khiển Đồ thị luồng điều khiển mô tả cấu trúc lô-gic của một chương trình Mỗi đồ thị luồng điều khiển là một đồ thị có hướng gồm các nút và các cung Mỗi nút biểu diễn một khối lệnh tuần tự, mỗi cung biểu diễn một luồng điều khiển giữa các khối lệnh tuần tự Mỗi đồ thị luồng điều khiển được thêm vào một nút vào và một nút ra, tương ứng với điểm vào và điểm ra của chương trình Độ phức tạp của McCabe được định nghĩa cho một đơn vị phần mềm hay còn gọi là mô-đun, tức là một hàm hay thủ tục trong các ngôn ngữ lập

trình truyền thống Theo McCabe, độ phức tạp của một mô-đun là e - n + 2, trong đó e là số cung và n là số nút trong đồ thị luồng điều khiển biểu diễn

mô-đun Theo McCabe, độ phức tạp của một mô-đun là số các lộ trình độc lập (cyclomatic number) trong một đồ thị có hướng hoàn toàn liên thông (strongly connected directed graph) Đồ thị hoàn toàn liên thông là đồ thị mà mỗi nút đều có thể đến được (theo các cung có hướng) từ bất kỳ nút nào trong

24

đồ thị Số lộ trình độc lập trong một đồ thị liên thông hoàn toàn là e − n + 1

Đồ thị luồng điều khiển của một chương trình không là đồ thị liên thông hoàn toàn, tuy nhiên nó sẽ trở thành đồ thị liên thông hoàn toàn khi thêm một "cung ảo" nối nút ra đến nút vào Từ đó, số lộ trình độc lập của đồ thị luồng điều

khiển không chứa cung ảo là e − n + 2 Độ đo McCabe của một đồ thị G thường được ký hiệu bởi v(G)

v(G) = e − n + 2

McCabe chỉ ra rằng v(G) chính là số các lộ trình cơ bản trong đồ thị

luồng điều khiển Số lộ trình cơ bản là số lộ trình tối thiểu mà khi kết hợp chúng lại có thể tạo ra tất cả các lộ trình có thể của đồ thị Một điều thú vị của tập lộ trình cơ bản là bất kỳ một cung nào trong đồ thị luồng điều khiển đều thuộc ít nhất một lộ trình trong các lộ trình cơ bản Điều đó có nghĩa là khi thực thi tập lộ trình cơ bản thì sẽ thực thi tất cả các cung trong đồ thị luồng điều khiển Tuy nhiên, thông thường để bao phủ tất cả các cung thì số lộ trình cần thực thi ít hơn số lộ trình cơ bản Một mô-đun càng phức tạp càng tiềm ẩn khả năng chứa các rủi ro, càng khó hiểu và càng khó để kiểm thử, nghĩa là tính khả kiểm thử thấp Vì vậy, McCabe đề nghị chỉ nên xây dựng những mô-đun với độ phức tạp McCabe nhỏ hơn 10 với mục đích nâng cao tính khả kiểm thử của mô-đun

Phương pháp chèn xác nhận

Phương pháp chèn các xác nhận (assertion) khi thực thi mã nguồn là một trong những phương pháp cho phép định vị lỗi và đảm bảo mã nguồn thỏa mãn những ràng buộc xác định Các tác giả Yin và Bieman [18] đề xuất áp dụng kỹ thuật chèn xác nhận và xây dựng công cụ hỗ trợ cho ngôn ngữ lập trình C Các xác nhận được chèn vào để kiểm tra các ràng buộc trên dữ liệu hay trạng thái chương trình trong quá trình phát triển chương trình Các xác

25

nhận được xây dựng dựa trên đặc tả yêu cầu thay vì dựa trên mã nguồn Yin and Bieman xây dựng công cụ C-Patrol, là một bộ tiền xử lý cho phép chèn các xác nhận vào các vị trí xác định trong chương trình C Tuy nhiên, C-Patrol được thiết kế độc lập với ngôn ngữ lập trình C, nhằm có thể mở rộng được cho các ngôn ngữ lập trình khác Công cụ C-Patrol cho phép chèn các xác nhận dưới dạng các chú thích trong mã nguồn Vì vậy, các xác nhận được

bỏ qua bởi trình biên dịch và không ảnh hưởng đến hiệu năng của chương trình Công cụ cho phép ngưởi sử dụng chèn các xác nhận vào vị trí mong muốn hoặc cho phép chèn tự động các xác nhận trong chương trình Các xác nhận được chèn tự động sau tất cả các câu lệnh có thay đổi dữ liệu Phương pháp này được ứng dụng trong nhiều dự án công nghiệp, kết quả cho thấy nhiều lỗi được phát hiện, chất lượng mã nguồn tốt hơn [18]

Phương pháp PIE

Voas và các đồng tác giả [8, 19] cho rằng một chương trình có thể có lỗi khi các bước sau xảy ra: 1) Sai sót (trong chương trình) phải được thực thi (execution); 2) Trạng thái dữ liệu ngay sau đó (sau sai sót) phải bị ảnh hưởng (infection); 3) Lỗi trên trạng thái dữ liệu phải lan truyền (propagation) đến kết quả đầu ra

Như vậy, theo Voas và các đồng tác giả, mô hình lỗi gồm ba phần: thực thi (Execution), ảnh hưởng (Infection) và lan truyền (Propagation) đến đầu ra

Mô hình này chính là cơ sở của phương pháp PIE (Propagation – Infection – Execution) Phương pháp PIE phân tích ba phần này đối với mỗi vị trí trong chương trình nhằm đánh giá khả năng phát sinh lỗi: gồm phân tích sự thực thi, phân tích các ảnh hưởng và phân tích sự lan truyền Phương pháp PIE yêu cầu phải thực thi mã nguồn Các dữ liệu đầu vào được lựa chọn ngẫu nhiên từ miền dữ liệu vào Phân tích PIE là quá trình phân tích động, tuy nhiên nó

26

không phải là quá trình kiểm thử phần mềm vì không dữ liệu đầu ra nào được kiểm tra so với đặc tả Ba bước phân tích của phương pháp PIE có thể được thực hiện ở nhiều mức trừu tượng khác nhau: chương trình, mô-đun và câu lệnh

Sau khi thực hiện ba bước phân tích, chúng ta nhận được ba tập giá trị xác suất cho mỗi vị trí trong chương trình: xác suất một vị trí được thực thi; xác suất một đột biến tại một vị trí ảnh hưởng đến trạng thái dữ liệu; và xác suất khi một trạng thái dữ liệu bị ảnh hưởng, đầu ra của chương trình bị thay đổi Xác suất một chương trình gây lỗi là xác suất các dữ liệu vào ngẫu nhiên với một phân bố được xác định sẽ tạo ra lỗi Khi đó, xác suất một chương trình gây lỗi chính là tích của các giá trị xác suất thực thi, ảnh hưởng và lan truyền đối với lỗi đó Như vậy, phương pháp PIE tính toán xác suất gây lỗi của chương trình ứng với mỗi vị trí trong chương trình bằng cách tính xác suất thực thi, ảnh hưởng và lan truyền đối với vị trí đó Các giá trị xác suất gây lỗi của chương trình thể hiện tính khả kiểm thử của chương trình đó [8, 19]

Phương pháp biến đổi tính khả kiểm thử

Phương pháp biến đổi tính khả kiểm thử (testability transformation) [20] nghiên cứu cách chuyển đổi chương trình để làm cho nó dễ dàng tạo ra các dữ liệu thử hơn, nghĩa là nâng cao tính khả kiểm thử của chương trình

Phương pháp biến đổi tính khả kiểm thử biến đổi chương trình để dễ dàng tạo ra dữ liệu kiểm thử hiệu quả Tuy nhiên, khi biến đổi chương trình, thì cấu trúc của chương trình thay đổi Khi đó, các tiêu chí kiểm thử (testing criteria) dựa trên cấu trúc chương trình (đối với kiểm thử hộp trắng) cũng sẽ

bị thay đổi Vì vậy, kỹ thuật này không những chỉ biến đổi chương trình cần kiểm thử mà còn đồng thời biến đổi các tiêu chí kiểm thử tương ứng Các tiêu

27

chí kiểm thử có thể phủ tất cả các đỉnh, phủ tất cả các cung, phủ tất cả các đường đi Chương trình và các tiêu chí kiểm thử tương ứng bị biến đổi làm sao dễ dàng tạo ra được dữ liệu thử, sau đó dữ liệu thử được tạo ra sẽ được sử dụng để kiểm thử chương trình ban đầu (không bị biến đổi) ứng với tiêu chí kiểm thử ban đầu Các luật biến đổi chương trình C được các tác giả trình bày chi tiết trong [20]

Phương pháp khả năng điều khiển các phép gán

TDD (test-driven development) được xem là một trong những kỹ thuật phát triển các chương trình có tính khả kiểm thử tốt hơn Muller đề xuất khái

niệm khả năng điều khiển các phép gán (controllability of assignments) [21]

nhằm đánh giá tính khả kiểm thử của các chương trình có sử dụng TDD và không sử dụng TDD Theo tác giả, khả năng điều khiển đối với một chương trình là khả năng các tham số đầu vào của chương trình cung cấp đủ thông tin

để mô tả trạng thái và hành vi của chương trình Trong kỹ thuật này, tác giả chỉ tập trung vào việc phân tích các phép gán, bởi vì chúng là cách duy nhất thay đổi trạng thái của chương trình Độ đo khả năng điều khiển các phép gán được đề xuất cho mỗi hàm hay phương thức Để tính toán khả năng điều khiển các phép gán, ban đầu, tất cả các tham số của một phương thức được xem là hoàn toàn điều khiển được (controllable) Các thành phần này sẽ được

sử dụng để tính toán khả năng điều khiển các phép gán Bảng 1.2 đề xuất các luật để tính khả năng điều khiển của phép gán

Bảng 1.2 Các luật tính khả năng điều khiển các phép gán

Phép toán Khả năng điều khiển của kết quả

lhs := rhs Vế trái của phép gán là điều khiển được, nếu vế phải là điều

khiển được

exp 1⊕ exp 2 Kết quả của phép toán hai ngôi là điều khiển được, nếu cả hai

28

toán hạng exp 1 và exp 2 là điều khiển được

⊕ exp 1 Kết quả của phép toán một ngôi là điều khiển được, nếu toán

hạng exp 1 là điều khiển được

obj.foo(a, b) Kết quả của lời gọi hàm là điều khiển được nếu, obj và các

tham số a và b là điều khiển được

Khả năng điều khiển của một hàm hay phương thức m là tỷ lệ giữa số các phép gán điều khiển được và tổng số các phép gán Gọi AC (Assignment

Controllability) là độ đo khả năng điều khiển của phép gán:

AC (m) = số phép gán điều khiển được trong hàm m / tổng số phép gán trong hàm m

Khả năng điều khiển của phép gán của một chương trình hay một lớp là giá trị trung bình của các khả năng điều khiển của phép gán của các hàm của

nó Đối với một lớp hay một chương trình c gồm các hàm m i (i = 1 n), khả

năng điều khiển của phép gán được định nghĩa như sau:

∑

=

n

i m AC n c AC

1

) (

1 ) (

Muller đã áp dụng độ đo trên cho nhiều chương trình khác nhau để đánh giá tính khả kiểm thử Kết quả cho thấy các chương trình được phát triển sử dụng kỹ thuật TDD cho tính khả kiểm thử cao hơn so với các chương trình được phát triển không sử dụng kỹ thuật TDD [21]

Phân tích tính khả kiểm thử miền

Freedman [7] là một trong những nhà nghiên cứu đầu tiên đưa khái niệm tính khả kiểm thử vào lĩnh vực phần mềm Tác giả cho rằng tính khả kiểm thử

là các tính chất của một chương trình dễ dàng được kiểm thử Theo Freeman, một đơn vị phần mềm có tính khả kiểm thử cao cần có các tính chất: tập dữ liệu kiểm thử có kích thước nhỏ và dễ dàng được tạo ra; tập dữ liệu kiểm thử

29

không dư thừa; kết quả kiểm thử dễ dàng hiểu được; các lỗi dễ dàng định vị được

Freedman cho rằng nguyên nhân chính mà một đơn vị phần mềm không

dễ dàng được kiểm thử là do sự không nhất quán đầu vào và đầu ra output inconsitency) Sự không nhất quán đầu vào (input inconsitency) khi cùng một dữ liệu vào nhưng cho các kết quả ra khác nhau Sự không nhất quán đầu ra (output inconsitency) khi một dữ liệu đầu ra được đặc tả vượt quá miền giới hạn Sự không nhất quán đầu vào và đầu ra thường dẫn đến các tập

(input-dữ liệu quá lớn và dư thừa Các chương trình với sự không nhất quán đầu vào

và đầu ra gặp nhiều khó khăn khi kiểm thử Freedman đề xuất khái niệm tính khả kiểm thử miền (domain testability) Tính khả kiểm thử miền được định nghĩa dựa trên khả năng quan sát (observability) và khả năng điều khiển (controllability) Khả năng quan sát là khả năng xác định dữ liệu đầu vào tác động đến kết quả đầu ra Khả năng điều khiển là khả năng tạo ra kết quả đầu

ra từ dữ liệu đầu vào

− Một hàm có tính khả kiểm thử miền cao (domain testable), nếu nó

dễ dàng quan sát và dễ dàng điều khiển

Các hàm có tính khả kiểm thử miền thấp sẽ rất khó khăn khi kiểm thử Đối với các hàm này, cần có các chỉnh sửa nhằm nâng cao tính khả kiểm thử

Freedman định nghĩa: Tính khả kiểm thử miền (domain testability) là khả