10/20/2011 PHẦN V: KIỂM THỬ VÀ BẢO TRÌ I Kiểm thử Khái niệm kiểm thử Phương pháp thử Kỹ thuật thiết kế trường hợp thử Kiểm thử module Kiểm thử hệ thống Kiểm thử chấp nhận II Bảo trì 1 Khái niệm kiểm thử • Là mấu chốt đảm bảo chất lượng phần mềm • Là tiến trình (và nghệ thuật) nhằm phát lỗi việc xem xét lại đặc tả, thiết kế mã nguồn • Kiểm thử thành công phát lỗi; kiểm thử không phát lỗi kiểm thử dở 10/20/2011 Khó khăn • Nâng cao chất lượng phần mềm không vượt chất lượng thiết kế: phát lỗi tiềm tàng sửa chúng • Phát lỗi bị hạn chế thủ cơng • Dễ bị ảnh hưởng tâm lý kiểm thử • Khó đảm bảo tính đầy đủ kiểm thử Lưu ý kiểm thử Chất lượng phần mềm khâu thiết kế định chủ yếu, khơng phải khâu kiểm thử Tính dễ kiểm thử phụ thuộc vào cấu trúc chương trình Người kiểm thử người phát triển nên khác Dữ liệu thử cho kết bình thường khơng có ý nghĩa nhiều, cần có liệu kiểm thử mà phát lỗi Khi thiết kế trường hợp thử, không liệu kiểm thử nhập vào, mà phải thiết kế trước liệu kết có Khi phát sinh thêm trường hợp thử nên thử lại trường hợp thử trướcđó để tránh ảnh hưởng lan truyền sóng 10/20/2011 Tương ứng vòng đời dự án kiểm thử Đối tượng phạm vi Kiểm thử chấp nhận Đặc tả chức năng/ Thiết kế lơ gíc Kiểm thử hệ thống Thiết kế Vật lý Kiểm thử tích hợp Cấu trúc chương trình đặc tả module Kiểm thử đơn vị chương trình Kiểm thử hồi quy Mã hố module chương trình 2.1 Kiểm thử tĩnh • Kiểm thử bàn: giấy bút bàn, kiểm tra logic, lần chi tiết sau lập trình xong • Đi xuyên suốt (walk through) • Thanh tra (inspection) 10/20/2011 2.2 Kiểm thử máy • Gỡ lỗi máy (machine debug) hay kiểm thử động: Dùng máy chạy chương trình để điều tra trạng thái động tác chương trình • bước trình tự kiểm thử máy: Trình tự kiểm thử máy Thiết kế trường hợp thử theo thử bàn Trường hợp thử phải có kết kỳ vọng thu Dịch chương trình nguồn tạo module tải để thực Khi trường hợp thử có xử lý tệp vào-ra, phải làm trước bàn việc xác định miền tệp Nhập liệu thiết kế cho trường hợp kiểm thử Điều chỉnh môi trường thực module tải (tạo thủ tục đưa tệp truy cập tệp vào chương trình) Thực module tải ghi nhận kết Xác nhận kết với kết kỳ vọng Lặp lại thao tác (5)-(8) 10/20/2011 Kỹ thuật thiết kế trường hợp thử • Kỹ thuật thiết kế trường hợp thử dựa đặc tả bề ngồi chương trình: Kiểm thử hộp đen (Black box test): WHAT ? • Kỹ thuật thiết kế trường hợp thử dựa đặc tả bên chương trình: Kiểm thử hộp trắng (white box test): HOW ? • Kiểm thử Top-Down hay Bottom-Up 3.1 Kiểm thử hộp đen • • • • Phân đoạn tương đương Phân tích giá trị biên Đốn lỗi Và số kỹ thuật khác Input Results Black Box Black box Data Testing Strategy 10 10/20/2011 a Phương pháp phân đoạn tương đương (Equivalence Partition) • Mục đích: giảm số lượng test cách chọn tập liệu đại diện • Thực hiện: Chia kiệu vào thành đoạn, đoạn đại diện cho số liệu => việc kiểm thử thực đại diện • Ưu điểm: Test theo mức trừu tượng trường • Áp dụng: hình, menu hay mức q trình • Ví dụ: 11 b Phương pháp phân tích giá trị biên (Boundary value analysis) • Là trường hợp riêng phân đoạn • Thí dụ: miền liệu tháng giá trị hay >12 khơng hợp lệ • Thường sử dụng kiểm thử module 12 10/20/2011 c Phương pháp đốn lỗi (Error Guessing) • Dựa vào trực giác kinh nghiệm • Thí dụ lỗi chia cho Nếu module có phép chia phải kiểm thử lỗi • Nhược điểm: không phát hết lỗi 13 d Phương pháp đồ thị nguyên nhân kết (Cause-effect Graphing) SEQUENCE AND NOT OR DO UNTIL 14 10/20/2011 3.2 Kiểm thử hộp trắng • Là phương pháp kiểm thử dựa vào cấu trúc điều khiển thủ tục để thiết kế trường hợp kiểm thử Input  Results  White Box Data Testing Strategy 15 Kiểm thử hộp trắng (tiếp) • Người KSPM đảm bảo: – Kiểm tra tất lộ trình độc lập bên mơ đun lần – Kiểm tra tất nhánh đúng/sai lựa chọn – Kiểm tra việc thực vòng lặp biên bên vòng lặp – Kiểm tra cấu trúc liệu để đảm bảo tính hợp thức • Các kỹ thuật: – Kiểm thử theo lộ trình (Basis path testing) – Kiểm thử theo cấu trúc điều khiển 16 10/20/2011 a Kiểm thử theo lộ trình • Là kỹ thuật Tom McCabe đề xuất cho phép nhà kiểm thử tiến hành số đo độ phức tạp lô gic thủ tục số đo sử dụng để giúp cho việc định nghĩa lộ trình cho lệnh chương trình thực lần q trình kiểm thử • Sử dụng Ký pháp đồ hoạ luồng/ đồ thị chương trình: – Mỗi nút đồ thị biểu diễn lệnh/ dãy lệnh liên tiếp – Cung đồ thị biểu diễn luồng điều kiện (trình tự thực hiện) 17 Ví dụ: lưu đồ khối chương trình 11 10 18 10/20/2011 Ví dụ: Đồ thị chương trình 2, 4, 10 11 19 Chú ý • Một cung phải kết thúc nút (có thể nút khơng tương ứng với lệnh thủ tục) • Vùng bao cung nút gọi Region (khi tính, ta phải tính vùng bao ngồi) • Thí dụ đồ thị chương trình slide trước gồm vùng (các số in nghiêng) • Với điều kiện phức tạp (nhiều phép so sánh) so sánh lại tách thành nút riêng • Thí dụ: If a OR b then X else Y Endif 20 10 10/20/2011 3.3 Trình tự thiết kế • Kiểm thử module • Kiểm thử tích hợp – Kiểm thử tích hợp xuống – Kiểm thử tích hợp lên – Kiểm thử hồi qui 25 Kiểm thử module • Kiểm thử tích hợp module – – – – Kiểm Kiểm Kiểm Kiểm thử thử thử thử lên (Bottom-up Test) xuống (Top-down Test) cột trụ (Big bang Test) kẹp (Sandwich Test) 26 13 10/20/2011 a Bottom-up Test • Các module mức thấp tổ hợp vào chùm thực chức • Viết trình điều khiển phối hợp vào/ kiểm thử • Kiểm thử chùm/bó • Loại bỏ trình điều khiển chuyển lên mức 27 Bottom-up Test (Tiếp) Mức Mức Mức Mức 28 14 10/20/2011 b Top-down Test • module điều khiển dùng trình điều khiển kiểm thử, gắn nút trực tiếp vào • Thay nút module thực (theo chiều sâu / ngang) • Kiểm thử module gắn vào • Các nút thử xong thử tiếp nút khác • Kiểm thử hồi quy 29 Top-down Test (tiếp) Mức Mức Mức Mức 30 15 10/20/2011 c Big bang Test • • • • Tích hợp khơng tăng dần Tất các module tổ hợp trước Tồn chương trình kiểm thử tổng thể Khó khăn: khó lập lỗi, chữa xong lỗi lỗi lại phát sinh 31 d Sandwich Test • Tích hợp xuống cho mức cấu trúc chương trình • Tích hợp lên cho mức phụ thuộc 32 16 10/20/2011 Kiểm thử hệ thống • Kiểm thử phục hồi: bắt buộc phần mềm hỏng nhiều cách để kiểm chứng phục hồi • Kiểm thử an toàn: kiểm chứng chế bảo vệ • Kiểm thử gay cấn • Kiểm thử hiệu 33 Kiểm thử chấp nhận • Mục đích: để bàn giao PM cho khách hàng • Đối tượng: Cần có tham gia ND • Trình tự: Dựa vào Yêu cầu PM 34 17 10/20/2011 PHẦN V: KIỂM THỬ VÀ BẢO TRÌ I Kiểm thử II Bảo trì Khái niệm Quy trình nghiệp vụ Các vấn đề cịn tồn Bảo trì phương pháp phát triển phần mềm 35 Khái niệm • Bảo trì cơng việc tu sửa, thay đổi phần mềm phát triển (chương trình, liệu, JCL, loại tư liệu đặc tả, ) theo lý • Các hình thái bảo trì: bảo trì để – – – – Tu chỉnh Thích nghi Cải tiến Phịng ngừa 36 18 10/20/2011 a Bảo trì để tu sửa • • Là bảo trì khắc phục khiếm khuyết có phần mềm Một số nguyên nhân điển hình – Kỹ sư phần mềm khách hiểu nhầm – Lỗi tiềm ẩn phần mềm sơ ý lập trình kiểm thử chưa bao quát hết – Vấn đề tính phần mềm: khơng đáp ứng yêu cầu nhớ, tệp, Thiết kế sai, biên tập sai – Thiếu chuẩn hóa phát triển phần mềm (trước đó) • • Kỹ nghệ ngược (Reverse Engineering): dò lại thiết kế để tu sửa Những lưu ý – – – – Mức trừu tượng Tính đầy đủ Tính tương tác Tính định hướng 37 b Bảo trì để thích hợp • Là tu chỉnh phần mềm theo thay đổi môi trường bên ngồi nhằm trì quản lý phần mềm theo vịng đời • Thay đổi phần mềm thích nghi với mơi trường: cơng nghệ phần cứng, mơi trường phần mềm • Những ngun nhân chính: – Thay đổi phần cứng (ngoại vi, máy chủ, .) – Thay đổi phần mềm (môi trường): đổi OS – Thay đổi cấu trúc tệp mở rộng CSDL 38 19 10/20/2011 c Bảo trì để cải tiến • • Là việc tu chỉnh hệ phần mềm theo yêu cầu ngày hoàn thiện hơn, đầy đủ hơn, hợp lý Những nguyên nhân chính: – Do muốn nâng cao hiệu suất nên thường hay cải tiến phương thức truy cập tệp – Mở rộng thêm chức cho hệ thống – Cải tiến quản lý kéo theo cải tiến tư liệu vận hành trình tự công việc – Thay đổi người dùng thay đổi thao tác • • • Cịn gọi tái kỹ nghệ (reengineering) Mục đích: đưa thiết kế chức có chất lượng cao Các bước thực hiện: – Xây dựng lưu đồ phần mềm – Suy dẫn biểu thức Bun cho dãy xử lý – Biên dịch bảng chân lí – Tái cấu trúc phần mềm 39 d Bảo trì để phịng ngừa • Là cơng việc tu chỉnh chương trình có tính đến tương lai phần mềm mở rộng thay đổi • Thực thiết kế phần mềm phải tính đến tính mở rộng nó, nên thực tế ta gặp bảo trì phịng ngừa phần mềm thiết kế tốt • Mục đích: sửa đổi để thích hợp với u cầu thay đổi có người dùng • Thực thay đổi thiết kế khơng tường minh • Hiểu hoạt động bên chương trình • Thiết kế / lập trình lại • Sử dụng công cụ CASE 40 20 10/20/2011 Quy trình nghiệp vụ • Quy trình bảo trì: q trình vòng đời phần mềm, tuân theo pha phân tích, thiết kế, phát triển kiểm thử từ phát sinh vấn đề giải xong • Các nhiệm vụ bảo trì: – Phân tích/cơ lập: phân tích tác động, phân tích giá trị lợi ích, lập thành phần cần bảo trì – Thiết kế: thiết kế lại hệ thống (phải biết cách tu sửa, thay đổi) – Thực thi: thay mã nguồn kiểm soát đơn vị thành phần hệ thống, có tính đến thời gian lập trình • Thao tác bảo trì: Gồm loại – Tu chỉnh cải có (loại 1) – Thêm (loại 2) 41 Sơ đồ bảo trì Hiểu phần mềm có Loại bảo trì? Tu sứa phần mềm có Kiểm thử tính qn Kiểm thử sau bảo trì Tạo biểu quản lý bảo trì Phát triển phần mềm Thực thi “trên bàn”: -Nắm vững chức hệ thống theo tài liệu -Nắm vững đặc tả chi tiết, điều kiện kiểm thử, theo tài liệu -Dị đọc chương trình nguồn, hiểu trình tự xử lý chi tiết hệ thống -Khi thêm chức phải phát triển chương trình cho phù hợp với yêu cầu -Cần tiến hành từ thiết kế, lập trình, gỡ lỗi kiểm thử unit -Phản ảnh vào giao diện phần mềm (thông báo, phiên bản, ) -Bảo trì chương trình nguồn, tạo module dịch lại -Thực kiểm thử unit tu chỉnh mục liên quan có tư liệu đặc tả -Chú ý theo sát tác động module sửa đến thành phần khác 42 hệ thống 21 10/20/2011 Sơ đồ bảo trì Hiểu phần mềm có Loại bảo trì? Tu sứa phần mềm có Kiểm chứng tính quán Kiểm thử sau bảo trì Tạo biểu quản lý bảo trì Phát triển phần mềm Bằng kiểm thử tích hợp -Đưa đơn vị (unit) dược kiểm thử vào hoạt động hệ thống -Điều chỉnh tương tích module -Dùng liệu trước kiểm thử để kiểm thử lại tính quán ! Chú ý hiệu ứng sóng chỉnh sửa Khi hồn thành bảo trì: -Kiểm tra nội dung mơ tả có tư liệu đặc tả -Cách ghi tư liệu có phù hợp với mơ tả mơi trường phần mềm hay khơng ? Để quản lý tình trạng bảo trì, lập biểu: -Ngày tháng, -Nguyên nhân -Tóm tắt cách khắc phục -Chi tiết khắc phục, hiệu ứng sóng -Người làm bảo trì 43 -Số cơng Các vấn đề cịn tồn • Phương pháp cải tiến thao tác bảo trì: – Sáng kiến quy trình phát triển phần mềm – Sáng kiến quy trình bảo trì phần mềm – Phát triển kỹ thuật cho bảo trì 44 22 10/20/2011 a Sáng kiến quy trình phát triển phần mềm • Chuẩn hóa khâu phát triển phần mềm • Người bảo trì chủ chốt tham gia vào giai đoạn phân tích thiết kế • Thiết kế để dễ bảo trì 45 b Sáng kiến quy trình bảo trì phần mềm • Sử dụng cơng cụ hỗ trợ phát triển phần mềm • Chuẩn hóa thao tác bảo trì thiết bị mơi trường bảo trì • Lưu lại thơng tin sử bảo trì • Dự án nên cử người chủ chốt làm cơng việc bảo trì sau dự án kết thưc giai đoạn phát triển 46 23 10/20/2011 c Phát triển kỹ thuật cho bảo trì • Cơng cụ phần mềm hỗ trợ bảo trì • Cơ sở liệu cho bảo trì • Quản lý tài liệu, quản lý liệu, quản lý chương trình nguồn, quản lý liệu thử, quản lý sử bảo trì • Trạm bảo trì tính cao hệ thống mạng lưới bảo trì với máy chủ thơng minh 47 Bài tập nhà • Tìm hiểu SMMM – Software Maintenance Maturity Model 48 24 10/20/2011 a Phát triển lặp 49 RUP 50 25 10/20/2011 Scrum 51 Agile 52 26 10/20/2011 b Hướng thành phần • Những hoạt động bảo trì CBSD – – – – – – Gắn kết hóa gói hóa May đo hóa Phát lỗi lập Cập nhật cấu hình thành phần Theo dõi kiểm tra hành vi hệ thống Kiểm thử thành phần 53 c Mã nguồn mở • Sự khác biệt với bảo trì theo phương pháp truyền thống – Phiên ngày tháng – Chờ đợi dịch vụ 54 27 ... = -9 99 12 Endif 13 LastUpdate 8-0 7 Dept of SE, 2001 SE-V.23 Lời giải • Số lộ trình độc lập (độ phức tạp lặp) = – – – – 1-2 -1 0-1 1-1 3; 1-2 -1 0-1 2-1 3 1-2 - 3-1 0-1 1-1 3; 1-2 - 3-4 - 5- 8 - 9-2 … 1-2 - 3-4 - 5- 6 - 8-9 -2 …;... hành để đảm bảo lệnh thực lần • Lộ trình độc lập? phần CT bao gồm tập lệnh hay điều kiện • Đồ thị CT có lộ trình độc lập: 1-1 1; 1-2 - 3-4 -5 1 0-1 -1 1; 1-2 - 3-6 - 8-9 -1 0-1 -1 1; 1-2 - 3-6 - 7-9 -1 0-1 -1 1 21 Độ... 1-2 - 3-4 - 5- 6 - 8-9 -2 …; 1-2 - 3-4 - 5- 6 - 7-8 - 9-2 … …: có nghĩa phần lại đồ thị chấp nhận • Đồ thị chương trình ? • Số test phải thực hiện: 24 12 10/20/2011 3.3 Trình tự thiết kế • Kiểm thử module • Kiểm thử tích