Luận văn tổ chức dữ liệu kiểm định phần mềm theo tiếp cận hộp đen

tập trung hệ thống hóa một số vấn đề trong kiểm định phàn mềm: Các phương pháp và chiến lược trong quy trình kiểm định phần mềm.Các phương pháp, quy trình và bản chất của kỹ thuật kiểm đ

Bô GIÁO DUC VÀ ĐÀO TAO

• • • TRƯỜNG ĐẠI HỌC sư PHẠM HÀ NỘI 2 ■ • ■ •

NGUYỄN TRỌNG TÂN

Tổ CHỨC DỮ LIỆU KIÊM ĐỊNH PHÀN MỀM THEO TIẾP

CẬN HỘP ĐEN

LUẬN VĂN THẠC SĨ MÁY TÍNH

Bộ GIÁO DỤC VÀ ĐÀO TẠO

• • • TRƯỜNG ĐẠI HỌC sư PHẠM HÀ NỘI 2

NGUYỄN TRỌNG TÂN

Tổ CHỨC DỮ LIỆU KIÊM ĐỊNH PHÀN MÈM THEO TIẾP

CẬN HỘP ĐEN

Chuyên ngành: Khoa học máy tính Mã số: 60 48 01 01

LUẬN VĂN THẠC SĨ MÁY TÍNH

Người hướng dẫn khoa học: PGS.TSKH Nguyễn Xuân Huy

LỜI CAM ĐOAN

Tôi xin cam đoan đây là kết quả nghiên cứu của tôi dưới sự hướng dẫn khoa học của PGS TSKH Nguyễn Xuân Huy

Các số liệu và kết quả nghiên cứu ttong luận văn này là trung thực và không trùng lặp với các đề tài khác Tôi cũng xin cam đoan rằng mọi sự giúp

đỡ cho việc thực hiện luận văn này đã được cảm ơn và các thông tin trích dẫn trong luận văn đã được chỉ rõ nguồn gốc

Hà Nội, ngày 12 thảng 12 Năm 2014 Học viên

Nguyễn Trọng Tân

MỤC LỤC

MỞ ĐẦU

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

Do nhu cầu thị trường, các hệ thống phần mềm đang ngày càng lớn hơn

và trở nên phức tạp hơn đòi hỏi hoạt động kiểm định phần mềm ngày càng gánh trách niệm thêm nặng nề và chuyên nghiệp Đảm bảo cho phần mềm dễ dùng và không có lỗi nhằm thỏa mãn và đáp ứng các yêu cầu ngày càng khắt khe của ngưòi sử dụng Chính vì vậy kiểm định phần mềm là một phần quan ữọng không thể thiếu trong quy trình phát triển phần mềm

Hiện nay, có hai phương pháp tiếp cận phổ biến đó là kiểm định hộp trắng (kiểm định dựa vào cấu trúc bên trong của hệ thống) và kiểm định hộp đen (kiểm định dựa trên chức năng hay kiểm định vào/ra) Trong đó kiểm định hộp đen được nhiều nhà phát triển phần mềm lựa chọn bởi vì nó có một số mặt thuận lợi nhất định Kiểm định hộp đen có thể được thực hiện bởi ngay cả những người không có nhiều kinh nghiệm kỹ thuật chuyên môn Điều này là

do kiểm định hộp đen không cần biết trước cấu trúc nội tại hay mã nguồn bên trong phần mềm

2 Mục đích nghiên cứu

Tổng quan về sản phẩm phần mềm, vấn đề kiểm định phần mềm và các cách tiếp cận trong kiểm định phần mềm Đi sâu vào các phương pháp kiểm định phàn mềm theo tiếp cận hộp đen

Xây dựng, tổ chức quy trình kiểm định phần mềm theo phương pháp hộp đen cho chương trình cụ thể

3 Nhiệm vụ nghiền cứu

Hệ thống hóa các phương pháp và quy trình kiểm định phàn mềm

Tổng quan về phương pháp kiểm định hộp đen, quy trình và một số kỹ thuật của kiểm định hộp đen

4 Đổi tượng và phạm vỉ nghiên cứu

Đề tài “Tổ chức dữ liệu kiểm định phần mềm theo tiếp cận hộp đen ”

5

tập trung hệ thống hóa một số vấn đề trong kiểm định phàn mềm: Các phương pháp và chiến lược trong quy trình kiểm định phần mềm.

Các phương pháp, quy trình và bản chất của kỹ thuật kiểm định hộpđen

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

Tổng họp, phân tích và đánh giá các kết quả lý thuyết, các ứng dụng, các nghiên cứu trong nước và thế giới về quy trình phát triển phần mềm Từ đó tập trung đi sâu vào các phương pháp kiểm định, đặc biệt là phương pháp kiểm định hộp đen

Tổ chức báo cáo, thảo luận định kỳ, trao đổi thường xuyên các thông tin, kết quả trong quá trình nghiên cứu với giáo viên hướng dẫn cũng như những người trong ngành có liên quan

Xây dựng các bộ dữ liệu test và tổ chức thực nghiệm

6 Giả thuyết khoa học

