Tải bản đầy đủ
ChƯƠNG 3 CHIẾN LƯỢC KIỂM ĐỊNH PHẦN MỀM

ChƯƠNG 3 CHIẾN LƯỢC KIỂM ĐỊNH PHẦN MỀM

Tải bản đầy đủ

- Kiểm định cần bắt đầu trong “phạm vi nhỏ” và quá trình hướng đến
các kiểm định trong “phạm vi rộng”. Các kiểm định đầu tiên được lập kế
hoạch và thực hiện chủ yếu tập trung vào các module chương trình riêng biệt.
Trong quá trình kiểm định, các thay đổi kiểm định tập trung vào việc cố gắng
tìm các lỗi trong các nhóm module được tích hợp và cuối cùng là trong toàn
bộ chương trình.
- Kiểm định toàn diện là không thể. Số phép hoán vị đường dẫn cho
chương trình có kích thước vừa phải là vô cùng lớn. Vì lý do này nên không
thể thực hiện mỗi một tổ hợp các đường dẫn trong quá trình kiểm định. Tuy
nhiên, có thể phủ một cách thích hợp logic chương trình và đảm bảo rằng tất
cả các điều kiện trong thiết kế thủ tục đã được thực thi.
- Để đạt hiệu quả nhất, kiểm định cần thực hiện bởi một nhóm độc lập
thứ ba. Một lập trình viên nên tránh việc cố gắng kiểm định chương trình của
chính mình; đồng thời một tổ chức lập trình cũng không nên tự kiểm định
phần mềm của chính họ. Để “hiệu quả nhất”, chúng ta muốn nói kiểm định
có khả năng phát hiện lỗi cao nhất (mục tiêu chính của việc kiểm định). Tuy
nhiên, một lập trình viên khi vừa hoàn thành công việc xây dựng chương trình
thì sẽ vô cùng khó khăn nếu ngay sau đó cố gắng thiết lập tư duy phá huỷ
chương trình của mình. Đa số các lập trình viên không thể kiểm định chương
trình của chính mình một cách hiệu quả bởi vì bản thân họ không thể hình
thành tư duy tự bộc lộ lỗi. Thêm vào đó, ngoài vấn đề tâm lý này còn có một
vấn đề đáng lưu ý khác: chương trình có thể có lỗi do lập trình viên hiểu lầm
phát biểu hoặc đặc tả bải toán. Vì vậy, lập trình viên sẽ có cùng một sự hiểu
lầm như vậy khi cố gắng kiểm định chương trình của chính mình. Một dự án
hay một tổ chức lập trình theo nhiều khía cạnh, cũng có những vấn đề tâm lý
tương tự như trên. Hơn nữa, người quản lý dự án còn định trước thời hạn với
một chi phí cố định nào đó. Chính vì vậy, một tổ chức lập trình không thể
khách quan kiểm định chương trình của họ, vì nếu theo định nghĩa kiểm định

thì quá trình kiểm định làm giảm khả năng đạt được mục tiêu về thời gian và
chi phí. Song, những điều này không có nghĩa là một lập trình viên hoặc một
tổ chức lập trình không thể tự phát hiện lỗi trong chương trình của họ, họ
hoàn toàn có thể có một số thành công nhất định. Tuy nhiên, để kiểm định
thành công và hiệu quả thì kiểm định phần mềm phải do một nhóm độc lập
thực hiện.
- Các trường hợp kiểm định phải được viết cho các điều kiện đầu vào
không hợp lệ và không mong đợi, cũng như các điều kiện hợp lệ và được
mong đợi. Và một phần cần thiết nữa là phải xác định đầu ra hay kết quả
mong đợi. Khi kiểm định một chương trình, một xu hướng tự nhiên là chủ yếu
tập trung vào các điều kiện đầu vào hợp lệ và mong đợi nhưng lại ít để ý đến
các điều kiện đầu vào không hợp lệ và không mong đợi. Trong khi các điều
kiện đầu vào không hợp lệ và không mong đợi thường có khả năng phát hiện
lỗi cao hơn. Tương tự như vậy, nếu kết quả đầu ra mong đợi vẫn chưa được
xác định cho một trường hợp kiểm định thì khả năng một kết quả sai sẽ được
hiểu là kết quả đúng. Vì vậy, một trường hợp kiểm định phải gồm hai phần:
+ Mô tả chi tiết đầu vào hợp lệ và được mong đợi hoặc không hợp lệ,
không được mong đợi.
+ Mô tả chi tiết đầu ra đúng cho một tập đầu vào tương ứng.
- Kiểm tra kĩ kết quả của mỗi trường hợp kiểm định. Có rất nhiều
trường hợp lỗi là do sai sót trong mô tả đầu ra vì không kiểm tra kĩ trước đó,
nên rất mất thời gian và công sức để cố gắng tìm lỗi tưởng như rõ ràng của
chương trình không lỗi do không khớp với mô tả.
- Kiểm tra một chương trình xem nó có thực hiện đúng những gì nó
phải thực hiện và những gì dự kiến không thực hiện.
- Tránh bỏ qua những trường hợp kiểm định trừ khi chương trình thực
sự là một sản phẩm bỏ đi.

