Giáo trình kiểm định phần mềm

Giáo trình được kiến trúc như sau: Chương đầu tiên giới thiệu một số khái niệm cơ sở về công nghệ phần mềm với giả định là bạn đọc đã biết ít nhiều về sản phẩm phần mềm và các tiêu chí đ

Nguyễn Xuân Huy

Giáo trình KIỂM ĐỊNH PHẦN MỀM

2.2 Tại sao lỗi phần mềm xuất hiện? 19

2.3 Chi phí sửa lỗi 22

Chương 3 Kiểm định phần mềm 24

3.1 Khái niệm chung 24

3.2 Hai vấn đề trọng tâm: K&K 27

3.3 Qui trình kiểm định phần mềm 30

3.4 Tính không đầy đủ của kiểm định 36

3.5 Thanh sát (inspection) và kiểm điểm (review) 40

3.6 Test tự động 42

Chương 4 Kiểm định phát triển 47

4.1 Kiểm định đơn vị 48

4.1.1 Định nghĩa 48

6.1 Khái niệm chung 70

6.2 Kiểm định dựa trên yêu cầu 71

6.3 Thiết kế test theo kịch bản 72

6.4 Kiểm định hiệu năng 73

Chương 7 Kiểm định của khách hàng 76

7.1 Khái niệm chung 76

Giáo trình này giới thiệu một số kiến thức cơ bản về kiểm định phần

mềm, một nhánh quan trọng thuộc lĩnh vực công nghệ phần mềm

Kể từ những năm sáu mươi của thế kỉ 20, công nghệ phần mềm đã được hình thành như một nguyên lí khoa học và phát triển ngày càng mạnh mẽ Có thể hiểu công nghệ phần mềm là lĩnh vực của công nghệ thông tin nhằm nghiên cứu và đề xuất các nguyên lí, qui trình công nghệ, phương pháp, và công cụ trợ giúp các quá trình thiết kế, cài đặt và bảo trì sản phẩm phần mềm đáp ứng được các chỉ tiêu về chất lượng: tính đúng, tính khoa học, tính tin cậy, tính vững vàng, tính dễ chuyển mang, tính dễ sử dụng, dễ phát triển và hoàn thiện

Kiểm định phần mềm chính là một nhánh của công nghệ phần mềm có nhiệm vụ kiểm tra và xác minh các tiêu chí chất lượng nói trên

Theo nghĩa hẹp, kiểm định phần mềm tập trung chủ yếu vào việc kiểm

tra tính đúng của phần mềm Tính đúng của một phần mềm được hiểu là

phần mềm đó thực thi đúng đắn và chính xác các yêu cầu do người thiết kế

mô tả trong bản thiết kế Các yêu cầu này được hình thành trên cơ sở trao đổi

và thống nhất giữa nhóm phát triển phần mềm với khách hàng

Khoảng những năm sáu mươi của thế kỉ 20 đã bùng nổ một cuộc tranh luận về toán tử đầy nghi vấn – toán tử GOTO trong ngôn ngữ lập trình Chính cuộc tranh luận này đã làm nảy sinh các ý tưởng và nguyên lí đầu tiên

về công nghệ phần mềm Điều thú vị là, ngay từ những ngày đầu sơ khởi và chập chững của công nghệ phần mềm, các phương pháp hình thức đã ra đời

và phát triển nhanh chóng Hàng loạt công trình nghiên cứu có ý nghĩa của các nhà tin học đầu đàn như Dijkstra, Dahl, Hoare, Boehm đã nâng kĩ thuật lập trình lên một tầm cao, mang tính chặt chẽ và hoàn thiện, rất gần với các ngành khoa học chính xác (Dijkstra, Dahl, and Hoare, 1972) Dahl và

hệ tiên đề chứng minh tính đúng của chương trình thông qua các phương pháp toán học và suy luận logic, Boehm và Dijkstra chứng minh tính đủ của hai cấu trúc điều khiển tuần tự và lặp while, trên cơ sở đó đề xuất khái niệm

D-cấu trúc với lời khuyên lập trình viên chỉ nên sử dụng ba cấu trúc điều

khiển một cách trong sáng và tao nhã là cấu trúc tuần tự, cấu trúc rẽ nhánh và cấu trúc lặp điều kiện trước (Boehm, 1979)

Do nhu cầu thị trường, các hệ thống phần mềm phức tạp ngày càng tăng trưởng Cùng với nó, hoạt động kiểm định ngày càng gánh trách nhiệm thêm nặng nề và chuyên nghiệp Nếu như trước đây, lập trình viên thường đảm đương luôn nhiệm vụ kiểm định các đoạn mã do chính mình viết ra thì ngày nay, việc đó là không thể, chưa nói đến khả năng không được khuyến khích Các phương pháp kiểm định được hình thành và phát triển rất đa dạng Có thể nói, ngày nay, mỗi mô hình phát triển phần mềm quyết định một vài qui trình sản xuất phần mềm Đến lượt mình, mỗi qui trình sản xuất phần mềm lại quyết định một vài qui trình kiểm định hiệu quả tương ứng

Giáo trình đặt ra hai mục tiêu cơ bản sau đây:

1 Giới thiệu khái quát các qui trình và phương pháp kiểm định phần mềm, đi sâu vào các phương pháp tiên tiến và có hiệu quả theo nghĩa các phương pháp này đã được kiểm chứng trong thực tế;

2 Định hướng cho học viên một số kĩ năng trợ giúp tổ chức và chỉ đạo các nhóm kiểm định phần mềm tại các cơ sở làm phần mềm

Nội dung của giáo trình tương đương với một học phần khoảng 60 tiết Giáo trình được kiến trúc như sau:

Chương đầu tiên giới thiệu một số khái niệm cơ sở về công nghệ phần mềm với giả định là bạn đọc đã biết ít nhiều về sản phẩm phần mềm và các tiêu chí đánh giá một sản phẩm phần mềm, về mô hình và các qui trình phát triển phần mềm

Nội dung của chương 2 dành cho các thảo luận về lỗi phần mềm, trong

đó phân tích chủ yếu về các dạng lỗi tiềm ẩn trong phần mềm và các nguyên nhân sinh lỗi

