Kim th v m bo cht lng phn
Kiểm thử và đảm bảo chất lượng phần mềm Xem xét đặc tả và mã nguồn 1
Nội dung • Xem xét đặc tả • Xem xét mã nguồn 2
Duyệt đặc tả mức cao • Duyệt đặc tả mức cao – Quan sát ở mức tổng thể – Đóng vai người khách hàng • Hiểu xem họ thực sự cần gì • Khách hàng không nói những gì là hiển nhiên – Ví dụ: an ninh, dễ sử dụng, v. v. – Đối chiếu với đặc tả • Làm rõ những gì mình không hiểu – Không hiểu được là lỗi của đặc tả 3
Duyệt đặc tả mức cao • Đối chiếu chuẩn mực hiện hành – Thuật ngữ, qui ước – Chuẩn mực quốc tế, – Chuẩn do địa phương ban hành – Chuẩn về an ninh – Chuẩn về dễ sử dụng –. . . 4
Duyệt đặc tả mức cao • So sánh với các sản phẩm cạnh tranh – Chức năng – Công nghệ – Đơn giản, dễ sử dụng – An ninh, bảo mật – Độ tin cậy –. . 5
Duyệt đặc tả mức thấp • Dựa trên danh sách kiểm tra – Đầy đủ – Chính xác, không nhập nhằng – Tương thích – Khả thi – Ngôn ngữ diễn đạt – Tính khả kiểm thử 6
Khảo sát mã nguồn • Phản biện hình thức – Xác định vấn đề – Đặt ra nguyên tắc làm việc – Chuẩn bị họp – Biên bản, báo cáo kết luận • Ích lợi – Phổ biến thông tin – Tăng tính tự giác – Tăng tính đồng đội – Phát hiện các cải tiến hữu ích 7
Phản biện chéo • Kiểm tra lẫn nhau, phi hình thức • Qui trình tương tự phản biện hình thức, nhưng đơn giản hóa bớt • Thông qua – Tác giả trình bày cho một nhóm nhỏ (5 lập trình, kiểm thử viên khác) đã xem mã nguồn trước • Thanh tra – Người trình bày không phải là tác giả nói và nhận xét về mã nguồn, những người khác cũng phản biện 8
Chuẩn mã nguồn • Mã nguồn cần tuân thủ các nguyên tắc về mã nguồn – Thụt đầu dòng – Cách đặt tên – Chú thích –. . . • Đảm bảo tính nhất quán, dễ hiểu của mã nguồn do nhiều người cùng viết, sửa 9
Danh sách kiểm tra mã nguồn • Kiểm tra theo danh sách để không bỏ sót – Lỗi tham chiếu dữ liệu – Lỗi mô tả dữ liệu – Lỗi tính toán – Lỗi điều khiển – Lỗi truyền tham số –. . . 10
Ví dụ danh sách kiểm tra • Structure – – – – – ❏ Does the code completely and correctly implement the design? ❏ Does the code conform to any pertinent coding standards? ❏ Is the code well-structured, consistent in style, and consistently formatted? ❏ Are there any uncalled or unneeded procedures or any unreachable code? ❏ Are there any leftover stubs or test routines in the code? ❏ Can any code be replaced by calls to external reusable components or library functions? ❏ Are there any blocks of repeated code that could be condensed into a single procedure? ❏ Is storage use efficient? ❏ Are symbolic used rather than “magic number” constants or string constants? ❏ Are any modules excessively complex and should be restructured or split into multiple routines? 11
Ví dụ danh sách kiểm tra • Documentation – ❏ Is the code clearly and adequately documented with an easy-to-maintain commenting style? – ❏ Are all comments consistent with the code? • Variables – ❏ Are all variables properly defined with meaningful, consistent, and clear names? – ❏ Do all assigned variables have proper type consistency or casting? – ❏ Are there any redundant or unused variables? • Arithmetic Operations – ❏ Does the code avoid comparing floating-point numbers for equality? – ❏ Does the code systematically prevent rounding errors? – ❏ Does the code avoid additions and subtractions on numbers with greatly different magnitudes? – ❏ Are divisors tested for zero or noise? 12
Ví dụ danh sách kiểm tra • Loops and Branches – ❏ Are all loops, branches, and logic constructs complete, correct, and properly nested? – ❏ Are the most common cases tested first in IF- -ELSEIF chains? – ❏ Are all cases covered in an IF- -ELSEIF or CASE block, including ELSE or DEFAULT clauses? – ❏ Does every case statement have a default? – ❏ Are loop termination conditions obvious and invariably achievable? – ❏ Are indexes or subscripts properly initialized, just prior to the loop? – ❏ Can any statements that are enclosed within loops be placed outside the loops? – ❏ Does the code in the loop avoid manipulating the index variable or using it upon exit from the loop? 13
Ví dụ danh sách kiểm tra • Defensive Programming – ❏ Are indexes, pointers, and subscripts tested against array, record, or file bounds? – ❏ Are imported data and input arguments tested for validity and completeness? – ❏ Are all output variables assigned? – ❏ Are the correct data operated on in each statement? – ❏ Is every memory allocation deallocated? – ❏ Are timeouts or error traps used for external device accesses? – ❏ Are files checked for existence before attempting to access them? – ❏ Are all files and devices are left in the correct state upon program termination? 14
Minh họa • Nghiên cứu một số chuẩn mã nguồn – https: //google-styleguide. googlecode. com/svn/trunk/javascriptguide. xml – https: //google-styleguide. googlecode. com/svn/trunk/javaguide. html • Nghiên cứu một số danh sách kiểm tra mã nguồn • Phát hiện vấn đề của một số mã nguồn mở 15
Bài tập • Sử dụng một số danh sách kiểm tra mã nguồn và áp dụng xem xét mã nguồn của người khác 16
- Slides: 16