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

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

ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

VERIFICATION AND

VALIDATION

GVHD: Lê Mậu Long

ĐẠI HỌC TÔN ĐỨC THẮNG_ KHOA CNTT Nhóm 9

(Xác minh và thẩm định)

Nội dung trình bày

mềm, phân biệt sự khác nhau giữa

chúng

và vai trò cuả nó trong V & V

 Tìm hiểu kĩ thuật phân tích tĩnh

Cleanroom

Nhóm 9

Quá trình V & V

Là quá trình xoay vòng V & V phải

được ứng dụng ở mỗi bước trong các

tiến trình phần mềm

Có 2 nội dung chính:

 Phát hiện ra những khuyết điểm trong hệ

thống

 Ước lượng được hệ thống có hữu ích và

tiện lợi để sẵn sàng dùng hay không.

Nhóm 9

Mục đích của V & V

 Xác minh và thẩm định phải tạo được sự tin

tưởng rằng phần mềm phải phù hợp với mục

đích.

 Điều này không có nghĩa là nó hoàn toàn

không có khuyết điểm

 Hơn nữa, nó phải đáp ứng được đầy đủ các

chức năng dự định và các loại chức năng sẽ

quyết định mức độ tin cậy cần thiết.

Sự tin cậy V & V

 Phụ thuộc vào mục đích hệ thống, sự mong đợi

của người sử dụng và môi trường tiếp thị

 Chức năng phần mềm: Mức độ tin cậy được phụ thuộc vào sự đánh giá phần mềm được tổ chức

như thế nào

 Sự mong đợi của người sử dụng: Người sử

dụng ít kì vọng các loại phần mềm

 Môi trường tiếp thị: Đưa sản phẩm ra thị trường

sớm thì quan trọng hơn là tìm ra những khuyết

điểm chương trình

Nhóm 9

Xác minh tĩnh và động

Kiểm tra phần mềm:

 Liên quan đến phân tích các biểu hiện tĩnh

của hệ thống để phát hiện vấn đề(xác minh

tĩnh)

 Liên quan đến việc ứng dụng và nhận xét

các phản hồi sản phẩm.

Xác minh tĩnh và động Nhóm 9

Kiểm thử chương trình

năng thì khi chương trình được thực thi nó có thể biết được cách hoạt động

cung cấp đầy đủ các chức năng của V&V

Các loại kiểm thử Nhóm 9

 Kiểm thử các khuyết điểm:

 Những phương thức kiểm tra được thiết kế để phát hiện

ra những khuyết điểm của hệ thống

 Một phương thức kiểm tra khuyết điểm thành công là tìm thấy những khuyết điểm tồn tại trong hệ thống

 Kiểm thử thẩm định:

 Dùng để chỉ ra rằng các phần mềm đáp ứng được những yêu cầu

 Phương thức kiểm tra thành công để chỉ ra rằng những yêu cầu được thực thi chính xác.

Kiểm thử và sửa lỗi

 Kiểm thử khuyết điểm và sửa lỗi là những quá trình riêng biệt

 Xác minh và thẩm định là liên quan đến việc chứng minh sự tồn tại những khuyết điểm trong chương

Qúa trình sửa lỗi Nhóm 9

thống trong các bước tiến trình.

 Cần quyết định dựa trên sự cân bằng giữa thẩm định

và xác minh động và tĩnh

 Kiểm tra để xác nhận sự tương thích giữa chương

trình với phần thiết kế và đặc tả của nó.

Sự phát triển của tiến trình chữ V Nhóm 9

3 Kế hoạch kiểm thử liên kết giữa thành viên phát triển dự án và lập trình

cấu trúc của kế hoạch kiểm thử phần mềm

Tiến trình kiểm thử Yêu cầu truy xuất nguồn gốc.

Danh mục kiểm thử.

Sao lưu lại những thủ tục kiểm thử

Các yêu cầu về phần cứng và phần mềm.

Những hạn chế.

Kế hoạch kiểm thử phần mềm Nhóm 9

 Tiến trình kiểm thử

Mô tả về các giai đoạn chính của quá trình thử nghiệm.

 Khả năng lần vết theo yêu cầu

Người dùng quan tâm nhất trong hệ thống đáp ứng yêu cầu của mình và

cần phải lên kế hoạch để tất cả các yêu cầu được thử nghiệm riêng lẻ

Có 3 đặc điểm chính khi kiểm thử Nhóm 9

 Vì kiểm tra là một quá trình tĩnh, bạn không

phải quan tâm đến sự tương tác giữa các sai

