Bài giảng Đảm bảo và kiểm soát chất lượng phần mềm: Chương 4 - Nguyễn Mạnh Tuấn

Chương 4 cung cấp kiến thức về các kỹ thuật kiểm tra tĩnh. Trong chương này người học sẽ tìm hiểu những nội dung cơ bản sau: Các phương pháp Testing (Kiểm thử tĩnh, kiểm thử động), các kiểu rà soát (Review), phân tích tĩnh. Mời các bạn cùng tham khảo.

ĐẢM BẢO VÀ KIỂM SOÁT

Reviews

Walkthroughs

Desk-checking

Data Flow

Symbolic

Execution

Definition

Statement Branch/Decision Branch Condition LCSAJ

Arcs

Equivalence Partitioning

Boundary Value Analysis

Cause-Effect Graphing

Random

Usability Performance

Static Analysis Inspection

Control Flow

Kiểm thử tĩnh

Phân tích tĩnh thực hiện mà không cần

thực thi hệ thống thực sự Điều này

ngược với kiểm thử động

Thường thì nó không kiểm thử chi tiết

mà chủ yếu kiểm tra tính đúng đắn của code (mã lệnh), thuật toán hay tài liệu

Đây chính là verification trong mô

hình V&V

Những thực hiện: lập trình viên và QC

Lợi ích

 Bổ sung cho kiểm tra động trong giai đoạn kiểm chứng

chương trình

 Chi phí chỉnh sửa một khiếm khuyết tăng lên nhanh

chóng sau mỗi giai đoạn trong thiết kế tốn phí 1.0, trước kiểm thử: 6.5, trong kiểm thử:15 và sau phân phối sẽ từ 60 đến 100

 Nhận diện tổng quát, các lỗi sớm được phát hiện

 Chi phí thấp hơn nhưng lại đạt được khả năng sửa lỗi phù hợp hơn, tốt hơn

 Chỉ ra một “lô” các lỗi “liên quan”

 Sửa toàn thể (một loạt) lỗi sau đó

 Phát hiện sự phụ thuộc, thiếu nhất quán

Chi phí sửa lỗi trong quá trình

phát triển

Kiểm thử động

Kiểm thử động cần thực thi hệ thống

thực sự bao gồm nhập các giá trị đầu

vào và kiểm tra xem liệu đầu ra có như mong muốn hay không

Đây chính là validation trong mô hình

Kiểm thử Tĩnh vs Kiểm thử Động

Thế nào là rà soát (Review)

 Review là quá trình kiểm tra có hệ thống

được thực hiện bởi 1 hay nhiều người với

mục tiêu chính là tìm kiếm và loại bỏ

những khiếm khuyết

 Mục tiêu của rà soát:

 Tìm kiếm khiếm khuyết

 Thu sự hiểu biết

 Tạo sự thảo luận

 Review giúp xác định lỗi trước khi chúng

trở thành 1 phần của code thực thi

 Làm những lỗi rẻ hơn và dễ sửa hơn

Các loại lỗi

Ba loại lỗi có ở mỗi bước của quá trình phát triển phần mềm:

 Lỗi mới được sinh ra

 Lỗi còn lại của các bước trước

 Lỗi được phóng đại lên do các nhân tố lỗi của các bước trước

Nếu không rà soát lỗi tồn lại gia tăng

nhanh, và chi phí cho việc loại trừ các

lỗi ngày càng lớn; Nguyên tắc xử lý lỗi:

“chi phí bây giờ hay để lại sau phải với chi phí nhiều hơn?”

Review: Chi phí và lợi ích

 Gia tăng năng suất

 ‰Cải tiến chất lượng sản phẩm

Tiến trình chung của hoạt động

rà soát

 Mô tả, giải thích và trả lời các câu hỏi

 Tìm kiếm lỗi

 Lập kế hoạch, sắp xếp tài nguyên và việc huấn luyện,

