Kiểm định phần mềm bằng kỹ thuật hộp đen.PDF

Kiểm định phần mềm là một quá trình liên tục, xuyên suốt mọi giai đoạn phát triển phần mềm để đảm bảo rằng phần mềm thoả mãn các yêu cầu thiết kế và các yêu cầu đó đáp ứng các nhu cầu c

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Trương Thị Thu Hà

KIỂM ĐỊNH PHẦN MỀM BẰNG KỸ THUẬT HỘP ĐEN

LUẬN VĂN THẠC SĨ

Hà nội - 2006

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Trương Thị Thu Hà

KIỂM ĐỊNH PHẦN MỀM BẰNG KỸ THUẬT HỘP ĐEN

Ngành: Công nghệ thông tin

Chuyên ngành: Công nghệ thông tin

MỤC LỤC

Trang

Lời cảm ơn Lời cam đoan Danh mục các bảng i

Danh mục các hình vẽ - sơ đồ ii

Mở đầu iv

CHƯƠNG 1: TỔNG QUAN KIỂM ĐỊNH PHẦN MỀM 1.1 Các mô hình phát triển phần mềm 1

1.2 Chất lượng phần mềm 6

1.3 Kiểm định phần mềm 12

CHƯƠNG 2: KỸ THUẬT VÀ CHIẾN LƯỢC KIỂM ĐỊNH PHẦN MỀM THEO TIẾP CẬN HỘP ĐEN 2.1 Kiểm định phần mềm bằng kỹ thuật hộp đen 20

2.2 Thiết kế các giai đoạn kiểm định phần mềm theo tiếp cận hộp đen 38

CHƯƠNG 3: XÂY DỰNG ỨNG DỤNG KIỂM ĐỊNH 3.1 Mục tiêu xây dựng kiểm định……… 53

3.2 Giới thiệu tổng quan phần mềm……… 55

3.3 Cài đặt và hướng dẫn sử dụng………………….56

3.4 Chương trình dùng để kiểm định……….62

KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN……… 81

TÀI LIỆU THAM KHẢO ……… …83

LỜI CAM ĐOAN

Tôi xin cam đoan :

1 Đây là công trình nghiên cứu của riêng tôi

2 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ả

Trương Thị Thu Hà

lời cảm ơn

Trong suốt quá trình học tập và thực hiện luận văn, em đã nhận đ-ợc sự h-ớng dẫn của quý Thầy Cô , cùng sự giúp đỡ động viên của bạn bè và gia đình

Em xin chân thành cảm ơn quý Thầy khoa Công nghệ thông tin, Tr-ờng

Đại học công nghệ - Đại học Quốc gia Hà nội cùng các Thầy Viện Công nghệ thông tin - Viện Khoa học và Công nghệ Việt nam đã tận tình giảng dạy và tạo

điều kiện thuận lợi cho em học tập và nghiên cứu trong thời gian học tập tại tr-ờng

Lời cảm ơn sâu sắc em xin dành cho Thầy giáo, pgs tskh Nguyễn Xuân Huy, Viện Công nghệ thông tin, Viện Khoa học và Công nghệ Việt nam Trong thời gian qua, Thầy đã tận tình h-ớng dẫn, chỉ bảo tận tình và truyền đạt những kiến thức quý báu giúp em thực hiện tốt luận văn này

Nhân dịp này, em cũng xin gửi lời cảm ơn đến bạn bè đồng nghiệp Nhất

là những ng-ời thân trong gia đình đã luôn bên cạnh động viên, giúp đỡ em trong suốt quá trình học tập

Hà nội ngày 22 tháng 11 năm 2006 Tr-ơng Thị Thu Hà

DANH MỤC CÁC BẢNG

Trang

Bảng 1.1 Tỷ lệ công việc các giai đoạn phát triển phần mềm 14

Bảng 2.1 Kiểm định theo các lớp phân hoạch hợp lệ điểm thi 27

Bảng 2.2 Kiểm định theo các lớp phân hoạch hợp lệ điểm thi 28

Bảng 2.3 Kiểm định theo các lớp phân hoạch hợp lệ điểm thi 28

Bảng 2.4 Kiểm định theo các lớp phân hoạch hợp lệ điểm thi 29

Bảng 2.5 Kiểm định theo các lớp phân hoạch hợp lệ điểm thi 29

Bảng 2.6 Kiểm định theo các lớp phân hoạch không hợp lệ điểm thi 30

Bảng 2.7 Kiểm định cho tất cả các lớp phân hoạch điểm thi 30

Bảng 2.8 Kiểm định cho tất cả các lớp phân hoạch điểm thi… 31

Bảng 2.9 Kiểm định cho tất cả các lớp phân hoạch điểm thi 31

Bảng 2.10 Bảng quyết định 35

Bảng 2.11 Quan hệ nhân quả thuế thu nhập 36

Bảng 2.12 Bảng quyết định tính thuế thu nhập 37

Bảng 2.13 Minh họa các testcase chương trình sắp xếp 52

Bảng 3.1 Testcase_Bai1 63

Bảng 3.2 Testcase_Bai2 66

Bảng 3.3 Testcase_Bai3 71

Bảng 3.4 Testcase_Bai4 77

DANH MỤC CÁC HÌNH VẼ - SƠ ĐỒ

Trang

Hình 1.1 Mô hình tuần tự tuyến tính 1

Hình 1.2 Mô hình làm bản mẫu 2

Hình 1.3 Mô hình RAD 3

Hình 1.4 Mô hình tăng dần 4

Hình 1.5 Một phần tử của mô hình tiến trình tương tranh 6

Hình 1.6 Chi phí cho việc sửa lỗi 10

Hình 1.7 Các giai đoạn kiểm định 16

Hình 1.8 Quy trình chi tiết quá trình kiểm định 17

Hình 1.9 Minh họa kiểm định hộp đen 17

Hình 2.1 Phân hoạch các lớp tương đương 22

Hình 2.2 Sơ đồ phân hoạch các lớp tương đương điểm thi 24

Hình 2.3 Sơ đồ phân hoạch các lớp tương đương theo giá trị biên tổng điểm 25

Hình 2.4 Sơ đồ phân tích giá trị biên cho tập số nguyên X, Y 34

Hình 2.5 Đồ thị nhân quả tính thuế thu nhập… 37

Hình 2.6 Chiến lược kiểm định … 39

Hình 2.7 Các bước kiểm định 39

Hình 2.8 Kiểm định đơn vị (a) và mội trường kiểm định đơn vị 43

Hình 2.9 Tích hợp Top - down …44

Hình 2.10 Tích hợp bottom - up 45

Hình 2.11 Sơ đồ tổng quát các giai đoạn kiểm định theo tiếp cận hộp đen …49

Hình 2.12 Chi tiết các giai đoạn kiểm định theo tiếp cận hộp đen …50

Hình 3.1 Cây thư mục lưu bài thi… 55

Hình 3.2 Các lớp chương trình kiểm định 56

Hình 3.3 Giao diện ban đầu 58

Hình 3.4 Giao diện nhập bài thi và Testcase 59

Hình 3.5 Giao diện danh sách thí sinh 59

Hình 3.6 Giao diện kết quả chấm thi 60

Hình 3.7 Giao diện kết quả chi tiết 61

Hình 3.8 Giao diện nhập thêm thí sinh 61

Hình 3.9 Giao diện nhập thêm Testcase 61

MỞ ĐẦU

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

