Đảm bảo và kiểm soát chất lượng - Chương 4: Các kỹ thuật kiểm tra tĩnh

ĐẢM BẢO VÀ KIỂM SOÁT CHẤT LƯỢNG HCM – 10/2012 Chương 4: Các kỹ thuật kiểm tra tĩnh 1 4/23/2014 Nội dung 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 4/23/2014 Trang 2 Các phương pháp Testing 4/23/2014 Trang 3 Static Dynamic Structural Behavioural Functional Non-functional Reviews Walkthroughs Desk-checking Data Flow Symbolic Execution Definition -Use Statement Branch/Decision Branch Condition Branch Condition Combination LCSAJ Arcs Equivalence Partitioning Boundary Value Analysis Cause-Effect Graphing Random Usability Performance Static Analysis Inspection Control Flow etc. etc. etc. etc. etc. State Transition 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 4/23/2014 Trang 4 Lợi ích  Bổ sung cho kiểm tra động trong giai đoạn kiểm chứng chương trình  Có thể phát hiện sớm 30%-70% lỗi  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  Nâng cao khả năng bảo trì mã/chương trình  „Ngăn ngừa khiếm khuyết 4/23/2014 Trang 5 Chi phí sửa lỗi trong quá trình phát triển 4/23/2014 Trang 6 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 V&V Các phương pháp kiểm thử động gồm có kiểm thử Unit – Unit Tests, Kiểm thử tích hợp – Intergration Tests, Kiểm thử hệ thống – System Tests, và Kiểm thử chấp nhận sản phẩm – Acceptance Tests 4/23/2014 Trang 7 Kiểm thử Tĩnh vs. Kiểm thử Động 4/23/2014 Trang 8 Nội dung 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 4/23/2014 Trang 9 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 4/23/2014 Trang 10 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?” 4/23/2014 Trang 11 Review: Chi phí và lợi ích Chi phí  Thời gian  Sự nỗ lực thu thập và phân tích các yếu tố (metrics) Lợi ích  Lịch biểu ngắn hơn  Chu kỳ kiểm tra ngắn hơn, chi phí kiểm thử thấp hơn  Gia tăng năng suất  ‰Cải tiến chất lượng sản phẩm 4/23/2014 Trang 12 Tiến trình chung của hoạt động rà soát 4/23/2014 Trang 13 Vai trò và Trách nhiệm  Điều phối/Chủ trì (Moderator):  Chủ trì các cuộc họp  Thư ký:  Tập hợp thông tin về tìm kiếm lỗi  Tác giả:  Mô tả, giải thích và trả lời các câu hỏi  Người rà soát (Reviewer/inspector):  Tìm kiếm lỗi  Người quản lý:  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  Đôi khi, một người có thể đóng nhiều vai trò  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ý 4/23/2014 Trang 14 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 giờ).  Cuộc họp chỉ nên từ 2-3 giờ. Mỗi cuộc họp rà soát chỉ hạn chế trong một phần nhỏ, cụ thể. Kết luận đưa ra 1 trong 3 quyết định sau:  Chấp nhận sản phẩm không cần chỉnh sửa  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 4/23/2014 Trang 15 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ỉ rõ:  Đã rà soát cái gì  Ai rà soát  Tìm thấy cái gì và Kết luận ra sao 4/23/2014 Trang 16 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  4/23/2014 Trang 17 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  Tập trung tìm kiếm“vấn đề”, không đi vào giải quyết  Nắm rõ các ghi chú đã viết  Giới hạn, cẩn thận chọn lựa người tham gia 4/23/2014 Trang 18  Phải có sự chuẩn bị  Rà soát sản phẩm, không rà soát người làm ra nó Các kiểu Review 4/23/2014 Trang 19 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 4/23/2014 Trang 20 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 việc theo nhóm.  Quá trình làm việc theo nhóm thúc đẩy sự cạnh tranh lành mạnh  Con người thích phô trương các lỗi mà họ tìm thấy. 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. 4/23/2014 Trang 21 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ó 4/23/2014 Trang 22 Start Planning Walk Through Rework End Author Author/Reviewer Follow up Author Author/Reviewer Lần bước (Walkthrough) Mục tiêu:  Giải thích và đánh giá những nội dung trong tài liệu hay source code  Phát hiện sớm những lỗi 4/23/2014 Trang 23  Thiết lập sự hiểu biết chung mọi người trong team  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) Không có quy trình thực sự, không tài liệu ghi chú, không xác định rõ trách nhiệm 4/23/2014 Trang 24 Review có thể tiến hành qua „trao đổi ngoài lề, lập trình theo cặp Mục tiêu chính là để kiếm ra lỗi Chưa hữu ích, rẻ, phổ biến Thanh tra (Inspection) 4/23/2014 Trang 25 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 nguyên nhân Những để nghị để cải thiện quy trình Làm lại Tiếp tục Tất cả lỗi được sửa End Chủ trì Nhóm Chủ trì/Tác giả Nhóm Chủ trì/Tác giả Reviewer/Chủ trì/Tác giả No 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 4/23/2014 Trang 26 Thanh tra (Inspection) 4/23/2014 Trang 27 Kích cỡ  Min: 3 (4 nếu tác giả là người trình bày)  Max: 7 (ít hơn nếu chủ trì có ít kinh nghiệm) Thời lượng  Không nhiều hơn 2 giờ Kết quả  Tất cả reviewers phải đồng ý trên kết quả  Tất cả các phát hiện phải được lưu trữ lại  Scope  Chỉ nên tập trung vào từng phần cụ thể  130-150 SLOC per hour  Thời điểm  Không quá sớm  Không quá muộn  Mục tiêu  Không để những lỗi tương tự xuất hiện trong tương lai  Nguyên tắc (Rules)  Không cố gắng giải quyết vấn để liền  Tất cả mọi người tham dự phải chuẩn bị tài liệu kỹ càng Lỗi thường gặp trong phân tích yêu cầu-thiết kế  Mập mờ: nghĩa chính xác là gì ?  VD: Hệ thống nên truy cập đển hệ thống khác • Hệ thống khác là những hệ thống nào? Phương thức truy cập? Cấu trúc của dữ liệu truyền nhận?  Không đầy đủ: Rồi, Còn gì nữa?  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?  Không kiểm tra được: Tôi có thể kiểm tra phần này ra sao?  VD: Hệ thống có khả năng sẵn sàng 100% • ‰Không biết kỹ thuật kiểm tra để biết hoàn toàn sẵn sàng  Quá phức tạp hay khó hiểu  Các sơ đồ ‘tồi” và gây khó hiểu 4/23/2014 Trang 28 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? 4/23/2014 Trang 29 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? 4/23/2014 Trang 30 Danh mục rà soát cho việc tạo test case Có phải tất cả các đường logic độc lập đều được kiểm thử? Có phải tất cả các ca kiểm thử đều đã được xác định và lập danh sách với đủ các kết 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? 4/23/2014 Trang 31 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? 4/23/2014 Trang 32 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 Mã “chết” Vi phạm chuẩn lập trình Yếu điểm bảo mật Vi phạm cú pháp mã và mô hình v..v 4/23/2014 Trang 33 Nội dung 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 4/23/2014 Trang 34 Phân tích tĩnh Phân tích source code để tìm ra những lỗi mà không cần thực hiện chúng Phân tích tĩnh thường đi kèm với những công cụ hỗ trợ Có khá nhiều công cụ hỗ trợ tĩnh, nhưng phần lớn chúng tập chung vào:  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) 4/23/2014 Trang 35 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 4/23/2014 Trang 36 Coding standards  A set of programming rules  e.g. 'Always check boundaries on an array when copying to that array'  Naming conventions 4/23/2014 Trang 37  Variables, global variables, constants, methods, classes, attributes,...  Comments  brief, explain WHY instead of HOW, placement of comments,...  Layout specifications  indentation, spacing, blank lines, curly braces,...  ...  Should use support tools 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:  Những vòng lặp vô hạn  Những dòng code chết  Những điều kiện đi vào vòng lặp  Độ phức tạp của chương trình • complexity = number of decisions + 1 4/23/2014 Trang 38 Cấu trúc luồng điều khiển 4/23/2014 Trang 39 1 2 3 5 Hình nào có độ phức tạp cao hơn? Cấu trúc luồng điều khiển 4/23/2014 Trang 40 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: 4/23/2014 Trang 41  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 4/23/2014 Trang 42 ĐẢM BẢO VÀ KIỂM SOÁT CHẤT LƯỢNG 43 4/23/2014