Khảo sát, phân tích và đề xuất các kỹ thuật kiểm định hộp đen, xây dựng chương trình kiểm định Thiết kế bộ test áp dụng cho chương trình cụ thể

CHƯƠNG 1 TỔNG QUAN VÈ SẢN PHẨM PHẦN MỀM VÀ CÁC KHÁI

NIỆM Cơ SỞ

■

1.1 Sản phẩm phần mềm

1.1.1 Phần mềm máy tính và chương trình máy tính

Một hệ thống phần mềm được phát triển chuyên nghiệp thường bao gồm nhiều phần mềm nhỏ chứ không phải chỉ là một phần mềm đơn nhất Hệ thống này thường bao gồm nhiều chương trình riêng biệt và các file dữ liệu cấu hình được dùng để cài đặt các chương trình này Các file có thể bao gồm tài liệu hệ thống (mô tả cấu trúc hệ thống) và tài liệu hướng dẫn sử dụng (giải thích cách

dử dụng hệ thống) và trang web hỗ trợ người dùng (mô tả các thông tin chi tiết sản phẩm hiện hành)

Định nghĩa về phần mềm được nêu trong [9] như sau:

Phần mềm bao gồm:

6

(1) Các chương trình máy tỉnh mà khỉ được thực hiện, nó mang lại chức năng và hiệu quả mong muốn.

(2) Các cẩu trúc dữ liệu mà theo đó chương trình có thể thao tác được với các thông tin.

(3) Các tài liệu hướng dẫn cách hoạt động của chương trình và cách sử dụng của chương trình.

Theo quan điểm hệ thống, một sản phẩm phàn mềm được xem là một hệ thống bao gồm một hoặc nhiều phân hệ Mỗi phân hệ lại được xây dựng từ những cấu phần Mỗi cấu phần bao gồm các đơn vị nhỏ hơn Các thành phần của phần mềm được liên kết với nhau thông qua các mối quan hệ và các tương tác

Ở đây ta cũng có thể đưa ra sự phân biệt giữa “sản phẩm phần mềm” với

“chương trình máy tính”

các chỉ dẫn được thể hiện dưới dạng các lệnh, các mã, lược đồ hoặc bất kỳ dạng nào khác, khi gắn vào một phương tiện mà máy tỉnh đọc được, có khả năng làm cho máy tính thực hiện được một công việc hoặc đạt được một kết quả cụ thể".

Có thể hiểu chương trình máy tính là chương trình được lập trình để điều khiển hoạt động của máy điện tử, là một chuỗi thông tin chứa các lệnh điều khiển máy tính thực hiện một hay nhiều nhiệm vụ nhất định Chương trình máy tính được xây dựng dưới dạng mã nguồn ừên cơ sở một ngôn ngữ lập trình nhất định và thường được lưu trữ dưới dạng mã máy Trong thực tiễn thường có sự nhầm lẫn giữa khái niệm chương trình máy tính và khái niệm phần mềm máy tính Tuy nhiên, xét dưới góc độ kỹ thuật và pháp lý thì đây là hai khái niệm khác nhau

Qua các định nghĩa ừên, có thể thấy rằng khái niệm phần mềm máy tính

có nội hàm rộng hơn khái niệm "chương trình máy tính" vì tài liệu mô tả chương trình, tài liệu hỗ trợ, nội dung thông tin số hóa và chương trình máy

7

ữong phần mềm máy tính nhưng thật ra không có sự phân định rõ ràng giữa hai khái niệm này.

1.1.2 Phân loại phần mềm máy tính

Đối với các họ máy tính hoạt động theo nguyên lý Von Neumann hiện nay ta có thể tạm chia các sản phẩm phần mềm thành 6 nhóm sau đây:

+ Nhóm 1: Các hệ điều hành, bao gồm

1.1 Các Driver (các chương trình điều khiển ổ đĩa)

1.2 Các Monitor

1.3 Các hệ quản lý tệp

1.4 Các hệ thống quản lý thư viện và chương trình dịch

1.5 Các hệ thống quản lý mạng máy tính + Nhóm 2: Các chương trình

Prolog,

+ Nhóm 3: Các chương trình hệ thống, bao gồm

3.1 Các chương trình điều khiển thiết bị ngoại vi

3.2 Các chương trình mở rộng các chức năng quản lý tệp:sắp xếp, saochép, cập nhật,

3.3 Các chương trình đồ họa

3.4 Các giao diện thân thiện giữa người sử dụng và hệ điều hành

+ Nhóm 4: Các hệ quản tri cơ sở dữ liệu, tri thức và các chương trình mở rộng tương ứng

+ Nhóm 5: Các chương trình ứng dụng có tính hệ thống

5.1 Các chương trình xử lý dữ liệu đa năng

5.2 Các bộ chương trình phục vụ cho các yêu cầu tính toán cơ sở

5.3 Các chương trình tối ưu hóa

5.4 Các hệ chuyên gia và các hệ tương tự

+ Nhóm 6: Các chương trình tiện ích và trò chơi

6.1 Các chương trình soạn thảo văn bản

6.2 Các chương trình xử lý bảng tính điện tử

6.3 Các chương trình chuyển đổi ngôn ngữ, dịch chéo, khôi phục

