Quá trình thầm tra và xác nhận khi xây dựng phần mềm Đề tài môn kỹ nghệ phần mềm

HỌC VIỆN KỸ THUẬT MẬT MÃ
KHOA CÔNG NGHỆ THÔNG TIN
.......................

BÀI TẬP LỚN MÔN

CÔNG NGHỆ PHẦN MỀM

ĐỀ TÀI:
VERIFICATION AND VALIDATION
(XÁC MINH VÀ XÁC NHẬN)

Giáo viên hướng dẫn: Lê Bá Cường
Nhóm sinh viên thực hiện:
Nhóm 5 – Lớp AT6B:

Hà Văn Trường
Nguyễn Việt Long
Đỗ Văn Tiền
Nguyễn Như Tỉnh

Hà Nội, 10/2012


NHẬN XÉT CỦA GIÁO VIÊN

..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................

..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................
..............................................................................................................................

2


MỤC LỤC
Trang
Nhận xét của giáo viên...............................................................................1
Mục lục.......................................................................................................2
Danh mục các hình vẽ................................................................................3
Lời nói đầu..................................................................................................4
Giới thiệu ...................................................................................................5
22.1. Lập kế hoạch xác minh và xác nhận................................................10
22.2. Kiểm tra phần mềm ........................................................................ 15
Các chương trình kiểm tra quá trình ............................................. 17
22.3. Phân tích tĩnh tự động......................................................................23
22.4. Xác minh và phương pháp hình thức...............................................28
22.4.1 Phát triển phần mềm phòng sạch (Cleanroom)...................30
Kết luận.....................................................................................................35

3


DANH MỤC CÁC HÌNH VẼ
Danh mục các hình vẽ

Trang

Hình 22.1 Xác minh và xác nhận tĩnh và xác minh và xác nhận
tĩnh động.
Hình 22.2 Các quá trình gỡ lỗi.

7

Hình 22.3 Mô hình quá trình phát triển phần mềm.

11

Hình 22.4 Cấu trúc của một kế hoạch thử nghiệm phần mềm.

13

Hình 22.5 Vai trò của từng đối tượng trong quá trình kiểm tra.

18

Hình 22.6 Các quá trình kiểm tra.

19

Hình 22.7 Quá trình kiểm tra.

22

Hình 22.8 Kiểm tra phân tích tĩnh tự đông.

24

Hình 22.9 Ví dụ về phân tích tĩnh LINT.

27

Hình 22.10 Quá trình phát triển phòng sạch.

31

9

4


Lời Nói Đầu
Ngày nay công nghệ thông tin phát triển mạnh mẽ, kéo theo đó là
công nghệ phần mềm ngày một phát triển. Phần mềm đem lại cho người
dùng phát triển, xây dựng duy trì một hệ thống nào đó. Như vậy nó có vai
trò quan trọng trong thực tiễn, Để một phần mềm được sử dụng nó phải
trải qua nhiều khâu từ nhưng khâu đầu tiên xây dựng ý tưởng đến khâu
đưa vào thực tiễn. Trong quá trình đó không thể không nhắc đến Thẩm
Tra và Xác Nhận. Đây cũng là nội dung chúng em muốn trình bày trong
đề tài này.
Thẩm tra: Xem xét một sản phẩm có được được làm đúng theo yêu
cầu đặc tả hay không. xác nhận tính hợp lệ : Phần mềm cần phải làm
những gì mà người dùng thật sự yêu cầu. Việc kiểm tra cho thấy tính phù
hợp với các đặc tả. Việc xác nhận cho thấy chương trình đã đáp ứng nhu
cầu của người dùng hay chưa. Kế hoạch kiểm tra phải được lập để hướng
dẫn quá trình thử nghiệm. Như vậy đây là bước quan trọng khi một phần
mềm đưa ra sản phẩm
Trong quá trình thực hiện đề tài nhóm em không khỏi mắc phải
thiếu sót. Mong thầy đóng góp ý kiến để chúng em có thể hoàn thiện tốt
hơn trong những đề tài sau này.
Em xin chân thành cảm ơn.

Sinh viên thực hiện:

Hà văn Trường
Nguyễn việt Long
Đỗ văn Tiền
Nguyễn như Tỉnh

5


CHƯƠNG 22: XÁC MINH VÀ XÁC NHẬN
Giới thiệu:
Mục tiêu: Mục tiêu của chương này là để giới thiệu phần mềm xác minh
và xác nhận đặc biệt tập trung vào các kỹ thuật xác minh tĩnh. Khi bạn đã
đọc chương này, bạn sẽ:
 Giới thiệu về thẩm tra và xác nhận phần mềm, cùng với thảo luận
sự khác biệt giữa chúng.
 Mô tả quá trình kiểm tra chương trình và vai trò của nó trong V&V
(Verification and Validation).
 Giải thích phân tích tĩnh là một kỹ thuật thẩm tra.
 Mô tả quá trình phát triển phần mềm phòng sạch (Cleanroom
software development)
Nội dung:
 22.1. Lập kế hoạch V&V.
 22.2. Kiểm tra phần mềm (Software inspections).
 22.3. Phân tích tĩnh tự động (Automated static analysis).
 22.4. Xác minh và phương pháp hình thức.
Trong và sau quá trình thực hiện, chương trình đang được phát
triển phải được kiểm tra để đảm bảo rằng nó đáp ứng đặc điểm kỹ thuật
của nó và cung cấp các chức năng dự kiến của người dùng phần mềm.

Xác minh và xác nhận (V&V) là tên được đặt cho các quá trình kiểm tra
và phân tích. Xác minh và các hoạt động diễn ra ở từng giai đoạn của quá
trình phát triển phần mềm. V&V bắt đầu với đánh giá yêu cầu và tiếp tục
thông qua các đánh giá thiết kế và kiểm tra mã để thử nghiệm sản phẩm.
Xác minh và xác nhận là hai công việc khác nhau, mặc dù thường
bị nhầm lẫn. Boehm (Boehm, 1979) đã diễn tả một cách ngắn gọn sự
khác biệt giữa chúng:
 ’Xác minh: Phần mềm chúng ta xây dựng có phù hợp với các đặc