Chương 3 trình bày qui trình tổ chức và thực thi hoạt động kiểm định phần mềm

giới thiệu các nhóm phương pháp kiểm định phần mềm: kiểm định phát triển, kiểm định thực tế và kiểm định của người sử dụng

Trước khi biên soạn giáo trình này, người viết đã tiếp thu được nhiều kiến thức bổ ích cả về nội dung công nghệ phần mềm và phương pháp luận truyền thụ từ giáo sư John Vũ, kĩ sư trưởng Công nghệ thông tin hãng Boeing, giáo sư kiêm nhiệm tại Viện nghiên cứu phần mềm của Đại học Carnegie Mellon (CMU) và giáo sư Anthony Lattanze, CMU Tiến sĩ John Kang, chủ nhiệm Khoa Quốc tế CMU và thày Lê Công Cơ, Q hiệu trưởng trường Đại học Duy Tân Đà Nẵng đã cấp kinh phí và tạo nhiều điều kiện thuận lợi cho người viết được thăm và tham gia các khoá đào tạo công nghệ phần mềm tại CMU PGS TS Đoàn Văn Ban, PGS TS Đặng Văn Đức, Nghiên cứu viên chính Ngô Trung Việt, Viện Công nghệ thông tin, Viện Khoa học và Công nghệ Việt Nam, TS Hồ Cẩm Hà, trưởng khoa Công nghệ thông tin Đại học Sư phạm Hà Nội thường xuyên trao đổi và cung cấp thông tin cho người viết về các vấn đề đương đại của công nghệ phần mềm

Trong thời gian biên soạn giáo trình này, thạc sĩ Lê Thị Mỹ Hạnh, Khoa Công nghệ thông tin trường Đại học Bách khoa, Đại học Đà Nẵng đã cung cấp một số hình vẽ và những trợ giúp trong soạn thảo và trình bày văn bản Người viết chân thành cảm ơn những hỗ trợ quí báu và chân tình của các thày và đồng nghiệp

Người viết rất mong nhận được các ý kiến bình luận và đánh giá của bạn đọc gửi về theo địa chỉ sau đây:

Nguyễn Xuân Huy,

Chủ tịch Hội đồng tư vấn Giáo dục Microsoft,

Nhập đề

Chương này nhắc lại một số khái niệm cơ bản để chuẩn bị cho việc tiếp thu các khái niệm về kiểm định phần mềm là khái niệm trọng tâm của giáo trình:

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

một nhiệm vụ tương đối độc lập nhằm phục vụ cho một hoặc nhiều ứng dụng

cụ thể: quản lý họat động của máy tính hoặc áp dụng máy tính trong các họat động kinh tế, quốc phòng, văn hóa, giáo dục, giải trí,…

Thí dụ

S1 Hệ điều hành Ubutu;

S2 Môi trường lập trình C++ Devcpp;

S4 Game: Lines;

…

1.2 Các thành phần của một sản phẩm phần mềm

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

Thí dụ

Một hệ thống thông tin có thể bao gồm các phân hệ sau đây:

Phân hệ quản lí nhân sự, phân hệ quản lí sản phẩm, phân hệ quản lí tài chính (kế toán – tài vụ), phân hệ quản lí hành chính, phân hệ tiếp thị,…

Các phân hệ trên có thể được xây dựng từ các cấu phần sau:

Cấu phần quản lí dữ liệu, cấu phần quản lí lưu trữ, cấu phần quản lí mạng,…

Mỗi cấu phần lại được tổ hợp từ các đơn vị, các lớp (class - theo tiếp cận hướng đối tượng), các thư viện chương trình, hoặc các đơn thể (module), chẳng hạn:

Lớp các cửa sổ màn hình, lớp các thực đơn, thư viện các hàm số học, … Trong tài liệu này các thuật ngữ sau đây được hiểu là tương đương về ngữ nghĩa:

Các thuật ngữ như cấu phần, đơn thể, đơn vị, chi tiết trong một hệ thống

(phần mềm) được hiểu theo nghĩa tương đối, không có một phân định rõ ràng

nào Khi cần thiết, trong những trường hợp cụ thể, ngữ nghĩa của các khái niệm trên sẽ được làm rõ trong văn cảnh

Với một số phần mềm đơn giản, thí dụ như một bài tập về lập trình, thì kiểm định không đặt ra nhiều vấn đề gay cấn Vì lí do đó, các nguyên lí, mô hình và kĩ thuật kiểm định sẽ định hướng chủ yếu đến các hệ thống phần mềm bao gồm nhiều cấu phần có quan hệ hữu cơ với nhau

1.3 Các tiêu chí chất lượng của

sản phẩm phần mềm

Dưới đây liệt kê và phân tích vắn tắt một số tiêu chí xác định chất lượng của

Mã nguồn

Đặc tả sản phẩm Duyệt lại sản phẩm Tài liệu thiết kế Tài liệu kiểm định Lịch biểu

Phản hồi từ phiên bản

cũ

Thông tin cạnh tranh Khảo sát khách hàng

Dữ liệu

Kiến trúc phần mềm

Sản phẩm cuối

Bộ cài, Module trợ giúp, Hướng dẫn khử lỗi, Bẫy lỗi, Thực đơn, Biểu tượng, Âm thanh, Hướng dẫn

sử dụng, Nâng cấp, Cập nhật, Trợ giúp sản phẩm…

phẩm…ProductSupport Information, …

Hình 1.1 Sản phẩm phần mềm

TC1 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ụ

Trong bản thiết kế đặc tả rằng phần mềm S có thể sắp xếp một mảng có

tối đa 10000 phần tử thì những tình huống sau đây được coi là sai:

- Phần mềm S không sắp được các mảng rỗng là mảng không chứa phần tử nào;

- Phần mềm S không sắp được những mảng có đúng 10000 phần tử;

- Phần mềm S chỉ sắp tăng, không sắp giảm;

- Phần mềm S gây lỗi khi ta yêu cầu sắp (lại) một mảng đã sắp;

- Phần mềm S không thực thi được với các mảng có các phần tử giống nhau