- Không nên đặt kết quả dưới một giả định rằng sẽ không phát hiện
một lỗi nào.
- Xác suất tồn tại lỗi cao ở những phần có nhiều lỗi được phát hiện.
- Kiểm định phần mềm là một nhiệm vụ mang tư duy sáng tạo và tính
trách nhiệm cao. Tính sáng tạo và trách nhiệm đòi hỏi cho việc kiểm định một
chương trình còn cao hơn cho việc thiết kế chương trình đó. Vì vậy, chỉ nên
giao công việc thiết kế, cài đặt và phân tích trường hợp kiểm định, dữ liệu
kiểm định và kết quả kiểm định cho những người có trình độ.
3.2. Phương pháp tiếp cận kiểm định phần mềm
Kiểm định là một tập các hoạt động có thể được lập kế hoạch trước và
được thực hiện một cách có hệ thống. Vì lý do này, một khuôn mẫu để kiểm
định phần mềm.
Kế hoạch kiểm định phần mềm cung cấp cho người phát triển một
khuôn mẫu kiểm định, và có các đặc điểm sau:
- Kiểm định bắt đầu tại mức module và các công việc “phát triển”
hướng tới việc tích hợp toàn bộ hệ thống.
- Các kỹ thuật kiểm định khác nhau thích hợp tại những thời điểm khác
nhau.
- Kiểm định được thực hiện bởi người phát triển phần mềm và nhóm
kiểm định độc lập (cho các dự án lớn).
- Kiểm định và gỡ rối là các hoạt động khác nhau, nhưng gỡ rối phải có
trong mọi chiến lược kiểm định.
Một kế hoạch kiểm định phải đưa ra các kiểm định mức thấp cần thiết
để thẩm định rằng đoạn mã nguồn nhỏ đã được cài đặt một cách chính xác
cũng như các kiểm định mức cao để xác minh những chức năng chính của hệ
thống phù hợp yêu cầu của khách hàng. Kế hoạch cần cung cấp sự hướng dẫn
cho người thực hành và tập các giai đoạn quan trọng cho người quản lý. Vì

các bước của kế hoạch kiểm định xuất hiện tại thời điểm khi sức ép thời hạn
bắt đầu tăng, tiến trình cần phải lường được và các vấn đề cần phải bộc lộ
càng sớm càng tốt.
3.2.1. Xác minh và thẩm định

Kiểm định phần mềm là một phần của đề tài rộng hơn mà thường được
đề cập tới như là sự xác minh và thẩm định (V&V). Thẩm định và xác minh là
từ chung để chỉ quá trình kiểm tra để đảm bảo phần mềm thoả mãn các yêu
cầu của chúng và các yêu cầu đó đáp ứng yêu cầu của khách hàng. Xác minh
là một tập các hoạt động đảm bảo rằng phần mềm cài đặt chức năng cụ thể
một cách chính xác. Thẩm định là tập hợp hoạt động khác đảm bảo rằng phần
mềm đã được xây dựng theo đúng các yêu cầu của khách hàng.
- Xác minh (Verification): “Chúng ta xây dựng có đúng sản phẩm
không?”
- Thẩm định (Validation): “Chúng ta xây dựng sản phẩm đúng chưa?”
Xác minh và thẩm định là một phần của hoạt động đảm bảo chất lượng
phần mềm, bao gồm việc duyệt lại kỹ thuật, kiểm định chất lượng và cấu
hình, theo dõi hiệu suất, mô phỏng, nghiên cứu tính khả thi, duyệt lại tài liệu,
xem lại cơ sở dữ liệu, phân tích thuật toán, kiểm định phát triển, kiểm định
chất lượng và kiểm định cài đặt. Kiểm định đóng vai trò rất quan trọng trong
việc xác minh và thẩm định phần mềm và nhiều hoạt động khác trong phát
triển phần mềm.
Ví dụ, một chương trình kế toán đáp ứng đúng các tính toán do người
thiết kế đã đặc tả. Tuy nhiên, trong màn hình quyết toán lập trình viên lại đặt
màu là đỏ. Đó là màu mang ý nghĩa hủy bỏ trong ngành tài chính. Chương
trình kế toán được xác minh, nhưng không được thẩm định.
Trách nhiệm của người đảm bảo chất lượng phần mềm là tạo ra và tuân
thủ các tiêu chuẩn và phương pháp để hoàn thiện quá trình phát triển phần
mềm và ngăn ngừa lỗi xuất hiện.