tả của nó hay không?’
 ’Xác nhận: Phần mềm cần phải những gì mà người dùng thật sự
yêu cầu?’
Các định nghĩa này cho biết vai trò của các xác minh liên quan đến
việc kiểm tra được phần mềm phù hợp với đặc điểm kỹ thuật của nó.
6


Chúng ta nên kiểm tra xem nó đáp ứng yêu cầu quy định chức năng và
phi chức năng của nó. Xác nhận, tuy nhiên, là một quá trình chung. Mục
đích của việc xác nhận là để đảm bảo rằng hệ thống phần mềm đáp ứng
các mong đợi của khách hàng. Nó vượt ra ngoài tầm kiểm tra mà hệ
thống đáp ứng được, đặc điểm này cho thấy rằng các phần mềm đáp ứng
những gì mà khách hàng mong đợi. Hệ thống phần mềm không phản ánh
những mong muốn thực sự nhu cầu của người sử dụng và chủ sở hữu hệ
thống.
Mục tiêu cuối cùng của quá trình xác minh và xác nhận là thiết lập
sự tin tưởng rằng hệ thống phần mềm "phù hợp cho mục đích”. Điều này
có nghĩa là hệ thống phải tốt, đủ cho mục đích sử dụng của nó. Mức độ
của sự tin cậy cần thiết phụ thuộc vào mục đích của hệ thống, sự mong
đợi của người sử dụng hệ thống và tiếp thị môi trường hiện tại cho hệ
thống:

1. Chức năng của phần mềm: Mức độ tin cậy phụ thuộc vào
tầm quan trọng của phần mềm đến một một tổ chức. Ví dụ,
mức độ tin cậy cho phần mềm được sử dụng để điều khiển
một hệ thống an toàn là cao hơn rất nhiều hơn so với yêu cầu
cho một hệ thống phần mềm nguyên mẫu đã được phát triển
để chứng minh một số ý tưởng mới.
2. Mong đợi của người dùng: Là một sự phản ánh chắc chắn về
ngành công nghiệp phần mềm mà nhiều người sử dụng có
những kỳ vọng thấp của phần mềm của họ, không ngạc
nhiên nó phù hợp trong suốt quá trình sử dụng. Họ sẵn sàng
chấp nhận những lỗi hệ thống khi các lợi ích của việc sử
dụng nhiều hơn kể từ những năm 90 của thế kỉ XX. Bây giờ
nó ít được chấp nhận để cung cấp cho các hệ thống không
đáng tin cậy, vì vậy các công ty phần mềm phải dành nhiều
nỗ lực hơn trong việc xác minh và xác nhận.
3. Tiếp thị thị trường: Khi một hệ thống được thương mại hóa,
những người bán hàng của hệ thống phải đưa vào chương
trình cạnh tranh khách hàng, khách hàng sẵn sàng trả tiền
cho một hệ thống và tiến độ theo yêu cầu cho việc cung cấp
hệ thống đó. Trường hợp một công ty có vài đối thủ cạnh
tranh, nó có thể quyết định để phát hành một chương trình
trước khi nó đã được kiểm tra đầy đủ và sửa lỗi bởi vì họ
muốn là người đầu tiên vào thị trường. Trường hợp khách
hàng không sẵn sàng trả giá cao cho các phần mềm, họ phải
chịu lỗi phần mềm. Tất cả những yếu tố này phải được xem
7


xét khi quyết định nên được dành nhiều nỗ lực như thế nào
vào quá trình V&V.

Hình 22.1 Xác minh và xác nhận tĩnh, xác minh và xác nhận tĩnh động.
Hình 22.1 cho ta thấy kiểm tra và thử nghiệm phần mềm đóng vai
trò hỗ trợ trong quá trình làm phần mềm. Các mũi tên chỉ ra các giai đoạn
trong quá trình mà các kỹ thuật có thể được sử dụng. Vì vậy, chúng ta có
thể kiểm tra phần mềm ở tất cả các giai đoạn của quá trình làm phần
mềm. Bắt đầu với các yêu cầu, bất kỳ biểu diễn nào mà phần mềm có thể
đọc được thì đều có thể được kiểm tra. Yêu cầu và đánh giá thiết kế kỹ
thuật chính được sử dụng để phát hiện các lỗi trong các đặc điểm kỹ thuật
và thiết kế.
Trong quá trình V&V, có hai cách tiếp cận bổ sung cho kiểm tra hệ
thống và phân tích:
1. Kiểm tra phần mềm hoặc đánh giá phân tích và kiểm tra các đặc
trưng cho hệ thống như các tài liệu yêu cầu, sơ đồ thiết kế và mã
nguồn của chương trình. Chúng ta có thể sử dụng kiểm tra ở tất cả
các giai đoạn mã nguồn của một hệ thống hoặc các tài liệu liên
quan. Kiểm tra phần mềm và phân tích tự động là kỹ thuật V&V
tĩnh, không cần phải chạy phần mềm trên một máy tính.
2. Kiểm thử phần mềm liên quan đến việc chạy một thực thi của phần
mềm với các dữ liệu thử nghiệm. Kiểm tra đầu ra của phần mềm và
cách hoạt động của nó để kiểm tra xem nó có thực hiện theo yêu
cầu không? Thử nghiệm là một kỹ thuật xác minh và xác nhận
động.

8


Chúng ta chỉ có thể thử nghiệm một hệ thống khi một nguyên mẫu
hoặc một phiên bản thực thi của một chương trình có sẵn. Một lợi thế của
phát triển gia tăng là phiên bản có thể kiểm tra của một hệ thống là có sẵn

