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

CHƯƠNG 1 TỔNG QUAN KIỂM ĐỊNH PHẦN MỀM Phần đầu của chương giới thiệu sơ lược một số mô hình cơ bản theo các quy trình phát triển phần mềm.. Từ đó phân tích lý do tại sao phải kiểm định

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

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

Trương Thị Thu Hà

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

LUẬN VĂN THẠC SĨ

Hà nội - 2006

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

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

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

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

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

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

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

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

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

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

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

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

Phân

tích

Thiết

kế

Lập trình

Kiểm

đị nh

Vận hành

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

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

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

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

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

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

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

và đảm bảo dữ liệu vào có cung cấp đúng dữ liệu ra muốn có?

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

b Mô hình bản mẫu

Mô hình làm bản mẫu bắt đầu với việc thu thập yêu cầu Người phát triển phần mềm xác định các mục tiêu tổng thể cho phần mềm thông qua khách hàng Sau đó thiết

kế nhanh để đưa ra một bản mẫu với những yêu cầu cơ bản, người dùng đánh giá và bổ sung để làm mịn các yêu cầu và tiếp tục quá trình xây dựng và điều chỉnh bản mẫu để đạt được phần mềm đúng theo yêu cầu của khách hàng

Lắng nghe khách hàng

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

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

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

c Mô hình RAD

RAD là mô hình tiến trình phát triển phần mềm tăng dần nhấn mạnh vào chu kỳ phát triển cực ngắn Cách tiếp cận RAD bao gồm các pha sau đây:

- Mô hình hoá nghiệp vụ: luồng thông tin giữa các chức năng nghiệp vụ được mô hình hoá theo cách trả lời câu hỏi như: thông tin nào được sinh ra? ai sinh ra nó? Ai xử lý nó?

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

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

Tổ #3

Mô hình

hoá

nghiệp vụ

Mô hình

dữ liệu

Mô hình

xử lý Sinh ứng dụng

Kiểm đị nh

và quay vòng

Tổ #1

Mô hình hoá

nghiệp vụ

Mô hình

dữ liệu

Mô hình

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

và quay vòng

Tổ #2

Mô hình hoá

nghiệp vụ

Mô hình

dữ liệu

Mô hình

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

và quay vòng

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

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

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

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

để phù hợp với sản phẩm tiến hoá theo thời gian

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

e Mô hình tăng dần

Mô hình tăng dần là tổ hợp các yếu tố của mô hình tuần tự tuyến tính và bản chất lặp của mô hình bản mẫu

Mô hình tăng dần áp dụng các trình tự tuyến tính theo kiểu so le khi thời gian lịch tiếp diễn Mỗi trình tự tuyến tính lại tạo ra một “việc tăng” chuyển giao được của phần mềm

Kỹ nghệ hệ

thống/ thông tin

Chuyển giao tăng 4

Tăng 2

Chuyển giao tăng 1

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

Phân

tích

Thiết

kế

Phân tích

Phân tích

Phân tích

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

Tăng 4

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

f Mô hình xoáy ốc

Là mô hình tiến hoá cặp đôi bản chất lặp của mô hình bản mẫu với các khía cạnh

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

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

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

- Lập kế hoạch

- Phân tích rủi ro

- Chế tạo

- Xây dựng và đưa ra

- Đánh giá của khách hàng

Khi tiến trình tiến hoá bắt đầu, tổ kỹ nghệ phần mềm đi vòng xoáy ốc bắt đầu từ trung tâm Mạch đầu tiên quanh xoáy ốc có thể làm phát sinh việc phát triển đặc tả sản phẩm Các bước tiếp theo quanh xoáy ốc được dùng để phát triển bản mẫu và phát triển các phiên bản phức tạp dần thêm Mỗi bước qua vùng lập kế hoạch lại làm nảy sinh việc điều chỉnh kế hoạch dự án Chi phí và lịch biểu được điều chỉnh dựa trên phản hồi được suy ra từ đánh giá của khách hàng

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