TC2 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 tự nhiên 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 vị trí, 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…

2 Phần mềm S cung cấp hai lệnh có chức năng tương tự nhau nhưng cú pháp khác nhau, chẳng hạn:

asc(a, n) – sắp tăng mảng a gồm n phần tử;

dec(n, a) – sắp giảm mảng a gồm n phần tử

Hai lệnh trên có thứ tự (vị trí) đặt tham trị khác nhau nên sẽ gây khó khăn cho người sử dụng

TC3 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

TC5 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

TC6 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 format bộ nhớ ngoại vi hoặc khởi động (setup) lại hệ thống

TC7 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

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

Thí dụ

1 Theo những qui định mới chẳng hạn, người ta có thể thay đổi các phương thức tính thuế suất, tính điểm trung bình trong nhà trường, thay đổi các trình tự, thủ tục và hồ sơ cấp phép… Trong những tình huống đó ta không phải xây dựng lại hệ thống mà chỉ cần khai báo lại các tùy biến

Chẳng hạn, trước kia người ta qui định tính điểm trung bình của ba môn thi theo hệ số toán: 4, văn: 4, ngoại ngữ: 2 Công thức tính khi đó sẽ là:

[(Điểm thi toán  4) + (Điểm thi văn  4) + (Điểm thi ngoại ngữ  2)] / 10 Nay người ta qui định lại như sau: toán: 4, văn: 3, ngoại ngữ: 3 Công thức tính mới sẽ là:

[(Điểm thi toán  4) + (Điểm thi văn  3) + (Điểm thi ngoại ngữ  3)] / 10 Nếu sửa một số mã lệnh trong chương trình thì chắc chắn sẽ gây nhiều phiền toái trong việc phổ biến và cập nhật cho hàng loạt khách hàng tại nhiều điểm ứng dụng khác nhau Các phần mềm tinh tế thường cho phép người sử

dụng đặt lại các tùy biến khi cần thiết

2 Khi chuyển từ môi trường lập trình đơn lẻ trên một máy tính sang nguyên lý mới như lập trình mạng hoặc điện toán đám mây, có thể xảy ra rất nhiều thay đổi, trong số đó có những thay đổi căn bản về quan niệm hệ thống, về cấu trúc dữ liệu và về thuật toán… Có thể phải thêm hoặc mở rộng một số trường trong cấu trúc file, chẳng hạn, trước kia ta dành ra 1 byte để ghi nhận định dạng file, nay các chủng loại phương tiện (media) phát triển quá nhiều thì 1 byte dành cho việc ghi nhãn phương tiện sẽ là không đủ, chẳng hạn, người ta thay bằng 2 byte Khi đó toàn bộ các thủ tục liên quan đến xử lí file của hệ thống sẽ phải thay đổi

3 Cũng là một lệnh mở file Khi phần mềm chạy trên máy đơn thì việc kiểm tra file có tồn tại hay không, có thể đọc được hay không là đơn giản Nay, trên môi trường mạng, số sự cố sẽ thay đổi về lượng và chất Ngoài các

sự cố “truyền thống” như file không tồn tại, file thuộc loại chỉ đọc… còn có

thể có nhiều sự cố mới như: đường truyền chưa thông, file đang bị hệ thống khác chiếm giữ…

Một phần mềm được xem là dễ phát triển và hoàn thiện nếu gặp các

tình huống trên ta không phải thiết kế lại mà chỉ cần sửa đổi chút ít hoặc viế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,

Một số yêu cầu về chất lượng cũng rất khó chỉ ra một cách rõ ràng như tính bảo trì, tính khoa học

Bản đặc tả phần mềm thường không đầy đủ và hay mâu thuẫn

Vì thế phải có sự thỏa hiệp về chất lượng Hai kinh nghiệm sau đây thường được định hướng trong pha thu thập và đặc tả yêu cầu:

1 Chúng ta không thể đợi các đặc tả hoàn thiện trước khi tập trung chú

ý đến quản lý chất lượng;

2 Chúng ta phải xây dựng một qui trình nghiêm ngặt và đủ thông thái phục vụ cho hoạt động hoàn thiện chất lượng sản phẩm phần mềm mặc dù đặc tả chưa hoàn thiện

Quản lý chất lượng không chỉ quan tâm đến việc làm hạn chế tối thiểu những khiếm khuyết của sản phẩm và đảm bảo sao cho sản phẩm đáp ứng được các yêu cầu thể hiện trong bản đặc tả, mà còn phải quan tâm đến những thuộc tính chất lượng khác của sản phẩm

1.4 Một số khái niệm khác

Phần mềm đặt hàng (may đo) và phần mềm làm sẵn

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 K dùng để quản lí các kho hàng Khi đó phần mềm K được

gọi là phần mềm đặt hàng hay phần mềm may đo, theo nghĩa phần mềm này

định hướng đến một ứng dụng cụ thể cho một khách hàng cụ thể 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

Một số phần mềm trên thị trường được sản xuất để phục vụ đại trà, 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 tiện ích như

nén dữ liệu, mã hóa, diệt virus, tổ chức hội thảo từ xa,… Đó là các phần mềm

Theo nghĩa hẹp, nhóm làm phần mềm chỉ bao gồm những người trực tiếp và thường xuyên chịu trách nhiệm phát triển phần mềm, cụ thể là những người thuộc biên chế trong dự án phần mềm đó: trưởng dự án, người thiết kế, lập trình viên, kiểm định viên, người bán sản phẩm

Người có thẩm quyền (stakeholder)

Những người quyết định đến sự sống còn của phần mềm Người có thẩm quyền bao gồm:

Người làm phần mềm, người sử dụng, người chi tài chính, lãnh đạo bên

A (bên đặt hàng), lãnh đạo của chính xí nghiệp sản xuất phần mềm đó, công

ty phần mềm khác (có thể mua sản phẩm và sau đó "diệt" sản phẩm đó, không đưa vào sử dụng) …

Trong giáo trình này ta chỉ giới hạn quan niệm người có thẩm quyền bao gồm:

- Người sử dụng,

- Người chi tài chính, lãnh đạo bên A (bên đặt hàng),