Với việc phát triển nhanh chóng của ngành Công nghệ thông tin nói chung và Công nghệ phân mềm nói riêng Hàng triệu phần mềm đã ra đời nhằm đáp ứng nhu cầu của khách hàng Hơn thế nữa, các sản phẩm phần mềm còn giúp cho con người tiết kiệm tối đa công sức, thời gian, chi phí,… giúp cho công việc đạt hiệu quả cao hơn

Việc phát triển phần mềm cũng ngày càng được hỗ trợ bởi nhiều công cụ tiến tiến, giúp cho việc xây dựng phần mềm đỡ khó khăn và đáp ứng nhu cầu người dùng cao hơn Tuy nhiên, do độ phức tạp của phần mềm, cho nên dù các hoạt động đảm bảo chất lượng phần mềm nói chung và kiểm định nói riêng ngày càng chặt chẽ và khoa học, vẫn không đảm bảo được rằng các sản phầm phần mềm đang được ứng dụng không có lỗi Lỗi vẫn luôn tiềm ẩn trong mọi sản phẩm phần mềm và nhiều khi gây ra những thiệt hại nặng nề về tài chính cũng như ảnh hưởng đến công việc

Vì vậy, kiểm định phần mềm là một bước không thể thiếu của công nghệ phần

mềm bao gồm các bước: phân tích, thiết kế, mã hoá, kiểm định và bảo trì Kiểm định

phần mềm là một quá trình liên tục, xuyên suốt mọi giai đoạn phát triển phần mềm để đảm bảo rằng phần mềm thoả mãn các yêu cầu thiết kế và các yêu cầu đó đáp ứng các nhu cầu của người dùng

Các kỹ thuật kiểm định phần mềm đã, đang được nghiên cứu, và việc kiểm định phần mềm trở thành qui trình bắt buộc trong các dự án phát triển phần mềm trên thế giới Kiểm định phần mềm là một hoạt động rất tốn kém, mất thời gian, và khó phát hiện được hết lỗi Vì vậy, việc kiểm định phần mềm đòi hỏi phải có chiến lược phù hợp, một kế hoạch hợp lý và việc thực hiện được quản lí chặt chẽ

Ở Việt Nam, trong thời gian qua việc kiểm định phần mềm bị xem nhẹ, với công cụ lập trình hiện đại, người ta cảm tính cho rằng không kiểm định cũng không sao, nên chưa có nhiều sự quan tâm, nghiên cứu Những năm gần đây, một số tổ chức nghiên cứu và phát triển phần mềm đã bắt đầu có những quan tâm hơn đến vấn đề kiểm

định phần mềm Tuy nhiên, vấn đề kiểm định phần mềm hầu như vẫn chưa được đầu tư

và quan tâm đúng mức Nước ta đang trong quá trình xây dựng một ngành công nghiệp phần mềm thì không thể xem nhẹ việc kiểm định phần mềm vì xác suất thất bại sẽ rất cao, hơn nữa, hầu hết các công ty phần mềm có uy tín đều đặt ra yêu cầu nghiêm ngặt

là nếu một phần mềm không có tài liệu kiểm định đi kèm thì sẽ không được chấp nhận

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

- Luận văn tập trung nghiên cứu, tìm hiểu, đánh giá các nguyên lý, chiến lược và

kỹ thuật kiểm định phần mềm bằng kỹ thuật hộp đen

- Áp dụng kỹ thuật kiểm định hộp đen để xây dựng chương trình chấm thi học sinh giỏi Tin học

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

- Nghiên cứu, tìm hiểu các kỹ thuật, chiến lược kiểm định phần mềm theo kỹ thuật hộp đen

- Sử dụng phương pháp kiểm định hộp đen đã nghiên cứu để thiết kế bộ test cho chương trình cụ thể Đưa ra tài liệu kế hoạch kiểm định và đặc tả kiểm định; Xây dựng chương trình thực thi kiểm định

4 Kết quả nghiên cứu

- Thiết kế các trường hợp kiểm định theo kỹ thuật hộp đen cho một số chương trình cụ thể

- Tạo các tài liệu kiểm định (đặc tả trường hợp kiểm định và kết quả kiểm định.)

- Xây dựng chương trình kiểm định chấm bài thi học sinh giỏi Tin học

5 Ý nghĩa khoa học và thực tiễn của Luận văn

Việc thiết kế các giai đoạn kiểm định phần mềm theo tiếp cận hộp đen có thể được dùng làm tài liệu tham khảo cho việc kiểm định phần mềm tại một số công ty, cơ quan, trường học tại Việt nam

Định hướng người dùng hiểu tầm quan trọng của việc kiểm định phần mềm, để khái niệm này không còn mang tính lý thuyết mà sẽ là một phần không thể thiếu trong quá trình xây dựng và phát triển phần mềm

6 Chọn tên đề tài: “Kiểm định Phần Mềm Theo Kỹ Thuật Hộp Đen”

7 Bố cục của Luận văn: Nội dung của Luận văn chia thành 4 chương :

Chương 1: Tổng quan kiểm định phần mềm

Đề cập sơ lược các mô hình phát triển phần mềm, vấn đề chất lượng phần mềm

và tầm quan trọng của việc kiểm định phần mềm, các kỹ thuật kiểm định phần mềm hay sử dụng

Chương 2: Kỹ thuật và chiến lược kiểm định phần mềm theo tiếp cận hộp đen

Chương này trình bày các kỹ thuật cơ bản kiểm định phần mềm theo tiếp cận hộp đen như: xây dựng lớp phân hoạch tương đương, phân tích giá trị biên, kỹ thuật đồ thị nhân quả, kiểm định so sánh Để từ đó người đọc có những khái niệm cơ bản nhất

về kiểm định phần mềm theo kỹ thuật hộp đen

Phần tiếp theo của chương giới thiệu các chiến lược kiểm định phần mềm : kiểm định đơn vị, kiểm định tích hợp, kiểm định hợp lệ và kiểm định hệ thống

Nội dung chính của chương này là giúp người đọc có cái nhìn tổng quan khi xây dựng kiểm định phần mềm bằng kỹ thuật hộp đen theo các giai đoạn: thiết kế các trường hợp kiểm định, thiết kế giao diện và lập trình các trường hợp kiểm định, thực hiện các trường hợp kiểm định, kiểm tra và đánh giá kết quả

Chương 3: Xây Dựng Ứng Dụng Kiểm định

Để minh hoạ cho phần lý thuyết ở trên, chương 3 sẽ trình bày một chương trình

áp dụng kỹ thuật hộp đen để kiểm định bài thi của học sinh trong các kỳ thi học sinh giỏi Tin học:

- Xây dựng các test case cho từng bài thi

- Xây dựng chương trình và giao diện để: đọc vào bài thi của học sinh, thực hiện các bài thi đó với các testcase đã xây dựng, sau đó so sánh kết quả của bài thi và kết quả dự kiến của testcase Đưa ra đánh giá và cho điểm

- Tổng hợp điểm của từng bài thi để cho kết quả cuối cùng

Các nội dung chính trong chương 1 và 2 chủ yếu được trình bày lại qua quá trình đọc và nghiên cứu tài liệu của tác giả với những kiến thức đã được nhiều nhà khoa học công bố Trong đó phần đóng góp của tác giả là:

- Hệ thống hóa lại kiến thức theo cách tiếp cận kỹ thuật hộp đen

- Từ các chiến lược kiểm định phần mềm nói chung Tác giả áp dụng để

xây dựng các giai đoạn thiết kế kiểm định phần mềm theo kỹ thuật hộp đen

