Kiểm thử và đảm bảo chất lượng phần mềm

1. Kiểm thử và đảm bảo chất lượng phần mềm Xem xét đặc tả và mã nguồn

2. Nội dung • Xem xét đặc tả • Xem xét mã nguồn

3. 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ả

4. 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 • ...

5. 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 • ..

6. 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ử

7. 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

8. 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

9. 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

10. 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ố • ...

11. 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?

12. 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?

13. 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?

14. 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?

15. Minh họa • Nghiêncứumộtsốchuẩnmãnguồn • https://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml • https://google-styleguide.googlecode.com/svn/trunk/javaguide.html • Nghiêncứumộtsốdanhsáchkiểmtramãnguồn • Pháthiệnvấnđềcủamộtsốmãnguồnmở

16. Bàitập • Sửdụngmộtsốdanhsáchkiểmtramãnguồnvàápdụngxemxétmãnguồncủangườikhác