ở một giai đoạn trong quá trình phát triển. Chức năng có thể được kiểm
tra khi nó được thêm vào hệ thống do đó chúng ta không cần phải có một
thực hiện đầy đủ trước khi thử nghiệm bắt đầu.
Kỹ thuật kiểm tra bao gồm kiểm tra chương trình, tự động phân
tích mã nguồn và xác minh hình thức. Tuy nhiên, kỹ thuật tĩnh chỉ có thể
kiểm tra sự tương ứng giữa một chương trình và phần của nó (xác minh),
nó không thể chứng minh rằng phần mềm là còn hoạt động hữu ích.
Chúng ta cũng không thể sử dụng các kỹ thuật tĩnh để kiểm tra các thuộc
tính nổi bật của phần mềm chẳng hạn như hiệu suất và độ tin cậy của nó.
Mặc dù kiểm tra phần mềm đang được sử dụng rộng rãi nhưng thử
nghiệm chương trình sẽ luôn luôn được dùng kỹ thuật xác minh và xác
nhận phần mềm chính. Thử nghiệm liên quan đến việc thực thi chương
trình bằng cách sử dụng dữ liệu như các dữ liệu thực tế được xử lý bởi
chương trình. Chúng ta phát hiện ra khuyết tật chương trình hoặc bất cập
bằng cách kiểm tra các kết quả đầu ra của chương trình và tìm kiếm bất
thường. Thử nghiệm có hai loại khác nhau có thể được sử dụng ở các giai
đoạn khác nhau trong quá trình làm phần mềm:
1. Thử nghiệm xác nhận được dự định để cho thấy rằng khách hàng
muốn phần mềm đáp ứng yêu cầu của nó. Là một phần của thử
nghiệm xác nhận, chúng ta có thể sử dụng thử nghiệm thống kê để
kiểm tra việc thực thi chương trình và độ tin cậy, và kiểm tra xem
trong tình trạng hoạt động nó hoạt động như thế nào.
2. Khuyết điểm của thử nghiệm được thiết kế để tìm ra các khiếm
khuyết trong hệ thống chứ không phải là sử dụng để mô phỏng
hoạt động của nó. Mục đích của kiểm tra lỗi là để tìm sự mâu thuẫn
giữa một chương trình và đặc điểm kỹ thuật của nó.
Tất nhiên, không sự cứng nhắc về ranh giới giữa các phương pháp
tiếp cận để thử nghiệm. Trong quá trình thử nghiệm xác nhận, chúng ta sẽ
tìm thấy khiếm khuyết trong hệ thống, khiếm khuyết trong quá trình thử
nghiệm, một số các bài kiểm tra sẽ hiển thị chương trình đáp ứng yêu cầu

của nó.
Quá trình V&V và gỡ lỗi thường xen kẽ. Khi bạn phát hiện ra lỗi
trong chương trình mà bạn đang thử nghiệm, bạn phải thay đổi chương

9


trình để sửa chữa những lỗi lầm. Tuy nhiên, thử nghiệm (hoặc, nói chung
xác minh và xác nhận) và gỡ lỗi có mục tiêu khác nhau:
1. Quá trình xác minh và xác nhận này được dự định để thiết lập sự
tồn tại của khiếm khuyết trong một hệ thống phần mềm.
2. Gỡ lỗi là một quá trình (Hình 22.2) mà nó xác định và sửa chữa
những khiếm khuyết.

Hình 22.2 Các quá trình gỡ lỗi
Không có phương pháp đơn giản để gỡ lỗi chương trình. Kỹ năng
gỡ rối tìm kiếm các khuôn mẫu trong đầu ra, nơi mà lỗi được tìm thấy và
sử dụng những hiểu biết về các loại lỗi, khuôn mẫu đầu ra, ngôn ngữ lập
trình và quá trình lập trình để xác định vị trí các khuyến khuyết. Khi gỡ
lỗi, chúng ta có thể sử dụng kiến thức của mình về các lỗi lập trình phổ
biến (chẳng hạn như lỗi tăng số đếm) và phù hợp với các đối với các
khuôn mẫu quan sát. Chúng ta cũng nên tìm các lỗi đặc trưng của ngôn
ngữ lập trình.
Định vị các lỗi trong một chương trình không phải là một quá trình
đơn giản, vì các lỗi có thể không gần điểm nơi mà chương trình bị lỗi. Để
xác định vị trí một lỗi chương trình, chúng ra có thể có để thiết kế các bài
kiểm tra bổ sung tái tạo lỗi ban đầu và xác định vị trí của nó trong chương
trình. Chúng ra có thể theo dõi từng dòng trong chương trình bằng tay, gỡ
lỗi các công cụ thu thập thông tin về việc thực thi chương trình cũng có
thể giúp xác định vị trí nguồn gốc của một vấn đề.

Công cụ gỡ lỗi là một phần của một tập hợp các công cụ hỗ trợ
ngôn ngữ được tích hợp với một hệ thống biên dịch. Chúng cung cấp một
môi trường thời gian chạy chuyên dụng cho các chương trình cho phép
truy cập vào bảng biểu tượng của trình biên dịch và các giá trị của các
biến chương trình. Chúng ta có thể kiểm soát thực thi bởi “step ping”

10


thông qua báo cáo kết quả chương trình bằng cách lệnh. Sau khi từng
lệnh đã được thực hiện, kiểm tra giá trị của biến và từ đó, tìm ra được vị
trí của lỗi.
Sau khi một khiếm khuyết trong chương trình đã được phát hiện,
chúng ta phải điều chỉnh lại và hợp lệ lại hệ thống. Điều này có thể liên
quan đến việc kiểm tra lại chương trình, kiểm tra ngược trở lại nơi thử
nghiệm hiện tại thì được thực thi một lần nữa. Kiểm tra ngược trở lại
được sử dụng để kiểm tra xem các thay đổi được thực thi cho một chương
trình đã giới thiệu lỗi mới. Kinh nghiệm cho thấy một tỷ lệ cao sửa chữa
lỗi hoặc là không đầy đủ hoặc giới thiệu các lỗi mới vào chương trình.
Về nguyên tắc, chúng ta nên lặp lại tất cả các bài kiểm tra sau mỗi
lần sửa chữa khiếm khuyết, trong thực tế, điều này thường là tốn chi phí.
Là một phần của kế hoạch kiểm tra, chúng ta nên xác định phụ thuộc giữa
các thành phần và các bài kiểm tra liên quan đến mỗi thành phần. Đó là,
cần phải có truy xuất nguồn gốc từ các trường hợp thử nghiệm các thành
phần được kiểm tra. Nếu truy xuất nguồn gốc này được hỗ trợ bởi các tài
liệu, sau đó chúng ta có thể chạy một tập hợp con các trường hợp thử
nghiệm hệ thống để kiểm tra các thành phần sửa đổi và những phụ thuộc
của nó.