Toàn bộ nội dung chương 3 là kết quả của riêng tác giả với việc xây dựng phần mềm kiểm thử theo kỹ thuật hộp đen bằng cách thiết kế bộ testcase chấm thi học sinh giỏi Tin học Toàn quốc

CHƯƠNG 1 TỔNG QUAN KIỂM ĐỊNH PHẦN MỀM

Phần đầu của chương giới thiệu sơ lược một số mô hình cơ bản theo các quy trình phát triển phần mềm

Phần tiếp theo đánh giá chất lượng phần mềm qua một số tiêu chí có sẵn Từ đó phân tích lý do tại sao phải kiểm định phần mềm, và nhấn mạnh tầm quan trọng của kiểm định phần mềm trong quy trình phát triển của mỗi phần mềm nói riêng và nhận thức của những người làm phần mềm nói chung

1.1 CÁC MÔ HÌNH PHÁT TRIỂN PHẦN MỀM

1.1.1 Phần mềm là gì?

Phần mềm là một (bộ) chương trình được cài đặt trên máy tính nhằm thực hiện

một nhiệm vụ tương đối độc lập và phục vụ cho một ứng dụng cụ thể như việc quản lí hoạt động của máy tính hoặc áp dụng máy tính trong các hoạt động kinh tế, quốc phòng, văn hóa, giáo dục,

Việc tạo ra một sản phẩm phần mềm phải trải qua nhiều giai đoạn, người ta gọi

là qui trình phát triển phần mềm, bắt đầu từ khi có ý tưởng đến khi đưa ra sản phẩm phần mềm thực thi Khối lượng công việc trong từng giai đoạn của quá trình sản xuất phần mềm cũng thay đổi theo thời gian

1.1.2 Các mô hình phát triển phần mềm [5]

a Mô hình tuần tự tuyến tính

Mô hình tuần tự tuyến tính còn gọi là vòng đời cổ điển hay mô hình thác nước

Kỹ nghệ hệ thống/ thông tin

Hình 1.1 Mô hình tuần tự tuyến tính

Mô hình tuần tự tuyến tính bao gồm các hoạt động:

- Kỹ nghệ và mô hình hoá hệ thống thông tin: thiết lập yêu cầu cho mọi phần tử hệ thống và phân bổ một tập con các yêu cầu đó cho phần mềm

- Phân tích yêu cầu phần mềm: tiến trình thu thập yêu cầu phần mềm như chức năng, hiệu năng, giao diện,…lập tư liệu thông qua việc thăm dò khách hàng

- Thiết kế: là một tiến trình tập trung vào bốn bước chính: cấu trúc dữ liệu, kiến trúc phần mềm, biểu diễn giao diện và chi tiết thuật toán Tiến trình thiết kế mô tả các yêu cầu thành một biểu diễn phần mềm

- Sinh mã: Thiết kế phải được biên dịch sang ngôn ngữ máy

- Kiểm định: Việc kiểm định được thực hiện sau khi mã hoá, tiến hành kiểm định phần mềm để xem xét các chức năng có đúng đặc tả hay không? hoặc để làm lộ ra các lỗi và đảm bảo dữ liệu vào có cung cấp đúng dữ liệu ra muốn có?

- Hỗ trợ: Trong quá trình sử dụng phần mềm có thể có những thay đổi do khách quan hoặc chủ quan Vì vậy, việc bảo trì phần mềm phải áp dụng lại các bước vòng đời nói trên

Lắng nghe khách hàng

Xây dựng/điều chỉnh bản mẫu

Khách hàng sử dụng bản mẫu

Hình 1.2 Mô hình làm bản mẫu

- Mô hình hoá dữ liệu: các thông tin được làm mịn thành tập các dữ liệu, các đặc trưng của từng sự vật được nhận diện và mối quan hệ giữa chúng được xác định

- Mô hình hoá xử lý: dữ liệu được biến đổi để đạt tới luồng thông tin cần cho việc thực hiện chức năng nghiệp vụ Các mô tả xử lý được tạo ra để bổ sung, sửa đổi, xoá bỏ hay tìm kiếm sự vật dữ liệu

và quay vòng

Tổ #1

Mô hình hoá nghiệp vụ

Mô hình

dữ liệu

Mô hình

xử lý Sinh ứng dụng Kiểm định

và quay vòng

và quay vòng

- Sinh ứng dụng: RAD làm việc để dùng lại các cấu phần chương trình hiện có hay tạo

ra các cấu phần chương trình dùng lại được

- Kiểm định và quay vòng

d Mô hình tiến trình phần mềm tiến hoá

Phần mềm, giống như mọi hệ thống phức tạp khác, tiến hoá theo từng thời kỳ thời gian Các yêu cầu nghiệp vụ và sản phẩm thường thay đổi khi sự phát triển tiến hoá Vì vậy, người phát triển phần mềm cần một mô hình tiến trình đã được thiết kế tường minh để phù hợp với sản phẩm tiến hoá theo thời gian

Các mô hình tiến hoá mang tính lặp Chúng được đặc trưng theo cách thức tạo khả năng cho người phát triển phần mềm phát triển các phiên bản ngày một hoàn thiện

và phù hợp với thời gian

Kỹ nghệ hệ

thống/ thông tin

Chuyển giao tăng 4

Tăng 2

Chuyển giao tăng 1

Thiết kế Lập trình Kiểm định Vận hành

Phân tích

Thiết kế Lập trình Kiểm định Vận hành

Phân tích

Thiết kế Lập trình Kiểm định Vận hành

Chuyển giao tăng 2

Chuyển giao tăng 3 Tăng 3

Tăng 4

Sử dụng mô hình tăng dần: lần tăng đầu thường là sản phẩm lõi (các yêu cầu cơ bản) Sản phẩm lõi được khách hàng dùng và đánh giá và lập bản kế hoạch cho lần tăng tiếp theo Tiếp tục sửa đổi sản phẩm lõi dựa vào bản kế hoạch và chuyển giao các tính năng và chức năng phụ Tiến trình được lặp lại với việc chuyển giao từng phần cho đến khi sản phẩm hoàn chỉnh được tạo ra

f Mô hình xoáy ốc

Là mô hình tiến hoá cặp đôi bản chất lặp của mô hình bản mẫu với các khía cạnh hệ thống của mô hình trình tự tuyến tính Cung cấp tiềm năng cho việc phát triển nhanh các phiên bản tăng dần của phần mềm Trong mô hình xoáy ốc, phần mềm được phát triển thành từng chuỗi các lần đưa ra tăng dần

Mô hình xoáy ốc được chia thành sáu vùng nhiệm vụ sau đây:

- Trao đổi với khách hàng

g Mô hình phát triển tương tranh

Mô hình tiến trình tương tranh có thể được biểu diễn như một chuỗi các hoạt động kỹ thuật chính, các nhiệm vụ và trạng thái liên kết của chúng

Mô hình tiến trình tương tranh định nghĩa ra một loạt các biến cố làm nảy sinh việc chuyển trạng thái nọ sang trạng thái kia của hoạt động kỹ nghệ phần mềm Chẳng hạn, trong các giai đoạn đầu của thiết kế, sự không nhất quán trong mô hình phân tích được làm lộ ra Điều này sinh ra biến cố sửa mô hình phân tích chuyển hoạt động phân tích từ trạng thái đã làm sang trạng thái đợi thay đổi

1.2 CHẤT LƢỢNG PHẦN MỀM

1.2.1 Chất lƣợng phần mềm là gì?

