Đang tải... (xem toàn văn)
Kiểm tra chất lượng phần mềm
CHƯƠNG KIỂM TRA CHẤT LƯỢNG PHẦN MỀM Như nói trước, sản phẩm phần mềm gọi thực xác tiêu chuẩn mà người thiết kế đặt Để có đánh giá xác cấp độ phần mềm, ta phải kiểm tra chất lượng phần mềm Như thế, kiểm tra trình tìm lỗi đánh giá cuối đặc tả, thiết kế mã hố Mục đích kiểm tra đảm bảo tất thành phần ứng dụng ăn khớp, vận hành mong đợi phù hợp tiêu chuẩn thiết kế Trong chương này, thảo luận chiến lược kiểm tra phần mềm kỹ thuật, phương pháp hiệu cho mức độ kiểm tra Cuối cùng, công cụ hỗ trợ kiểm tra tự động công cụ hỗ trợ kiểm tra độc lập trình bày để hỗ trợ cho trình kiểm tra 6.1 ĐỘ TIN CẬY CỦA PHẦN MỀM 6.1.1 Chất lượng phần mềm việc đảm bảo chất lượng phần mềm Kiểm tra chất lượng phần mềm hoạt động khó khăn để chấp nhận mặt ý thức cân nhắc công việc đồng nghiệp để tìm lỗi Sau trình làm việc nhóm trở thành thành viên, ngại tìm lỗi khơng phát chúng thơng qua kiểm tra Khi người tiến hành kiểm tra lại thành viên dự án, ví dụ chuyên gia kiểm tra, họ nhìn nhận kẻ thù Thêm vào đó, kiểm tra chất lượng phần mềm lại hoạt động khó chấp nhận việc quản lý tốn kém, thời gian phát lỗi Kết phần lớn ứng dụng không kiểm tra đầy đủ phát hành với lỗi tiềm ẩn Tuy vậy, chất lượng phần mềm cao mục tiêu quan trọng nhóm phát triển phần mềm Do vậy, cần phải đảm bảo tiêu chuẩn phần mềm đề cập chương Đảm bảo chất lượng phần mềm hoạt động có hệ thống kế hoạch Nó bao gồm nhiều nhiệm vụ liên kết với hoạt động sau: + Áp dụng phương pháp kỹ thuật, + Tiến hành xét duyệt kỹ thuật thức, + Kiểm thử phần mềm, + Buộc tôn trọng chuẩn, + Kiểm soat thay đổi, + Đo chất lượng, + Báo cáo, lưu giữ kết Chương 6: Kiểm tra chất lượng phần mềm Theo chuẩn ANSI/IEEE, kế hoạch đảm bảo chất lượng phần mềm sau: I Mục đích kế hoạch II Tham khảo III Quản lý A Tổ chức B Nhiệm vụ C Trách nhiệm IV Tài liệu A Mục đích B Tài liệu công nghệ phần mềm cần thiết C Các tài liệu khác V Chuẩn, thực hành quy ước A Mục đích B Quy ước VI Xét duyệt kiểm tốn A Mục đích B Các u cầu xét duyệt Xét duyệt yêu cầu phần mềm Xét duyệt thiết kế Kiểm chứng phần mềm xét duyệt hợp lệ Kiểm toán chức Kiểm tốn vật lý Kiểm tốn tiến trình Xét duyệt quản lý VII Quản lý cấu hình phần mềm VIII Báo cáo vấn đề cách sửa chữa IX Công cụ, kỹ thuật phương pháp luận X Kiểm soát mã XI Kiểm soát phương tiện XII Kiểm sốt người cung cấp XIII Thu thập bảo trì ghi nhớ báo cáo Việc đảm bảo chất lượng phần mềm hoạt động chất cho nhóm phát triển phần mềm sản xuất phần mềm cho người sử dụng 6.1.2 Độ tin cậy phần mềm 6.1.2.1 Các lỗi thường gặp Khi phân tích chất lượng, phần mềm thường gặp số lỗi như: + Lỗi chiến lược: ý đồ thiết kế sai + Phân tích u cầu khơng đầy đủ lệch lạc + Hiểu sai chức + Vi phạm nguyên lý đối tượng + Lỗi thủ tục chịu tải, lỗi nặng + Lỗi lây lan: lỗi truyền từ chương trình sang chương trình khác + Lỗi cú pháp: viết sai quy định ngôn ngữ 118 Chương 6: Kiểm tra chất lượng phần mềm + Hiệu ứng phụ: lỗi xảy đơn vị chương trình làm thay đổi giá trị biến ý kiến lập trình viên Các lỗi phần mềm tuân theo nguyên lý mức độ lỗi: a) Mức chịu tải tăng theo chiều xuống: lỗi phát mức xem nặng mức b) Lỗi nặng nằm mức cao (ý đồ thiết kế ) mức thấp (thủ tục chịu tải lớn nhất) Do vậy, phát triển phần mềm, cần đảm bảo nguyên lý an toàn là: Mọi lỗi dù nhỏ lớn phải phát bước chương trình, trước lỗi hồnh hành 6.1.2.2 Độ tin cậy phần mềm Độ tin cậy hệ phần mềm độ đo mức độ tốt dịch vụ mà hệ cung cấp cho máy tính Cần ý người dùng không xét dịch vụ quạn trọng nhau: chẳng hạn hệ điều khiển máy bay rất, thất bại, chúng có thất bại gây tai nạn máy bay người bị nạn thân nhân người bị nạn khơng thể xem hệ đáng tin Độ tin cậy đặc trưng động hệ thống, hàm số thất bại phần mềm Một thất bại phần mềm kiện thi hành mà phần mềm hành xử khơng người ta mong đợi Chú ý thất bại phần mềm khác nột hư hỏng phần mềm Hư hỏng phần mềm đặc trưng tĩnh, gây thất bại phần mềm mà mã lỗi thi hành với tập hợp đặc biệt thông tin vào Các hư hỏng luôn xuất đầu lộ diện, đọ tin cậy phụ thuộc vào việc sử dụng hệ thống Không thể đưa phát biểu đơn giản khái quát độ tin cậy phần mềm Các hư hỏng phần mềm khuyết tật chương trình Một hành xử bất ngờ xảy mà phần mềm phù hợp với yêu cầu nó, mà yếu tố lại khơng đầy đủ Các sai sót tư liệu phần mềm dẫn đến hành vi bất ngờ phần mềm khơng có khiếm khuyết Có cơng trình nghiên cứu rút bỏ 60% khiếm khuyết mà cải tạo 3% độ tin cậy Cũng có người ý nhiều khiếm khuyết sản phẩm kết hàng trăm hàng nghìn tháng sử dụng 6.1.2.3 Một số đánh giá độ tin cậy Đặc tả độ tin cậy phần mềm: gồm bước + Phân tích hệ thất bại + Chia thất bại thành nhóm khác + Thiết lập yêu cầu độ tin cậy cách sử dụng độ đo thích hợp cho loại 119 Chương 6: Kiểm tra chất lượng phần mềm Đo độ tin cậy: theo vài cách đo sau + Xác suất thất bại tính theo địi hỏi + Tỷ lệ xuất thất bại + Thời gian trung bình hai thất bại + Độ đo mức sẵn sàng hoạt động hệ Thử nghiệm tĩnh Mục tiêu chủ yếu thử nghiệm tĩnh xác định độ tin cậy phần mềm xác định hư hỏng phần mềm Quá trình thử nghiệm tĩnh liên quan đến bước sau: i) Xác định độ đo thao tác phần mềm Độ đo thao tác mẫu sử dụng phần mềm xác định mẫu liên quan đến việc phát lớp thơng tin vào chương trình ước tính xác suất chúng ii) Chọn sinh tập liệu thử tương ứng với độ đo iii) Áp dụng trường hợp thử chương trình, ghi lại độ dài thời gian thi hành cặp thất bại quan sát Thích hợp dùng thời gian thô, với đơn vị thời gian thích hợp cho độ đo mức tin cậy iv) Tính tốn độ đo mức tin cậy sau số đáng kể (về mặt thống kê) thất bại quan sát An tồn phần mềm Có hệ thống mà thất bại gây mối đe dọa tính mạng người Thí dụ hệ thống an toàn sinh mệnh hệ thống điều khiển máy bay Có hai lớp phần mềm an toàn sinh mệnh i) Các phần mềm an toàn sinh mệnh sơ cấp: phần mềm lồng nhúng hệ phần cứng dùng để điều khiển q trình khác mà làm việc sai sót trực tiếp gây thương vong phá hủy môi trường sống người ii) Các phần mềm an toàn sinh mệnh thứ cấp: phần mềm gián tiếp gây thương vong Thí dụ hệ thống phần mềm trợ giúp thiết kế kỹ thuật, hệ thống sở liệu y tế liên quan đến chất độc bảng A Thử nghiệm khiếm khuyết Thử nghiệm chương trình có hai mục đích: thứ hệ thống phù hợp với đặc tả nó, thứ hai thực hành hệ thống theo cách cho khuyêt tật phơi Các thử nghiệm với mục đích thứ thẩm định, thử nghiệm để chấp nhận Các thử nghiệm cho mục đích thứ hai lại khác hẳn: thử nghiệm thành công thử nghiệm phơi nhiều khuyết tật Các thử nghiệm phát triển song song với việc thiết kế thực người khơng dính dáng tới việc thiết kế 120 Chương 6: Kiểm tra chất lượng phần mềm 6.1.2.4 Lập trình độ tin cậy Lập trình một công đoạn phụ thuộc nhiều vào kỹ xảo cá nhân, ý đến chi tiết kiến thức việc làm để sử dụng cơng cụ sẵn có theo cách thức tốt Nhu cầu hệ thống đáng tin tăng lên cần có kỹ thuật chun biệt nhằm đạt hệ thống tin cậy Hiện nay, có hai kỹ thuật để tăng độ tin cậy phần mềm viết chương trình ứng dụng là: tránh lỗi tha thứ lỗi Tránh lỗi Tất kỹ sư phần mềm hẳn muốn sản phần mềm khơng có lỗi Một q trình phát triển dựa vào việc phát lỗi trừ khử lỗi tránh lỗi q trình cõi lỗi thời Phần mềm khơng có lỗi phần mềm tuân theo đặc tả Nói chung, có lỗi đặc tả khơng phản ánh nhu cầu người sử dụng phần mềm khơng có lỗi khơng thiết phần mềm ln ln hành xử người dùng dự đốn Việc phát triển phần mềm khơng có lỗi việc đắt đỏ, mà số lỗi tháo khỏi chương trình giá cho việc tìm tháo lỗi cịn lại có xu hướng tăng theo hàm số mũ Do tổ chức định chấp nhận vài lỗi lưu lại Tính mặt giá chịu tiền chi trả cho thất bại hệ thống lỗi gây cịn phát tháo gỡ lỗi trước phân phối Tránh lỗi phát triển phần mềm vô lỗi dựa trên: + Sản phẩm đặc tả hệ thống xác + Chấp nhận cách tiếp cận thiết kế phần mềm dựa việc che dấu thông tin bao gói thơng tin + Tăng cường việc duyệt lại trình phát triển thẩm định hệ phần mềm + Chấp nhận triết lý chất lượng tổ chức: chất lượng bánh lái trình phát triển phần mềm + Việc lập kế hoạch cẩn thận cho việc thử nghiệm hệ thống để trưng lỗi mà lỗi chưa phát trình duyệt lại để định lượng độ tin cậy hệ thống Thứ lỗi Ngay với hệ vơ lỗi cần tiện ích thứ lỗi: có lỗi đặc tả Một tiện ích thứ lỗi cần thiết cho hệ thống đáng tin cậy Có bốn hoạt động cần phải tiến hành hệ thống phải thứ lỗi: + Phát lỗi + Định mức độ thiệt hại + Hồi phục sau gặp lỗi Hệ thống phải hồi phục trạng thái mà biết an tồn Cũng chỉnh lý trạng thái bị hủy hoại (hồi phục tiến), lui trạng thái trước mà an toàn (hồi phục lùi) 121 Chương 6: Kiểm tra chất lượng phần mềm + Chữa lỗi Cải tiến hệ thống lỗi khơng xuất Trong nhiều trường hợp thất bại phần mềm tàng hình gây tổ hợp đặc biệt thông tin vào Xử lý bất thường Một sai loại cố bất ngờ xuất ta gọi chúng bất thường Các bất thường phần cứng phần mềm Khi mà bất thường không dự đốn điều khiển chuyển cho chế xử lý bất thường hệ thống Nếu bất thường dự đốn mã phải bao gồm việc phát việc xử lý bất thường Hầu hết ngơn ngữ lập trình khơng có tiện ích để phát xử lý bất thường Các bất thường ghi lại cách dùng biến Logic nhằm có bất thường xuất Lập trình phịng thủ Lập trình phịng thủ cách phát triển chương trình mà người lập trình giả định mâu thuẫn lỗi chưa phát tồn chương trình Mã có phần kiểm tra trạng thái hệ thống sau biến đổi phải đảm bảo biến đổi trạng thái kiên định phát mâu thuẫn việc biến đổi trạng thái phải rút lại trạng thái phải trở trạng thái đắn trước Lập trình phịng thủ cách thứ lỗi, mà tiến hành không cần điều khiển thứ lỗi Về trình là: phát lỗi, đánh giá lỗi, phục hồi sau lỗi Nói chung lỗi gây sụp đổ trạng thái: biến trạng thái gắn trị khơng hợp luật Ngơn ngữ lập trình Ada cho phép phát lỗi thời gian biên dịch Tuy nhiên việc kiểm tra biên dịch hạn chế cho giá trị tĩnh vài phép kiểm tra thời gian thực tránh Một cách để phát lỗi chương trình Ada dùng chế xử lý bất thường kết hợp với đặc tả miền trị Hồi phục lỗi q trình cải biên khơng gian trạng thái hệ thống cho hiệu ứng lỗi nhỏ hệ thống tiếp tục vận hành, có lẽ mức suy giảm Hồi phục tiến liên quan đến việc cố gắng chỉnh lại trạng thái hệ thống Hồi phục lùi liên quan đến việc lưu trạng thái hệ thống trạng thái biết Hồi phục tiến thường chuyên biệt ứng dụng, mà kiến thức miền sử dụng để tính chỉnh lý Tuy nhiên có hai tình chung mà hồi phục tiến thành cơng: 1) Khi liệu mã bị sụp Việc sử dụng mã hóa thích hợp cách thêm liệu dư thừa vào liệu cho phép sửa sai phát lỗi 2) Khi cấu trúc nối bị sụp Nếu trỏ tiến lùi có cấu trúc liệu cấu trúc tái tạo đủ trỏ chưa bị sụp Kỹ thuật thường dùng cho việc sửa chữa hệ thống tệp sở liệu 122 Chương 6: Kiểm tra chất lượng phần mềm Hồi phục lùi kỹ thuật đơn giản liên quan đến việc trì chi tiết trạng thái an tồn cất giữ trạng thái mà sai bị phát Hầu hết hệ quản trị sở liệu có phục hồi lỗi Cơ sở liệu cập nhật liệu giao dịch hồn tất khơng phát vấn đề Nếu giao dịch thất bại sở liệu không cập nhật Một kỹ thuật khác thiết lập điểm kiểm tra thường kỳ mà chúng trạng thái hệ thống Khi mà lỗi phát trạng thái an tồn tái lưu kho từ điểm kiểm tra gần Không may hệ thống dính líu tới nhiều q trình hợp tác dãy thao tác điểm kiểm tra q trình khơng đồng để phục hồi trình phải lần trở lại trạng thái ban đầu 6.2 KIỂM TRA VÀ CÁC CHIẾN LƯỢC KIỂM TRA PHẦN MỀM 6.2.1 Đặ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 q 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ó sản phẩm khơ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ó sản phẩm khô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ể: • 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 123 Chương 6: Kiểm tra chất lượng phần mềm 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 ngồi đ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: Các giai đoạn phát triển ứng dụng Phạm vi mục tiêu Các kiểu kiểm tra QA/Kiểm tra chấp thuận Yêu cầu chức năng/Thiết kế logic Kiểm tra hệ thống Thiết kế vật lý Kiểm tra tích hợp Đặc tả mơ hình cấu trúc chương trình Kiểm tra đơn vị Mã hố module/chương trình 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 124 Chương 6: Kiểm tra chất lượng phần mềm • 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ự đố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 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 cịn 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ã hố lại hồ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, đơi 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à 125 Chương 6: Kiểm tra chất lượng phần mề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 6.2.2 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 blackbox 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 6.2.2.1 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ân tích cực biê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 ngồi 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 • Đốn lỗ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 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 126 Chương 6: Kiểm tra chất lượng phần mềm 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 khơng 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 khơng có nghĩa cho tập thử 6.2.2.2 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 hố 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 tố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 đặ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 khơng có lỗi 127 Chương 6: Kiểm tra chất lượng phần mềm 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ề: tốn, thống kê, logic ngơn ngữ đặc tả hình thức 6.2.2.3 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 6.2.2.4 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 128 Chương 6: Kiểm tra chất lượng phần mềm Để 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 hố 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 ngun nhân lực máy tốn kém, có black-box vấn đề logic đặc trưng chưa khám phá 6.3 KỸ THUẬT KIỂM THỬ PHẦN MỀM VÀ ĐẶC ĐIỂM 6.3.1 Khái niệm Kiểm thử sản phẩm phần mềm xây dựng cách có chủ đích tập liệu dãy thao tác nhằm đánh giá số toàn tiêu chuẩn sản phẩm phần mềm Thử nghiệm có hai mục đích: hệ thống phù hợp với đặc tả phơi khuyết tật hệ thống 6.3.2 Đặc điểm kiểm thử 6.3.2.1 Các hạn chế kiểm thử • Do kiểm thử chạy thử chương trình với tập liệu giả nên khơng thể khẳng định tính chương trình chất quy nạp khơng hồn tồn • Trong nhiều trường hợp, việc kiểm thử thường thực từ giai đoạn đầu trình cài đặt sản phẩm • Các chương trình nên kiểm chứng theo hai kỹ thuật: kiểm thử chứng minh Và nên khẳng định tính chương trình thơng qua văn chương trình Như vây, chương trình tuyệt đối phải thực thơng qua: tính đắn thuật tốn tính tương đương chương trình với thuật tốn (được thể chứng minh thơng qua văn chương trình) Việc kiểm thử chương trình nhìn kiện đưa kết luận khẳng định chương trình tuyệt đối kiểm thử Tuy vậy, liệu kiểm thử phải phủ kín trường hợp cần đánh giá 129 Chương 6: Kiểm tra chất lượng phần mềm Thêm vào đó, q trình kiểm thử, ta thưòng mắc phải đặc trưng nguyên lý chủ quan sau: • Bộ liệu Test khơng thay đổi q trình xây dựng phần mềm • Chỉ Test trường hợp thống, hợp lệ, không quan tâm đến cận cố • Cài đặt chức Test riêng chức đó, khơng Test tổng hợp chức vừa cài đặt với chức cài đặt trước • Người Test đồng thời người xây dựng phần mềm tức vừa đá bóng, vừa thổi cịi 6.3.2.2 Các loại hình kiểm thử • Kiểm thử lược đồ hệ thống: quan tâm đến chọn (menu) đánh giá tính hợp lý, khả chọn mục, khả di chuyển qua mục khác, tính đủ, tính khoa học chức • Kiểm thử cận • Kiểm thử cận trên: cho hệ thống thực đến mức tối hạn • Kiểm thử qua cố: tạo cố để kiểm thử phần mềm 6.3.2.3 Nguyên tắc kiểm thử • Nguyên tắc khách quan: người kiểm thử tác giả phần mềm kiểm thử • Nguyên tắc ngẫu nhiên: liệu chức chọn, có chủ đích khơng phải xuất theo thứ tự định • Nguyên tắc "người sử dụng kém": hệ thống người sử dụng có trình độ thấp (ở mức chấp nhận được) dùng thử (Người gây cố khơng lường trước hệ thống ) • Nguyên tắc "kẻ phá hoại": hệ thống rơi vào tay có trình độ nghiệp vụ cao, chủ ý phá hoại "Trình độ" thuộc lĩnh vực công nghệ thông tin lĩnh vực phần mềm hướng tới 6.3.2.4 • • • • • Kỹ thuật kiểm thử Kỹ thuật đối xứng: dựa vào tính đối xứng thao tác tập liệu để xậy dựng liệu Test Kỹ thuật đám đông Kỹ thuật kiểm thử liệu thật: cho hệ thống vận hành với tập liệu thật thu từ trước để so sánh đánh giá kết Kỹ thuật kiểm thử thị trường thật: cho hệ thống vận hành thị trường thật (khơng thức) để so sánh với hệ thống dùng đánh giá kết Kỹ thuật đối sánh: cho thực với vài sản phẩm khác với chức giống tập liệu lập bảng so sánh chức 6.3.2.5 Quá trình kiểm thử 130 Chương 6: Kiểm tra chất lượng phần mềm Trừ hệ thống nhỏ, nói chung khơng nên kiểm thử ngun khối; q trình kiểm thử chia giai đoạn: Thử đơn vị Thử module Thử hệ Thử hệ thống Thử nghiệm thu: gọi thử anpha Khi hệ thống đem bán phép thử beta: phân phối hệ thống cho số người dùng đồng ý dùng thử báo cáo lại vấn đề cho người phát triển hệ thống 6.3.3 Kế hoạch thử nghiệm Thử hệ thống đắt đỏ, vài hệ thời gian thực có ràng buộc thời gian phức tạp việc thử ngốn hết khoảng nửa tổng chi phí phát triển.Vì mà phải lập kế hoạch thử khống chế chi phí thử Cần ý việc thử liên quan đến việc thiết lập mẫu cho q trình thử nhiều mơ tả phép thử 6.3.4 Phân loại số công cụ kiểm thử tự động Vì kiểm thử phần mềm thường chiếm tới 40% tất nổ lực dành cho dự án xây dựng phần mềm, nên công cụ làm giảm thời gian kiểm thử (khơng làm giảm tính kỹ lưỡng) có giá trị Thừa nhận lợi ích tiềm này, nhà nghiên cứu người thực hành phát triểnmột số hệ công cụ kiểm thử tự động: Bộ phân tích tĩnh Các hệ thống phân tích chương trình hỗ trợ cho "việc chứng minh" lý lẽ tĩnh - mệnh đề yếu cấu trúc định dạng chương trình Bộ kiểm tốn mã Những lọc chuyên dụng dùng để kiểm tra chất lượng phần mềm để đảm bảo đáp ứng chuẩn mã hố tối thiểu Bộ xử lý khẳng định Những hệ thống tiền xử lý/hậu xử lý sử dụng biết liệu phát biểu người lập trình nêu, gọi khẳng định, hành vi chương trình có thực đáp ứng việc thực chương trình thực hay khơng Bộ sinh tệp kiểm thử Những xử lý sinh ra, điền giá trị xác định, vào tệp đọc vào điển hình cho chương trình kiểm thử Bộ sinh liệu kiểm thử Những hệ thống phân tích tự động hỗ trợ cho người dùng việc chọn liệu kiểm thử làm cho chương trình hành xử theo cách đặc biệt 131 Chương 6: Kiểm tra chất lượng phần mềm Bộ kiểm chứng kiểm thử Những công cụ đo mức bao quát kiểm thử bên trong, thường diễn tả dạng có liên quan tới cấu trúc điều khiển vật kiểm thử, báo cáo giá trị bao quát cho chuyên gia đảm bảo chất lượng Dụng cụ kiểm thử Lớp công cụ hỗ trợ cho việc xử lý phép kiểm thử cách làm gần khơng khó khăn để (1) thiết lập chương trình ứng cử viên mơi trường kiểm thử, (2) nạp liệu vào, (3) mô cuống cho hành vi module phụ Bộ so sánh Công cụ làm cho người ta so sánh tập từ chương trình với tập khác (đã lưu giữ trước) để xác định khác biệt chúng Hệ thống thực ký hiệu Công cụ thực việc kiểm thử chương trình cách dùng vào đại số, thay giá trị liệu số Phần mềm kiểm thử xuất để kiểm thử lớp liệu, thay trường hợp kiểm thử đặc biệt Cái đại số so sánh với kết trơng đợi xác định dạng đại số Bộ mô môi trường Công cụ hệ thống dựa máy tính giúp người kiểm thử mơ hình hố mơi trường bên ngồi phần mềm thời gian thực mô điều kiện vận hành thực cách động Bộ phân tích luồng liệu Công cụ theo dõi dấu vết luồng liệu qua hệ thống (tương tự nhiều khía cạnh với phân tích đường đi) cố gắng tìm tham khảo liệu khơng xác định, đặt số sai lỗi khác có liên quan tới liệu Hiện việc dùng cơng cụ tự động hố cho kiểm thử phần mềm phát triển, ứng dụng phát triển nhanh thập kỷ tới Các cơng cụ kiểm thử gây thay đổi lớn cách kiểm thử phần mềm cải tiến độ tin cậy hệ thống dựa máy tính 6.4 CHỨNG MINH TỐN HỌC TÍNH ĐÚNG ĐẮN CỦA CHƯƠNG TRÌNH Như đề cập trên, mục tiêu chứng minh tốn học để khẳng định tính chương trình thơng qua văn chương trình 6.4.1 Khái niệm chung Như ta biết, chương trình P biến đổi P để chuyển vào x thành y; x y hoàn toàn xác định trước Như vậy, chương trình P gọi thực xác mục tiêu người thiết kế đặc Ta gọi: + Giả thiết A mệnh đề phát biểu để thể tính chất vào, gọi tắt mệnh đề liệu vào 132 Chương 6: Kiểm tra chất lượng phần mềm + Kết luận B mệnh đề phát biểu để tính chất cần có liệu ra, gọi tắt mệnh đề liệu Do P có tính hữu hạn nên biểu diễn P dãy liên tiếp cấu trúc điều khiển P1, P2, ,Pn Do vậy, cách mà ta khẳng định được: P1 biến đổi A thành A1 P2 biến đổi A1 thành A2 Pn biến đổi An-1 thành An Và dựa vào quy tắc tốn học, An suy B ta nói P P với vào A B Lúc ký hiệu APB hay A=>B P L Cần ý A=>B khác với A=>B :mệnh đề {A} suy diễn mệnh đề {B} dựa vào quy tắc toán học A Nói cách khác, để chứng minh P đúng, P1 ta chứng minh theo sơ đồ sau: A1 A P1 A1 P2 A1 P2 A2 An-1PnAn L An=>B Ơ Ở đây, cần để ý tính chất A tính chất B khơng liên quan đến Pn Ví dụ 1: Cho mệnh đề liệu vào {A: x,y∈R; 02} {A1}P1{A2: x,y∈R; x>2} {A2}P1{A3: x,y∈R; x>4} {A3}P1{A4: x,y∈R; x>y+4} L A4=>B Ơ Vậy ta có kết luận {A}P{B} hay nói cách khác P với liệu vào {A} liệu {B} 133 Chương 6: Kiểm tra chất lượng phần mềm Cần để ý khí ta có dãy biến đổi tính chất liệu vào sau: A P1 A1 A1 P2 A2 An-1PnAn L An≠>B Ơ Thì chưa thể kết luận điều cịn tuỳ thuộc vào mệnh đề trung gian thu {A1},{A2}, {An} "mạnh nhất" hay chưa Xét ví dụ cho trên, ta có dãy biến đổi sau: {A} P1{A'1: x,y∈R; x>0} {A'1}P1{A'2: x,y∈R; x>0} {A'2}P1{A'3: x,y∈R; x>2} {A'3}P1{A'4: x,y∈R; x>y+2} Rõ ràng ta có: A' L theo ta có kết luận {A}P{B} >B 4≠ Trong trường hợp này, ta thấy mệnh đề {A'1}{A'2}{A'3}{A'4} rõ ràng mệnh đề hệ mệnh đề {A1}{A2}{A3}{A4} Ví dụ 2: Cho mệnh đề liệu vào {A: x,y∈N; x=3y}, đoạn trình P =P1∪P2 sau: x:=x+5; (P1) y:=y+5; (P2) P mệnh đề liệu {B: x,y∈R; x=3y} Ở đây, rõ ràng ta có A≠>B 6.4.2 Hệ tiên đề Hoare Tiên đề 1: Tiên đề Nếu mệnh đề A sau chịu tác động khối cấu trúc điều khiển P ta B mệnh đề B sau chịu tác động cấu trúc điều khiển Q ta C A chịu tác động P,Q thu C Hay nói cách khác, tiên đề dãy thao tác: Nếu A P B B Q C A P,Q C Tiên đề gán: tính chất phép gán Điều kiện để có mệnh đề B sau thực lệnh gán x: = E (với E biểu thức) từ mệnh đề {A} trước ta phải có {A} suy dẫn {B[x|E]} Mệnh đề {B[x|E]} mệnh đề thu từ {B} phép thay xuất L x {B} E Tức là: A x: = E B A=>B[x|E] 134 Chương 6: Kiểm tra chất lượng phần mềm Kỹ thuật lần ngược tiên đề gán Cho đoạn trình P gồm n phép gán x1:=E1; x2:=E2; .xn:=En; để {A}P{B} L ta phải có A=>Bn Trong {Bn} xác định sau A Bn Trong mệnh đề {Bi} xác định sau: x1:=E1 {B1} mệnh đề {B[xn|En]} Bn-1 x2:=E2 {Bn-1} mệnh đề {Bn-2[x2|E2]} B1 xn:=En {Bn} mệnh đề {Bn-1[x1|E1]} B L Trong trường hợp A≠>B ta nói P có lỗi n Ví dụ 3: (Xét ví dụ 1) Cho mệnh đề liệu vào {A: x,y∈R; 0y+3} {B1[x|x+2]} ≡{B2 : (x+2)+y,y∈R; (x+2)+y>y+3} {B2[y|y+1]} ≡{B3 : (x+2)+(y+1),(y+1)∈R; (x+2)+(y+1)>(y+1)+3} {B3[x|1/x+1]} ≡{B4 : ((1/x+1)+2)+(y+1),(y+1)∈R; ((1/x+1)+2)+(y+1)>(y+1)+3} L Rõ ràng ta có A=>B , nên {A}P{B} 4 135 Chương 6: Kiểm tra chất lượng phần mềm Tiên đề rẽ nhánh i Với mệnh đề liệu vào {A}, mệnh đề liệu {B}, biểu thức logic E, L đoạn trình P Nếu ta có {A, E}P{B} A,!E=>B ta nói mệnh đề {A} {B} tuân theo cấu trúc rẽ nhánh dạng khuyết với cấu trúc P điều kiện lựa chọn E; tức là: {A} if E then P; {B} ii Với mệnh đề liệu vào {A}, mệnh đề liệu {B}, biểu thức logic E, đoạn trình P, Q Nếu ta có {A, E}P{B} {A,!E}Q{B} ta nói mệnh đề {A} {B} tuân theo cấu trúc rẽ nhánh dạng đủ với cấu trúc P, Q điều kiện lựa chọn E; tức là: {A} if E then P else Q; {B} Ví dụ 4: Cho mệnh đề liệu vào {A: x,y,q,r∈R, x=qy+r, 0≤r0 Begin If (x mod 2)≠0 then z:=z+y; x=x div 2; y:=y*2; End; Return z; Ta cần phải khẳng định chương trình với yêu cầu đặt Thật vậy, gọi mệnh đề thể tính chất liệu vào chương trình {A} mệnh đề thể tính chất liệu cần có {B}, ta có {A: x,y,z∈N; x=a; y=b;} {B: x,y,z∈N; z=ab;} Ta cần chứng tỏ {A}P {B} + Xét mệnh đề {C: x,y,z∈N; ab=z+xy;} + Ta có {A} z:=0;{C} + Để chứng tỏ {C} bất biến đoạn trình while x>0 Begin If (x mod 2)≠0 then z:=z+y; x=x div 2; y:=y*2; End; Ta cần có: {C,E: x,y,z∈N; ab=z+xy;x>0}Q{C}, với đoạn trình Q sau: If (x mod 2)=0 then z:=z+y; x=x div 2; y:=y*2; Theo tính chất phép gán, ta có: {C1}≡{C[y|y*2]: x,y*2,z∈N; ab=z+x(y*2);} {C2}≡{C1[x|(x div 2)]: (x div 2),y*2,z∈N; ab=z+(x div 2)(y*2);} Nên cần chứng tỏ: {C,E: x,y,z∈N; ab=z+xy;x>0} If (x mod 2)≠0 then z:=z+y; {C2} Dễ dàng ta có i {C,E,F: x,y,z∈N; ab=z+xy;x>0,(x mod 2)≠0} z:=z+y {C2}; L ii {C,E,!F: x,y,z∈N; ab=z+xy;x>0,(x mod 2)=0} =>{C2}; 137 Chương 6: Kiểm tra chất lượng phần mềm Vậy {C} bất biến Q Nên kết thúc Q, ta có mệnh đề {C,!E} L + Dễ dàng chứng tỏ: {C,!E}=>{B} Vậy ta có {A}P{B}, hay chương trình L Để ý rằng: {A,E}P{A} nên trường hợp {A}=>E vịng lặp vơ hạn khơng tồn mệnh đề {A, !E} 138 ... 6: Kiểm tra chất lượng phần mề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. .. thái ban đầu 6.2 KIỂM TRA VÀ CÁC CHIẾN LƯỢC KIỂM TRA PHẦN MỀM 6.2.1 Đặ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... 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 123 Chương 6: Kiểm tra chất lượng phần mềm Các kiểm tra đội dự án gọi kiểm tra phát triển (Development