6.4 Các chương trình chống (và diệt) virus máy tính

6.5 Các chương trình ừò chơi, giải trí

V.V

Ngoài ra ta có thể phân loại phần mềm dựa theo một số tiêu chí sau đây:

Dựa theo cơ sở yêu cầu và mục đích sử dụng ta cũng có thể phân loại phần mềm thành

+ Phàn mềm đóng gói (phần mềm làm sẵn)

Có những phần mềm được thiết kế dựa trên những yêu cầu chung của nhiều người, không theo yêu cầu đặt hàng của riêng ai Chúng được viết rất hoàn chỉnh và thường kèm theo những phương tiện để cài đặt lên máy một cách tự động Người sử dụng chỉ càn mua về, cài đặt lên máy của mình, thiết lập các chế độ làm việc phù hợp là có thể sử dụng được Những phần mềm như thế gọi là phần mềm đóng gói Thí dụ như các hệ điều hành, các phần mềm ừò chơi, các phần mềm soạn thảo văn bản như WinWord, phần mềm tra cứu Internet như Internet Explorer, FireFox, Chrome, phàn mềm tra cứu kiến thức, phần mềm thiết kế bản vẽ như Auto Cad, Revit, phần mềm nghe nhạc

9

phàn mềm đóng gói Các phần mềm làm sẵn thường có phạm vi và lượng khách hàng lớn, đôi khi trải rộng toàn cầu.

+ Phần mềm theo yêu cầu (phần mềm đặt hàng)

CÓ những phần mềm ứng dụng được viết theo yêu cầu riêng có tính đặc thù của một cá nhân hay tổ chức Thí dụ một cơ sở có thể đặt hàng cho một công ty phàn mềm xây dựng một hệ thống thông tin dùng để quản lý nhân sự, quản lý các kho hàng hay phần mềm thiết kế một thí nghiệm, phần mềm điều khiển một dây chuyền sản xuất Hay phần mềm kiểm soát hệ thống giao thông, tài chính ngân hàng Thường thì với các phần mềm đặt hàng, số lượng khách hàng và phạm vi ứng dụng không lớn, mang tính chuyên biệt, định hướng khá

mã nguồn để dùng nó Phát triển phần mềm nguồn mở là phổ biến vì nó cho phép người dùng tạo ra các ứng dụng mói, và các sản phẩm từ phần mềm hiện

có Thí dụ các trình duyệt Internet như Fừefox hay Chrome cũng được xây dựng từ phần mềm nguồn mở

Mục đích của phần mềm nguồn mở là làm cho nó thành sẵn có cho mọi người để cho họ có thể phát triển nhiều thứ hữu dụng và có khả năng làm nó thành đích xác điều họ muốn Tương phản lại, phần mềm nguồn đóng có những hạn chế về cách mã có thể được dùng hay thay đổi Thí dụ PHP là phàn mềm nguồn mở Bất kì ai muốn dùng PHP đều có thể lên php.net để thu được việc truy nhập vào mã nguồn, hướng dẫn cách làm, và có thể bắt đầu phát triển ngay cái gì đó Nếu có gì giới hạn bạn khỏi việc làm điều bạn muốn thì bạn có thể đổi mã nguồn để làm bất kì cái gì bạn muốn Tất nhiên, chúng ta không thể làm được điều đó với phần mềm nguồn đóng như Java vì không thể đổi được

mã nguồn

1

ƯU điểm của nguồn mở là không phải trả tiền cho mã nguồn, có thể đổi

nó theo bất kì cách nào chúng ta muốn, cũng có cộng đồng lớn hỗ trợ

Phần mềm nhúng

Ngoài ra cũng có một thuật ngữ mà ta có thể kể đến đó là phàn mềm nhúng Phần mềm nhúng là phần mềm do nhà sản xuất thiết bị cài sẵn vào sản phẩm và chúng được sử dụng ngay cùng với đồ điện tử đó mà không cần có sự cài đặt của ngưòi sử dụng hay người thứ ba

Ngày nay, các thiết bị điện tử dân dụng trở nên thông minh hơn nhờ công nghệ vi xử lý Các phần mềm được cứng hóa ữong các thiết bị điều khiển, thí

dụ phần mềm gắn trong các thiết bị di động như điện thoại, máy tính bảng Phần mềm điều khiển cửa tự động, kiểm soát vào ra hay đơn giản hơn trong các thiết bị gia dụng hàng ngày được dùng ừong gia đình như ti vi, tủ lạnh, lò

vi sóng đều sử dụng các hệ vi xử lý

Các lĩnh vực có nhu cầu về "nhúng" cao nhất gồm: công nghiệp ôtô, thiết

bị viễn thông di động, điện tử gia dụng, tự động hóa sản xuất, thiết bị y tế Phần mềm nhúng chiếm một tỉ trọng rất lớn trong thị trường phần mềm nói chung

1.1.3 Các tiêu chí chất lượng của sản phẩm phần mềm

Các tiêu chí chất lượng của sản phẩm phần mềm có thể được kể đến: Tiêu chí 1: Tính đúng

Tính đúng của một sản phẩm phần mềm được hiểu là sản phẩm phần mềm đó thực thi đầy đủ và chính xác những yêu cầu đặc tả ưong bản thiết kế