Chất lượng trong phần mềm máy tính hiện vẫn còn là một vấn đề còn nhiều tranh luận Trong một số trường hợp, nói tới chất lượng phần mềm là nói tới tính thực tiễn và tính thẩm mỹ của phần mềm Ở đây, khái niệm này trả lời cho câu hỏi một chương trình máy tính thực thi một nhiệm vụ nào đó hiệu quả và có tính thẩm mỹ tới mức nào Trong một ngữ cảnh khác, chất lượng phần mềm được hiểu là sự đáp ứng đến mức tối đa các yêu cầu đặt ra và không chứa lỗi Trong cả hai trường hợp trên, có một loạt các vấn đề đặt ra cần giải quyết để đi đến một kết quả cuối cùng là phần mềm có chất lượng

Hiện nay, có rất nhiều định nghĩa khác nhau về lỗi phần mềm, nhưng tóm lại có

thể phát biểu một cách tổng quát như sau: “Lỗi phần mềm là sự không khớp nhau giữa

chương trình và đặc tả của nó”

Như vậy, chúng ta có thể thấy lỗi phần mềm xuất hiện dưới ba hình thức sau:

- Sai: Sản phẩm được xây dựng khác với đặc tả

- Thiếu: Một yêu cầu đã được đặc tả nhưng lại không có trong sản phẩm

- Thừa: Một yêu cầu được đưa vào sản phẩm mà không có trong đặc tả

Cũng có trường hợp yêu cầu có thể là một thuộc tính sẽ được người dùng chấp nhận nhưng khác với đặc tả nên vẫn được coi là có lỗi

Một hình thức khác cũng được coi là một dạng lỗi, đó là phần mềm khó hiểu,

khó sử dụng, chậm chễ hoặc dễ gây cảm nhận rằng phần mềm hoạt động không đúng

Nguyên nhân xuất hiện lỗi phần mềm

Suy nghĩ chung của nhiều người lỗi phần mềm là do lập trình Thực tế, lỗi xuất

hiện nhiều nhất không phải do lập trình Nhiều nghiên cứu đã được thực hiện trên các

dự án từ rất nhỏ tới rất lớn đều cho kết quả giống nhau Đó là số lỗi gây ra do đặc tả

chiếm phần lớn nhất, khoảng 80% Trong nhiều trường hợp, đặc tả không được viết ra

Các nguyên nhân khác có thể do đặc tả không đủ cẩn thận, hay thay đổi hoặc do chưa

có sự phối hợp tốt trong toàn nhóm phát triển Sự thay đổi yêu cầu của khách hàng

cũng là một nguyên nhân dễ gây ra lỗi phần mềm Khách hàng thường thay đổi yêu cầu

không mà cần quan tâm đến những tác động sau khi thay đổi yêu cầu như phải thiết kế

lại, lập lại kế hoạch, làm lại những việc đã hoàn thành Nếu có nhiều sự thay đổi, rất

khó nhận biết hết được phần nào của dự án phụ thuộc và phần nào không phụ thuộc

vào sự thay đổi Vì vậy, lỗi thường rất dễ phát sinh

Ta xét một ví dụ nhỏ về sự không cẩn thận trong đặc tả của bài toán phân số:

- Với việc đặc tả phi hình thức: Phân số là một cặp t/m, trong đó t là một số nguyên, m

là một số tự nhiên lớn hơn 0; t được gọi là tử số, m được gọi là mẫu số của phân số

- Đặc tả hình thức là đặc tả trong đó sử dụng các ký hiệu toán học để mô tả Một phân

số có thể được mô tả như sau:

nhất của hai số tự nhiên

Như vậy, đặc tả phép chia trên mâu thuẫn với đặc tả phân số (*) Chẳng hạn, khi

thực hiện chia hai phân số (1,3):(2,5) = (5,6), thì mẫu số trong trường hợp này lại là

Tiếp theo là lỗi do lập trình Ai cũng có thể mắc lỗi khi lập trình dù đó có là người giỏi hay kinh nghiệm tới mức nào Thời kỳ đầu của quá trình phát triển của ngành phần mềm, công việc lập trình còn rất nặng nhọc, do vậy lỗi do lập trình là chủ yếu Ngày nay, lập trình chỉ là một phần việc của quá trình phát triển phần mềm, cộng với sự hỗ trợ của nhiều công cụ lập trình cao cấp nên việc lập trình trở nên nhẹ nhàng hơn dù độ phức tạp của phần mềm lớn hơn rất nhiều Do đó, lỗi do lập trình gây ra cũng ít hơn

Tuy vậy, các yếu tố khiến lập trình tạo ra lỗi lại nhiều hơn Đó là độ phức tạp của phần mềm, tài liệu nghèo nàn, do đặc tả, thiết kế không hợp lý, sức ép thời gian, bộ

biên dịch phần mềm có lỗi hoặc chỉ đơn giản là những lỗi “không rõ nguyên nhân”

Chi phí cho việc sửa lỗi

Người ta ước tính, bảo trì là phần chi phí chính của phần mềm và kiểm định là hoạt động có chi phí đắt thứ hai, ước tính khoảng 40% của chi phí trong quá trình phát triển ban đầu của sản phẩm phần mềm Kiểm định cũng là phần chi phí chính của giai đoạn bảo trì do phải tiến hành kiểm định lại những thay đổi trong quá trình sửa lỗi và đáp ứng yêu cầu của người dùng

Kiểm định và sửa lỗi có thể được thực hiện tại bất kỳ giai đoạn nào của vòng đời phần mềm Tuy nhiên, chi phí cho việc tìm và sửa lỗi sẽ tăng đáng kể theo thời gian trong quá trình phát triển

Sự thay đổi một tài liệu yêu cầu khi duyệt lại lần đầu tiên là không đắt nếu không nói là không đáng kể Chi phí sẽ tăng lên nhiều hơn nếu các yêu cầu thay đổi được đưa ra sau khi đã lập trình Thay đổi lúc này đồng nghĩa với việc phải viết lại chương trình

Việc sửa lỗi sẽ không đáng kể nếu người lập trình tự phát hiện lỗi của mình, và không có sự liên quan đến chi phí khác Họ không phải giải thích lỗi cho bất kỳ người nào trong nhóm Họ cũng không phải nhập lại lỗi đó vào cơ sở dữ liệu lỗi và lưu vết lỗi Người kiểm định và người quản lý không phải duyệt lại tình trạng lỗi Và lỗi đó không ảnh hưởng đến công việc của người khác trong nhóm dự án

Nói chung, sửa một lỗi trước khi phát hành một phần mềm rẻ hơn rất nhiều so với việc khắc phục nó sau khi đã phát hành

Theo các nghiên cứu của IBM, GTE cho biết, lỗi được phát hiện càng muộn thì chi phí cho việc sửa lỗi càng lớn Chi phí tăng theo hàm mũ như sau:

Chúng ta từng chứng kiến sự cố máy tính Y2K năm 2000 Nguyên nhân là do việc tiết kiệm bộ nhớ bằng cách biểu diễn năm có 4 chữ số bằng 2 chữ số cuối của năm

mà không dự tính được lỗi tiềm ẩn có thể xảy ra mà mấy chục năm sau, thế giới đã phải lo sợ và tốn nhiều tỉ đô la để khắc phục do dữ liệu ngày tháng có thể bị thay đổi khi máy tính coi năm 1900 như năm 2000

1.2.3 Đánh giá chất lƣợng phần mềm

Chất lượng phần mềm có thể được đánh giá theo một số tiêu chí [6] sau:

 Tính dễ hiểu: Phần mềm có tính dễ hiểu phải có mục đích rõ ràng Mục

