Bài giảng Công nghệ phần mềm

ode mô tả một điều kiện đơn được gọi là predicate XÂY DỰNG ĐỒ THỊ DÒNG CHẢY (t.t) LIỆT KÊ CÁC ĐƯỜNG ĐỘC LẬP CƠ BẢN Từ node bắt đầu đến node kết thúc, các đường thực thi cơ bản được liệt kê theo một thứ tự nào đó để đảm bảo rằng: đường đang liệt kê ít nhất đi qua một cạnh chưa được duyệt qua bởi các đường đã liệt kê trước đó Tổng số đường thực thi cơ bản độc lập nhau được tính bằng 	V = P + 1; trong đó P là số node phân nhánh (predicate) LIỆT KÊ CÁC ĐƯỜNG ĐỘC LẬP CƠ BẢN (t.t) Đối với chương trình con DoSomething Tổng số đường : V = 3 + 1 = 4 Đường 1: 1-9 Đường 2: 1-2-3-8-1… Đường 3: 1-2-4-5-7-8-1… Đường 4: 1-2-4-6-7-8-1… Chú ý: dấu 3 chấm (…) mang ý nghĩa 	"không quan tâm", từ đó có thể đi theo 	bất kỳ cạnh nào bởi vì các cạnh sau đó 	đã được duyệt qua rồi LIỆT KÊ CÁC ĐƯỜNG ĐỘC LẬP CƠ BẢN (t.t) Đối với chương trình con AnalyzeTriangle Tổng số đường : V = 6 + 1 = 7 Đường 1: 1-3-12 Đường 2: 1-2-3-12 Đường 3: 1-2-4-5-12 Đường 4: 1-2-4-6-7-12 Đường 5: 1-2-4-6-8-7-12 Đường 6: 1-2-4-6-8-9-10-12 Đường 7: 1-2-4-6-8-9-11-12 THIẾT LẬP CÁC TEST-CASE Thiết lập một test-case cho mỗi đường thực thi cơ bản Dựa vào thuật giải để tìm ra một dữ liệu input, sau đó tính ra dữ liệu output hay đáp ứng mong đợi của thuật giải Chú ý: có thể không tạo ra được test-case cho một đường thực thi nào đó THIẾT LẬP CÁC TEST-CASE (t.t) Sinh test-case cho chương trình con AnalyzeTriangle THIẾT LẬP CÁC TEST-CASE (t.t) TỔNG KẾT Mục tiêu của kiểm nghiệm phần mềm là tìm ra lỗi Hai loại kiểm nghiệm: white-box và black-box. Kiểm nghiệm các đường độc lập cơ bản dùng trong kiểm nghiệm white-box, bao gồm các bước Thiết lập đồ thị dòng chảy Liệt kê các đường thực thi độc lập cơ bản Sinh các test-case cho các đường thực thi đó CÔNG NGHỆ PHẦN MỀM Chương 10: Chiến thuật kiểm tra phần mềm Giới thiệu Verification & Validation Unit test & Integration test Kiểm nghiệm hướng đối tượng Nghệ thuật gỡ rối Nội dung 10.1. Một số khái niệm 10.1.1. Verification và validation 10.1.2. Một chiến thuật kiểm nghiệm phổ biến 10.2. Kiểm nghiệm từng module 10.3. Kiểm nghiệm tích hợp 10.3.1. Tích hợp từ trên xuống (top-down) 10.3.2. Tích hợp từ dưới lên (bottom-up) 10.3.3. Kiểm nghiệm hồi quy (regression) 10.4. Kiểm nghiệm tính năng (validation) Nội dung (tt) 10.5. Kiểm nghiệm hướng đối tượng 10.5.1. Kiểm nghiệm đơn vị hướng đối tượng 10.5.2. Kiểm nghiệm tích hợp hướng đối tượng 10.5.3. Kiểm nghiệm theo kịch bản 10.6. Nghệ thuật gỡ rối (debug) 10.6.1. Brute force 10.6.2. Loại trừ nguyên nhân 10.6.3. Theo vết MỘT SỐ KHÁI NIỆM Chiến thuật kiểm tra phần mềm tích hợp các phương pháp tạo ra test-case trở thành một chuỗi các bước có thứ tự để có thể kiểm nghiệm phần mềm thành công. Bao gồm các công việc Lập kế hoạch kiểm nghiệm Sinh test-case Thực hiện kiểm nghiệm, thu thập kết qủa và đánh giá VERIFICATION và VALIDATION Verification: các hành động để đảm bảo cho phần mềm được hiện thực đúng theo một chức năng cụ thể nào đó “Are we building the right product?" Validation: các hành động để đảm bảo cho phần mềm được xây dựng theo đúng yêu cầu của khách hàng “Are we building product right?” MỘT CHIẾN THUẬT KIỂM NGHIỆM PHỔ BIẾN MỘT CHIẾN THUẬT KIỂM NGHIỆM PHỔ BIẾN (t.t) Bắt đầu tại từng module rồi tích hợp lớn dần đến toàn bộ hệ thống. Các kỹ thuật khác nhau thích hợp tại các giai đoạn khác nhau. Kiểm nghiệm có thể được tiến hành bởi người phát triển phần mềm, nhưng đối với các dự án lớn thì việc kiểm nghiệm phải được tiến hành bởi một nhóm độc lập. Kiểm nghiệm và sửa lỗi là các hoạt động độc lập nhưng việc sửa lỗi phải phù hợp với các chiến thuật kiểm nghiệm. KIỂM NGHIỆM TỪNG MODULE Tiến hành kiểm nghiệm trên từng đơn vị nhỏ nhất của phần mềm, đó là module mã nguồn, sau khi đã thiết kế, mã hoá và biên dịch thành công Thường dùng kỹ thuật kiểm nghiệm white-box Có thể tiến hành kiểm nghiệm cùng lúc nhiều module. KIỂM NGHIỆM TỪNG MODULE (t.t) KIỂM NGHIỆM TỪNG MODULE (t.t) Mỗi module mã nguồn không phải là một chương trình hoàn chỉnh và đôi khi phải gọi các module chưa được kiểm nghiệm khác thể phải thiết lập driver và/hoặc stub: phí tổn khá lớn (70%) Driver là một chương trình chính có nhiệm vụ nhận dữ liệu kiểm nghiệm, chuyển dữ liệu đó xuống cho module để kiểm tra và in ra các kết quả kiểm tra tương ứng. Stub thay thế các module được gọi bởi module đang kiểm tra. KIỂM NGHIỆM TÍCH HỢP Từng module mã nguồn đã hoạt động đúng. Liệu khi kết hợp chúng lại thành một nhóm lớn chúng có hoạt động đúng không? Phải tiến hành kiểm nghiệm tích hợp để phát hiện lỗi liên quan đến giao tiếp giữa các module. Tránh tích hợp kiểu big-bang: tất cả các module được kết hợp lại, và toàn bộ chương trình sẽ được kiểm nghiệm một lúc Nên tích hợp tăng dần: từ trên xuống hoặc từ dưới lên TÍCH HỢP TỪ TRÊN XUỐNG Module chính được dùng như là driver, và stub được thay thế bởi các module con trực tiếp của của module chính này. Tuỳ thuộc vào cách tích hợp theo chiều sâu (depth-first) hoặc chiều ngang(breath-first), mỗi stub con được thay thế một lần bởi module tương ứng đã kiểm nghiệm. Tiến hành kiểm nghiệm khi có sự thay thế mới Tiến hành kiểm nghiệm hồi quy để phát hiện các lỗi khác trong từng module TÍCH HỢP TỪ TRÊN XUỐNG (t.t) TÍCH HỢP TỪ DƯỚI LÊN Các module mức thấp nhất được kết hợp thành các nhóm thể hiện một chức năng con đặc biệt của phần mềm. Một driver được tạo ra để thao tác các test-case Nhóm module được kiểm nghiệm. Driver được bỏ đi và các nhóm module được kết hợp dần lên phía trên trong sơ đồ phân cấp của chương trình. TÍCH HỢP TỪ DƯỚI LÊN (t.t) KIỂM NGHIỆM HỒI QUY Việc kết hợp các module lại với nhau có thể ảnh hưởng đến vòng lặp điều khiển, cấu trúc dữ liệu hay I/O chia sẻ trong một số module Điều đó làm lộ ra một số lỗi không thể phát hiện được khi tiến hành kiểm nghiệm theo đơn vị Kiểm nghiệm hồi quy có thể được tiến hành thủ công bằng cách thực hiện lại các test-case đã tạo ra. Hoặc có thể dùng một công cụ capture-playback để thực hiện tự động KIỂM NGHIỆM TÍNH NĂNG Kiểm nghiệm tính năng hiểu theo cách đơn giản nhất là: các chức năng của phần mềm đáp ứng được nhu cầu của khách hàng vốn đã được xác định trong văn bản đặc tả yêu cầu của phần mềm Áp dụng kỹ thuật black-box Kiểm nghiệm tính năng bao gồm Xem xét lại cấu hình phần mềm Kiểm nghiệm alpha Kiểm nghiệm beta KIỂM NGHIỆM TÍNH NĂNG (t.t) Kiểm nghiệm alpha Được tiến hành ngay tại nơi sản xuất phần mềm. Nhà phát triển phần mềm sẽ quan sát người sử dụng sản phẩm và ghi nhận lại những lỗi phát sinh để sửa chữa. Kiểm nghiệm beta Phần mềm được kiểm tra bên ngoài phạm vi của đơn vụ sản xuất. Khách hành trực tiếp sử dụng và ghi nhận lỗi để báo lại cho nhà phát triển sửa chữa. KIỂM NGHIỆM HƯỚNG ĐỐI TƯỢNG Về cơ bản chiến thuật kiểm nghiệm hướng đối tượng cũng theo thứ tự giống như kiểm nghiệm cổ điển: kiểm nghiệm đơn vị - kiểm nghiệm tích hợp - kiểm nghiệm chức năng -kiểm nghiệm toàn bộ hệ thống KIỂM NGHIỆM ĐƠN VỊ HƯỚNG ĐT Không thể tách rời từng tác vụ của đối tượng/lớp để kiểm nghiệm Tác vụ được đóng bao trong lớp Các lớp con có thể override một tác vụ nào đó Kiểm nghiệm đơn vị hướng đối tượng tập trung vào các lớp  kiểm nghiệm hành vi của lớp KIỂM NGHIỆM TÍCH HỢP HƯỚNG ĐT Khái niệm sơ đồ phân cấp không còn nhiều ý nghĩa trong chương trình hướng đối tượng  kiểm nghiệm tích hợp theo cách khác Hai hình thức kiểm nghiệm tích hợp hướng đối tượng Kiểm nghiệm trên cơ sở thread: tích hợp các lớp tạo thành một thread để phục vụ cho một input nào đó của chương trình Kiểm nghiệm trên cơ sở sử dụng: các lớp client sẽ được tích hợp để sử dụng dịch vụ nào đó cung cấp bởi các lớp server KIỂM NGHIỆM THEO KỊCH BẢN 	 Dựa vào các use-case để soạn ra các kịch bản Ví dụ: một kịch bản cho hệ thống đăng ký môn học qua WEB 1. Login với username = "e59306547", password = "6547" 2. Chọn chức năng đăng ký môn học 3. Chọn 5 nhóm môn học của 5 môn: CNPM, AI, XLTHS, PTTK, XLSS trong đó có 2 nhóm trùng thời khoá biểu 4. Nhấn nút Submit Chương trình phải báo lỗi và liệt kê 2 nhóm bị trùng thời khoá biểu NGHỆ THUẬT GỠ RỐI Gỡ rối là một quá trình nhằm loại bỏ các lỗi được phát hiện trong quá trình kiểm tra. Gỡ rối được thực hiện như là một kết quả của việc kiểm tra: lỗi phát hiện được tìm kiếm nguyên nhân sửa lỗi Có 3 hình thức gỡ rối: brute force, loại trừ nguyên nhân và theo vết. Nên dùng kết hợp cả 3 hình thức này. NGHỆ THUẬT GỠ RỐI (t.t) Gỡ rối là công việc khó khăn và dễ gây tâm lý chán nản bởi nguyên nhân gây ra lỗi nhiều khi lại mơ hồ: do time-out, do độ chính xác, do chủ quan lập trình... Khả năng gỡ rối gần như là bẩm sinh của mỗi người BRUTE FORCE Là phương pháp phổ biến nhất nhưng lại ít hiệu quả nhất cho việc phát hiện nguyên nhân gây lỗi phần mềm. Triết lý của phương pháp này là: "Hãy để máy tính tìm ra lỗi". Có 3 cách thực hiện: Lấy dữ liệu trong bộ nhớ để xem xét. Dùng run-time trace để tìm lỗi. Dùng lệnh WRITE để xuất dữ liệu cần kiểm tra ra màn hình. Áp dụng phương pháp này khi tất cả các phương pháp khác đều thất bại. LOẠI TRỪ NGUYÊN NHÂN Phương pháp này dựa trên nguyên tắc phân chia nhị phân. Cách thực hiện: Khi một lỗi được phát hiện, cố gắng đưa ra một danh sách các nguyên nhân có thể gây ra lỗi. Danh sách này được nghiệm lại để loại bỏ dần các nguyên nhân không đúng cho đến khi tìm thấy một nguyên nhân khả nghi nhất. Khi đó dữ liệu kiểm nghiệm sẽ được tinh chế lại để tiếp tục tìm lỗi. THEO VẾT Là một phương pháp gỡ lỗi khá phổ biến có thể dùng thành công trong các chương trình nhỏ nhưng khó áp dụng cho đối với các chương trình rất lớn. Cách thực hiện: bắt đầu tại dòng mã nguồn có triệu chứng lỗi thực hiện lần ngược trở lại từng dòng mã nguồn cho đến khi tìm thấy dòng gây ra lỗi. Nội dung môn học Chương 1: Giới thiệu về Công Nghệ Phần Mềm Chương 2: Phân tích yêu cầu theo phương pháp cổ điển Chương 3: Các khái niệm cơ bản của mô hình hướng đối tượng Chương 4: Mô hình nghiệp vụ và thu thập yêu cầu Chương 5: Phân tích yêu cầu hướng đối tượng Chương 6: Cơ sở của thiết kế phần mềm và phương pháp thiết kế cổ điển Chương 7: Thiết kế hướng đối tượng Chương 8: Hiện thực và triển khai hệ thống Chương 9: Kỹ thuật kiểm tra phần mềm Chương 10: Chiến thuật kiểm tra phần mềm