Bài giảng kiểm thử phần mềm ( combo full slides 9 chương )

Bài giảng kiểm thử phần mềm ( combo full slides 9 chương ) Bài giảng kiểm thử phần mềm ( combo full slides 9 chương ) Bài giảng kiểm thử phần mềm ( combo full slides 9 chương ) Bài giảng kiểm thử phần mềm ( combo full slides 9 chương ) Bài giảng kiểm thử phần mềm ( combo full slides 9 chương ) Bài giảng kiểm thử phần mềm ( combo full slides 9 chương ) Bài giảng kiểm thử phần mềm ( combo full slides 9 chương )

BÀI GIẢNG KIỂM THỬ PHẦN MỀM NỘI DUNG BÀI GIẢNG  CHƯƠNG : TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM  CHƯƠNG : QUI TRÌNH VÀ KẾ HOẠCH KIỂM THỬ PHẦN MỀM  CHƯƠNG : PHƯƠNG PHÁP KIỂM THỬ ( HỘP TRẮNG )  CHƯƠNG : PHƯƠNG PHÁP KIỂM THỬ ( HỘP ĐEN )  CHƯƠNG : KIỂM THỬ ĐƠN VỊ  CHƯƠNG : KIỂM THỬ TỰ ĐỘNG VÀ CÔNG CỤ HỖ TRỢ  CHƯƠNG : CHẠY THỬ VÀ THANH TRA KIỂM TRA MÃ NGUỒN  CHƯƠNG : CÁC HOẠT ĐỘNG KIỂM THỬ KHÁC  CHƯƠNG : PHÂN TÍCH VÀ GIẢI THÍCH KẾT QUẢ KIỂM THỬ Chương 1: Tổng quan kiểm thử phần mềm  Qui trình phát triển phần mềm RUP  Một vài định nghĩa kiểm thử phần mềm  Kiểm thử: worker qui trình  Các mức độ kiểm thử phần mềm  Test case  Các nguyên tắc kiểm thử  Các ý tưởng không kiểm thử  Các hạn chế việc kiểm thử Tổng kết Qui trình phát triển phần mềm RUP Qui trình phát triển phần mềm RUP • Chu kỳ phần mềm tính từ lúc có u cầu (mới nâng cấp) đến lúc phần mềm đáp ứng yêu cầu phân phối • Trong chu kỳ, người ta tiến hành nhiều công đoạn : khởi động (Inception), chi tiết hóa (elaboration), xây dựng (construction) chuyển giao (transition) • Mỗi công đoạn thường thực theo chế lặp nhiều lần để kết ngày hoàn hảo • Trong bước lặp, thường thực nhiều workflows đồng thời (để tận dụng nguồn nhân lực hiệu nhất) : nắm bắt yêu cầu, phân tích chức năng, thiết kế, thực kiểm thử Qui trình phát triển phần mềm RUP • Sau lần lặp thực công việc đó, ta phải tạo kết (artifacts), kết bước/công việc liệu đầu vào bước/cơng việc khác • Nếu thơng tin khơng tốt ảnh hưởng nghiêm trọng đến kết bước/hoạt động sau Qui trình phát triển phần mềm RUP Một số vấn đề thường gặp phát triển phần mềm:  Tính tốn khơng đúng, hiệu chỉnh sai liệu  Trộn liệu khơng  Tìm kiếm liệu sai yêu cầu  Xử lý sai mối quan hệ liệu  Coding/hiện thực sai qui luật nghiệp vụ  Hiệu suất phần mềm thấp  Kết hiệu suất phần mềm không tin cậy  Hỗ trợ chưa đủ nhu cầu nghiệp vụ  Giao tiếp với hệ thống khác chưa ₫úng hay chưa đủ  Kiểm soát an ninh phần mềm chưa đủ Một số định nghĩa kiểm thử phần mềm  Kiểm thử phần mềm qui trình chứng minh phần mềm khơng có lỗi  Mục đích kiểm thử phần mềm phần mềm thực chức mong muốn  Kiểm thử phần mềm qui trình thiết lập tin tưởng việc phần mềm hay hệ thống thực điều mà hỗ trợ  Kiểm thử phần mềm qui trình thi hành phần mềm với ý định tìm kiếm lỗi  Kiểm thử phần mềm xem qui trình cố gắng tìm kiếm lỗi phần mềm theo tinh thần "hủy diệt" Một số định nghĩa kiểm thử phần mềm • Các mục tiêu kiểm thử phần mềm :  Phát nhiều lỗi tốt thời gian kiểm thử xác định trước  Chứng minh sản phẩm phần mềm phù hợp với đặc tả yêu cầu  Xác thực chất lượng kiểm thử phần mềm dùng chi phí nỗ lực tối thiểu  Tạo testcase chất lượng cao, thực kiểm thử hiệu tạo báo cáo vấn ₫ề ₫úng hữu dụng Một số định nghĩa kiểm thử phần mềm • Kiểm thử phần mềm thành phần lĩnh vực rộng hơn, Verification & Validation (V &V), ta tạm dịch Thanh kiểm tra Kiểm định phần mềm • Thanh kiểm tra phần mềm qui trình xác định xem sản phẩm cơng đoạn qui trình phát triền phần mềm có thoả mãn yêu cầu đặt công đoạn trước khơng (Ta có xây dựng đắn sản phẩm khơng ?) • Thanh kiểm tra phần mềm thường hoạt động kỹ thuật dùng kiến thức thành phần lạ (artifacts), yêu cầu, đặc tả rời rạc phần mềm • Các hoạt động Thanh kiểm tra phần mềm bao gồm kiểm thử (testing) xem lại (reviews) Sử dụng biểu đồ phân loại nhóm lỗi 30 Độ tương quan lỗi khách hàng phát Trong khoảng thời gian từ lúc project trước hoàn thành đến lúc project sau phát triển, ta có thêm nhiều thơng tin khác Một thông tin quan trọng số lượng lỗi tính chất lỗi phát phản hồi phận HelpDesk khách hàng Ta dùng độ tương quan lỗi khách hàng phát sau: - Tỉ lệ lỗi tiên đoán/lỗi khách hàng phát thực tế - 487/70 = 6.9 Nhờ độ tương quan mà ta tiên đoán số lượng lỗi mà khách hàng phát sử dụng project phần mềm phát triển Dựa vào số lượng lỗi mà ta qui hoạch tương đối xác số lượng thời lượng làm việc nhân viên phận hỗ trợ (Support) giúp đỡ (HelpDesk) người dùng ⇒ dự tốn xác chi phí sửa lỗi - Bảng theo dõi lỗi phản ánh khách hàng phận giúp đỡ khách hàng ghi nhận phận phát triển phân loại nhóm lỗi 31 Độ tương quan lỗi khách hàng phát 32 Độ tương quan lỗi khách hàng phát Bắt đầu project Lúc ta có : - số lượng hàng lệnh số lỗi project trước (được thể đường cong miêu tả số lỗi phát được) - mức độ tầm trọng lỗi cách phân phối chúng theo thời gian (được thể biểu đồ phân phối mức độ lỗi project trước) So sánh với số lượng hàng lệnh project phát triển, ta tính số lượng lỗi cho project này, từ kế hoạch hóa việc kiểm thử, chuẩn bị tài nguyên phù hợp cho việc kiểm thử 33 Độ tương quan lỗi khách hàng phát Trong chu kỳ kiểm thử, ta tổng kết vẽ số lượng lỗi phát trực tiếp lên đường biểu diễn project trước để dễ dàng so sánh nội suy thông tin cần Do project có qui mơ tính chất khác nhau, số lượng lỗi phát tuần đầu khác 34 Độ tương quan lỗi khách hàng phát • Thí dụ Project hành A có số lỗi phát nhiều project cũ tốc độ phát lỗi tuần đầu cao nhiều so với project cũ Đây xu mà ta mong muốn Điều đặt câu hỏi : ta kiểm thử hiệu trước ? Câu trả lời ta dùng nhiều tools kiểm thử tự động trước Thí dụ Project hành B có số lỗi phát project cũ tốc độ phát lỗi chậm so với project cũ • Đây xu mà ta khơng mong muốn Điều đặt câu hỏi : ta kiểm thử hiệu trước ? Câu trả lời ta bỏ hay làm thiếu số hoạt ₫ộng mà project trước làm Sau xác định nguyên nhân rõ ràng, ta khắc phục để việc kiểm thử hiệu cho tuần lại 35 Độ tương quan lỗi khách hàng phát • Khi project tiếp tục Tiếp tục kiểm soát vẽ đường cong biểu diễn lỗi phát cột mốc trình phát triển phần mềm Tới lúc đó, thường khoảng 1/3 thời gian phát triển phần mềm, tốc ₫ộ phát lỗi (số lỗi phát hiện/trên tuần) đạt ngưỡng bắt đầu giảm xuống Điểm uốn điểm neo quan trọng cho hầu hết hoạt động phân tích kết lỗi : - Project A có điểm ngưởng tuần với số lượng 1213 lỗi ⇒ Project A kiểm thử hiệu project cũ - Project B có điểm ngưỡng tuần 12 với số lượng 607 lỗi ⇒ Project B ₫ược kiểm thử hiệu project cũ project A 36 Độ tương quan lỗi khách hàng phát 37 Khi project kết thúc • Tiếp tục kiểm thử vẽ kết theo thời gian Mỗi lần vẽ điểm vào đồ thị, ta phân tích điểm có bất thường khơng ? Nếu có đặt câu hỏi tạo từ có biện pháp khắc phục • Khi project kết thúc (giả sử theo kế hoạch tuần 24 biểu đồ), ta nội suy nới rộng đồ thị sang phải tiếp xúc trục x Một số tiên đoán ước lượng : - Project A chứa 14 lỗi ₫ược tiên đốn khách hàng tìm nên có lỗi mà khách hàng thực tìm → chi phí sửa 2*14000 = 28000$ (giảm ₫ược 952000$ so với project trước) - Project B chứa 1377 lỗi tiên đốn khách hàng tìm nên có 196 lỗi mà khách hàng thực tìm → chi phí sửa 196*14000 = 2744000$ (tăng 1746000$ so với project trước) 38 Khi project kết thúc 39 Đường cong Rayleight - Gunsight cho mẫu phát lỗi • Làm biết tốc độ phát lỗi project công nghiệp hãng lớn ? Nhờ so sánh, đánh giá hoạt động kiểm thử project ? • Rất tiếc, ta khó lịng có thơng tin xác thực cơng ty phần mềm có khuynh hướng dấu nhẹm, khơng cơng bố (vì ảnh hướng lớn đến hình ảnh cơng ty) • Hiện nguồn cung cấp chủ yếu ứng dụng đường cong Rayleight Đây cơng thức tốn học cho phép ta tái tạo đường cong chuẩn dựa vào điểm ngưỡng (gunsight) Đường cong chuẩn sai lệch so với giá trị thật nhiều dự án phần mềm năm gần 10% 40 Đường cong Rayleight - Gunsight cho mẫu phát lỗi 41 Đường cong Rayleight - Gunsight cho mẫu phát lỗi 42 Đường cong Rayleight - Gunsight cho mẫu phát lỗi 43 Các thước đo khác theo dõi lỗi • Các thước đo hoạt động phát triển phần mềm : - mã lỗi phát triển - ngày phát lỗi phát triển - mức độ trầm trọng lỗi phát triển - ngày sửa lỗi phát triển - mã earcode lỗi phát triển • Các thước ₫o hoạt động HelpDesk : - mã lỗi khách hàng - ngày phát lỗi khách hàng - mức độ trầm trọng lỗi khách hàng - ngày sửa lỗi khách hàng - mã earcode lỗi khách hàng Thước đo khác : ODC (Orthogonal Defect Classification) hãng IBM 44