đích ở đây không đơn thuần chỉ là mục tiêu phần mềm cần đạt được mà hơn thế nữa, tất cả các thiết kế, các tài liệu hướng dẫn sử dụng phải được trình bày rõ ràng, dễ hiểu Một vấn đề đặt ra là cần trả lời câu hỏi rằng phần mềm được đặt trong ngữ cảnh người dùng nào, chẳng hạn như phần mềm dành cho người dùng bình thường thì cần dễ hiểu hơn phần mềm dành cho người sử dụng là các kỹ sư phần mềm

Ví dụ, đối với người dùng, sản phẩm phải có những yếu tố sau:

- Dễ thao tác

- Dễ học và dễ sử dụng

- Giao diện phải rõ ràng, dễ hiểu, dễ nhớ

 Tính hoàn chỉnh: Được đánh giá qua tập các chức năng của sản phẩm Tập các

chức năng nên thoả mãn các tính chất sau:

- Tính đối xứng: Nếu có thao tác phát sinh thì cũng có thao tác huỷ bỏ và ngược lại

- Tính tiêu chuẩn: Sản phẩm cần đạt một số tiêu chuẩn được thừa nhận trên thị

trường hoặc trong khoa học

 Tính khúc chiết: Yêu cầu đặt ra là không có các thông tin dư thừa Điều này

đặc biệt quan trọng khi bộ nhớ của hệ thống có giới hạn Vì vậy, việc giảm các dòng lệnh đến mức tối đa là cần thiết Tính khúc chiết có thể được nâng lên nhờ việc dùng chương trình con thay cho các chức năng được xử lí lặp đi lặp lại

 Tính tương thích: Phần mềm phải có khả năng hoạt động trơn tru, dễ dàng trên

nhiều nền tảng cấu hình máy tính khác nhau

 Tính nhất quán: Tất cả các ký hiệu, biểu tượng hay thuật ngữ trong chương

trình phải thống nhất

 Tính dễ bảo trì: Dễ dàng trong việc cập nhật để đáp ứng những yêu cầu mới

Vì vậy, để có được đặc tính này, phần mềm phải có những tài liệu hỗ trợ kỹ thuật đầy

đủ chi tiết mà không phức tạp Có thể thay đổi trong cấu trúc dữ liệu? Nếu một thiết kế dựa trên chức năng được sửa lại thì có yêu cầu cấu trúc lại cả chương trình chính hay chỉ một vài module

 Tính khả kiểm: Phần mềm cho phép dễ dàng xây dựng các tiêu chuẩn và

trường hợp đánh giá hoạt động của nó Đây là đặc tính gắn liền với giai đoạn thiết kế, cho phép việc kiểm định có dễ dàng không Một thiết kế quá phức tạp sẽ dẫn đến việc rất khó khăn trong kiểm tra, đánh giá phần mềm

 Tính tiện dụng: Điều này được thể hiện rất nhiều qua giao diện Người – Máy

Thành tố có ảnh hưởng lớn nhất đến đặc tính này của phần mềm chính là giao diện đồ

họa người dùng (Graphical User Interface)

 Tính tin cậy: Phần mềm thực hiện được những chức năng, nhiệm vụ như

mong đợi Yếu tố thời gian trong đặc tính này rất quan trọng, tức là phần mềm phải thực thi tốt các yêu cầu đặt ra trong một giới hạn thời gian nhất định nào đó Hơn nữa,

chương trình có tránh được các lỗi lặp vô hạn, kiểm tra lỗi dữ liệu đầu vào hay cung

cấp các điều khiển ngoại lệ khi xảy ra xung đột không?

Ngoài ra, sản phẩm có cơ chế bảo mật và bảo vệ các đối tượng do nó quản lý

hoặc phát sinh và bản thân sản phẩm cũng được đặt trong một cơ chế bảo mật nhằm

chống lại sự sao chép trộm hoặc làm biến dạng sản phẩm

 Tính khoa học: được thể hiện qua các mặt sau:

- Cấu trúc: Sản phẩm được chia thành các đơn vị cân đối, không trùng lặp về mặt

chức năng, các chức năng quan hệ với nhau và tổ hợp để có thể tạo thành chức năng

mới

- Nội dung: Các thuật toán dựa trên những thành tựu khoa học, có cơ sở và chặt chẽ

về tính khoa học

- Hình thức và thao tác: Tên của các lệnh phải hợp lý, thể hiện tính logic và phù hợp

với tư duy tự nhiên của con người

 Tính hiệu quả: Thể hiện qua các tiêu chuẩn sau:

- Hiệu quả kinh tế, giá trị thu được khi áp dụng sản phẩm

- Tốc độ xử lý của sản phẩm được tính bằng tỉ lệ giữa số lượng đối tượng xử lý và

tổng số đơn vị thời gian cần thiết để xử lý đối tượng trên

- Giới hạn tối đa của sản phẩm hoặc miền xác định của chương trình được xác

định thông qua đối tượng mà sản phẩm đó quản lý

- Dung lượng tối đa của miền nhớ trong mà chương trình sử dụng

Phần mềm thỏa mãn được mục đích đặt ra mà không làm lãng phí tài nguyên,

tức là tận dụng tối đa bộ nhớ và tốc độ của hệ thống

1.3 KIỂM ĐỊNH PHẦN MỀM

1.3.1 Kiểm định phần mềm là gì?

Như đã trình bày ở phần trước Một phần mềm dù lớn hay nhỏ đều có thể xuất hiện những lỗi nếu không được kiểm tra và giám sát chặt chẽ các quy trình, có các biện pháp sửa chữa khắc phục kịp thời tại các khâu đoạn

Với các lỗi xảy ra với phầm mềm, để phát hiện ra được thì chúng ta phải tổ chức kiểm định chúng Do đó, kiểm định phần mềm thường đồng nghĩa với việc tìm ra lỗi chưa được phát hiện Tuy nhiên, có nhiều bối cảnh kiểm định không bộc lộ ra lỗi Như

vậy, có thể khái quát rằng: kiểm định phần mềm là quá trình thực thi một hệ thống phần mềm để xác định xem phầm mềm đó có đúng với đặc tả hay không và thực hiện trong môi trường như mong đợi hay không?[6]

Có rất nhiều phương pháp kiểm định phần mềm Có những phương pháp tập

trung vào phân tích mã nguồn, như kỹ thuật kiểm định hộp trắng Có những phương

pháp đi sâu vào các dữ liệu vào và kết quả đầu ra của chương trình như mong muốn,

điển hình là kỹ thuật kiểm định hộp đen

Tuy nhiên trên thực tế, hệ thống đang thực hiện sẽ khác biệt so với việc duyệt lại mã nguồn Thông thường, người thực hiện sẽ thực hiện việc đọc lại và phân tích mã nguồn, xem xét mã nguồn và tạo các lưu đồ của chương trình với các nhánh mà mã nguồn có Chương trình với mã nguồn đó sẽ phải thực hiện được hay nói cách khác nó

là một hệ thống chạy được, bởi hệ thống không chạy được thì việc kiểm định sẽ rất mất thời gian và tiền bạc

Ngoài việc phân tích mã nguồn của chương trình ra, người thực hiện sẽ căn cứ vào các đặc tả , đặc tả chính là căn cứ chủ yếu cho việc kiểm định Các phần đặc tả chỉ quan tâm chủ yếu đến yếu tố vào ra chứ không tìm hiểu về cấu trúc và nội dung các thao tác cần thực hiện Mỗi chương trình được xem như một hộp đen – một bộ biến đổi

