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

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

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

HÀ NỘI, 2014

LỜI CẢM ƠN

Để hoàn thành luận văn này tôi đã nhận được sự giúp đỡ tận tình của thầy hướng dẫn khoa học, của các thầy cô trường Đại học Sư phạm Hà Nội 2 Tôi xin chân thành cảm ơn các thầy cô trường Đại học Sư phạm Hà Nội 2 đã tạo điều kiện học tập và giúp đỡ tôi rất nhiều trong quá trình làm luận văn Đặc biệt tôi xin cảm ơn PGS.TSKH Nguyễn Xuân Huy đã tận tình hướng dẫn, chỉ bảo tôi trong suốt quá trình học tập, thực hiện đề tài và giúp tôi hoàn thành bản luận văn này

Hà Nội, ngày 12 tháng 12 năm 2014

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

HÀ NỘI, 2014

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 trong 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

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

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

3 Nhiệm vụ nghiên cứu 1

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

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

6 Giả thuyết khoa học 2

CHƯƠNG 1 TỔNG QUAN VỀ SẢN PHẨM PHẦN MỀM 3

VÀ CÁC KHÁI NIỆM CƠ SỞ 3

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

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

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

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

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

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

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

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

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

1.3.1 Khái niệm chung 17

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

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

CHƯƠNG 2 KIỂM ĐỊNH HỘP ĐEN 23

2.1 Khái niệm chung 23

2.1.1 Kiểm định hộp đen 23

2.1.2 Quy trình kiểm định hộp đen 25

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

2.2.1 Phân hoạch tương đương 26

2.2.2 Kỹ thuật phân tích giá trị biên 32

2.2.3 Kỹ thuật dùng bảng quyết định 36

CHƯƠNG 3 ÁP DỤNG KỸ THUẬT KIỂM ĐỊNH HỘP ĐEN 42

3.1 Mô tả yêu cầu bài toán 42

3.2 Giải pháp giải quyết bài toán 42

3.2.1 Đầu vào cho ứng dụng kiểm định 43

3.2.2 Kiểm định giao diện người sử dụng (User Interface Testing) 47

3.2.3 Kiểm định luồng nghiệp vụ (Business Flow Testing) 49

3.3 Thực hiện kiểm định và kết quả đạt được 51

KẾT LUẬN 54

DANH MỤC CÁC TÀI LIỆU THAM KHẢO 55

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 trọ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 vi 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”

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:

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”

Theo khoản 1 Điều 22 Luật SHTT 2005: "Chương trình máy tính là tập

hợp 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 trê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 trê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 tính đều thuộc phần mềm máy tính Chương trình máy tính là một bộ phận nằm trong 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:

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 dịch và thông dịch như Pascal, C, C++, 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, sao ché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 trị 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ự

5.5 Các hệ mô phỏng

5.6 Các lớp ngôn ngữ dữ liệu và tri thức phục vụ cho việc khai thác các

cơ sở dữ liệu tri thức

5.7 Các hệ tự động hóa quản lý chuyên ngành

5.13 Các hệ chương trình điều khiển quy trình và các thiết bị công nghiệp

+ 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 trò 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 trò 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 hay xem phim trên đĩa CD như Windows Media Player, Jet audio đều là các 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á cụ thể, tường minh

Dựa trên mã nguồn ta có thể phân loại phần mềm thành phần mềm nguồn mở và phần mềm nguồn đóng

Phần mềm nguồn mở là phần mềm máy tính với mã nguồn của nó được làm thành sẵn có cho bất kì ai dùng, thay đổi và phân phối Tương phản lại, Phần mềm nguồn đóng bị hạn chế và người dùng phải trả tiền để truy nhập vào 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ư Firefox 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

Ư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 trong 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 trong 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ả trong 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

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í 4: Tính tương tác

Phần mềm có thể tương tác với các hệ thống khác, thí dụ:

- Có thể đọc các file định dạng khác nhau;

- Có thể chuyển, nhận và dĩ nhiên là hiểu được các thông điệp, dữ liệu trao đổi qua lại với các hệ thống khác hiện đang tồn tại trên thị trườ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

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 nếu