11

22.1. Lập kế hoạch xác minh và xác nhận:
Xác minh và xác nhận là một quá trình tốn kém. Đối với một số hệ
thống, chẳng hạn như các hệ thống thời gian thực với những ràng buộc
phi chức năng phức tạp, hơn một nửa ngân sách phát triển hệ thống có thể
được dành cho V & V. Lập kế hoạch cẩn thận là cần thiết để nhận được
kết quả tốt nhất của các quá trình thử nghiệm và kiểm tra, và để kiểm soát
chi phí quá trình xác minh và xác nhận.

Hình 22.3 Mô hình quá trình phát triển phần mềm
Chúng ta nên bắt đầu lập kế hoạch xác nhận và kiểm tra hệ thống
sớm trong quá trình phát triển. Quá trình phát triển phần mềm thể hiện
trong mô hình Hình 22 3 đôi khi được gọi là V-model. Nó là một ví dụ cụ
thể của mô hình thác nước chung (xem Chương 4) và cho thấy rằng kế
hoạch kiểm tra nên được bắt nguồn từ các đặc điểm kỹ thuật và thiết kế
hệ thống. Mô hình này cũng phá vỡ hệ thống V & V vào một số giai
đoạn. Mỗi giai đoạn được điều khiển bằng cách thử nghiệm rằng đã được
xác định để kiểm tra sự phù hợp của chương trình với thiết kế và đặc
điểm kỹ thuật của nó.
Là một phần của quá trình lập kế hoạch V & V, chúng ta nên quyết
định sự cân bằng giữa cách tiếp cận tĩnh và động để xác minh và xác
nhận, lập các tiêu chuẩn và thủ tục cho việc kiểm tra và thử nghiệm phần
mềm, thiết lập danh sách kiểm tra để điều khiển sự kiểm tra chương trình
(xem Phần 22.3) và xác định kế hoạch kiểm tra phần mềm.
Những nỗ lực tương quan dành cho kiểm tra và thử nghiệm phụ
thuộc vào kiểu hệ thống đang được phát triển và tổ chức chuyên môn với

12

sự kiểm tra chương trình. Như một quy tắc chung, một hệ thống then chốt
hơn, nỗ lực nhiều hơn nên được dành cho các kỹ thuật xác minh tĩnh.
Kế hoạch thử nghiệm là có liên quan với các thiết lập tiêu chuẩn
cho quá trình thử nghiệm không chỉ mô tả các thử nghiệm sản phẩm.
Cũng như giúp các nhà quản lý phân phối nguồn lực và lịch trình đánh
giá thử nghiệm, thử nghiệm kế hoạch dành cho các kỹ sư phần mềm liên
quan đến thiết kế và tiến hành thử nghiệm hệ thống. Họ giúp nhân viên
kỹ thuật có được một bức tranh tổng thể của các thử nghiệm hệ thống và
đặt công việc của mình trong bối cảnh này. Một bản mô tả tốt thử nghiệm
kế hoạch và mối quan hệ của họ để chất lượng kế hoạch tổng quát hơn
được đưa ra trong Frewin và Hatton (Frewin và Hatton, 1986). Humphrey
(Humphrey, 1989) và Kit (Kit, năm 1995) cũng bao gồm các cuộc thảo
luận về kế hoạch thử nghiệm.
Các thành phần chính của một kế hoạch thử nghiệm cho một hệ
thống lớn và phức tạp được thể hiện trong Hình 22.4 bên dưới. Cũng như
đặt ra lịch trình thử nghiệm và thủ tục, sự thử nghiệm kế hoạch xác định
các nguồn tài nguyên phần của cứng và phần mềm được yêu cầu. Điều
này rất hữu ích cho các nhà quản lý hệ thống - những người có trách
nhiệm để đảm bảo rằng các nguồn lực sẵn có cho nhóm thử nghiệm. Kế
hoạch kiểm tra thường bao gồm số lượng đáng kể các sự kiện ngẫu nhiên
xảy ra làm cho không giữ đúng được mục tiêu trong thiết kế và thi hành
có thể được cung cấp và nhân viên tái triển khai các hoạt động khác.

13


Quá trình thử nghiệm
Mô tả về các giai đoạn chính của quá trình thử nghiệm. Điều này có thể
được mô tả trước đó trong chương này.

Định ra yêu cầu
Người dùng quan tâm nhiều nhất trong các cuộc họp về đáp ứng yêu cầu
và thử nghiệm của hệ thống nên được lên kế hoạch để tất cả các yêu cầu
được từng người thử nghiệm.
Thử nghiệm các mặt hàng
Các sản phẩm của quá trình phần mềm có thể được thử nghiệm thì nên
được chỉ định.
Kế hoạch thử nghiệm
Rõ ràng một lịch trình kiểm tra tổng thể và phân bổ nguồn lực cho kế
hoạch này liên quan đến lịch phát triển dự án tổng quát hơn.
Bản ghi của các thử nghiệm
Nó là không đủ đơn giản để chạy thử nghiệm, kết quả thử nghiệm phải
được hệ thống ghi lại. Nó phải được kiểm toán các quá trình thử nghiệm
để kiểm tra xem nó đã được thực thi một cách chính xác hay chưa.
Yêu cầu về phần cứng và phần mềm
Phần này nên đặt ra các công cụ phần mềm được yêu cầu và ước tính sử
dụng phần cứng.
Hạn chế
Hạn chế ảnh hưởng đến quá trình thử nghiệm như thiếu nhân viên nên
được dự kiến trong phần này.
Hình 22.4 Cấu trúc của một kế hoạch thử nghiệm phần mềm
Đối với các hệ thống nhỏ hơn, một kế hoạch thử nghiệm ít chính
thức hơn có thể được sử dụng, nhưng vẫn còn có một nhu cầu cho một tài
liệu chính thức để hỗ trợ kế hoạch của quá trình thử nghiệm. Đối với một
số quá trình ngắn gọn như lập trình cực đoan, thử nghiệm thì không thể
tách rời phát triển. Giống như các hoạt động quy hoạch khác, kiểm tra lập
kế hoạch cũng gia tăng. Trong hệ điều hành Windows XP, khách hàng
chịu trách nhiệm cuối cùng để quyết định xem nên dành bao nhiêu nỗ lực
cho thử nghiệm hệ thống.