- Lãnh đạo của chính xí nghiệp sản xuất phần mềm đó (B)

1.5 Mô hình phát triển phần mềm

Là một hệ thống các quan niệm, phương pháp, qui trình, kỹ thuật vận

dụng trong phát triển phần mềm Tên gọi mô hình thường trùng với tên của

1.6 Qui trình phát triển phần mềm

Để 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 Theo nghĩa rộng, qui trình phát triển

phần mềm được khởi động từ khi bắt đầu có ý tưởng và bao gồm nhiều vòng đời dưới dạng đường xoắn ốc thể hiện sự hoàn thiện dần của dòng sản phẩm theo thời gian Vòng đời sau cao hơn vòng đời trước Mỗi vòng đời thường bắt đầu từ công đoạn thiết kế, đặc tả các yêu cầu từ phía khách hàng đối với

hệ thống và kết thúc sau công đoạn kiểm định chấp nhận một phiên bản của sản phẩm Vòng đời tiếp theo là một bước phát triển để tạo ra một phiên bản mới của dòng sản phẩm do công ty phần mềm đang bảo trì 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

Qui trình phát triển phần mềm được xác định theo mô hình phát triển

Thuật ngữ phát triển phần mềm thường được dùng hơn cả vì nó thể hiện

được động thái, tức là qui trình xây dựng phần mềm từ mức đơn giản nhất, mức khởi thủy, đến khi nhận được một hệ thống phần mềm hoàn chỉnh

Công nghệ phần mềm được phát triển theo thời gian Trong vài thập niên gần đây người ta quan sát thấy sự xuất hiện nhiều mô hình tiên tiến cùng những môi trường và công cụ trợ giúp làm phần mềm Các ngôn ngữ lập trình cũng tiến bộ đáng kể, ngày càng trở nên tâm lí hơn, dễ sử dụng hơn, các

từ khóa, từ dành riêng được hiển thị với màu và font phân biệt, công cụ bẫy lỗi tự động cũng được phát triển theo kịp sự tăng trưởng của môi trường sản xuất phần mềm…

Xác định yêu cầu

Thiết kế

Cài đặt, kiểm định

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

Nội dung

2.1 Thế nào là lỗi phần mềm?

2.2 Tại sao lỗi phần mềm xuất hiện?

2.3 Chi phí sửa lỗi

2.1 Thế nào là lỗi phần mềm?

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

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)

Dựa vào nhận định trên, chúng ta có thể thấy lỗi phần mềm xuất hiện theo ba dạng sau:

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 bản đặc tả Cũng có trường hợp yêu cầu này 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 coi

là có lỗi

Một hình thức khác nữa liên quan đến các khía cạnh tâm lí khách hàng cũng được xem là lỗi, đó là phần mềm khó hiểu, khó sử dụng, chậm hoặc dễ gây cảm nhận rằng phần mềm họat động không đúng

2.2 Tại sao lỗi phần mềm xuất hiện?

Lỗi xuất hiện nhiều nhất không phải do lập trình

Số lỗi do đặc tả gây ra là nhiều nhất, chiếm khoảng 80%

Tại pha đầu tiên của qui 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ố

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) | t  Z, m  Z+} (*) Trong đó:

Z = {0, 1, 2, 3, …}

Z+ = {1, 2, 3, …}

Phép chia hai phân số:

(t1,m1)/(t2,m2) = Reduce(t1m2, t2m1),

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

Thiết kế

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

thì các số liệt kê trong dẫn chứng thứ 3 là đúng đắn

Bài tập 2.2

Bạn thử gắng tìm 6 nghĩa khác nhau của câu nói dưới đây:

"Ông cụ già đi nhanh quá"

Nhận xét

Các chuyên gia ngôn ngữ cho biết rằng: mặc dầu ngôn ngữ tự nhiên là nhập nhằng nhưng nó đủ tinh tế để diễn tả chính xác mọi tình huống Nhập nhằng hay không là do người sử dụng

Chúng ta thử sửa lại đề toán nói trên như sau:

“Liệt kê các số tự nhiên lẻ có đúng ba chữ số Ba chữ số này, theo trật

tự xuất hiện từ trái qua phải, lập thành một cấp cộng.”

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 Khi lập trình ai cũng có thể mắc lỗi Thời kì đầu, phát triển phần mềm thường đồng nghĩa với 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 Với sự hỗ trợ của nhiều công cụ và môi trường lập trình cao cấp

và tiện dụng, việc lập trình trở nên nhẹ nhàng hơn, mặc dù độ phức tạp phần

nguyên nhân sinh lỗi trong lập trình ngày nay 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ác mẫu có xu hướng tổng quát hóa…

2.3 Chi phí sửa lỗi

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 (Boehm, 1979) Chi phí tăng theo hàm mũ như trong hình 2.1

Chúng ta đã từng chứng kiến sự cố máy tính năm 2000 (Y2K) Từ một giải pháp tiết kiệm bộ nhớ, chỉ dùng hai chữ số cuối để biểu diễn năm thay cho bốn chữ số vào đầu những năm 70 của thế kỷ trước dẫn đến việc 25 năm sau làm cả thế giới lo sợ và phải bỏ ra nhiều tỉ dollars để khắc phục sự cố này

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

Nội dung

3.1 Khái niệm chung

3.2 Hai vấn đề trọng tâm: K&K

3.3 Qui trình kiểm định phần mềm

3.4 Tính không đầy đủ của kiểm định

3.5 Thanh sát (inspection) và kiểm điểm (review)

3.6 Test tự động

3.1 Khái niệm chung

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, trong nhiều bối cảnh, hoạt động của chương trình có

thể chưa bộc lộ lỗi 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 đó hoạt động có đúng với đặc tả không và thể hiện hành vi có đúng như kì vọng của người sử dụng hay không

Trên thực tế, quan sát một hệ thống đang thực thi là khác biệt so với việc duyệt mã nguồn của chương trình viết cho hệ thống đó Thông thường, người phát triển phần mềm luôn luôn đọc lại và phân tích mã nguồn Nhưng điều đó không có nghĩa là họ đã phát hiện hết lỗi Có những lỗi nằm ngay trong đầu, trong quan niệm của họ Như vậy, nhiệm vụ quan trọng của kiểm định hệ thống phần mềm là xác định xem hệ thống đó có phục vụ tốt hay