3.2.2. Tổ chức việc kiểm định

Với mọi dự án phần mềm, có một xung đột cố hữu về quyền lợi xuất
hiện khi kiểm định bắt đầu. Những người xây dựng phần mềm được yêu
cầu kiểm định phần mềm. Điều này tưởng như vô hại: sau tất cả, không có
ai hiểu rõ chương trình hơn người phát triển. Thật đáng tiếc, những người
phát triển này được đảm bảo quyền lợi trong việc chứng minh rằng chương
trình là không lỗi, các công việc của họ tuân theo các yêu cầu của khách
hàng, và tuân theo kế hoạch và ngân sách. Mỗi quyền lợi trên ngăn cản việc
kiểm định hoàn toàn.
Từ quan điểm tâm lý, phân tích và thiết kế phần mềm (cùng với mã
hoá) là những công việc xây dựng. Người kỹ sư phần mềm tạo ra các chương
trình máy tính, các tài liệu của nó và các cấu trúc dữ liệu liên quan. Giống như
bất kỳ người xây dựng nào, kỹ sư phần mềm tự hào về công trình đã xây dựng
và nghi ngờ tất cả những ai cố gắng giật đổ nó. Khi kiểm định bắt đầu, một
cách tế nhị nhưng rõ ràng, là cố gắng “bẽ gãy” những gì mà kỹ sư phần mềm
đã xây dựng. Từ quan điểm xây dựng, kiểm định có thể được xem xét để (mặt
tâm lý) phá huỷ. Vì thế người xây dựng làm việc một cách dè dặt, thiết kế và
thực hiện các kiểm định để chứng mình rằng chương trình làm việc, hơn là
phát hiện các lỗi. Đáng tiếc, các lỗi sẽ thường vẫn có mặt. Và nếu kỹ sư phần
mềm không tìm thấy chúng, khách hàng sẽ tìm thấy.
Thường có một số quan niệm sai có thể dẫn đến kết luận sai từ sự tranh
luận trên: (1) người phát triển phần mềm sẽ không thực hiện một kiểm định
nào ; (2) phần mềm sẽ được “tung lên tường” để một người lạ sẽ kiểm định nó
một cách khắt khe; và (3) những người kiểm định tham gia dự án chỉ khi các
bước kiểm định sắp bắt đầu. Mỗi phát biểu trên là không đúng.
Người phát triển phần mềm luôn có trách nhiệm kiểm định các đơn vị
(module) riêng biệt của chương trình, đảm bảo rằng mỗi đơn vị thực hiện
chức năng mà nó đã được thiết kế. Trong nhiều trường hợp, người phát triển