14


Kế hoạch kiểm tra không phải là một tài liệu tĩnh nhưng nó tiến
triển dần trong quá trình phát triển. Kế hoạch kiểm tra thay đổi vì sự
chậm trễ ở các giai đoạn khác trong quá trình phát triển. Nếu một phần
của một hệ thống là không đầy đủ, toàn bộ hệ thống không thể được thử
nghiệm. Sau đó chúng ta phải xem xét lại kế hoạch kiểm tra để tái phát
triển cho người thử nghiệm cho một số hoạt động khác và mang chúng
trở lại khi phần mềm có hiệu lực một lần nữa.

15


22.2. Kiểm tra phần mềm:
Kiểm tra phần mềm là một quá trình xác minh và xác thực (V&V)
tĩnh, trong đó một hệ thống phần mềm được xem xét để tìm lỗi, thiếu sót
và bất thường. Nói chung kiểm tra tập trung vào các mã nguồn, nhưng bất
kỳ biểu diễn có thể đọc được của phần mềm như yêu cầu của nó hoặc một
mô hình thiết kế có thể được kiểm tra. Khi chúng ta kiểm tra một hệ
thống, chúng ta sử dụng những hiểu biết về hệ thống, miền ứng dụng và
ngôn ngữ lập trình hoặc mô hình thiết kế để phát hiện ra lỗi.
Có ba lợi thế chính của sự kiểm tra qua thử nghiệm:
1. Trong quá trình thử nghiệm, các lỗi này có thể che khuất
(ẩn) các lỗi khác. Sau khi lỗi được phát hiện, chúng ta không
bao giờ có thể chắc chắn nếu bất thường ở đầu ra khác là do
một lỗi mới hoặc là tác dụng phụ của các lỗi ban đầu. Bởi vì
kiểm tra là một quá trình tĩnh, chúng ta không cần phải quan
tâm đến sự tương tác giữa các lỗi. Do đó, một phiên kiểm tra
duy nhất có thể phát hiện ra nhiều sai sót trong một hệ thống.

2. Phiên bản không đầy đủ của một hệ thống có thể được kiểm
tra mà không có chi phí bổ sung. Nếu một chương trình
không đầy đủ, sau đó chúng ta cần để phát triển khai thác
thử nghiệm chuyên môn để kiểm tra các bộ phận có sẵn.
Điều này rõ ràng là thêm vào các chi phí phát triển hệ thống.
3. Cũng như tìm kiếm cho khiếm khuyết của chương trình,
kiểm tra cũng có thể xem xét các thuộc tính chất lượng rộng
lớn hơn của một chương trình như vậy là phù hợp với tính di
động, tiêu chuẩn và bảo trì. Chúng ta có thể tìm kiếm không
hiệu quả, các thuật toán không phù hợp và lập trình kém có
thể làm cho hệ thống khó khăn để duy trì và cập nhật.
Kiểm tra là một ý tưởng cũ. Đã có một số nghiên cứu và thí
nghiệm đã chứng minh rằng việc kiểm tra có hiệu quả hơn để phát hiện
khiếm khuyết hơn so với chương trình kiểm nghiệm. Pagan (Fagan, 1986)
báo cáo rằng hơn 60% các lỗi trong một chương trình có thể được phát
hiện bằng cách sử dụng kiểm tra chương trình phi hình thức. Mills et al.
(Mills và cộng sự, 1987) cho thấy một cách tiếp cận kiểm tra hình thức
dựa trên lập luận đúng Ness có thể phát hiện hơn 90% các lỗi trong một
chương trình. Kỹ thuật này được sử dụng trong quá trình phòng sạch
Cleanroom được mô tả trong Mục 22.4. Selby và Basili (Selby, et al.,

16


1987) thực nghiệm so sánh hiệu quả của kiểm tra và thử nghiệm. Họ nhận
thấy rằng xem xét mã tĩnh hiệu quả hơn và ít tốn kém hơn so với thử
nghiệm khiếm khuyết trong phát hiện ra lỗi chương trình. Gilb và
Graham (Gilb và Graham 1993) cũng tìm thấy điều này là đúng.
Phê duyệt và thử nghiệm đều có ưu và nhược điểm và nên được sử
dụng với nhau trong quá trình xác minh và xác nhận. Thật vậy, Gilb và

Graham cho rằng một trong những sử dụng hiệu quả nhất là để xem xét
các trường hợp thử nghiệm cho một hệ thống. Nhận xét có thể phát hiện
ra các vấn đề với các bài kiểm tra và có thể giúp cách thiết kế hiệu quả
hơn để kiểm tra hệ thống. Chúng ta có thể khởi động hệ thống V&V với
giám định sớm trong quá trình phát triển, nhưng một khi hệ thống được
tích hợp, chúng ta cần thử nghiệm để kiểm tra các thuộc tính mới xuất
hiện và chức năng của hệ thống là những gì các chủ sở hữu của hệ thống
thực sự muốn.
Mặc dù sự thành công của kiểm tra, nó đã được chứng minh là khó
khăn để giới thiệu các kiểm tra chính thức vào nhiều tổ chức phát triển
phần mềm. Kỹ sư phần mềm có kinh nghiệm thử nghiệm chương trình
đôi khi bắt buộc phải chấp nhận rằng kiểm tra có thể có hiệu quả hơn để
phát hiện sai sót hơn so với thử nghiệm. Các nhà quản lý có thể nghi ngờ
bởi vì kiểm tra đòi hỏi chi phí bổ sung trong quá trình thiết kế và phát
triển. Họ có thể không muốn chấp nhận rủi ro rằng sẽ có không có tương
ứng trong quá trình thử nghiệm chương trình.
Phần mềm kiểm tra V&V đòi hỏi chi phí và kết quả tiết kiệm chi
phí sau khi đội phát triển trở nên có kinh nghiệm trong việc sử dụng. Hơn
nữa, có những vấn đề thực tế trong việc sắp xếp kiểm tra: Kiểm tra mất
thời gian để sắp xếp và xuất hiện làm chậm quá trình phát triển. Thật khó
khăn để thuyết phục khi một người quản lý bận rộn thì thời gian kiểm tra
này có thể được thực hiện sau đó, vì ít thời gian những người này đã dành
cho việc tìm lỗi chương trình.

