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

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

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

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

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

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ó vaitrò 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ướngdẫ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ảithiếu sót Mong thầy đóng góp ý kiến để chúng em có thể hoàn thiện tốthơ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

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 (Cleanroomsoftware 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áttriển phải được kiểm tra để đảm bảo rằng nó đáp ứng đặc điểm kỹ thuậtcủ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ụcthô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 đếnviệc kiểm tra được phần mềm phù hợp với đặc điểm kỹ thuật của nó

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 ứngcá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 ứngnhững gì mà khách hàng mong đợi Hệ thống phần mềm không phản ánhnhữ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ểnmột hệ thống an toàn là cao hơn rất nhiều hơn so với yêu cầucho 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ạcnhiên nó phù hợp trong suốt quá trình sử dụng Họ sẵn sàngchấ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ươngtrình cạnh tranh khách hàng, khách hàng sẵn sàng trả tiềncho 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ạnhtranh, nó có thể quyết định để phát hành một chương trìnhtrướ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áchhàng không sẵn sàng trả giá cao cho các phần mềm, họ phải

xét khi quyết định nên được dành nhiều nỗ lực như thế nàovà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 vaitrò hỗ trợ trong quá trình làm phần mềm Các mũi tên chỉ ra các giai đoạntrong 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ầnmề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ênquan Kiểm tra phần mềm và phân tích tự động là kỹ thuật V&Vtĩ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êucầu không? Thử nghiệm là một kỹ thuật xác minh và xác nhậnđộng

Chúng ta chỉ có thể thử nghiệm một hệ thống khi một nguyên mẫuhoặ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ểmtra khi nó được thêm vào hệ thống do đó chúng ta không cần phải có mộtthự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ântí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ộctí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ácnhận phần mềm chính Thử nghiệm liên quan đến việc thực thi chươngtrình bằng cách sử dụng dữ liệu như các dữ liệu thực tế được xử lý bởichương trình Chúng ta phát hiện ra khuyết tật chương trình hoặc bất cậpbằ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ấtthườ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 xemtrong 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ỏnghoạt động của nó Mục đích của kiểm tra lỗi là để tìm sự mâu thuẫngiữ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áptiế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ầucủa nó

Quá trình V&V và gỡ lỗi thường xen kẽ Khi bạn phát hiện ra lỗitrong chương trình mà bạn đang thử nghiệm, bạn phải thay đổi chươngtrình để sửa chữa những lỗi lầm Tuy nhiên, thử nghiệm (hoặc, nói chungxá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ậptrì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áckhuô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ônngữ 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àikiểm tra bổ sung tái tạo lỗi ban đầu và xác định vị trí của nó trong chươngtrì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ộtmôi trường thời gian chạy chuyên dụng cho các chương trình cho phéptruy 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ácbiến chương trình Chúng ta có thể kiểm soát thực thi bởi “step ping”thông qua báo cáo kết quả chương trình bằng cách lệnh Sau khi từnglệ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ênquan đế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ươngtrình đã giới thiệu lỗi mới Kinh nghiệm cho thấy một tỷ lệ cao sửa chữalỗ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ỗilầ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ữacá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ànhphần được kiểm tra Nếu truy xuất nguồn gốc này được hỗ trợ bởi các tàiliệ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ộccủa nó

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ộcphi 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 đượckết quả tốt nhất của các quá trình thử nghiệm và kiểm tra, và để kiểm soátchi 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ốngsớm trong quá trình phát triển Quá trình phát triển phần mềm thể hiệntrong 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 đã đượcxá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ácnhận, lập các tiêu chuẩn và thủ tục cho việc kiểm tra và thử nghiệm phầnmề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

sự kiểm tra chương trình Như một quy tắc chung, một hệ thống then chốthơ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ẩncho 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 đánhgiá thử nghiệm, thử nghiệm kế hoạch dành cho các kỹ sư phần mềm liênquan đế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ảoluậ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 địnhcác nguồn tài nguyên phần của cứng và phần mềm được yêu cầu Điềunày rất hữu ích cho các nhà quản lý hệ thống - những người có tráchnhiệ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ênxả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

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

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

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ínhthứ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àiliệ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àngchịu trách nhiệm cuối cùng để quyết định xem nên dành bao nhiêu nỗ lựccho thử nghiệm hệ thống

Kế hoạch kiểm tra không phải là một tài liệu tĩnh nhưng nó tiếntriể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ầncủ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áttriển cho người thử nghiệm cho một số hoạt động khác và mang chúngtrở lại khi phần mềm có hiệu lực một lần nữa.

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ôngbao giờ có thể chắc chắn nếu bất thường ở đầu ra khác là domộ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 quantâm đến sự tương tác giữa các lỗi Do đó, một phiên kiểm traduy 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ìnhkhông đầy đủ, sau đó chúng ta cần để phát triển khai thácthử 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ộnglớ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ônghiệ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ệnkhiế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áthiệ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ứcdựa trên lập luận đúng Ness có thể phát hiện hơn 90% các lỗi trong mộtchương trình Kỹ thuật này được sử dụng trong quá trình phòng sạchCleanroom được mô tả trong Mục 22.4 Selby và Basili (Selby, et al.,

1987) thực nghiệm so sánh hiệu quả của kiểm tra và thử nghiệm Họ nhậnthấ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étcá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ớigiám định sớm trong quá trình phát triển, nhưng một khi hệ thống đượctích hợp, chúng ta cần thử nghiệm để kiểm tra các thuộc tính mới xuấthiệ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ốngthự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ểnphầ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áttriể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 chiphí sau khi đội phát triển trở nên có kinh nghiệm trong việc sử dụng Hơnnữa, có những vấn đề thực tế trong việc sắp xếp kiểm tra: Kiểm tra mấtthờ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 tranày có thể được thực hiện sau đó, vì ít thời gian những người này đã dànhcho việc tìm lỗi chương trình

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áthiện khiếm khuyết Khái niệm một quá trình kiểm tra hình thức lần đầutiê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ươngpháp ban đầu của Fagan một số phương pháp thay thế kiểm tra đã đượcphát triển (Gilb và Graham 1993), tất cả đều dựa vào một đội với cácthà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ìnhchứ 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ìnhtrạ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ựchiệ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ộtcá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 trangườ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ứcquá trình

Khi các tổ chức đã đạt được kinh nghiệm với kiểm tra, đề xuấtkhá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ủaHewlett-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ươngtrì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ểmtra 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ùngcuối và quản lý chất lượng