không Một hệ thống được xem là phục vụ tốt nếu như hệ thống đó đáp ứng

đầy đủ và chính xác các yêu cầu đặt ra trong bản thiết kế Tại thời điểm này,

hàng Phục vụ tốt được hiểu là hệ thống thể hiện đúng như kì vọng của người

sử dụng Đặc tả là căn cứ chủ yếu hỗ trợ cho việc kiểm định Đó là một bản

mô tả tường minh các hành vi được gọi là đúng và được dùng làm căn cứ cho hoạt động thiết kế, mã hóa và kiểm tra chương trình

Khi phần mềm được thực thi, mỗi hành vi thể hiện không đúng như đặc

tả sẽ được coi là một lỗi phần mềm Nói chung, người phát triển hệ thống phải tự chẩn đoán nguyên nhân sinh lỗi ngay trong mã nguồn

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 ở thời điểm sớm nhất có thể và đảm bảo rằng lỗi đó đã được sửa, được khắc phục Chúng ta sẽ nghiên cứu kĩ hơn vấn đề này ở những phần tiếp theo Mục tiêu của kiểm định phần mềm là thiết kế tài liệu, qui trình kiểm định một cách có hệ thống và thực thi qui trình này sao cho có hiệu quả, tiết kiệm được thời gian, công sức và chi phí

Trên quan điểm qui trình, kiểm định phần mềm là một phần của kiểm

tra và kiểm dụng phần mềm Kiểm tra và kiểm dụng là hai khái niệm thuộc

phạm vi của công nghệ phần mềm và sẽ được giới thiệu chi tiết trong các mục tiếp theo Công nghệ phần mềm lại là một phần của công nghệ hệ thống Nhìn từ ngữ cảnh chất lượng, kiểm định phần mềm cũng là một phần phần của kiểm tra và kiểm dụng phần mềm, nên cũng có thể xem như là một phần của hoạt động quản lí chất lượng phần mềm

Mục tiêu kiểm định

1 Phát hiện lỗi sớm

2 Giảm thiểu thời gian

3 Giảm thiểu chi phí

Ta minh họa nhận định trên qua khái niệm kĩ nghệ phòng sạch do IBM

phòng phát triển) luôn luôn sạch Mỗi khi thêm một chi tiết mới, ta kiểm tra

cẩn thận để sửa hết lỗi của hệ thống, sau đó mới thêm chi tiết mới khác Tư tưởng này được triển khai thông qua một chu trình gồm các bước sau:

Giả sử phần mềm có tên gọi S Khi đó

 Mỗi chi tiết d thêm vào hệ thống S sẽ được đặc tả để thu được kết quả v;

 Cài đặt đặc tả v (lập trình / mã hóa) để thu được mã trình p;

 Kiểm định tính đúng đắn của p theo tiếp cận hình thức;

 Không thực hiện kiểm định đơn vị;

 Kiểm định hệ thống S (đã thêm mã trình p), tập trung vào đánh giá tính tin cậy của hệ thống

Mục tiêu của qui trình phòng sạch là nhận được sản phẩm phần mềm không có lỗi, tức là cung cấp những hệ thống tin cậy cao