Thí dụ một hệ thống xử lý dữ liệu không chạy được khi file cơ sở dữ liệu rỗng

Tiêu chí 2: Tính khoa học

Giao diện được thiết kế hợp lí, gần với tư duy và kì vọng của người sử dụng Các chức năng được sắp đặt khoa học, thể hiện logic của hệ thống Có thể di chuyển, thay đổi kích thước, màu sắc của các giao diện, kiểu của văn bản, hình vẽ, đồ thị, bảng biểu

1

Thí dụ trên ứng dụng bàn phím ảo cho các điện thoại thông minh, cho phép người dùng có thể tùy chọn màu sắc, giao diện, kích thước phím gõ Hay

có thể tùy chọn bố cục bàn phím (QWERTY, AZERTY, ) giúp người dùng thuận tiện trong việc soạn thảo và phù hợp với ngôn ngữ, kiểu gõ của từng vùng quốc gia

Tiêu chí 3: Tính dễ sử dụng

Sau một vài lần thực thi phần mềm, người sử dụng có thể nhớ được một cách logic trình tự làm việc Phần mềm có tính năng trợ giúp người sử dụng đúng lúc và đúng chỗ Các thao tác nhanh chóng, rõ ràng, dễ theo dõi Làm việc lâu với phần mềm không gây cảm giác khó chịu

Thí dụ trên các điện thoại di động thông minh hiện nay người dùng có thể dễ dàng soạn thảo tin nhắn cũng như văn bản hơn thông qua việc máy có thể học và nhớ những kí tự hay dùng và đưa ra gợi ý cho người sử dụng

Tiêu chí 5: Tính dễ chuyển mang (tính độc lập)

Phần mềm có thể làm việc bình thường trong các môi trường khác nhau, với các hệ điều hành và chủng loại máy khác nhau Tính dễ chuyển mang hiểu theo nghĩa đen là có thể cài phàn mềm trên các chủng loại máy tính và môi trường khác nhau

Tiêu chí 6: Tính vững vàng

Khi xảy ra các sự cố khách quan hoặc chủ quan phần mềm vẫn đủ “tỉnh táo” để nhận biết và xử lí, không bị treo, bị liệt hoặc gây ra các hậu quả nghiêm trọng

Các sự cố có thể là:

Người sử dụng chưa có đủ kỹ năng điều khiển phần mềm nên nạp sai dữ liệu, thay vì cần nạp một dãy số họ nạp dãy kí tự khác số, bấm nhầm lệnh

1

Thí dụ, nạp sai tên file, xóa nhầm các file của hệ điều hành, không hiểu

rõ các cảnh báo khi định dạng (format) bộ nhớ ngoại vi hoặc khởi động (setup) lại hệ thống

Tiêu chí 7: Tính dễ phát triển và hoàn thiện

Khi công nghệ phát triển, nhiều phần mềm phải thiết kế lại từ đầu, kể cả việc phải chọn môi trường và công cụ phát triển mới Nhiều phần mềm không thể tái sử dụng bất kì chi tiết nào Một phần mềm được xem là dễ phát triển và hoàn thiện nếu nó thích ứng được vói những thay đổi trong yêu cầu của khách hàng cũng như nền tảng kỹ thuật

Chất lượng phần mềm là một khái niệm đa chiều, khó có thể đơn giản hóa Ta tạm thừa nhận một sản phẩm phần mềm được xem là có chất lượng

1.2 Lỗi của sản phẩm phần mềm

1.2.1 Lỗi của sản phẩm phần mềm là gì

Lỗi phần mềm, có rất nhiều định nghĩa khác nhau về lỗi phần mềm Lỗi phàn mềm có thể sinh ra do nhiều nguyên nhân YÍ dụ như yêu càu phàn mềm

bị thiếu, yêu càu không rõ ràng

Nhưng có thể phát biểu một cách tổng quát: “Lỗi phần mềm là sự không khớp giữa chương trình và đặc tả của nó.” (Bezier, 1990)

Lỗi phần mềm có thể chia theo mức độ nghiêm trọng: Sai, thiếu, thừa

1

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

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

đã xây dựng.

3 Thừa: Một yêu cầu được thể hiện ưong sản phẩm nhưng lại không xuất hiện trong đặc tả.

1.2.2 Nguyên nhân gây ra lỗi phần mềm

Lỗi phần mềm cố thể sinh ra do nhiều nguyên nhân ví dụ như yêu cầu phần mềm bị thiếu, yêu cầu không rõ ràng Khác với sự cảm nhận thông thường, lỗi xuất hiện nhiều nhất không phải do lập trình Nhiều nghiên cứa đã được thực hiện ừong các dự án từ rất nhỏ đến các dự án rất lớn và kết quả luôn giống nhau

Số lỗi do đặc tả gây ra là nhiều nhất, chiếm khoảng 80% Có một số nguyên nhân làm cho đặc tả tạo ra nhiều lỗi nhất 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, nó hay thay đổi, hoặc do chưa 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à nguyên nhân dễ gây ra lỗi phần mềm Khách hàng thay đổi yêu cầu không cần quan tâm đến những tác động sau khỉ 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 đểỉ.