có cấu trúc thao tác bị che khuất Các đặc tả sẽ xác định những hành vi đúng và làm cho dễ dàng hơn trong việc xác định những hành vi không đúng Mỗi hành vi không đúng đó được hiểu chính là một lỗi phần mềm Từ những lỗi phần mềm phát hiện đó, người thực hiện sẽ căn cứ trên những hiểu biết của mình và mã nguồn của chương trình

để chẩn đoán nguyên nhân phát sinh lỗi, tìm ra các lỗi do lập trình hay mã nguồn xử lý

vấn đề sai lệch so với đặc tả được nêu ra và thậm chí sai lệnh so với kết quả mong muốn đạt được

Để giải quyết các vấn đề vướng mắc này trong kỹ thuật lập trình, các nhà tin học

lý thuyết đã đi sâu vào nghiên cứu tìm hiểu bản chất của ngôn ngữ, thuật toán và hoạt động lập trình và nâng nội dung của nó lên thành nguyên lý khoa học Cũng từ giai đoạn này, các công việc của quá trình kiểm định chương trình trên nhiều góc độ trước khi đi vào ứng dụng được chú ý nhiều và chiếm tỷ lệ rất lớn về thời gian và tiền bạc trong việc tạo ra chương trình (15% trên tổng số chi phí của vòng đời sản phẩm)

Bảng 1.1 Tỷ lệ công việc các giai đoạn phát triển phần mềm

Giai đoạn

Phân tích yêu cầu

Thiết

kế sơ

bộ

Thiết kế chi tiết

Lập trình và kiểm định đơn vị

Tích hợp và kiểm định tích hợp

Kiểm định

hệ thống

1.3.2 Tại sao phải kiểm định

Như đã trình bày ở trên, một phần mềm sau khi sản xuất ra do nhiều yếu tố có thể dẫn đến việc sai so với đặc tả ban đầu, lỗi trong thiết kế và viết mã của bản thân chương trình Các chương trình đó sau khi được thiết kế và được bán cho người sử dụng sẽ khiến việc bảo hành rất mất thời gian, tiền bạc và sức lực, nếu nghiêm trọng sẽ phá hủy nhiều thứ liên quan khi áp dụng Đây chính là những vấn đề về chất lượng phần mềm

Kiểm định sẽ giúp phát hiện ra những lỗi sai sót so với đặc tả, phát hiện được những lỗi hay mắc phải hoặc chưa từng được phát hiện Một cuộc kiểm định thành công chính là việc xác định những lỗi mà chưa từng được phát hiện

Việc phát hiện lỗi và tạo điều kiện để khắc phục sẽ làm chất lượng phần mềm nâng cao, các chi phí cho quá trình bảo dưỡng giảm xuống nhiều, các phần mềm sẽ trở nên hiệu quả hơn

Một chương trình dù lớn hay nhỏ đều qua các công đoạn khác nhau để tạo ra được nó Các phần mềm càng lớn thì đặc tả của nó càng nhiều, việc mắc lỗi trong quá trình xây dựng là không thể tránh khỏi Quá trình kiểm định tại giai đoạn cuối sẽ tìm ra sai sót và tạo điều kiện để hoàn thiện hơn chương trình

Kiểm định chương trình còn đóng vai trò rất lớn trong công tác giáo dục Ví dụ như trong các cuộc thi Tin học, hội đồng chấm thi phải mất rất nhiều thời gian để kiểm tra lại chương trình và chấm bài Các bài này đều phải được kiểm tra chặt chẽ, nếu không có các nguyên tắc và phương pháp kiểm tra và thử nghiệm thì việc chấm thi sẽ trở lên rất khó khăn trong việc xây dựng các Testcase chuẩn để kiểm tra được hết các đặc tả của bài đề ra

1.3.3 Quy trình kiểm định

Mục đích của cuộc kiểm định chính là thiết kế được một chuỗi các trường hợp kiểm định mà có khả năng phát hiện lỗi cao Chuỗi các trường hợp kiểm định đó sẽ rà soát hết tất cả các trường hợp có thể xử lý của chương trình so với đặc tả ban đầu Báo cáo kiểm định sẽ thống kê hết tất cả các trường hợp kiểm định đã chạy, những lỗi đã phát hiện trong kiểm định, chi tiết các dữ liệu đầu vào, các luồng dữ liệu, đầu ra mong đợi của chương trình (đây chính là kết quả đúng của chương trình), kết quả thực tế cho

ra của chương trình và mục đích kiểm định…Muốn có được các dữ liệu đầu vào hợp lý

và có khả năng phát hiện lỗi cao như vậy thì cần phải thông qua một kế hoạch và giai đoạn chuẩn bị hợp lý nhằm thiết kế các Testcase, các dữ liệu cho các trường hợp kiểm định Các giai đoạn kiểm định này có thể được mô tả qua hình vẽ sau:

Như vậy mô hình chi tiết quá trình kiểm định như sau:

SP

Báo cáo kiểm định

Kế hoạch kiểm định

Kiểm định

Phân tích Thiết kế

Chạy chương trình với dữ liệu kiểm định

So sánh các kết quả với các trường hợp kiểm định

Các trường hợp kiểm định

Dữ liệu kiểm định

Kết quả kiểm định

Báo cáo kết quả cuối cùng

1.3.4 Các phương pháp kiểm định phần mềm

a Phương pháp kiểm định hộp đen

Kỹ thuật kiểm định hộp đen còn gọi là kiểm định vào ra, chỉ tập trung vào các yêu cầu chức năng của phần mềm

Người kiểm định xem phần mềm như là một hộp đen không thể nhìn thấy vào bên trong xem nó hoạt động như thế nào Do đó, sẽ không quan tâm nhiều đến cấu trúc bên trong của phần mềm mà cần quan tâm đến miền thông tin, cho nhập các giá trị đầu vào, thực thi chương trình và xem xét các kết quả đầu ra tương ứng có phù hợp với kết quả mong đợi hay không?

Trong kiểm định hộp đen, người kiểm định chỉ biết phần mềm dự kiến thực hiện

và những gì dự kiến không thực hiện Căn cứ vào đặc tả, người kiểm định xây dựng các nhóm giá trị đầu vào cho tất cả các yêu cầu chức năng của chương trình

Để tìm tất cả các lỗi trong chương trình thì điều kiện bắt buộc là phải kiểm định tất cả các giá trị đầu vào Điều này thực tế là không tể thực hiện được Tuy nhiên, nếu

số lượng và sự đa dạng của các giá trị đầu vào và số lượng kiểm định đạt đến cũng có thể kết luận rằng: “Phần mềm có thể chấp nhận được”

Kiểm định hộp đen nhằm tìm ra các loại sai [4], đó là:

- Chức năng thiếu hoặc chức năng không đúng đắn

- Sai về giao diện

- Sai trong cấu trúc hoặc trong truy cập dữ liệu ngoài

- Sai trong thực thi

- Sai khởi đầu hoặc kết thúc

ra

Hình 1.9 Minh họa kiểm định hộp đen

Kiểm định hộp đen tập trung để trả lời các câu hỏi sau đây:

- Hiệu lực chức năng được kiểm định đến đâu?

- Lớp đầu vào nào làm cho các ca kiểm định tốt?

- Sự nhảy cảm đối với một vài giá trị vào nào?

- Các biên của lớp dữ liệu đã được cô lập như thế nào?