sót do đó, một buổi kiểm tra duy nhất có thể

phát hiện ra nhiều sai sót trong hệ thống.

 Phiên bản không đầy đủ của một hệ thống có thể được kiểm tra mà không có thêm chi phí.

 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ư phù hợp với tính di động, tiêu chuẩn và

bảo trì.

Kiểm tra và kiểm thử

 Đánh giá và thử nghiệm từng có lợi thế và bất lợi và cần

được sử dụng cùng nhau trong quá trình xác minh và thẩm định

 Selby and Basili ( Selby, et al., 198.7) thực nghiệm so

sánh kiểm tra hiệu quả và ít tốn kém hơn so với kiểm thử

trong việc phát hiện lỗi chương trình

 Một trong những sử dụng hiệu quả nhất của kiểm tra là

xem xét các trường hợp kiểm thử cho một hệ thống bạn

có thể bắt đầu xác minh và thẩm định hệ thống với kiểm

tra sớm trong quá trình phát triển, nhưng một khi hệ thống được tích hợp, bạn cần kiểm tra để kiểm tra giao diện

chức năng của nó và chức năng của hệ thống là những gì

mà chủ sở hữu của hệ thống thực sự muốn

Kiểm tra chương trình Nhóm 9

kế hoạch của quá trình kiểm tra

Khuyết điểm có thể là các lỗi logic, dị

thường trong mã có thể chỉ ra một tình trạng sai lệch hoặc không tuân thủ các tiêu chuẩn

tổ chức, dự án

Quá trình kiểm tra

Thủ tục kiểm tra Nhóm 9

kiểm tra

giao cho đội kiểm tra trước

Kiểm tra lại lần nữa

Vai trò các thành viên

Các lưu ý trong kiểm tra Nhóm 9

 Việc kiểm tra không nên quá 2 giờ và chủ yếu tập

trung vào các sai sót, không 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ị để sữa các khuyết

điểm, không nên khuyên thay đỗi thành phần khác.

 Sau kiểm tra, tác giả chương trình nên thay đổi nó để sửa chữa những vấn đề đã xác định.

 Bạn cần 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ó

Xem xét kiểm tra

Xem xét kiểm tra Nhóm 9

Xem xét kiểm tra

Tốc độ kiểm tra Nhóm 9

số lượng code có thể được bảo vệ tùy 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

và mỗi thành viên trong nhóm dành 1-2 giờ

chuẩn bị cho việc kiểm tra

phân tích tĩnh tự động

quét văn bản mã nguồn của một chương

trình và phát hiện lỗi có thể và dị thường

định sẵn nhằm mục đích là để thu hút sự chú

ý của một kiểm tra viên đến dị thường trong chương trình

phân tích tĩnh tự động Nhóm 9

Định dạng lỗi thường gặp Sự kiểm tra phân tích tĩnh

Lỗi dữ liệu -Những biến được dùng trước khi khởi động

-Những biến đã được khai báo nhưng không được sử dụng

-Những biến được gán 2 lần nhưng không được sử dụng giữa 2 thao tác

-Mảng tồn tại giới hạn những sự vi phạm -Những biến không được khai báo

Lỗi điều khiển -Những đoạn mã không thể ảnh hưởng đến

-Những nhánh không chịu ảnh hưởng bởi điều kiện của vòng lặp

Lỗi xuất /nhập -Những biến xuất 2 lần mà không xảy ra giữa những

thao tác Lỗi giao diện -Những kiểu tham số không phù hợp

-Số lượng tham số không phù hợp -Không sử dụng kết quả của các hàm chức năng -Những hàm và thủ tục không được gọi

Lỗi quản lý bộ nhớ -Những con trỏ không được xác định

-Chỉ số con trỏ

Các giai đoạn phân tích tĩnh

 Sự phân tích dòng điều khiển :Kiểm tra những vòng lặp với nhiều kiểu xuất và nhập,tìm thấy những đoạn code không thể truy cập

 Phân tích cách sử dụng dữ liệu : phát hiện ra những biến được sử dụng

mà không khởi động ,những biến mà được viết 2 lần mà không có thao tác xen giữa và những biến được khai báo nhưng không sử dụng

 Phân tích giao diện :kiểm tra tính nhất quán của những khai báo thông thường và khai báo thủ tục cũng như cách sử dụng của chúng

 Phân tích luồng thông tin :Xác định sự phụ thuộc của các biến đầu ra Nó không phát hiện ra những bất thường mà đưa ra những thông tin cho

việc kiểm tra code và kiểm duyệt.

 Phân tích đường dẫn : Xác định các đường dẫn thông qua chương trình