17


Các chương trình kiểm tra quá trình
Chương trình kiểm tra đánh giá mà mục tiêu là chương trình phát
hiện khiếm khuyết. Khái niệm một quá trình kiểm tra hình thức lần đầu

tiên được phát triển tại IBM vào những năm 1970 (Fagan, 1976; Fagan,
1986). Bây giờ, đó là một phương pháp xác minh chương trình được sử
dụng rộng rãi, đặc biệt là trong công nghệ hệ thống then chốt. Từ phương
pháp ban đầu của Fagan một số phương pháp thay thế kiểm tra đã được
phát triển (Gilb và Graham 1993), tất cả đều dựa vào một đội với các
thành viên từ cơ sở trở lại khác nhau, cẩn thận đánh giá line-by-line của
mã nguồn chương trình.
Sự khác biệt chính giữa kiểm tra chương trình và các khác của
đánh giá chất lượng ở mục tiêu của kiểm tra là để tìm lỗi chương trình
chứ không phải là để xem xét các vấn đề thiết kế rộng hơn. Khuyết điểm
có thể là lỗi lô-gic, bất thường trong các mã có thể cho thấy một tình
trạng sai sót hoặc không tuân thủ với các tiêu chuẩn tổ chức, dự án.
Ngược lại, các loại đánh giá có thể được quan tâm nhiều hơn với chi phí
lịch trình, các giai đoạn chống lại tiến bộ hoặc đánh giá xem phần mềm
đó là có khả năng để đáp ứng các mục tiêu của tổ chức.
Việc kiểm tra chương trình là một quá trình hình thức được thực
hiện bởi một đội ít nhất bốn người. Thành viên trong đội có phân tích một
cách có hệ thống mã nguồn và chỉ ra những khiếm khuyết có thể. Trong
đề xuất ban đầu của Fagan, ông cho vai trò như tác giả, trình kiểm tra
người đọc và người điều hành. Người đọc đọc to mã cho đội kiểm tra, thử
nghiệm kiểm tra mã từ một quan điểm thử nghiệm và điều hành tổ chức
quá trình.
Khi các tổ chức đã đạt được kinh nghiệm với kiểm tra, đề xuất
khác cho các vai trò trong đội đã xuất hiện. Trong một cuộc thảo luận về
cách kiểm tra được giới thiệu thành công trong quá trình phát triển của
Hewlett-Packard, Grady và Văn Slack (Grady và Văn Slack, l94) đề nghị
sáu vai trò, như thể hiện trong hình 22.5. Họ không nghĩ rằng đọc chương
trình là cần thiết. Cùng một người có thể có nhiều hơn một vai trò vì vậy
số thành viên trong đội có thể thay đổi từ một kiểm tra đến những kiểm
tra khác. Gilb và Graham cho rằng kiểm tra nên được lựa chọn để phản

ánh các quan điểm khác nhau chẳng hạn như thử nghiệm, người dùng
cuối và quản lý chất lượng.

18


Các hoạt động trong quá trình kiểm tra được thể hiện trong hình
22.6. Trước khi bắt đầu một quá trình kiểm tra chương trình, điều quan
trọng là:
Vai trò
Mô tả
Tác giả hoặc chủ sở
• Các người lập trình hoặc người thiết kế
hữu
chịu trách nhiệm sản xuất chương trình, tài
liệu. Chịu trách nhiệm sửa chữa các khiếm
khuyết được phát hiện trong quá trình kiểm
tra.
Người kiểm tra
• Tìm kiếm các lỗi, thiếu sót và không nhất
quán trong các chương trình và tài liệu.
Cũng có thể xác định các vấn đề rộng hơn
là nằm ngoài phạm vi của đội kiểm tra.
Người đọc
• Trình bày các mã hoặc tài liệu tại một cuộc
họp kiểm tra.
Người chép bản thảo
• Ghi lại kết quả của cuộc họp kiểm tra.
Chủ tịch hoặc người
• Quản lý quá trình và tạo điều kiện cho việc

điều hành
kiểm tra. Báo cáo kết quả quá trình tới
giám đốc điều hành.
Giám đốc điều hành
• Có trách nhiệm cải thiện quá trình kiểm tra,
cập nhật danh sách kiểm tra, phát triển các
tiêu chuẩn, v.v…
Hình 22.5 Vai trò của từng đối tượng trong quá trình kiểm tra
1. Có một đặc điểm kỹ thuật chính xác của mã này để được kiểm tra.
Nó không thể kiểm tra một thành phần ở mức độ chi tiết cần thiết
để phát hiện các khi khiếm khuyết mà không có một đặc điểm kỹ
thuật hoàn chỉnh.
2. Các thành viên trong đội kiểm tra đã quen thuộc với các tiêu chuẩn
tổ chức.
3. Một cập nhật cuối cùng, phiên bản có thể biên soạn của mã này đã
được phân phối cho tất cả các thành viên trong đội. Không có điểm
kiểm tra mã số đó là gần như hoàn toàn ngay cả khi chậm trễ gây ra
sự gián đoạn lịch trình.
Người điều hành đội kiểm tra có trách nhiệm lập kế hoạch kiểm
tra. Điều này liên quan đến việc lựa chọn một đội kiểm tra, tổ chức một
phòng họp và đảm bảo rằng các tài liệu được kiểm tra và chi tiết kỹ thuật
19


của nó được hoàn thành. Chương trình phải được kiểm tra được trình bày
cho đội kiểm tra trong giai đoạn tổng quan khi mô tả những gì tác giả của
mã chương trình được dự định để làm. Tiếp theo là một khoảng thời gian
chuẩn bị cá nhân. Mỗi thành viên trong đội kiểm tra nghiên cứu các đặc
điểm kỹ thuật và chương trình và tìm kiếm các khiếm khuyết trong các
mã.