- Khả năng dung thứ lỗi đối với các nhịp điệu và khối lượng dữ liệu như thế nào?

- Những tổ hợp dữ liệu đặc biệt ảnh hưởng gì đến hoạt động hệ thống

Khi áp dụng các kỹ thuật kiểm định hộp đen, cần tìm ra được các ca kiểm định thoả mãn các tiêu chuẩn sau:

Hộp Trắng ở đây chính là hộp trong suốt Chính vì vậy, kỹ thuật kiểm định này còn có một số tên khác là kiểm định hộp thủy tinh (Glass-Box Testing), hay kiểm định hộp trong suốt (Clear-Box Testing) Người kiểm định truy nhập vào mã nguồn chương trình và có thể kiểm tra nó, lấy đó làm cơ sở để hỗ trợ việc kiểm định (có nghĩa là người kiểm định có thể nhìn thấy bên trong hộp) Dựa vào những gì thấy được, người kiểm định có thể xác định được các số liệu cụ thể và hướng việc kiểm định theo những thông tin đó

Kiểm định hộp trắng sẽ đi vào kiểm định các đường dẫn lệnh trong chương trình Trong một chương trình thông thường sẽ có nhiều đường dẫn lệnh của nhiều lưu trình điều khiển khác nhau Nhiệm vụ của kiểm định chính là kiểm định toàn bộ lưu trình và đường dẫn lệnh này, khi kiểm định được hết thì có thể khẳng định là chương

trình đã được kiểm định

Nguyên tắc kiểm định hộp trắng:

- Thực hiện tất cả các đường dẫn độc lập ít nhất một lần

- Thực hiện mọi điều kiện logic (if then else) trên các giá trị có thể True hoặc

False của chúng

- Thực hiện mọi vòng lặp (các vòng lặp for, while do, repeat until) tại các

biên và trong phạm vi hoạt động của chúng

- Thực hiện mọi cấu trúc dữ liệu bên trong để đảm bảo tính hợp lệ của chúng

CHƯƠNG 2

KỸ THUẬT VÀ CHIẾN LƯỢC KIỂM ĐỊNH PHẦN

MỀM THEO TIẾP CẬN HỘP ĐEN

2.1 KIỂM ĐỊNH PHẦN MỀM BẰNG KỸ THUẬT HỘP ĐEN

2.1.1 Nguyên tắc kiểm thử hộp đen

Trong kỹ thuật kiểm định “hộp đen”, người kiểm định coi phần mềm như một

hộp đen Tức là người kiểm định hoàn toàn không quan tâm đến cấu trúc và hoạt động bên trong của phần mềm Người kiểm định chỉ cần quan tâm đến việc tìm các hiện tượng mà phần mềm không thực thi theo đúng đặc tả của nó (dựa trên đặc tả yêu cầu, người kiểm định chỉ biết những gì phần mềm dự kiến thực hiện và tìm ra những gì chưa thực hiện mà không thể nhìn vào bên trong xem nó hoạt động như thế nào) Vì vậy, dữ liệu kiểm định hộp đen dựa trên cơ sở đặc tả

Như vậy, cách tiếp cận kiểm định hộp đen tập trung vào các yêu cầu chức năng của phần mềm Kiểm định hộp đen cho phép các kỹ sư kiểm định xây dựng các nhóm giá trị đầu vào có khả năng thực thi đầy đủ các yêu cầu chức năng của chương trình Trên thực tế, trong các hãng phần mềm thường có các nhóm thực hiện công việc thiết

kế và các nhóm kiểm định độc lập với nhau Tuy vậy, kiểm định hộp đen không thay thế kỹ thuật kiểm định hộp trắng, nhưng nó bổ sung khả năng phát hiện các lớp lỗi khác với phương pháp hộp trắng để đạt được mục đích chung cuối cùng là phần mềm hạn chế tối đa số lỗi

Không giống kiểm định hộp trắng được thực hiện sớm trong quá trình kiểm định, kiểm định hộp đen được áp dụng trong các giai đoạn sau của qui trình kiểm định phần mềm Vì kiểm định hộp đen không nhằm mục đích kiểm tra cấu trúc bên trong của cấu trúc điều khiển mà sự quan tâm tập trung vào miền thông tin Kiểm định hộp đen cũng không thể tìm tất cả các lỗi trong chương trình vì để có thể phát hiện được tất

cả các lỗi thì điều kiện bắt buộc là phải kiểm định tất cả các giá trị đầu vào Tức là mỗi điều kiện đầu vào đều cần một trường hợp kiểm định Vì nếu chỉ kiểm định một số điều kiện đầu vào thì không đảm bảo được chương trình đã hết lỗi Tuy nhiên, trên thực tế điều này là không thể thực hiện được

Vì vậy, một số kỹ thuật kiểm định hộp đen được đề xuất [6, 7, 17, 19] để có thể kiểm định phần mềm một cách hiệu quả nhất mà không phải duyệt hết tất cả các điều kiện đầu vào

2.1.2 Một số kỹ thuật kiểm định hộp đen

a Phân hoạch tương đương

Việc kiểm định tất cả các đầu vào của chương trình là không thể Vì thế, khi kiểm định chương trình nên giới hạn một tập con tất cả các trường hợp đầu vào có thể

có Tất nhiên, người ta mong muốn lựa chọn một tập con đúng hay nói cách khác là một tập con có xác suất cao nhất phát hiện hầu hết các lỗi

Một tập con như vậy cần có hai tính chất:

- Mỗi trường hợp kiểm định nên gồm nhiều điều kiện đầu vào khác nhau có thể

để giảm thiểu tổng số các trường hợp cần thiết

- Nên cố gắng phân hoạch các miền đầu vào của một chương trình thành một số xác định các lớp tương đương, sao cho có thể giả định hợp lý rằng việc kiểm định một giá trị đại diện của mỗi lớp là tương đương với việc kiểm định một giá trị bất kỳ trong cùng lớp đó (tuy điều này không đảm bảo tuyệt đối) Có nghĩa, nếu một trường hợp kiểm định trong một lớp tương đương phát hiện ra lỗi, thì tất cả các trường hợp khác trong lớp tương đương cũng sẽ phát hiện ra cùng lỗi

đó Ngược lại, nếu một trường hợp kiểm định không phát hiện ra một lỗi, thì không có trường hợp nào khác trong lớp tương đương đó phát hiện ra lỗi (trừ khi một tập con của lớp tương đương nằm trong một lớp tương đương khác, vì các lớp tương đương có thể gối lên nhau)

Hai vấn đề xem xét ở trên tạo thành một phương pháp của kỹ thuật hộp đen và được gọi là phân hoạch tương đương Vấn đề thứ hai được sử dụng để phát triển một tập các điều kiện cần quan tâm phải được kiểm định Vấn đề thứ nhất được sử dụng để phát triển một tập cực tiểu các trường hợp kiểm định phủ các điều kiện trên

Thiết kế trường hợp kiểm định bằng phân hoạch tương đương được xử lý theo hai bước:

Bước 1: Phân hoạch các miền giá trị đầu vào thành các lớp tương đương

Buớc 2: Thiết kế các trường hợp kiểm định đại diện cho mỗi lớp

Phân hoạch thành các lớp tương đương:

Các lớp tương đương được nhận dạng bằng cách lấy mỗi điều kiện đầu vào và phân hoạch thành hai hoặc nhiều nhóm Các lớp tương đương biểu diễn một tập các trạng thái hợp lệ hoặc không hợp lệ cho điều kiện đầu vào Điều kiện đầu vào là giá trị