và đưa ra các câu lệnh đã thực hiện trong đường dẫn đó.Điều này có

thể hữu ích trong quá trình xem xét

 Cả hai giai đoạn này tạo ra khối lượng lớn thông tin Chúng phải được

sử dụng cẩn thận.

Lint_ex.c(10) :cảnh báo :c có lẽ được dùng trước khi thiết lập

Lint_ex.c(10) :cảnh báo :i có lẽ được dùng trước khi thiết lập

Printarray :biến# của mảng

Printarray,mảng 1 được dùng không nhất quán lint_ex.c(4) ::lint_ex.c(10)

Printarray,mảng 1 được dùng không nhất quán lint_ex.c(4) ::lint_ex.c(11)

Giá trị trả về của printf luôn bị gạt bỏ

Việc sử dụng phân tích tĩnh

kiểu yếu như C,trình biên dich có thể phát

hiện nhiều lỗi

kiểu mạnh như Java,vốn đã phát hiện nhiều lỗi trong quá trình biên dịch

Thẩm định và phương pháp hình thức Nhóm 9

dụng khi một đặc tả toán học của hệ thống

được đưa ra

cách chi tiết của đặc tả và có thể phát triển

các đối số chính thức mà một chương trình

phù hợp với đặc tả toán học của nó

Đưa ra một đặc tả toán học đòi hỏi phải

phân tích chi tiết về các yêu cầu và điều này

có thể phát hiện ra lỗi

các đặc tả,chúng có thể phát hiện những lỗi thực thi trước khi kiểm tra

Lập luận chống lại phương pháp hình thức

không thể hiểu được những kí hiệu chuyên

dụng

thậm chí đắt hơn nữa để thấy rằng một

chương trình đáp ứng đủ các đặc tả

Nó có lẽ rẻ hơn các kĩ thuật V&V khác

nhưng vẫn đạt được cùng mức độ tin cậy

trong chương trình

Nhóm 9

Phát triển phần mềm Cleanroom

 Tên gọi này có nguồn gốc từ quá trình “cleanroom" trong chế tạo bán dẫn Thực tế là tránh lỗi hơn là

loại bỏ khiếm khuyết.

 Tiến trình phát triển phần mềm này dựa trên:

1 Sự phát triển gia tăng

Phát triển phần mềm Cleanroom Nhóm 9

Đặc điểm của quá trình Cleanroom

Các hình thức đặc tả sử dụng mô hình chuyển

đổi trạng thái

Sự phát triển ngày càng được mở rộng khi mà sự

ưu tiên của khách hàng ngày càng tăng

Cấu trúc chương trình được hạn chế kiểm soát

và cấu trúc trừu tượng thì được sử dụng trong

chương trình

Xác minh tĩnh được kiểm tra nghiêm ngặt

Hình thức đặc tả và sự kiểm tra

Các mô hình trạng thái phụ thuộc vào đặc tả hệ thống và quá trình kiểm tra để kiểm tra chương

trình lần nữa theo mô hình này

Phương pháp lập trình được xác định để tương

thích giữa các mô hình và hệ thống

Lập luận toán học được sử dụng để tăng sự tin

cậy trong quá trình kiểm tra

Nhóm 9

Các nhóm tiến trình cleanroom

 Nhóm đặc tả: Nhóm này chịu trách nhiệm phát

triển và duy trì đặc tả hệ thống

 Nhóm phát triển: Chịu trách nhiệm phát triển và

xác minh hệ thống Phần mềm này không được

thực thi hoặc không biên dịch được trong quá trình.

 Nhóm xác nhận: Nhóm này chịu trách nhiệm về

việc tổng hợp lại các trường hợp kiểm tra để thực thi phần mềm trước khi phát triển Mô hình phát

triển độ tin cậy được sử dụng để quyết định khi nào thì dừng thử nghiệm

Qúa trình đánh giá Cleanroom

 Kết quả của việc sử dụng quá trình Cleanroom đã phát hiện ra những khuyết điểm trong phát biểu hệ thống.

 Dựa vào sự đánh giá khách quan cho thấy quá

trình này thì không đắt hơn các phương pháp tiếp cận khác

 Có lỗi ít hơn trong quá trình phát triển truyền thống

 Tuy nhiên, quá trình này thì không được sử dụng rộng rãi.

Nhóm 9

 Sự phát triển quá trình Cleanroom phụ thuộc

vào sự phát triển ngày càng mở rộng, xác minh tĩnh và thống kê kiểm thử

Thanks you for listen to me