cũng thực hiện việc kiểm định tích hợp – là bước kiểm định mà đưa đến việc
xây dựng (và kiểm định) cấu trúc chương trình hoàn thiện. Chỉ sau khi kiến
trúc phần mềm hoàn thành thì nhóm kiểm nhóm kiểm định độc lập mới được
huy động.
Vai trò của nhóm kiểm định độc lập (ITG) là để loại bỏ các vấn đề cố
hữu liên quan đến việc người phát triển tự kiểm định những gì đã được xây
dựng. Kiểm định độc lập cũng loại bỏ các xung đột khác có thể xảy ra. Cuối
cùng, nhân viên nhóm độc lập được trả lương để tìm các lỗi.
Tuy nhiên, người phát triển phần mềm không bàn giao hoàn toàn
chương trình cho ITG, mà người phát triển và nhóm kiểm định độc lập làm
việc thân thiện với nhau xuyên suốt dự án phần mềm để đảm bảo rằng toàn bộ
các kiểm định đã được thực hiện. Trong khi kiểm định được thực hiện, người
phát triển cần phải sẵn sàng để sữa các lỗi được phát hiện.
Nhóm kiểm định độc lập là một phần của nhóm dự án phát triển phần
mềm theo nghĩa họ sẽ được huy động trong suốt quá trình đặc tả và liên quan
(lập kế hoạch và đặc tả các thủ tục kiểm định) theo suốt một dự án lớn. Tuy
nhiên, trong nhiều trường hợp các báo cáo của nhóm kiểm định độc lập
chuyển đến cho tổ chức đảm bảo chất lượng phần mềm, do đó việc đạt được
một mức độ độc lập là không thể nếu nhóm này là một phần của tổ chức phát
triển phần mềm. Tiến trình công nghệ phần mềm có thể được xem như một
xoắn ốc, hình 3.1.
Việc phát triển phần mềm, đi vào dọc theo đường xoắn ốc, giảm dần
các mức trừu tượng trên mỗi vòng, gồm các bước:
Công nghệ hệ thống Phân tích yêu cầu Thiết kế Mã hoá.
Chiến lược kiểm định phần mềm cũng có thể di chuyển dọc theo đường
xoắn ốc và đi ra theo đường xoắn ốc theo luồng mở rộng phạm vi kiểm định
trên mỗi vòng, tức theo thứ tự ngược lại, tương ứng như sau:

Kiểm định hệ thống Kiểm định tính hợp lệ Kiểm định tích hợp Kiểm định đơn
vị.

Hình 3. - Chiến lược kiểm định
Theo quan điểm thủ tục, kiểm định nằm trong ngữ cảnh công nghệ phần
mềm trên thực tế là dãy bốn bước được cài đặt tuần tự. Các bước được mô tả
như hình 3.2.

Hình 3. – Các bước kiểm định
1. Kiểm định đơn vị: tập trung trên mỗi module riêng biệt, đảm bảo rằng
các chức năng của nó tương ứng với một đơn vị. Sử dụng thiên về kỹ thuật
kiểm định hộp trắng, thực hiện các đường dẫn độc lập trong cấu trúc điều
khiển của module để đảm bảo phủ hoàn toàn và phát hiện lỗi tối đa.
2. Kiểm định tích hợp: tập trung vào việc thiết kế và xây dựng kiến trúc
phần mềm. Các thành phần phải được lắp ráp lại hoặc tích hợp lại thành một
gói phần mềm hoàn chỉnh. Bước này nhằm kết hợp việc xác minh và xây
dựng chương trình. Các kỹ thuật thiết kế trường hợp kiểm định hộp đen là phổ

biến nhất trong việc tích hợp, tuy nhiên cũng có thể sử dụng hạn chế kiểm
định hộp trắng để đảm bảo phủ hết các đường dẫn điều khiển chính.
3. Kiểm định tính hợp lệ: trong đó các yêu cầu đã được thiết lập như một
phần của việc phân tích yêu cầu phần mềm được thẩm định, dựa vào phần
mềm đã xây dựng. Tiêu chuẩn hợp lệ (được thiết lập trong quá trình phân tích
yêu cầu) cần được kiểm định. Kiểm định nhằm cung cấp sự đảm bảo cuối
cùng là phần mềm đã thoả mãn các chức năng, hành vi và các yêu cầu thực
hiện. Chỉ sử dụng kỹ thuật hộp đen trong quá trình thẩm định.
4. Kiểm định hệ thống: là một phần của công nghệ hệ thống máy tính,
trong đó phần mềm và các thành phần khác của hệ thống được kiểm định.
Phần mềm được thẩm định một lần nữa, cần được kết hợp với các thành phần
khác của hệ thống (phần cứng, con người, cơ sở dữ liệu,..). Kiểm định hệ
thống nhằm xác minh rằng tất cả các thành phần hệ thống khớp nhau một
cách hợp lý, và tất cả các chức năng hệ thống và hiệu suất là đạt được.
3.2.3. Điều kiện hoàn thành kiểm định