Nguồn gây ra lỗi lớn thứ hai là thiết kế Đó là nền tảng mà lập trình viên dựa vào để nỗ lực thực hiện kế hoạch cho phàn mềm

Lỗi do lập trình gây ra cũng khá dễ hiểu Ai cũng có thể mắc lỗi khi lập trình Thời kì đàu, phát triển phần mềm có nghĩa là lập trình, công việc lập

1

trình thì nặng nhọc, do đó lỗi do lập trình gây ra là chủ yếu Ngày nay, công việc 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, việc lập trình trở nên nhẹ nhàng hơn, mặc dù độ phức tạp 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 nhiên, nguyên nhân để lập trình tạo ra lỗi lại nhiều hơn

Đó là do độ phức tạp của phàn mềm, do tài liệu nghèo nàn, do sức ép thòi gian hoặc chỉ đơn giản là những lỗi “không nói lên được” Một điều cũng hiển nhiên

là nhiều lỗi xuất hiện trên bề mặt lập trình nhưng thực ra lại do lỗi của đặc tả hoặc thiết kế

Một nguyên nhân khác tạo ra lỗi là do bản thân các công cụ phát triển phần mềm cũng có lỗi như công cụ trực quan, thư viện lớp, bộ biên dịch, Đăc tả:

Đặc tả một đối tượng nào đó là mô tả các đặc trưng của cả đối tượng đó Yêu cầu đầu tiên cũng là quan trọng nhất của đặc tả chính là tính chính xác

Đặc tả được xây dựng ở pha đầu tiên trong quy trình phát triển phần mềm, đó là khi người thiết kế thu thập, xây dựng và đặc tả yêu cầu đặt ra cho sản phẩm phần mềm đó

Đây cũng là khâu khó nhất trong quy trình phát triển phần mềm, nó trả lòi cho câu hỏi khách hàng cần gì? Đôi khi khách hàng đưa ra yêu cầu nhưng

đó chưa phải là điều mà họ thực sự cần, hoặc điều đó là chưa hoàn toàn đầy đủ đối với nhu cầu của họ và khách hàng không thể tự đặc tả được hết những yêu cầu đó Thí dụ: Khách hàng nói: "Tôi muốn hệ thống phải diệt hết virus trong

thâm nhập hệ thống rồi mới tìm và diệt chúng

Tại pha đầu tiên của quy trình phát triển phàn mềm, pha thu thập và đặc

tả yêu cầu, ngưòi thiết kế ừao đổi với khách hàng để thu nhận các yêu cầu đặt

ra đối với sản phẩm phần mềm Các yêu cầu này sau đó được đặc tả, tức là

1

được phát biểu dưới dạng chặt chẽ, hoàn chỉnh, không thể gây nhập nhằng trong cách hiểu.

Người ta thường sử dụng hai công cụ - ngôn ngữ ừong đặc tả yêu cầu:

1 Ngôn ngữ hình thức: chủ yếu là các ngôn ngữ toán học và logic với một hệ thống kí hiệu và cú pháp chặt chẽ, không nhập nhằng về ngữ nghĩa Đặc tả dưới dạng này thường ngắn gọn, súc tích, nhưng thường khó hiểu, đặc biệt là khi càn trao đổi, thống nhất với các khách hàng không có thiên hướng về toán học;

2 Ngôn ngữ tự nhiên: Dễ đọc, dễ hiểu nhưng thường gây nhập nhằng, khó phát hiện mâu thuẫn

Nguyên nhân sinh lỗi tại pha đặc tả

- Đặc tả không hình thức (hoặc phi hình thức): Ngôn ngữ tự nhiên dễ hiểu nhưng rườm rà, nhập nhằng

- Đặc tả hình thức: Đơn giản, chính xác nhưng khó hiểu, khó cài đặt

- Quên đặc tả một yêu cầu nào đó

- Đặc tả không hết

- Yêu cầu đã thay đổi nhưng đặc tả không thay đổi

- Đặc tả khác nhau cho cùng một yêu cầu xuất hiện ữong các cấu phần khác nhau của hệ thống

Thí dụ: Trong đặc tả bài toán phân số (Huy, 1996):

1 Đặc tả phi hình thức: Phân số là một cặp ưm, ừong đó t là một số nguyên, m là một số nguyên dương; t được gọi là tử số, m được gọi là mẫu số của phân số Phép chia hai phân số: Thương của hai phân số là phân số được rút gọn từ phân số có tử số là tích của tử số của phân số thứ nhất và mẫu số của phân số thứ hai; mẫu số là tích của mẫu số của phân số thứ nhất và tử số của phân số thứ hai

2 Đặc tả hình thức:

Phân số= {(t,m) 11 G z, m G z+} (*)

Trong đó:

1

Hàm gcd là hàm tìm ước chung lớn nhất của hai số tự nhiên.

Đặc tả phép chia như trên, kể cả trường hợp phi hình thức và hình thức,

là sai với đặc tả phân số Chẳng hạn, khi ta thực hiện chia hai phân số 2,5) = (5, -6), thì mẫu số trong trường họp này lại là một số âm, không phù hợp với đặc tả phân số