hỗ trợ, phân tích các yếu tố quy trình

 Tác giả đôi khi đóng vai trò như Trung gian

 Một trong những người rà soát làm thư ký

Cuộc họp rà soát

 Mọi cuộc họp rà soát phải:

 Gồm từ 3 đến 5 người liên quan

 Phải chuẩn bị trước (1 người không quá2

 Khước từ sản phẩm vì những lỗi nghiêm trọng

 Chấp nhận cho chỉnh sửa sản phẩm, sau khi chỉnh sửa phải rà soát lại

Sản phẩm rà soát

Sản phẩm của cuộc họp rà soát:

 Báo cáo các vấn đề nảy sinh do các cá

nhân rà soát nêu ra

 Một danh sách các vấn đề cần giải quyết

 Một văn bản tổng kết cuộc họp rà soát đó

Văn bản tổng kết họp rà soát phải chỉ

Những gì có thể được rà soát?

Bất kỳ thứ gì được viết ra:

 Hợp đồng, chính sách, kế hoạch kinh

doanh

 Yêu cầu, đánh giá mức độ khả thi, kế

hoạch kiểm tra chấp nhận (Acceptance Test)

 Kế hoạch Test, Test case, kết quả test

 Bản thiết kế, CSDL

 Source code

 User guide, training

Nhân tố Rà soát thành công

 Huấn luyện kỹ càng

 Rà soát cả chức năng –

phi chức năng

 Lập và theo danh sách

kiểm tra (checklist)

 Giới hạn tranh cãi

Các kiểu Review

Kiểm lại (Desk checking)

Tác giả sẽ gởi tài liệu,

source code… cho

người cần rà soát

Start

Tự review

Dựa trên kế hoạch review,

thông báo cho reviewers

Sửa lỗi

End

Author

Reviewer

Kiểm tra lại

Review và phát hiện lỗi Author

Reviewer Author

Kiểm lại (Desk checking)

 Desk checking kém hiệu quả hơn quá trình lần bước (walktrough) và rà soát

(inspector) vì không có sự phối hợp làm

 Trong quá trình desk-checking có thể sẽ

không tìm thấy lỗi nào

 Tóm lại Desk-checking cũng có giá trị còn hơn là không làm gì cả Tuy nhiên nó kém hiệu quả hơn walkthrough và inspection

Lần bước (Walkthrough)

Walkthrough:

 Tác giả (Author) là

nhân vật trung tâm và

là người điều phối buổi họp

 Những người tham gia

đặt câu hỏi, và ghi chú những lỗi có thể có

 Xem xét và thảo luận những giải pháp được

đề nghị cũng như tính khả thi của những giải pháp này

 Thiết lập sự nhất trí trong team

Rà soát cặp (Peer Review)

Mục tiêu chính là để kiếm ra lỗi

Chưa hữu ích, rẻ, phổ biến

Thanh tra (Inspection)

Start

Lên kế hoạch

Họp tổng quan Chuẩn bị Buổi họp rà soát

Defect Log Buổi họp phân tích

Thanh tra (Inspection)

Buổi họp được lên kế hoạch và có cấu

trúc rõ ràng

Có giai đoạn chuẩn bị kỹ càng

Vai trò của mọi người trong buổi họp

được phân rõ ràng

Được điều khiển bởi người điều tiết

Thanh tra (Inspection)

Lỗi thường gặp trong phân tích

 VD: trên 3 lần nhập mật khẩu không đúng, hệ thống

sẽ khóa tài khoản của NSD

• Trong bao lâu? Muốn mở khóa thì sao? Ai có quyền mở khóa?

ra sao?

• ‰ Không biết kỹ thuật kiểm tra để biết hoàn toàn sẵn sàng

 Các sơ đồ ‘tồi” và gây khó hiểu

Danh mục rà soát kế hoạch

kiểm thử

Các chức năng chủ yếu có được trình

diễn sớm không?

Kế hoạch kiểm thử có phù hợp với kế

hoạch dự án tổng thể hay không?

Lịch trình kiểm thử có được xác định rõ ràng hay không?

Nguồn lực và công cụ kiểm thử đã được xác định và đã sẵn sàng hay chưa?

Đã thiết lập cơ chế lưu trữ báo cáo

chưa?

Danh mục rà soát kế hoạch

kiểm thử

Các thiết bị và các tình huống kiểm thử

đã được minh định chưa?

Công việc phát triển kiểm thử đã được

lập lịch chưa?

Thử nghiệm áp bức cho phần mềm đã

được đặc tả chưa?

Cả hai loại kiểm thử hộp trắng và hộp

đen đã được đặc tả chưa?

Danh mục rà soát cho việc tạo

qủa mong đợi?

 Việc xử lý sai có được kiểm thử?

 Các giá trị biên có được kiểm thử?

 Các yêu cầu thời gian có được kiểm thử?

 Các biến thể chấp nhận được của kết quả

kiểm thử mong đợi đã được đặc tả chưa?

Danh mục rà soát cho việc

kiểm thử giao diện

 Màu nền chung của toàn bộ màn hình

 Màu chữ, font, font size

 Canh lề

 Thông báo trên màn hình có được viết đúng chính tả

 Kiểm tra maxlength

 Phân biệt chữ hoa / chữ thường

 Phân biệt 全角/半角 (toàn giác/bán giác: chỉ áp dụng với Tiếng Nhật, toàn giác thì chữ mập, tròn hơn 2-3bytes; bán giác: chữ

ốm 1byte)

 Phân biệt ký tự unicode

 Cho phép null hay không

 Cho phép nhập ký tự đặc biệt hay không? Kiểm tra format

theo kiểu nào?

 Kiểm tra đối với trường hợp năm nhuần có được tính đúng

không?

 Kiểm tra giá trị 00 và 13 đối với tháng

 Kiểm tra giá trị 00 và 32 đối với ngày

 Kiểm tra giá trị 28 , 29, 30 -Feb có được tính đúng không?

Lỗi tiêu biểu phát hiện

Tham chiếu tới biến chưa gán trị

Giao tiếp không nhất quán giữa chương trình và module

Biến chưa bao giờ sử dụng

 Những tiêu chuẩn code (coding standards)

 Cấu trúc luồng điều khiển (control flow

structure)

 Cấu trúc luồng dữ liệu (data flow structure )

 Cấu trúc dữ liệu (data structure)

Những tiêu chuẩn code (coding

standards)

Người lập trình viên không chỉ có nhiệm

vụ viết code chính xác mà còn phải viết

code có chất lượng cao

 Dễ đọc, dễ hiểu, có thể sử dụng lại, có thể

bảo trì…

Những tiêu chuẩn code: sẽ lập ra những

nguyên tắc (rule) về lập trình để đảm

bảo code đạt được những mục đích trên

và tránh được những lỗi tiềm ẩn

Coding standards

 e.g 'Always check boundaries

on an array when copying to that array'

Cấu trúc luồng điều khiển

Thể hiện source code dưới dạng đồ thị, giúp xác định:

Cấu trúc luồng điều khiển

1

Hình nào có độ phức tạp cao hơn?

Cấu trúc luồng điều khiển

Cấu trúc luồng dữ liệu

Tập trung vào sự xuất

hiện của những biến dữ

liệu từ lúc nó được khai

báo đến khi nó bị hủy,

để xác định:

 Biến không bao giờ được sử dụng

 Tham khảo đến 1 biến chưa được khai báo

 Phép gán không chính xác

Lợi ích của phân tích tĩnh

Phát hiện lỗi sớm

Có những cảnh báo về những lỗi tiềm

ẩn

Xác định những lỗi không dễ dàng phát hiện trong kiểm tra động

Tăng tính bảo trì (maintainability) của

source code

Ngăn ngừa lỗi

ĐẢM BẢO VÀ KIỂM SOÁT

CHẤT LƯỢNG