Nên dành ít thời gian cho việc kiểm tra chính nó (không quá hai
giờ) và nên tập trung vào phát hiện sai sót, sự phù hợp tiêu chuẩn và lập
trình kém chất lượng. Đội kiểm tra không nên đề nghị cách sửa chữa các
khiếm khuyết này, không nên đề nghị thay đổi các thành phần khác.
Sau kiểm tra, tác giả chương trình nên thay đổi nó phù hợp đã được
xác định. Trong giai đoạn tiếp theo, người điều hành nên quyết định liệu
một tái kiểm tra của mã này là cần thiết. Và có thể quyết định rằng một
tái kiểm tra hoàn toàn không cần thiết và rằng những khiếm khuyết đã
được cố định thành công. Chương trình này sau đó được sự chấp thuận
của người kiểm duyệt cho phát hành.

Hình 22.6 Các quá trình kiểm tra
Trong quá trình kiểm tra, một danh sách các lỗi lập trình phổ biến
thường được sử dụng để tập trung thảo luận. Danh sách kiểm tra này có
thể dựa trên các ví dụ danh sách kiểm tra từ sách hoặc từ kiến thức của
các khiếm khuyết được phổ biến trong một miền ứng dụng cụ thể. Chúng
ta cần các bản danh sách khác nhau cho các ngôn ngữ lập trình khác nhau
vì mỗi ngôn ngữ có lỗi của riêng đặc trưng của nó. Humphrey (Humphrey
1989), là một cuộc thảo luận toàn diện kiểm tra, đưa ra một số ví dụ của
các bản danh sách kiểm tra.
Danh sách kiểm tra này thay đổi tùy theo ngôn ngữ lập trình vì các
cấp độ kiểm tra khác nhau được cung cấp bởi trình biên dịch ngôn ngữ.
Ví dụ, một kiểm tra trình biên dịch Java thì hàm chức năng có số lượng
chính xác các thông số, trình biên dịch C thì không có. Kiểm tra là có thể
được thực hiện trong quá trình kiểm tra được thể hiện trong hình 22.7.
20


Gilb và Graham (Gilb và Graham, 1993) nhấn mạnh rằng mỗi tổ chức
nên phát triển danh sách kiểm tra riêng của mình dựa trên các tiêu chuẩn

và thực tiễn của địa phương. Danh sách kiểm tra cần được cập nhật
thường xuyên như các loại mới của các khiếm khuyết được tìm thấy.
Thời gian cần thiết cho một kiểm tra và số lượng mã có thể bị che
đậy phụ thuộc vào kinh nghiệm của đội kiểm tra, ngôn ngữ lập trình và
lĩnh vực ứng dụng. Cả hai Fagan tại IBM và Barnard và Price (Barnard
và Price, năm 1994), đã đánh giá quá trình kiểm tra cho phần mềm viễn
thông đến kết luận tương tự:
1. Khoảng 500 mã nguồn báo cáo mỗi giờ có thể được trình bày trong
giai đoạn tổng quan.
2. Trong quá trình chuẩn bị cá nhân, khoảng 125 báo cáo mã nguồn
mỗi giờ có thể được kiểm tra.
3. Từ 90 đến 125 báo cáo mỗi giờ có thể được kiểm tra trong cuộc
họp kiểm tra.
Với bốn người tham gia trong đội kiểm tra, chi phí kiểm tra 100
dòng mã là tương đương với một ngày người nỗ lực. Điều này giả định
rằng việc kiểm tra chính nó mất khoảng một giờ và mỗi thành viên trong
đội dành 1-2 giờ để chuẩn bị cho việc kiểm tra. Chi phí thử nghiệm khác
nhau và phụ thuộc vào số lượng các lỗi trong chương trình. Tuy nhiên, nỗ
lực cần thiết cho việc kiểm tra chương trình có lẽ ít hơn một nửa nỗ lực sẽ
được yêu cầu cho kiểm tra khiếm khuyết tương đương.

21


Lớp lỗi
Lỗi dữ liệu

Kiểm tra
• Có phải tất cả các biến trong chương trình
khởi tạo trước khi giá trị của chúng được sử

dụng?
• Có phải tất cả các hằng được đặt tên?
• Kích thước của một tập hợp trên mảng có
nên bằng kích thước của mảng?
• Nếu chuỗi ký tự được sử dụng, là một dấu
phân cách gán rõ ràng? Điều đó có gây nên
tràn bộ đệm không?

Lỗi điều khiển

• Đối với mỗi câu lệnh điều kiện, điều kiện có
đúng không?
• Mỗi vòng lặp có chắc chắn chấm dứt không?
• Thông báo có được đặt đúng trong ngoặc
không?
• Trong trường hợp thông báo, tất cả các
trường hợp có thể bị chiếm dụng không?
• Nếu một ngắt được yêu cầu sau mỗi trường
hợp trong thông báo, nó được bao gồm
không?

Lỗi vào/ra

• Có phải ất cả các biến đầu vào được sử dụng
không?
• Có phải tất cả các biến đầu ra chỉ rõ một giá
trị trước khi có đầu ra không?
• Đầu vào bất ngờ có thể gây ra sai lệch
không?

Lỗi giao diện

• Có phải tất cả các gọi hàm chức năng và
phương thức đều có các tham số chính xác?
• Các loại tham số hình thức và thực tế có phù
hợp? Là các tham số theo thứ tự đúng
không?
• Nếu các thành phần truy cập bộ nhớ chia sẻ,
thì có cùng một mô hình cấu trúc bộ nhớ
chia sẻ không?

Lỗi quản lý lưu trữ

•

Nếu một cấu trúc liên kết được sửa đổi, tất
cả các liên kết được bố trí một cách chính
xác không?
22


Nếu lưu trữ động được sử dụng, không gian
được phân bổ một cách chính xác không?
• Không gian có được phân bố lại rõ ràng sau
khi nó không còn cần thiết hay không?
•

Lỗi quản lý ngoại lệ

•

Tất cả các điều kiện lỗi đã đưa vào ngoại lệ
hay chưa?