Thật ra, “không bao giờ hoàn thành việc kiểm định, trách nhiệm này
thường chuyển từ người phát triển cho các khách hàng”. Mỗi lần, khách hàng
(người sử dụng) thực hiện chương trình máy tính, chương trình sẽ được kiểm
định với tập dữ liệu mới. Có rất nhiều tranh cãi về câu trả lời cho câu hỏi trên,
tuy nhiên, các kỹ sư phần mềm cần phải có các tiêu chuẩn chặt chẽ để xác
định khi nào kiểm định đạt hiệu quả.
Heiser (1997) đưa ra bốn tiêu chuẩn có thể cho việc kết thúc kiểm định:
- Khi dự án hết tiền hoặc thời gian.
- Khi đội ngũ kiểm định không nghĩ được thêm một trường hợp kiểm định nào.
- Khi kiểm định được tiếp tục mà không phát hiện được bất kỳ lỗi mới nào.
- Khi đạt đến một mức của độ phủ thích hợp.

Chiến lược phổ biến nhất hiện nay là kiểm định cho đến khi dự án hết
tiền hoặc thời gian. Tuy nhiên, chiến lược này sẽ bao gồm một vài rủi ro: nếu
việc phát triển đã vượt quá ngân sách thì việc kiểm định sẽ kém chất lượng.
Một chiến lược khác là sử dụng mô hình thống kê và lý thuyết độ tin cậy
phần mềm, các mô hình thất bại phần mềm (được phát hiện trong quá trình
kiểm định) theo hàm thời gian thực hiện có thể được phát triển. Mô hình thất
bại được gọi là mô hình thời gian thực hiện lôga Poisson, có dạng:
1
 
f(t) =  p  ln[lopt + 1]

(3.)

trong đó:
- f(t) là số thất bại luỹ tích được dự đoán xuất hiện mỗi lần phần mềm
được kiểm định trong khoảng thời gian thực hiện t nào đó.
- lo là cường độ thất bại phần mềm ban đầu (số thất bại trên một đơn vị
thời gian) khi bắt đầu kiểm định.
- p là biến đổi số mũ trong cường độ thất bại do các lỗi được phát hiện và
các khắc phục được thực hiện.
Cường độ thất bại tức thời, l(t) có thể được suy ra bằng cách tính đạo
hàm f(t):
lo
l(t) = l o pt + 1

(3.)

Sử dụng quan hệ được ghi trong phương trình (3.2), người kiểm định có
thể dự đoán việc giảm lỗi trong quá trình kiểm định. Cường độ lỗi thực tế có
thể được vẽ dọc theo đường cong dự đoán (Hình 3.3). Nếu dữ liệu thực tế
được tập hợp lại trong quá trình kiểm định và mô hình thời gian thực hiện
loga Poisson là phù hợp với nhau trên một số điểm dữ liệu, mô hình có thể

được sử dụng để dự đoán tổng thời gian thực hiện cần để đạt được tỷ lệ thất
bại có thể chấp nhận được.

Hình 3. - Mật độ lỗi là hàm thời gian thực hiện

Bằng các phép tập hợp trong việc kiểm định và sử dụng các mô hình độ
tin cậy phần mềm đang tồn tại, có thể phát triển chỉ dẫn để trả lời cho câu hỏi:
“Khi nào chúng ta hoàn thành kiểm định?”
Hình 3.4 chỉ ra mối quan hệ giữa số lượng kiểm định được thực hiện và
số lỗi được tìm thấy. Nếu chúng ta kiểm định quá nhiều thì chi phí sẽ tăng
một cách khó chấp nhận được, ngược lại nếu kiểm định ít thì chi phí thấp,
nhưng sẽ còn nhiều lỗi. Số lượng kiểm định tối ưu chỉ ra rằng chúng ta không
kiểm định quá nhiều nhưng cũng không ít quá.
Hình 3.- Quan hệ giữa chi phí kiểm định và số lỗi chưa được phát hiện

3.3. Kiểm định đơn vị
Kiểm định đơn vị tập trung vào việc xác minh trên đơn vị nhỏ nhất của
thiết kế phần mềm – thành phần phần mềm, module hoặc lớp. Sử dụng các
mô tả thiết kế thủ tục để hướng dẫn, các đường dẫn điều khiển quan trọng
được kiểm định để phát hiện lỗi trong phạm vi module. Độ phức tạp liên quan
của các kiểm định và các lỗi đã phát hiện được giới hạn bởi ràng buộc phạm
vi thiết lập cho kiểm định đơn vị. Kiểm định đơn vị thường hướng hộp trắng,
và các bước có thể được thực hiện song song trên nhiều module.