số xác định, miền giá trị, tập giá trị có liên quan, hoặc điều kiện logic

Các lớp tương đương có thể được phát biểu thành các quy tắc sau: 1) Nếu điều kiện vào xác định một miền giá trị, thì phân hoạch thành một lớp tương

Hình 2.1 Phân hoạch các lớp tuơng đương

Dữ liệu vào hợp lệ Dữ liệu vào không hợp lệ

Hệ thống

Kết quả

đương hợp lệ và hai lớp tương đương không hợp lệ Ví dụ, nếu đầu vào x nằm trong khoảng [0,100] thì lớp hợp lệ là 0 ≤ x ≤ 100, các lớp không hợp lệ là x < 0 và x > 100

2) Nếu điều kiện vào yêu cầu một giá trị xác định, phân hoạch thành một lớp tương

hợp lệ và hai lớp tương đương không hợp lệ Chẳng hạn, nếu đầu vào x = 0 thì lớp hợp

lệ là x = 0, còn các lớp không hợp lệ là x < 0 và x > 0

3) Nếu điều kiện đầu vào xác định một phần tử của tập hợp thì phân hoạch thành một lớp tương đương hợp lệ và một lớp tương đương không hợp lệ Chẳng hạn, nếu

đầu vào x thuộc tập các giá trị màu sắc trong bảy sắc cầu vồng: Colors = {“Red”,

“Orange”, , “Violet”}, thì lớp tương đương hợp lệ là x  Colors và lớp tương đương

không hợp lệ là x  Colors

4) Nếu điều kiện đầu vào là một biến hoặc một biểu thức logic, thì phân hoạch thành một lớp tương đương hợp lệ và một lớp tương đương không hợp lệ tương ứng với hai trang thái đúng và sai của biểu thức hoặc biến logic

Ví dụ: Xét chương trình “Sắp xếp lớp” dựa trên các đặc tả sau:

Chương trình nhận vào điểm thi (ĐT) (<75) và điểm trung bình môn (ĐTBM)

(<25), dựa vào các dữ liệu đó, nó sẽ tính toán và xếp lớp theo các lớp từ A đến D Việc

xếp lớp được tính toán dựa trên điểm trung bình chung = tổng điểm thi và điểm trung bình môn theo cách tính như sau:

- Điểm 70: lớp A

- 50 ≤ Điểm < 70: lớp B

- 30 ≤ Điểm < 50: lớp C

- Điểm < 30: lớp D

Nếu điểm nằm ngoài các khoảng trên thì sinh ra một thông báo lỗi Tất cả các

dữ liệu nhập vào đều là số nguyên

Ban đầu, ta cần xác định các phân hoạch tương đương, sau đó xây dựng các trường hợp kiểm định dựa trên các phân hoạch đó Các phân hoạch được xác định từ cả

dữ liệu vào và dữ liệu ra của chương trình Các dữ liệu hợp lệ và không hợp lệ đều được xét

Trước hết, ta xác định các phân hoạch cho dữ liệu vào:

* Các lớp tương đương hợp lệ:

0 ≤ điểm thi ≤ 75

0 ≤ điểm trung bình môn ≤ 25

* Các lớp tương đương không hợp lệ:

Điểm thi > 75 Điểm thi < 0 Điểm trung bình môn > 25 Điểm trung bình môn < 0

Như vậy, phân hoạch của dữ liệu vào điểm thi (ĐT) có thể được biểu diễn theo

Vì vậy, ta có thêm phân hoạch tương đương cho dữ liệu vào không hợp lệ:

Điểm thi = số thực Điểm thi = ký tự khác số Điểm trung bình = số thực Điểm trung bình = ký tự khác số Tiếp theo là việc xác định các phân hoạch cho dữ liệu ra:

Phân hoạch hợp lệ được tạo ra bằng cách tính toán từng dữ liệu ra hợp lệ cho mỗi thành phần:

Kết quả: lớp “A” được tạo ra khi 70 ≤ tổng điểm ≤ 100

“B” được tạo ra khi 50 ≤ tổng điểm < 70 “C” được tạo ra khi 30 ≤ tổng điểm < 50 “D” được tạo ra khi 0 ≤ tổng điểm < 30

“Thông báo lỗi” được tạo ra khi tổng điểm > 100

được tạo ra khi tổng điểm < 0 Các phân hoạch tương đương trên và dưới giá trị biên được thể hiện theo sơ đồ sau:

Một dữ liệu ra không hợp lệ là bất kỳ dữ liệu ra nào không nằm trong 5 giá trị

trên (“A”, “B”, “C”, “D”, “không hợp lệ”) Thực ra, việc xác định các dữ liệu ra không

Hình 2.3 Sơ đồ phân hoạch các lớp tương đương theo giá trị biên tổng điểm

Giá trị biên Giá trị biên Giá trị biên

Giá trị biên Giá trị biên Giá trị biên

rõ ràng là rất khó khăn Nhưng chúng cần được xem xét kỹ để nhận ra lỗi có thể có ở

cả trong chương trình và trong đặc tả Dưới đây là 3 ví dụ về dữ liệu ra không rõ ràng Việc phân hoạch như thế này mang tính khá chủ quan và khác nhau với mỗi người kiểm định vì họ có cảm nhận và phán đoán không giống nhau

Phân hoạch 7: ĐT = real number

Phân hoạch 8: ĐT = alphabetic

Phân hoạch 9: ĐTBM= real number

Phân hoạch 10: ĐTBM= alphabetic

Phân hoạch 16: TĐ < 0

Phân hoạch 17: output = 'E'

Phân hoạch 18: output = 'A+'

Phân hoạch 19: output = 'null'

Sau khi đã xác định được các phân hoạch, ta tiến hành xây dựng các trường hợp

kiểm định cho chúng Có hai cách xây dựng: Mỗi phân hoạch có một trường hợp kiểm

định hoặc xây dựng một bộ trường hợp kiểm định cho tất cả các phân hoạch

Cách thứ nhất: Mỗi phân hoạch có một trường hợp kiểm định

Các trường hợp kiểm định cho phân hoạch điểm thi nhập vào là:

Phân hoạch được thử

(đối với điểm thi nhập vào) 0≤ĐT≤75 ĐT < 0 ĐT > 75

Kết quả dự kiến lớp “B” “Thông báo lỗi” “Thông báo lỗi”

Chú ý: Trong bảng trên, việc kiểm định tập trung vào giá trị điểm thi nhập vào nên

“Điểm trung bình môn” được cho một giá trị tùy ý, cố định là 15

Các trường hợp kiểm định cho phân hoạch điểm trung bình môn nhập vào là:

Bảng 2.1 Kiểm định theo các lớp phân hoạch hợp lệ điểm thi

Chú ý: Dữ liệu “Điểm thi” được cho tùy ý, cố định = 40

Các trường hợp kiểm định cho phân hoạch dữ liệu nhập vào không hợp lệ:

Phân hoạch được thử

(đối với điểm trung bình môn) 0≤ĐTBM≤25 ĐTBM < 0 ĐTBM > 25 Kết quả dự kiến lớp “C” “Thông báo lỗi” “Thông báo lỗi”

ĐTBM = số thực ĐTBM = số thực Kết quả dự

kiến “Thông báo lỗi” “Thông báo lỗi” “Thông báo lỗi” “Thông báo lỗi”

Bảng 2.2 Kiểm định theo các lớp phân hoạch hợp lệ điểm thi

Bảng 2.3 Kiểm định theo các lớp phân hoạch hợp lệ điểm thi