Hình 22.7 Quá trình kiểm tra.
Một số tổ chức (GiIb và Graham, 1993) đã từ bỏ thử nghiệm thành
phần trong công tác kiểm tra. Họ đã tìm thấy rằng các kiểm tra chương
trình rất hiệu quả trong việc tìm ra lỗi, rằng các chi phí của kiểm tra thành
phần không hợp lý. Các tổ chức kiểm tra thành phần, kết hợp với hệ
thống kiểm tra, chiến lược V&V hiệu quả nhất.
Sự ra đời của kiểm tra có ý nghĩa đối với quản lý dự án. Quản lý là
quan trọng nếu kiểm tra là được chấp nhận bởi đội phát triển phần mềm.
Chương trình kiểm tra là một quá trình công cộng phát hiện lỗi so với quá
trình thử nghiệm thành phần thì riêng tư hơn. Chắc chắn, những sai lầm
được thực hiện bởi các cá nhân được tiết lộ cho các nhà lãnh đạo toàn bộ
lập trình theo tổ đội. Kiểm tra phải được đào tạo để quản lý các quá trình
một cách cẩn thận và để phát triển một nền giáo dục cung cấp hỗ trợ mà
không đổ trách nhiệm lên ai khi lỗi được phát hiện.
Là một tổ chức có kinh nghiệm trong quá trình kiểm tra, có thể sử
dụng kết quả kiểm tra để giúp cải tiến quy trình. Kiểm tra là một cách lý
tưởng để thu thập dữ liệu về các loại khiếm khuyết xảy ra. Đội kiểm tra,
các tác giả của mã đã được kiểm tra có thể đề nghị jcác lý do lý do tại sao
các khiếm khuyết này đã được giới thiệu. Bất cứ nơi nào có thể, quá trình
này sau đó sẽ được sửa đổi để loại bỏ những lý do cho các khiếm khuyết
để họ có thể tránh được trong các hệ thống trong tương lai.

23


22.3. Phân tích tĩnh tự động:

Sự kiểm tra là một trong những hình thức phân tích tĩnh chúng ta
kiểm tra các chương trình mà không thực hiện nó. Như đã thảo luận, kiểm
tra thường được thúc đẩy bởi các danh sách kiểm tra các lỗi và chẩn đoán
xác định các lỗi phổ biến trong các ngôn ngữ lập trình khác nhau. Đối với
một số chẩn đoán lỗi khô khan, nó có thể tự động quá trình kiểm tra các
chương trình chống lại danh sách này, đã dẫn đến sự phát triển của tự
động phân tích tĩnh cho các ngôn ngữ lập trình khác nhau.
Phân tích tĩnh là công cụ phần mềm mà quét văn bản nguồn của
một chương trình và phát hiện lỗi và dị thường có thể. Họ phân tích các
văn bản chương trình và do đó nhận ra các loại báo cáo trong chương
trình. Sau đó, họ có thể phát hiện xem báo cáo cũng được hình thành, suy
ra các dòng điều khiển trong chương trình, trong nhiều trường hợp, tính
toán các thiết lập của tất cả các giá trị có thể cho dữ liệu của chương
trình. Họ bổ sung cho các cơ sở phát hiện lỗi được cung cấp bởi trình
biên dịch ngôn ngữ. Chúng có thể được sử dụng như là một phần của quá
trình kiểm tra hoặc như là một V & V tiến trình hoạt động riêng biệt.
Mục đích của phân tích tĩnh tự động là để thu hút sự chú ý của một
kiểm tra đến dị thường trong chương trình, chẳng hạn như các biến được
sử dụng mà không cần khởi tạo, biến mà không sử dụng hoặc dữ liệu có
giá trị có thể đi ra khỏi phạm vi. Một số kiểm tra có thể được phát hiện
bằng cách phân tích tĩnh được thể hiện trong hình 22.8. Bất thường
thường là do các lỗi lập trình hoặc thiếu sót, do đó, họ làm nổi bật những
điều mà có thể bị sai khi chương trình được thực hiện. Tuy nhiên, chúng
ta nên hiểu rằng những bất thường không nhất thiết phải lỗi chương trình.
Chúng có thể là do cố ý hoặc có thể không có hậu quả xấu.

24


Các giai đoạn liên quan đến phân tích tĩnh bao gồm:

Lớp lỗi
Lỗi dữ liệu

Lỗi điểu khiển
Lỗi vào/ra
Lỗi giao diện

Lỗi quản lý lưu trữ

 Kiểm tra phân tích tĩnh.
 Biến được sử dụng trước khi khởi tạo.
 Các biến khai báo nhưng không bao giờ được
sử dụng.
 Biến được gán hai lần nhưng không bao giờ
được sử dụng giữa các phép gán.
 Mảng có thể có hành vi vi phạm ràng buộc.
 Không khai báo biến.
 Mã không thể truy cập tới.
 Rẽ nhánh không điều kiện trong các vòng
lặp.
 Biến đầu ra hai lần mà không được gán .
 Loại tham số bất xứng.
 Số tham số bất xứng.
 Không sử dụng các kết quả của các hàm chức
năng.
 Hàm hức năng và thủ tục không được gọi
đến.
 Không được gán con trỏ.
 Con trỏ số học.

Hình 22.8 Kiểm tra phân tích tĩnh tự đông.
1. Phân tích điều khiển lưu lượng: Giai đoạn này xác định và
làm nổi bật vòng lặp với nhiều đầu ra, đầu vào và. Mã không
thể truy cập tới là mã được bao quanh bởi vô điều kiện lệnh
goto hoặc đó là một nhánh của một lệnh nơi mà các điều
kiện bảo vệ có thể không bao giờ đúng.
2. Phân tích sử dụng dữ liệu: Giai đoạn này làm nổi bật cách
mà các biến trong chương trình được sử dụng. Nó sẽ phát
hiện những biến được sử dụng mà không cần khởi tạo trước
đó, các biến được viết hai lần mà không được gán cho nhiệm
vụ nào và các biến được khai báo nhưng không bao giờ được
sử dụng. Sử dụng phân tích dữ liệu cũng phát hiện ra không
có hiệu quả thử nghiệm điều kiện, nơi mà thử nghiệm là
không cần thiết. Điều kiện dự phòng là điều kiện hoặc là
luôn luôn đúng hoặc luôn luôn sai.
3. Phân tích giao diện: Phân tích này kiểm tra sự phù hợp thủ
tục thông thường, thủ tục khai báo và sử dụng của chúng.
25