(l,3)/(-Đây là một ví dụ đơn giản về việc đặc tả sai do không đủ cẩn thận Với các bài toán lớn thì việc đặc tả sẽ rất khó và dễ nhầm lẫn, sai sót

1.2.3 Những tác hại của lỗi phần mềm

Khi một phàn mềm có lỗi, nó không đơn thuần chỉ gây ra sự bất tiện, gây ra sai sót trong quá trình vận hành phần mềm mà nhiều khi nó còn gây ra thiệt hại to lớn về kinh tế Chi phí cho việc sửa lỗi phần mềm thường là rất lớn

Bảo trì là phàn chi phí chính của phần mềm và kiểm định là hoạt động chi phí đắt thứ hai, ước tính khoảng 40% chi phí ữong quá trình phát triển ban đầu của sản phẩm phần mềm Kiểm định cũng chiếm phần chi phí quan trọng 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 người dùng (Martin, 2007)

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 tăng một cách đáng kể trong quá trình phát triển phần mềm

Sự thay đổi về một yêu càu của khách hàng tại pha đàu tiên, pha thu thập

và đặc tả yêu cầu thường không đòi hỏi chi phí lớn, nếu không nói là không đáng kể Chi phí sẽ tăng nhiều hơn nếu các yêu cầu bị thay đổi sau khi đã lập trình Thay đổi yêu cầu lúc đó đồng nghĩa với việc viết lại chương trình, đôi khi là kiến trúc lại hệ thống

1

Việc sửa lỗi sẽ không còn đáng kể nếu lập trình viên tự phát hiện lỗi của mình Đương nhiên, trường hợp này không kéo theo bất kì chi phí phụ trội nào ngoài thời gian tự sửa lỗi của lập trình viên Họ không phải giải thích lỗi cho bất kỳ người nào 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 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.

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 kết quả nghiên cứu của IBM, GTE và TRW 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ư trong hình:

Hình 1.2 Chi phí sửa lỗi theo các pha

Ta có thể kể đến một số sự cố liên quan đến lỗi phàn mềm đã xảy ra trước đây

Thí dụ như sự cố Y2K (year two kilo) nghĩa là năm 2000 Sự cố Y2K (sự cố năm 2000) là sự cố kỹ thuật trong các bộ nhớ máy tính Trước thế kỉ 20,

do bộ nhớ của máy tính hạn hẹp nên người ta đã viết tắt các năm Ví dụ như năm 1940 thì chỉ viết là "40", năm 1978 thì chỉ viết "78" Nhưng khoảng năm 1997-1998, một số công ty phải lập kế hoạch cho những năm 2000 và họ đã vấp phải hai số "00" Khi họ nhập năm 2000, máy tính không hiểu được hai số

"00" nên mọi dữ liệu có trùng số đó bị tính toán nhầm lẫn, gây rối loạn hết các

dữ liệu Toàn thế giới đã được báo động về nguy cơ này Và theo ước tính thế

1

giới đã phải chi ra hàng nghìn tỷ USD để lập trình lại hệ thống, thay thế các phần cứng cũ, cài đặt những phần mềm mềm mới sử dụng cơ chế đọc số năm theo dạng đầy đủ (4 chữ số).

Intel đã phải bỏ ra trên 400 triệu dollar để chi trả cho quá trình thay thế các chip bị lỗi chia dấu phẩy động của bộ vi xử lý Intel Pentium (Intel Pentium Floating - Point Division Bug), 1994; Hay như những năm gần đây, lỗi bảo mật trên phần mềm đã khiến tin tặc đánh cắp thông tin ngưòi dùng và gây ra những thiệt hại không nhỏ cho các công ty trên thế giới;

Theo nghiên cứu của Watt Humphrey tại Đại học Carnegie Mellon, cho rằng tỉ lệ mắc lỗi đối với người phát triển phần mềm là 1/10 Điều này có nghĩa

là trong 10 dòng lệnh được viết ra thì thường có 1 lỗi Nhiều người phát triển phần mềm tin rằng trình biên dịch sẽ tìm ra mọi lỗi Tuy vậy có nhiều lỗi gõ vào mà trình biên dịch lại không tìm ra Thí dụ một lỗi cú pháp trong c, gõ “=“ thay cho “= =“ có thể tạo ra phép gán thay YÌ phép so sánh

Mặc dù trình biên dịch có thể tìm ra 90% lỗi nhưng còn 10% kia thì sao? Nhiều ngưòi tin rằng 10% kia có thể được thực hiện bằng kiểm định Tuy nhiên, nhiều chương trình sẽ chạy ngay cả khi chúng có lỗi Thực tế, chúng có thể có nhiều lỗi và vẫn qua được nhiều kiểm định Ngay cả để tìm ra số phần trăm lỗi lớn trong một chương trình, chúng ta vẫn phải kiểm định gần như tất

cả các con đường và điều kiện logic Và để tìm ra tất cả các lỗi trong ngay cả chương trình nhỏ, chúng ta sẽ phải cho chạy kiểm định vét cạn mà có thể tốn kém và yêu cầu nhiều nỗ lực

Vì vậy kiểm định phần mềm đang ngày một trở nên YÔ cùng quan trọng

và đóng một vai ưò không thể thiếu trong quy trình phát triển phần mềm

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

1.3.1 Khái niệm chung

Kiểm định phần mềm là quá trình khảo sát, kiểm tra, thực thi một hệ thống phần mềm để xác định xem phần mềm đó có hoạt động đáp ứng đúng

1

vói các yêu cầu của đặc tả không và thể hiện hành vi đúng như kì vọng của người sử dụng hay không?

Mục đích của kiểm định phàn mềm là tìm ra lỗi chưa được phát hiện, tìm một cách sớm nhất và đảm bảo rằng lỗi đã được sửa, mà kiểm định phần mềm không làm công việc chẩn đoán nguyên nhân gây ra lỗi đã được phát hiện

và sửa lỗi

2

Mục tiêu của kiểm định phần mềm là thiết kế tài liệu kiểm định một cách có hệ thống và thực hiện nó sao cho có hiệu quả, nhưng tiết kiệm được thời gian, công sức và chi phí.

Kiểm định phần mềm không đơn thuần chỉ là việc duyệt lại mã nguồn của chương trình viết cho hệ thống đó Nhiều người nghĩ kiểm định phần mềm

sẽ là khâu cuối cùng trong quy trình phát triển phần mềm nhưng không chỉ yậy

mà nó là một quá trình xuyên suốt thậm chí ngay từ khi bắt đầu xây dựng hệ thống phần mềm

1.3.2 Quy trình phát triển phần mềm

Vòng đời phần mềm

Được hiểu là thời kì tính từ khi phần mềm sinh (tạo) ra cho đến khi chết

đi (Từ lúc hình thành đáp ứng yêu cầu, vận hành, bảo dưỡng cho đến khi loại

bỏ không đâu dùng)

Một trong những quy trình được lấy làm nền tảng là quy trình Thác đổ

“Waterfall” Tuy có nhiều quy trình phát triển phần mềm khác nhưng chúng đều là phát triển của quy trình này theo thòi gian

2

MÔ hình thác đổ là quy trình phát triển phần mềm tuần tự nơi mọi hoạt động phát triển đều phải tuân theo những pha nào đó như yêu cầu, thiết kế, viết

mã, kiểm định và bảo trì Phải hoàn thành một pha trước khi chuyển sang pha tiếp, cũng như nước chảy từ trên đỉnh xuống đáy trong một thác nước Theo

mô hình thác đổ ta có thể tạm thời đơn giản hóa quy trình phát triển phàn mềm bao gồm các công việc sau đây:

1) Phân tích yêu cầu2) Thiết kế sơ bộ3) Thiết kế chi tiết4) Lập trình và kiểm định đơn vị5) Tích hợp và kiểm định tích họp6) Kiểm định hệ thống

