Kiểm tra chiến luợc kiểm tra phần mềm Kiểm tra chiến luợc kiểm tra phần mềm Bởi: Khoa CNTT ĐHSP KT Hưng Yên Đặc điểm kiểm tra phần mềm Xác minh thẩm định hệ phần mềm trình liên tục xuyên suốt giai đoạn trình phần mềm Xác minh thẩm định từ chung cho trình kiểm tra để đảm bảo phần mềm thỏa mãn yêu cầu chúng yêu cầu thỏa mãn nhu cầu người sắm phần mềm Xác minh thẩm định trình kéo dài suốt vòng đời Nó bắt đầu duyệt xét yêu cầu Xác minh thẩm định có hai mục tiêu: i) Phát khuyết tật hệ thống ii) Đánh giá xem hệ thống liệu có dùng hay không? Sự khác xác minh thẩm định là: i) Thẩm định: Xem xét xây dựng có làsảnphẩmđúngkhông? Tức kiểm tra xem chương trình có mong đợi người dùng hay không ii) Xác minh: Xem xét xây dựng có đúnglàsảnphẩmkhông? Như thế, xác minh kiểm tra chương trình có phù hợp với đặc tả hay không Như trên, kiểm tra trình tìm kiếm lỗi Một kiểm tra tốt có khả cao tìm kiếm lỗi chưa phát Một kiểm tra thành công kiểm tra tìm lỗi mới, kiểm tra tồi kiểm tra mà không tìm lỗi Có hai kiểu lỗi ứng dụng kiểm tra tốt xác định hai loại Cụ thể: 1/8 Kiểm tra chiến luợc kiểm tra phần mềm ? Không làm điều cần phải làm: lỗi bỏ sót thường xuất ứng dụng phát triển ? Làm điều không cần làm: lỗi lệnh cư trú trước ứng dụng bảo trì Các kiểm tra có mặt mức khác tiến hành cá nhân khác trình phát triển ứng dụng Các kiểm tra tiến hành đội ngũ dự án kiểm tra tiến hành quan bên để chấp nhận ứng dụng Các kiểm tra đội dự án gọi kiểm tra phát triển (Development test) Kiểm tra phát triển bao gồm kiểm tra đơn vị, kiểm tra hệ thống con, kiểm tra tích hợp kiểm tra hệ thống ? Kiểm tra đơn vị (Unit test) tiến hành cho đơn vị mã nhỏ ? Kiểm tra tích hợp (Subsystem integration test) kiểm tra mặt logic xử lý cho phù hợp khối, kiểm tra việc truyền tin chúng ? Kiểm tra hệ thống (System test) đánh giá đặc tả chức có đáp ứng, thao tác giao diện người có giống thiết kế không, công việc ứng dụng môi trường thao tác mong muốn, ràng buộc Các kiểm tra quan bên gọi đảm bảo chất lượng (Quality assurance-QA) kiểm tra chấp nhận (Acceptance test) Người người sử dụng đại diện người dùng, tạo mục đích, đánh giá khách quan ứng dụng quan bên coi có mục đích thành viên nhóm Kiểm tra đảm bảo chất lượng tương tự kiểm tra hệ thống mặt mục đích tiến hành, khác họ nằm điều khiển dự án trưởng Các báo cáo kiểm tra đảm bảo chất lượng gửi thường xuyên tới nhóm phát triển quản lý dự án Các kiểm tra viên đảm bảo chất lượng lập kế hoạch cho chiến lược tiến hành kiểm tra để đảm bảo ứng dụng thực tất chức cần thiết Kiểm tra đảm bảo chất lượng kiểm tra cuối làm trước ứng dụng đưa sản xuất đại trà Quan hệ mức kiểm tra giai đoạn vòng đời chương trình trình bày sau: 2/8 Kiểm tra chiến luợc kiểm tra phần mềm Mỗi mức kiểm tra đòi hỏi xác định chiến lược kiểm tra Chiến lược kiểm tra hộp trắng kiểm tra hộp đen ? Dữ liệu vào tạo theo thiết kế để sinh liệu khác mà không ý tới chức logic thực Các kết dự đoán so sánh với kết thực tế để đánh giá mức độ thành công ? Chiến lược White-box mở hộp nhìn vào logic đặc tả ứng dụng để kiểm tra làm Kiểm tra sử dụng đặc tả logic để tạo xử lý khác dự đoán kết Các kết trung gian đầu cuối dự đoán định lượng nhờ kiểm tra white-box Chiến lược kiểm tra top–down hay bottom–up: xác định kiểm tra phát triển mã tiến hành nào: ? Kiểm tra top–down cho mã điều khiển tới hạn chức phát triển kiểm tra Tiếp theo chức thứ cấp hàm hỗ trợ Lý thuyết có nhiều module tới hạn kiểm tra, ổn định chương trình ? Kiểm tra bottom–up cho thay đổi module khả sinh lỗi Toàn module mã đơn vị kiểm tra Sau kiểm tra tiến hành mức độ tích hợp 3/8 Kiểm tra chiến luợc kiểm tra phần mềm Các chiến lược kiểm tra không loại trừ lẫn nhau, chúng sử dụng đơn lẻ đồng thời Lý tưởng kiểm tra cho ứng dụng bao gồm nhiều chiến lược để phát hết lỗi Sau chiến lược xác định, áp dụng để tạo trường hợp kiểm tra cụ thể Test case: giao dịch riêng biệt ghi liệu tạo logic kiểm tra Cho trường hợp kiểm tra tất kết xử lý dự đoán Đối với ứng dụng on-line off-line tài liệu hoá, test scripts hội thoại tạo người dùng ứng dụng thay đổi từ hội thoại Test plan: tư liệu hoá chiến lược, kiểu, trường hợp mô tả cho kiểm tra vài khối ứng dụng Tất kế hoạch tạo thành kế hoạch tổng thể cho ứng dụng Kiểm tra lặp lại không lỗi, đạt mức độ chấp nhận ? Bước xử lý kiểm tra, đầu vào kiểm tra, cấu hình mã ứng dụng đòi hỏi để tạo kiểm tra ? Bước thứ hai so sánh kết kiểm tra với kết dự tính định lượng khác biệt ? Bước loại trừ lỗi, gỡ rối mã Khi việc mã hoá lại hoàn thành, kiểm tra lại tiến hành Quá trình tiến hành kiểm tra thiết kế Cộng tác viên thực việc kiểm tra nên có khả phân tích viên lập trình viên để hiểu đòi hỏi ứng dụng kiểu cách tiến hành kiểm tra Chương trình lớn phức tạp cần người có kinh nghiệm, cần có đội ngũ kiểm tra Đội ngũ kiểm tra sử dụng yêu cầu chức từ giai đoạn phân tích đặc tả chương trình, đặc tả thiết kế từ giai đoạn thiết kế đầu vào để phát triển chiến lược kiểm tra hệ thống Khi chiến lược hoàn tất, buổi thảo luận tiến hành để kiểm tra lại chiến lược thông báo tới toàn thể đội Các nhiệm vụ mức ấn định Thời gian ước lượng Đội ngũ kiểm tra làm việc độc lập song song với đội ngũ lập trình Họ làm việc với quản trị CSDL để phát triển sở liệu mà hỗ trợ tất mức kiểm tra Đối với kiểm tra đơn vị, đội kiểm tra kiểm tra kết quả, chấp nhận module chương trình cho kiểm tra tích hợp (integration test) Đội ngũ kiểm tra tiến hành định lượng kiểm tra tích hợp kiểm tra hệ thống 4/8 Kiểm tra chiến luợc kiểm tra phần mềm Chiến lược kiểm tra phần mềm Như nói trên, có hai kiểu chiến lược kiểm tra Kiểu thứ liên quan logic kiểm tra ứng dụng Chiến lược kiểm tra logic black- box white-box Chiến lược kiểm tra black-box cho ràng module chương trình hệ thống liên quan tới đầu vào đầu Các chi tiết logic chi tiết che dấu không cần phân tích Chiến lược black-box có tính hướng liệu White-box hướng tới việc cho logic đặc trưng quan trọng cần phải kiểm tra White-box đánh giá vài tất mặt logic để kiểm tra tính đắn chức White-box hướng logic - giải thuật Kiểu thứ hai liên quan tới việc kiểm tra tiến hành nào, không quan tâm chiến lược kiểm tra logic Nó top-down bottom-up Top-down coi chương trình quan trọng nên cần phải phát triển kiểm tra trước tiếp tục trình phát triển Bottom-up cho module chương trình riêng phát triển hoàn toàn standalone Vậy chúng kiểm tra riêng rẽ sau kết hợp thành kiểm tra tổ hợp Kiểm tra Black-box Kiểm tra hộp đen, black-box, coi xử lý kết minh chứng liệu Khái niệm kiểm tra black-box không quan tâm logic Khuynh hướng hiệu modul chức đơn hệ thống cấp cao Ba phương pháp là: ? Phân hoạch cân bằng: Mục đích phương pháp tối thiểu trường hợp kiểm tra cho trước, mục liệu vào chia thành nhóm liệu có vai trò cân nhau, nhóm đại diện cho tập liệu Nguyên tắc cách kiểm tra triệt để mục tập hợp, chấp nhận tất mục tương đương khác tập hợp kiểm tra cách kỹ ? Phântíchcựcbiên:Phân tích giá trị cực biên dạng nghiêm ngặt phân hoạch cân có sử dụng giá trị biên giá trị tập cân Ví dụ: miền giá trị tháng – 12 và 13 Thì kiểm tra ứng với bốn trường hợp kiểm tra phân tích cực biên thường xuyên dùng mức modul để xác định mục liệu đặc trưng cho testing ? Đoánlỗi:Dựa sở trực giác kinh nghiệm, chuyên gia dễ dàng kiểm tra điều kiện lỗi cách đoán dễ xảy Ví dụ, chia 0, modul có phép chia, nên dùng phép chia Vì dựa trực giác, nên phép thử khó tìm hết lỗi 5/8 Kiểm tra chiến luợc kiểm tra phần mềm Một nhược điểm phân hoạch cân phân tích cực biên tổ hợp miền hợp không xác định Để bổ sung, người ta dùng sơ đồ nguyên nhân – kết (Cause – Effect Graphing) Sơ đồ nguyên nhân – kết đầu thông tin di chuyển hệ đầu vào gây hệ Các ký hiệu graphic xác định tương tác, lựa chọn, logic điều kiện tương đương Một vòng đại diện dãy thao tác điểm định điều khiển Mỗi dòng biểu diễn lớp cân liệu điều kiện sử dụng Mỗi lần graph thực giá trị có nghĩa nghĩa cho tập thử White-box testing Có ba loại kiểm tra hộp trắng kiểm tra logic -logic test, chứng minh toán học -mathematical proof Cleanroom testing Logic test Logic test chi tiết đến mức lệnh Trong thực lệnh mục đích đáng khen ngợi, không kiểm tra tất điều kiện thuộc chương trình Ví dụ, kiểm tra cho kiểm tra điều kiện (1 sai) Cố gắng kiểm tra tất điều kiện lẽ dĩ nhiên thực thực tiễn Ví dụ module có 10 thao tác qua vòng lặp có 5,5 triệu trường hợp kiểm tra Do phải có phương pháp lựa chọn Logic kiểm tra nhìn vào định module sản sinh liệu để tạo tất kết Có vấn đề với logic test mức chúng không test tình trạng module đặc tả Nếu kiểm tra phát triển dựa đặc tả, mà đặc tả dịch khác người lập trình kiểm tra không Giải pháp đòi hỏi đặc tả chương trình đủ chi tiết logic Điều phù hợp với ngôn ngữ hệ Các kiểm tra nhiều điều kiện tạo kết tiêu chuẩn đa định nhiều điểm vào module Các kiểm tra đòi hỏi việc phân tích xác định bên định đa tiêu chuẩn Nếu biên xác định không xác, kiểm tra không hiệu Khi thiết kế phù hợp, test logic đa điều kiện tối thiểu hoá trường hợp kiểm tra để kiểm tra nhiều điều kiện Sự sử dụng kỹ thuật đòi hỏi luyện tập kỹ Chứng minh toán h ọ c Một phương pháp theo cách tiếp cận giảm thiếu sót áp dụng suy diễn toán học cho đòi hỏi logic, chứng minh tính đắn chương trình Phương pháp đòi hỏi 6/8 Kiểm tra chiến luợc kiểm tra phần mềm đặc tả ngôn ngữ dạng hình thức Kỹ thuật chứng minh tính đắn chương trình đề cập 6.4 Cleanroom testing Cleanroom testing mở rộng phương pháp chứng minh toán học Lý thuyết kỹ thuật cách ngăn chặn lỗi đầu vào trình xử lý, giá thành giảm, độ tin cậy tăng lên tiệm cận tới lỗi Phương pháp phát triển IBM đầu năm 1980 Mills, Dyer, Linger Các đặc tả hình thức dùng việc kiểm tra thủ công tiến hành đội kiểm tra Các chương trình khó đọc viết lại kiểm tra hoàn toàn giấy Cleanroom testing kỹ thuật kiểm tra toán học hình thức hội ý (walkthrough) Mục đích phân tích module thành chức liên kết Các phép kiểm tra chức dùng kỹ thuật toán học, kiểm tra liên kết sử dụng thuyết tập hợp Sau thực kiểm tra (verification), đội kiểm tra độc lập dịch thực mã Dữ liệu kiểm tra dịch phân tích đặc tả chức thực thể tỷ lệ xác suất liệu giả định cho hệ thống thực Thêm vào liệu chuẩn loại lỗi nghiêm trọng tạo để kiểm tra ứng dụng Bất lợi phương pháp bắt buộc đòi hỏi kỹ cao về: toán, thống kê, logic ngôn ngữ đặc tả hình thức Kiểm tra top-down Phương pháp kiểm tra top-down cần mã ngoài, hiểu khung để gắn chức gốc, modul, phần khác ứng dụng Bộ khung thường bắt đầu với ngôn ngữ điều khiển công việc logic ứng dụng Logic kiểm tra lập khung theo hệ thống phân rã Đầu tiên có thủ tục thiết yếu logic điều khiển kiểm tra Khi module thiết yếu kiểm tra chạy tốt mã modul quan trọng gắn vào khung tiếp tục kiểm tra Về lý thuyết thì, top-down tìm thấy lỗi thiết kế sớm kiểm tra thao tác (testing process) khuynh hướng khác Phương pháp hiệu việc cải thiện chất lượng phần mềm chuyển giao chất tương tác kiểm tra Kiểm tra top-down dễ dàng hỗ trợ giao diện người dùng thiết kế hình Trong ứng dụng tương tác, thường điều khiển hình kiểm tra Người dùng kiểm tra điều khiển thông qua hình với phát triển tạo mẫu 7/8 Kiểm tra chiến luợc kiểm tra phần mềm Kiểm tra bottom-up Nguyên tắc bottom-up kiểm tra thay đổi module ảnh hưởng tới chức Trong kiểm tra bottom-up, toàn khối đơn vị để đánh giá Tất module mã hoá kiểm tra riêng rẽ Các trường hợp kiểm tra: trường hợp kiểm tra liệu vào tạo để thể khối toàn hệ thống thoả mãn tất yêu cầu thiết kế Mỗi trường hợp kiểm tra nên phát triển để kiểm tra nghiệm đòi hỏi thiết kế đặc trưng, thiết kế chức năng, mã thoả mãn Hơn trường hợp kiểm tra cần dự đoán output Mỗi đơn nguyên ứng dụng (Ví dụ: module, subroutine, program, utility, ) phải kiểm tra với hai trường hợp kiểm tra: trường hợp chạy tốt trường hợp không chạy Trong trường hợp chạy sai hệ phải đưa thông báo, quay lại (rollback) trạng thái ban đầu giao dịch Để chắn trường hợp toàn diện nhất, người ta thường dùng ma trận Chúng dùng cho: ? Kiểm tra đơn khối để định nhánh logic, điều kiện logic, phần liệu biên liệu để kiểm tra sở đặc tả chương trình ? Kiểm tra tổ hợp để định yêu cầu liệu quan hệ số tương tác ? Kiểm tra hệ thống để xác định yêu cầu người dùng hệ thống từ yêu cầu chức yêu cầu chấp nhận Phối hợp kiểm tra chiến lược: mục đích nhà kiểm tra tìm cân chiến lược cho phép họ chứng minh ứng dụng chạy tốt mà tối thiểu hoá chi phí máy tính nhân lực Sử dụng chiến lược nguy hiểm Không có Nếu có white-box tài nguyên nhân lực máy tốn kém, có black-box vấn đề logic đặc trưng chưa khám phá 8/8 ... hợp kiểm tra hệ thống 4/8 Kiểm tra chiến luợc kiểm tra phần mềm Chiến lược kiểm tra phần mềm Như nói trên, có hai kiểu chiến lược kiểm tra Kiểu thứ liên quan logic kiểm tra ứng dụng Chiến lược kiểm. .. mức kiểm tra giai đoạn vòng đời chương trình trình bày sau: 2/8 Kiểm tra chiến luợc kiểm tra phần mềm Mỗi mức kiểm tra đòi hỏi xác định chiến lược kiểm tra Chiến lược kiểm tra hộp trắng kiểm tra. .. trình ? Kiểm tra bottom–up cho thay đổi module khả sinh lỗi Toàn module mã đơn vị kiểm tra Sau kiểm tra tiến hành mức độ tích hợp 3/8 Kiểm tra chiến luợc kiểm tra phần mềm Các chiến lược kiểm tra