“sản phẩm đó phù hợp với đặc tả của nó.” (Kaner, 2003; Somerville,

2011)

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 ví 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 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ả nhưng 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 trong 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ứu đã được thực hiện trong 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 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

Hình 1.1 Các nguyên nhân gây ra lỗi phần mềm

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 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 máy!" Tuy nhiên điều mà họ thực sự cần lại là: "Hệ thống phải ngăn chặn được mọi sự xâm nhập của virus" Rõ ràng là ngăn chặn virus sẽ tốt hơn

là để virus 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ế trao đổ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à đượ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ữ trong đặ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 trong 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 t/m, trong đó 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

trong đó Reduce(t, m) = (t/d, m/d) với d= gcd(t, m)

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ố (1,3)/(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ố

Đâ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í 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 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

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ế 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 vì 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 vô cùng quan trọng

và đóng một vai trò 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 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

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ỉ vậ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

c nh yêu u

( n m ?)

t ( c n o?)

i t, m nh ( c n)

ch p ( m )

Khai c o ( ng)

Hình 1.3 Mô hình thác đổ đơn giản

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ầu 2) Thiết kế sơ bộ 3) Thiết kế chi tiết 4) Lập trình và kiểm định đơn vị

5) Tích hợp và kiểm định tích hợp 6) Kiểm định hệ thống

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

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” trong đó 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)…

Hình 1.4 Kiểm định trong quy trình phát triển phần mềm

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 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 trong 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

nhóm độc lập có trá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 trong 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:

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

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 tra 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

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 trắng (white box testing)

Hình 1.7 Kiểm định hộp trắng

CHƯƠNG 2 KIỂM ĐỊNH HỘP ĐEN

2.1 Khái niệm chung

2.1.1 Kiểm định hộp đen

Để hiểu thế nào là kiểm định hộp đen chúng ta sẽ đi tìm câu trả 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, khi đó 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 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 tra qua đó đưa ra kết quả Với bài toán trên bộ Test có thể xây dựng như sau:

mong đợi

Kết quả thực tế Đánh giá

Đặc trưng

Thuyết minh: Các chức năng đủ và vận hành đúng

Thực hiện: Qua giao diện

Cơ sở: Đặc tả, điều kiện vào/ra và cấu trúc dữ liệu

Ít chú ý tới cấu trúc nội tại của nó

Kiểm định hộp đen không xét tới các cấu trúc điều khiển, nên sự chú ý được dồn vào miền thông tin Các phép kiểm định được thiết kế để trả lời các câu hỏi sau:

- Tính hợp lệ chức năng được kiểm định như thế nào?

- Lớp dữ liệu vào nào sẽ tạo ra những trường hợp kiểm định tốt?

- Hệ thống có nhạy cảm với những giá trị đầu vào nào đó không?

- Biên giới của lớp dữ liệu được xác định như thế nào?

- Hệ thống có thể dung sai cho tỉ lệ dữ liệu và khối lượng dữ liệu nào?

- Việc tổ hợp dữ liệu có tác động gì lên sự vận hành của hệ thống? Hiện nay việc sử dụng kiểm định hộp đen được sử dụng rộng rãi, vì đa

số các chương trình phần mềm khi bàn giao tới người sử dụng đều dưới dạng

file chạy *.exe

2.1.2 Quy trình kiểm định hộp đen

Quy trình kiểm định hộp đen tổng quát gồm các bước chính:

+ Phân tích đặc tả về các yêu cầu chức năng mà TPPM cần thực hiện

+ Dùng 1 kỹ thuật định nghĩa các trường hợp test (test case)

Định nghĩa mỗi testcase là xác định 3 thông tin sau:

 Giá trị dữ liệu nhập để TPPM xử lý (hoặc hợp lệ hoặc không hợp lệ)

 Trạng thái của TPPM cần có để thực hiện test case

 Giá trị dữ liệu xuất mà TPPM phải tạo được

+ Kiểm định các test case đã định nghĩa