7) Khai thác và bảo trì hệ thống

2

1.3.3 Quy trình kiểm định phần mềm

Mục đích của kiểm định là thiết kế một chuỗi các trường hợp kiểm định, gọi là các bộ test, có khả năng phát hiện lỗi cao Để cho việc kiểm định đạt được kết quả tốt cần có sự chuẩn bị về kế hoạch kiểm định, thiết kế các trường họp kiểm định và các dữ liệu kiểm định cho từng trường họp Đây chính là đầu vào cho giai đoạn kiểm định Và sản phẩm (đầu ra) của giai đoạn kiểm định chính là “báo cáo kiểm định” ừong đó mô tả chi tiết kết quả của tất cả các trường họp kiểm định đã thực thi: mục đích kiểm định, dữ liệu vào, kết quả dự kiến, kết quả thực tế, kết luận (đúng/sai)

Cũng giống như phát triển phần mềm thì kiểm định phần mềm cũng có vòng đời của nó Có thểm tạm chia thành các giai đoạn sau đây

Giai đoạn 1: Lập kế hoạch kiểm định

Bước đầu tiên là lập kế hoạch cho tất cả các hoạt động kiểm định sẽ được thực hiện và các phương pháp kiểm định sẽ sử dụng Bản kế hoạch bao gồm cả thông tin về người lập kế hoạch, các thành viên tham gia kiểm định và các bảng kiểm mục Dưới đây là liệt kê một số nhận định về kiểm định phần mềm của các chuyên gia công nghệ phần mềm (Sommerville, 2011):

1 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 nhằm đảm bảo rằng phàn mềm đáp ứng đầy đủ các yêu cầu của bản thiết kế và các yêu cầu đó đáp ứng đúng những gì mà người sử dụng mong đợi;

2

2 Kiểm định phàn mềm là quy trình bắt buộc trong các dự án phát triển phần mềm;

3 Kiểm định phần mềm là một hoạt động tốn kém, mất thòi gian, và khó phát hiện được hết lỗi;

4 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à được quản lí chặt chẽ;

5 Mã hóa chương trình chỉ là giai đoạn cuối ữong quy trình làm phần mềm

6 Làm phần mềm gồm nhiều pha với nhiều vòng lặp, mỗi pha, mỗi vòng lặp đều có thể sinh lỗi;