Mô hình tiến trình tương tranh có thể được biểu diễn như một chuỗi các hoạt động

kỹ thuật chính, các nhiệm vụ và trạng thái liên kết của chúng

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

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

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

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

1.2.2 Lỗi phần mềm

Đã phát triển

Đợi thay đổi

Đã xét duyệt

Đã xét duyệt

Vạch ranh giới

Xong

Không

Hình 1.5

Một phần tử của mô

hình tiến trình tương

tranh

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

quan tâm đến những tác động sau khi thay đổi yêu cầu như phải thiết kế lại, lập lại kế

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

được phần nào của dự án phụ thuộc và phần nào không phụ thuộc vào sự thay đổi Vì

vậy, lỗi thường rất dễ phát sinh

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

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

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

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

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

+ Phân số = {(t,m) | t  Z, m  N + } (*)

Trong đó: N = {0, 1, 2, 3, 4, }

N + = {1, 2, 3, 4, }

Z = { ±1, ±2, ±3, ±4, }

+ 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 gdc là hàm tìm ước số chung lớn nhất

của hai số tự nhiên

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

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

số âm, không đúng đặc tả

Trên đâ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

Nguồn gây lỗi lớn thứ hai sau đặc tả là thiết kế Đây là cơ sở để lập trình viên dựa vào để thực hiện lập trình Những thiết kế không hiệu quả hoặc quá phức tạp sẽ gây rất nhiều khó khăn cho việc lập trình và dẫn đến lỗi Bản thân các thiết kế nhiều khi cũng mang lỗi

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

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

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

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

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

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

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

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

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

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

TÀI LIỆU THAM KHẢO

Tiếng Việt

1 Nguyễn Xuân Huy (1994), Công nghệ phần mềm, Đại học Tổng hợp Tp Hồ Chí Minh

2 Nguyễn Xuân Huy (2006), Sáng tạo trong thuật Toán và lập trình tập 1, 2, Nhà xuất bản Giáo dục

3 Nguyễn Xuân My, Hồ Sĩ Đàm, Trần Đỗ Hùng, Lê Sĩ Quang (2002), Một số vấn đề chọn lọc trong môn Tin học, Nhà xuất bản Giáo dục

4 Nguyễn Văn Vỵ (2005), Bài giảng Đảm bảo chất lượng phần mềm và kiểm thử, Đại học Công nghệ -

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

5 Ngô Trung Việt, Nguyễn Kim Ánh (2002), Nhập môn kỹ nghệ phần mềm, Nhà xuất bản Khoa học và

Kỹ thuật

6 Roger S Pressman (2001), Kỹ nghệ phần mềm tập 1, 2, 3, Ngô Trung Việt dịch, Nhà xuất bản Giáo dục

Tiếng Anh

7 Beizer, B (1995), Black- box Testing, Wiley

8 Boehm B W (1976), Software Engineering, IEEE Transactions on Computers

9 British Standard (1998), BS 7925- 1 - Standard for Software Component Vocabulary, British

Computer Society

10 British Standard (1998), BS 7925- 2 - Standard for Software Component Testing, British Computer

Society, p 1- 15

11 Cem Kaner, Jack Falk, Hung Quoc Nguyen (1999), Testing Computer Software, John Wiley & Sons,

Inc., p 27- 141

12 Ernest Wallmuller (1994), Software Qulity Assurance - A Practical Approach, Prentice Hall

Internetional (UK) Ltd

13 Glenford J Mayers (1979), The Art of Software Testing, John Wiley & Sons, Inc

14 Ian Somerville (1996), Software Engineering, 5nd Edition, Addison-Wesley Publishers Ltd, USA

15 IEEE (1998), IEEE Std 1012-1998 – IEEE Standard for Software Verification Testing, The Institute

of Electrical and Electronics Engineerings, Inc., USA