(http://www.SoftwareEngineering-9.com/Web/Cleanroom/)

Để tiện so sánh ta liệt kê chi phí cho các giai đoạn trong qui trình phát triển và bảo trì phần mềm như sau (Jeffries, R and Melnik, G., 2007):

Các giai đoạn phát triển

Phân tích yêu cầu : 3%

Hình 3.2 – Chi phí cho các giai đoạn phát triển phần mềm

Để kết luận mục này ta 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à qui 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 qui 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

(a) Ngữ cảnh quy trình (b) Ngữ cảnh chất lượng

Hình 3.3 - Kiểm định phần mềm trong một số ngữ cảnh

3.2 Hai vấn đề trọng tâm: K&K

Khi khảo sát chất lượng của một phần mềm ta quan tâm đến hai vấn đề trọng tâm sau đây (Boehm, 1979) :

Kiểm tra (Verification): Ta xây dựng phần mềm có đúng như dự định? Kiểm dụng (Validation): Có đúng là ta xây dựng phần mềm đó?

Kiểm tra và kiểm dụng phần mềm nhằm chứng tỏ rằng phần mềm đó đáp ứng đầy đủ và chính xác các yêu cầu của khách hàng đã được đặc tả trong bản thiết kế và phần mềm đó thực thi, hoạt động đúng như kì vọng của khách hàng

Công nghệ hệ thống Công nghệ phần mềm Xác minh và thẩm định

phần mềm

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

Quản lý và đảm bảo chất lượng Đảm bảo chất lượng ph mềm Xác minh và thẩm định phần mềm

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

Kiểm định chương trình trên các bộ dữ liệu mô phỏng là một kĩ thuật kiểm dụng chính yếu Ngoài ra, kiểm dụng có thể bao gồm các qui trình kiểm

tra khác như thanh sát (inspection) hoặc kiểm điểm (review) tại mỗi pha của

qui trình phát triển phần mềm kể từ pha đầu tiên là xác định yêu cầu của khách hàng đến pha bảo trì, nâng cấp phần mềm

Mục đích của kiểm tra là xác định xem phần mềm có thực hiện đúng các

yêu cầu về chức năng và phi chức năng đã đặc tả trong bản thiết kế không

Kiểm dụng là một qui trình tổng quát hơn kiểm tra Mục đích của kiểm

dụng là đảm bảo rằng phần mềm đáp ứng được các kì vọng của khách hàng

Nó khác kiểm tra đơn giản ở tính hữu dụng Tính chất này đòi hỏi phần mềm thực thi đầy đủ và hoàn hảo những gì khách hàng kì vọng Kiểm dụng nhạy hơn, tinh tế hơn, vì bản đặc tả các yêu cầu nhiều khi không phản ảnh đúng những gì khách hàng và người sử dụng thực sự mong muốn (Sommerville, 2011)

Mục tiêu tối thượng của các qui trình kiểm tra và kiểm dụng K&K là đáp ứng niềm tin rằng hệ thống phần mềm “khớp với dự tính”

Một trong những nguyên nhân dẫn đến những thất bại của sản phẩm phần mềm là sự không khớp giữa yêu cầu và nguyện vọng (Vu, 2009) Do khả năng hạn chế trong diễn đạt nên con người khó có thể mô tả chính xác điều mà họ mong muốn Khi lấy yêu cầu của khách hàng chúng ta thường gặp hiện tượng khách hàng diễn tả rất khó khăn, đôi lúc không thể hiện được hết ý, không nói ra được bản chất của những gì họ mong đợi ở sản phẩm mà

họ thuê ta làm

Nhận định sau đây là quan trọng đối với các nhóm làm phần mềm:

- Điều mà khách hàng mong muốn chưa chắc đã là điều họ thực sự cần;

- Điều mà khách hàng mong muốn có thể khác với điều mà khách hàng

diễn tả

Thí dụ

Ta hãy xét hai thí dụ kinh điển sau đây lấy từ kho tàng truyện cười dân gian

1 Ba điều ước Hai vợ chồng trẻ nhà nọ được Bụt cho phép ước ba điều

Hai vợ chồng bảo nhau là hãy để dành ba điều ước, suy nghĩ thật chín chắn, khi nào thật sự cần thiết hãy dùng đến

Một buổi tối, hai vợ chồng ngồi ngắm trăng, bỗng cô vợ lên tiếng:

- Ước gì có khúc dồi chó!

Khúc dồi chó hiện ra ngay trước mặt đôi vợ chồng Lời hứa của Bụt quả

là linh nghiệm! Vậy là chỉ còn hai điều ước

Anh chồng thấy vợ ước ngớ ngẩn quá liền nổi cáu:

- Ước gì khúc dồi này mọc trên mặt mụ!

Lại một điều ước nữa được thực thi Chỉ còn một điều ước cuối cùng

Dĩ nhiên, không thể để khúc dồi lủng lẳng trên mặt mình, cô vợ đành phải lên tiếng:

- Ước gì khúc dồi rơi ra khỏi mặt tôi!

Ta thấy:

Điều mà đôi vợ chồngthực sự cần là giàu sang, phú quí Nhưng chị vợ

lại ước một khúc dồi chó!

Cả hai vợ chồng, trong vai khách hàng đều ước đúng, nhưng đó lại không phải là những yêu cầu mà họ thật sự cần Ngay cả điều ước thứ ba nữa, nếu hai vợ chồng suy nghĩ cho chín chắn thì vẫn có dùng điều ước này

để được giàu sang, phú quí, sau đó dùng tiền để sửa lại dung nhan cho cô vợ

2 Con rắn vuông

Giả sử khách hàng trong vai nhà cung cấp A đặt một công ty phần mềm

B làm một phần mềm trò chơi tên là Rồng rắn cho các em nhỏ chơi vào dịp

Trung Thu

Khách hàng A phát biểu yêu cầu:

“Nhân vật chính là một con rắn R thông minh, ngộ nghĩnh, có thể thay

đổi chiều dài để chui vào các tổ chim lấy trộm trứng chim mang giấu vào kho K Mỗi lần rắn lấy được một quả trứng chim thì chiều dài d của rắn sẽ dài thêm v milimét, còn mỗi lần chim mẹ mổ vào đầu rắn thì chiều dài của rắn sẽ ngắn bớt v milimét…”

Đặc tả của người thiết kế:

if (số_trứng_thêm == 1) d = d + v;

if (rắn_bị_chim_mổ_1_cái) d = d - v;

Giả sử chương trình Rồng rắn đã hoàn tất và người chơi điều khiển để chim tấn công rắn liên tiếp nhiều lần Khi đó có thể xảy ra các tình huống

(1) Chiều dài của rắn đúng bằng chiều rộng d = r Ta có một con rắn

vuông;

(2) Chiều dài của rắn ngắn hơn chiều rộng;

(3) Chiều dài của rắn biến mất, thậm chí trở thành một số âm

Trong trường hợp này chúng ta có ba lớp người: Người đặt hàng A, người phát triển hệ thống B và người sử dụng C Kì vọng của người sử dụng

là không xảy ra các tình huống (1)-(3) như trên Phần mềm rồng rắn thể hiện đúng các yêu cầu của người đặt hàng, nó có thể qua được các kiểm tra tự động, tuy nhiên nó không đáp ứng được mong đợi của người sử dụng: nó

không qua được kiểm dụng

Từ thời điểm này trở đi, trong tài liệu này các thuật ngữ khách hàng,

người đặt hàng và người sử dụng được xem là đồng nhất Khi cần nhấn

mạnh đến những chi tiết khác biệt, tài liệu sẽ chỉ rõ

3.3 Qui 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 3.4 Kiểm định trong qui trình phát triển phần mềm

Phân tích Thiết kế Mã hóa Bàn giao

Qui trình kiểm định bao gồm một số 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 liệt kê các điểm quan trọng nhất trong kế hoạch kiểm định (Whittaker, 2002):

 Mục đích: Qui định về phạm vi, phương pháp, tài nguyên và lịch biểu cho các hoạt động kiểm định;

 Tài liệu tham khảo: Các tài liệu liên quan đến hoạt động kiểm định bao gồm cả phương pháp luận, các tiêu chí, hồ sơ thiết kế, bản đặc tả yêu cầu…

 Các định nghĩa: Giải thích các khái niệm, kí hiệu, các thuật ngữ liên quan đến hoạt động kiểm định;

 Mô tả khái quát về kiểm tra và kiểm dụng (K&K): Tổ chức, tài nguyên, trách nhiệm, các công cụ, kỹ thuật và phương pháp luận;

 Vòng đời của K&K: Các nhiệm vụ, dữ liệu vào và kết quả ra dự kiến theo từng thời điểm của vòng đời;

 Báo cáo kiểm tra và kiểm dụng (K&K) phần mềm: Mô tả nội dung, định dạng và thời gian cho tất cả các báo cáo K&K

 Các thủ tục quản lý K&K: bao gồm các chính sách, thủ tục, các chuẩn, thực nghiệm và các qui ước

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

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 qui tắc kiểm định Các chi tiết này sẽ được trình bày dần trong tài liệu 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

4 Xử lý đo lường kiểm định 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ó

5 Đánh giá sản phẩm phần mề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 qui trình kiểm định phần mềm được thể hiện trong hình 3.5

Hình 3.5 – Qui trình kiểm định phần mềm

Thí dụ

Giả sử bạn cần kiểm định hệ thống phần mềm điều khiển đèn cầu thang trong một ngôi nhà 2 tầng Tại chân cầu thang có công tắc A, tại đầu trên của cầu thang (tầng 2) có công tắc B Trên cao có một ngọn đèn D soi sáng cầu thang khi cần thiết Bạn không thể cạo vữa trát tường để quan sát xem dây dẫn của hệ thống được lắp đặt ra sao, bóng đèn được nối thế nào, trong hệ thống có những bộ phận gì Bạn cũng không được phép tháo công tắc A và B

để xem cấu trúc của chúng Bạn chỉ có thể bấm các phím A, B để xem đèn có được bật và tắt theo yêu cầu của khách sẽ đi trên cầu thang hay không Kiểm

định loại này được gọi là kiểm định hộp đen (white box testing): kiểm định viên không “nhìn” thấy cầu trúc bên trong hệ thống Hệ thống chỉ là một hộp

đen đối với kiểm định viên Ta có thể mường tượng hộp đen như sau: Người

Kết quả kiểm định

Thiết kế các

trường hợp

kiểm định

Chuẩn bị dữ liệu kiểm định

Thực thi chương trình với dữ liệu kiểm định

So sánh kết quả kiểm định

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

Dữ liệu kiểm định

Kết quả kiểm định

ta đặt hệ thống vào trong một chiếc hộp rồi sơn đen hộp đó để ta không thể quan sát được cấu trúc của hệ thống

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

2 Hãy liệt kê một vài test theo mẫu sau:

Yêu cầu: Thực hiện theo đúng trình tự NN

NN Trạng thái

đèn lúc đầu

Bấm công tắc thực tế: trạng Kết quả

thái đèn

Kết quả dự kiến: trạng thái đèn

Kết luận Đúng / Sai

Qui trình kiểm định bao gồm hai mục tiêu chủ yếu:

1 Trình diễn cho người thiết kế và người sử dụng biết rằng phần mềm đáp ứng đầy đủ và chính xác các yêu cầu đã đặc tả trong hồ sơ thiết kế Với

người sử dụng phần mềm thì điều đó có nghĩa là mỗi yêu cầu trong hồ sơ thiết kế đã được kiểm định ít nhất bằng một (bộ) test Với người thiết kế điều

đó có nghĩa là mọi chức năng và mọi tổ hợp của các chức năng đã được kiểm định ít nhất bằng một qui trình test

2 Phát hiện các tình huống, hành vi phần mềm không đáp ứng đúng các đặc tả trong hồ sơ thiết kế

Hành vi của một hệ thống (phần mềm) là ứng xử của hệ thống đối với

mỗi tác động Thí dụ, khi ta nhấn nút OK trong bảng chọn chế độ SAVE thì

hệ thống ghi lại văn bản đang soạn thảo Khi ta bấm phím Pause/Break thì hệ thống tạm ngừng tiến trình thực thi cho đến khi ta bấm một phím nào đó… Mục tiêu thứ nhất thuộc về kiểm dụng: yêu cầu hệ thống thực hiện đầy

đủ và chính xác các đặc tả trong hồ sơ thiết kế thông qua các trường hợp test Mục tiêu thứ hai thuộc về kiểm tra khuyết tật hệ thống: các trường hợp test được xây dựng theo định hướng phát hiện lỗi trong hệ thống

Lưu ý rằng người ta không qui định một ranh giới rõ ràng nào giữa hai mục tiêu nói trên Giả sử hệ thống quản lí tài khoản dùng trong một ngân hàng thực thi một test theo định hướng trong mục tiêu thứ hai và gặp lỗi khi

thực hiện chức năng “chuyển tài khoản” Điều này chứng tỏ:

- Hệ thống không thực hiện đúng chức năng “chuyển tài khoản”: mục

tiêu thứ nhất không đạt;

- Hệ thống có khuyết tật: mục tiêu thứ hai không đạt

Mục đích chủ yếu của test khuyết tật là “đẩy” hoặc “bẫy” hệ thống rơi

vào lỗi bằng cách xây dựng các trường hợp test (test case) nhạy với lỗi Thí

dụ, nếu hệ thống yêu cầu nạp một số nguyên dương thì ta nạp số nguyên âm,

số 0 hoặc một số thực để theo dõi xem hệ thống phản ứng ra sao

Như vậy, test kiểm định, ngoài các trường hợp hợp lệ, thường bao gồm các trường hợp test nằm ngoài giới hạn

Cũng cần lưu ý rằng các bộ test trong trường hợp này phải tương tự

hoặc rất gần với hành vi của người sử dụng cuối (end user) Người sử dụng

cuối được hiểu là người sử dụng hệ thống nhưng không có kiến thức về công

nghệ thông tin, nói chung và/hoặc không hoặc ít hiểu biết về hệ thống đang

sở hữu nói riêng

3.4 Tính không đầy đủ của kiểm định

Luận điểm quan trọng sau đây thuộc về Dijkstra (Dijkstra et al., 1972):

Kiểm định chỉ có thể chỉ ra lỗi, không thể khẳng định rằng phần mềm không có lỗi

Bài tập 3.2

Giả sử bạn cần kiểm định hàm NC sau đây:

Hàm NC (Name Correcting) chuẩn hóa tên người theo các yêu cầu sau : YC1: input - string x chứa tên người ;

output - string y chứa tên người (đã được chuẩn hóa)

YC2: Không có các dấu cách ở đầu và cuối tên y;

YC3: Một tên có thể gồm nhiều từ, các từ cách nhau đúng 1 dấu cách; YC4: Chữ cái đầu từ viết HOA, chữ cái thân từ viết thường

Hãy cho biết dự đoán về output của bạn cho các test dưới đây

Với test 2, hàm có thể cho ra output:

y = ”Vũ Vinh Quang (sáu Vân)“

Với test 3, hàm có thể cho ra output:

y = ”Ho K’Rong“

Và với test 4, hàm có thể cho ra output:

y = ”Napoleon Iii“

Lưu ý rằng, trong cả 3 test 2, 3 và 4, dữ liệu vào x đều đã đạt chuẩn

Vậy mà hàm biến đổi cái đúng, cái chuẩn thành cái sai, cái lệch chuẩn!

Đây cũng là thí dụ minh họa cho thấy đôi khi khách hàng mô tả yêu cầu không chuẩn mực Và ngay cả người thiết kế trong trường hợp này cũng đặc

tả không đầy đủ Trong khi đó kì vọng của người sử dụng chỉ đơn giản như sau:

Số hiệu

test

(Kì vọng của khách hàng)

1 ” Vũ VINH qUang “ ”Vũ Vinh Quang“

2 ”Vũ Vinh Quang (Sáu Vân)“ ”Vũ Vinh Quang (Sáu Vân)“

3 ”Ho K’rong“ ”Ho K’rong“

4 ”Napoleon III“ ”Napoleon III“

Lí do dẫn đến sai lệch trên là do đặc tả cho hàm NC chưa làm rõ các chi tiết sau :

- Cấu trúc của tên và các thành tố (atom) cấu thành

- Cấu trúc của từ trong tên: Đầu từ là gì ? Kí tự đầu từ là gì ?

- Cấu trúc của thân từ: Kí tự thân từ gồm những gì ?

Ta cũng dễ thấy rằng trường hợp chỉ ra trong test 4 rất khó đặc tả; nó thuộc phạm vi của khái niệm nhập nhằng của ngôn ngữ tự nhiên

Bài tập 3.3

Máy bán báo

Giả sử một phần mềm điều khiển máy bán báo tự động được xây dựng với các yêu cầu sau đây:

YC1: Chỉ nhận tiền Việt

YC2: Có thể bán 5 loại báo khác nhau mã số từ 1 đến 5

YC3: Mỗi giao dịch chỉ bán 1 tờ báo với giá đồng loạt 4000 đồng

YC4: Khách hàng chọn loại báo nào thì nhấn nút tương ứng từ 1 đến 5 YC5: Trình tự thao tác:

Bước1: Nạp tiền: có thể nạp nhiều lần

Bước 2: Chọn loại báo cần mua

Bước 3: Nhấn nút “ĐỒNG Ý MUA” để nhận báo và tiền thừa nếu

có

Nhấn nút “HỦY GIAO DỊCH” để nhận lại tiền

YC6: Có khả năng trả lại tiền thừa

Bạn hãy trao đổi nhóm và cho biết các test dưới đây thể hiện mục tiêu nào?

test Nội dung test Ý nghĩa

Không phản ứng gì

vì loại báo số 2 đã hết

4 - Chọn loại báo số 1

- Nạp 5000đ

- Nhấn nút “ĐỒNG Ý MUA”

Khách hàng thực hiện sai hướng

dẫn: hoán đổi bước 1 và 2

Trong máy còn tiền

Không phản ứng gì

vì không thể chọn được tổ hợp tiền thừa để trả cho khách hàng

Phân tích kĩ hai bài tập trên chúng ta thấy nhiều chức năng của hệ thống chưa bộc lộ vào thời điểm kiểm định May ra, chúng chỉ xuất hiện trong quá

trình sử dụng, khai thác hệ thống một cách đại trà Thí dụ, nếu nhân viên test không nêu được tình huống 4 trong bài tập 3.2 thì rất có thể trong một thời gian dài hàm NC vẫn được xem là hoạt động bình thường

Bảo trì một hệ thống hay một dòng sản phẩm là qui trình nâng cấp và phát triển hệ thống Khi nâng cấp hệ thống ta thường thay thế một số kiến trúc hoặc cấu phần bằng những thành phần khác tốt hơn Những thay thế và chỉnh sửa này, đôi khi, dù rất nhỏ, cũng có thể gây ra các lỗi nghiêm trọng

Như vậy, mỗi khi nâng cấp hệ thống ta phải kiểm định lại không chỉ các cấu phần bị thay đổi mà phải kiểm định lại toàn bộ hệ thống

Bạn hãy cho biết các trường hợp sử dụng (use case) sau đây có gây phiền toái gì cho hệ thống ?

YC1: Bầu 3 trong số 20 ứng viên

YC2: Bầu 150 trong số 170 ứng viên

YC3: Nạp đến ứng viên 15 thì phát hiện ra phiếu đang nạp dở là không hợp lệ

YC4: Nạp đến ứng viên 15 thì phát hiện ra lệch mã số ứng viên

3.5 Thanh sát (inspection) và kiểm điểm (review)

Thanh sát hệ thống là một hoạt động kiểm định có nhiệm vụ phân tích

và kiểm tra các yêu cầu hệ thống, mô hình thiết kế, mã nguồn, dự liệu các qui trình test Khi thanh sát, có thể chưa yêu cầu thực thi (vận hành, chạy thử)

phần mềm Vì vậy các kĩ thuật vận dụng trong thanh sát được gọi là các kĩ

Mục đích của thanh sát là phát hiện các lỗi và các hành vi phi logic

Bài tập 3.5

Giả sử bạn là một nhân viên thanh sát Sau khi nhận được bản đặc tả hệ thống kiểm phiếu tự động như trong bài tập 3.4 Lúc này hệ thống đã được thiết kế nhưng chưa được cài đặt hoàn chỉnh Bạn trao đổi với nhóm phát triển phần mềm ra sao? Hãy nêu cho nhóm càng nhiều câu hỏi càng tốt để có thể phát hiện lỗi ở mức sớm nhất Các câu hỏi của bạn có thể có những dạng sau đây:

- Điều gì sẽ xảy ra nếu ?