7 Lỗi ở pha sớm là lỗi nặng nhưng không khó sửa;

8 Bắt lỗi sớm sẽ dễ sửa;

9 Lỗi sinh lỗi một cách liên hoàn

Giai đoạn 2: Bố trí nhân viên kiểm định

Việc kiểm định thường phải được tiến hành một cách độc lập Mỗi

2

nhóm độc lập có ưách nhiệm tiến hành các họat động kiểm định, gọi là các nhóm kiểm định.

Giai đoạn 3: Thiết kế các trường họp kiểm định

Các trường họp kiểm định là các đặc tả đầu vào cho kiểm định và đàu ra mong đợi của hệ thống cùng với các chức năng, câu lệnh cần kiểm định Các chuyên gia kiểm định đã đề xuất một vài phương pháp trợ giúp thiết kế trường hợp kiểm định và các quy tắc kiểm định Trước mắt ta phân biệt hai tiếp cận kiểm định cơ bản:

- Các phương pháp hộp đen: kiểm định dựa trên chức năng hay kiểm định vào/ra

- Các phương pháp hộp trắng: kiểm định dựa vào cấu trúc bên ưong của

hệ thống

Giai đoạn 4: Xử lý đo lường kiểm định

Được thực hiện bằng cách thu thập dữ liệu Chú ý rằng kiểm định viên không thể trực tiếp cải tiến chương trình mà họ chỉ có thể đánh giá nó Đánh giá sản phẩm phần mềm nhằm để xác nhận sản phẩm có vượt qua được kiểm định hoặc/và có thể sẵn sàng phát hành được chưa?

Mô hình chung của quy trình kiểm định phần mềm:

ì

Phân tích |=> Thiết kế Mã hóa <=> KIẺM THỪ

1=> chương trình với

dữ liệu kiểm

kết quả kiểm định Các

trường Dữ liệu kiểm Kết quả kiểm Kết quả

2

2

Kiểm định hộp đen còn được gọi là kiểm định vào/ra: với loại hệ thống này ta chỉ có thể kiểm ứa bằng cách nạp dữ liệu hoặc tác động vào hệ thống rồi quan sát kết quả ở đầu ra hoặc quan sát phản ứng của hệ thống.

Các yêu cầu (Hướng dừ liệu, Vào/ra.)

Hình 1.6 Kiểm định hộp đen Nếu đặt hệ thống vào một hộp kính trong suốt thì ta có thể nhìn rõ và kiểm tra mọi chi tiết trong cấu trúc của hệ thống Trường họp này cho ta khái niệm hộp ữắng (white box

Để hiểu thế nào là kiểm định hộp đen chúng ta sẽ đi tìm câu ừả lời cho câu hỏi: “Khi nào chúng ta bắt buộc phải sử dụng phương pháp kiểm định hộp đen”?

Trả lời: Khi chúng ta muốn kiểm tra một chương trình mà chúng ta lại không cỏ mã nguồn của chúng, khỉ đó bẳt buộc chúng ta phải sử dụng phương pháp kiểm định hộp đen.

Các phương pháp 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 Tức là, việc kiểm định hộp đen làm cho người kỹ sư phần mềm suy ra được tập các điều kiện vào sẽ thao tác qua tất cả các yêu cầu chức năng đối với một chương trình Kiểm định hộp đen giúp xác định lỗi trong các phạm vi sau đây:

- Các chức năng không đúng hay bị bỏ sót

- Lỗi giao diện

- Lỗi trong Cấu trúc dữ liệu hay thâm nhập Cơ sở dữ liệu ngoài

- Lỗi hiệu năng

- Lỗi khởi đầu và kết thúc

Như vậy kiểm định hộp đen là chiến lược kiểm định thành phàn phần mềm (TPPM) dựa vào thông tin duy nhất là các đặc tả về yêu càu chức năng của TPPM tương ứng

Đây là chiến lược kiểm định theo góc nhìn từ ngoài vào, các người tham gia kiểm định hộp đen có thể không cần quan tâm nhiều đến kiến thức về thông tin hiện thực TPPM cần kiểm định (mã nguồn của thành phần phần mềm, thuật giải được dùng, các dữ liệu được xử lý )

Đối tượng: Đối tượng được kiểm định là 1 thành phần phần mềm TPPM

có thể là một hàm chức năng, một module chức năng, một phân hệ chức năng Nói chung, chiến lược kiểm định hộp đen thích hợp cho mọi cấp độ kiểm định

2

từ kiểm định đơn vị, kiểm định tích hợp, kiểm định hệ thống, kiếm thử độ chấp nhận của người dùng.

Thí dụ

Chương trình tìm ước số chung lớn nhất của 2 số a và b bất kỳ nhập vào

từ bàn phím Khi chấm bài thay vì phải đọc bài thi (code) của từng thí sinh, giáo viên chấm bài sẽ xây dựng một bộ Test để kiểm ừa qua đó đưa ra kết quả Với bài toán trên bộ Test có thể xây dựng như sau:

2

Kết quả mong đọi

Kết quả thưc

tế ■

Đánh giá

4 Sô thực Sô thực Sai kiêu

12 Sô nguyên X Sô nguyên X Sô nguyên X