1. Trang chủ
  2. » Công Nghệ Thông Tin

Bài giảng Kiểm thử phần mềm Bài 3

31 6 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 31
Dung lượng 912,93 KB

Nội dung

BÀI GIẢNG KIỂM THỬ PHẦN MỀM BÀI 3: I Một số Thuật ngữ Chuyên môn II Defect/ bug/ fault Life Cycle III Tham khảo số tài liệu Software Testing: Verification & Validation ( V&V) Verification and Validation ( Xác minh Thẩm định)  Software Testing là:  Là trình thực thi chương trình với mục đích tìm lỗi  Là hoạt động kiểm tra xem phần mềm có chạy xác hay khơng (Verification) có thoả mãn u cầu khách hàng hay khơng (Validation) nhằm hướng tới mục tiêu chất lượng phần mềm  Quality Testing = Verification + Validation Verification and Validation ( V&V) Verification (xác minh) - - - Validation (thẩm định) Đảm bảo phần mềm thực đặc tả u cầu, có thiết kế hay khơng Phát lỗi lập trình - Đảm bảo phần mềm đáp ứng nhu cầu người dùng - Phát lỗi phân tích, thiết kế Verification đảm bảo “you built it right” Validation đảm bảo “you built the right thing” Software Testing - Là hai trình : kiểm tra phần mềm có chạy xác hay khơng có thỏa mãn u cầu khách hàng hay khơng - Đảm bảo chất lượng phần mềm Re-testing # Regression testing (test hồi quy) Test Hồi Quy gì?    Khi chức thêm vào phần mềm, cần chắn phần chức thêm vào không phá hỏng phần khác ứng dụng Hoặc lỗi chỉnh sửa, cần chắn lỗi chỉnh sửa không phá hỏng phần khác ứng dụng Để test điều thực kiểu test lặp lặp lại gọi test hồi quy Test hồi quy thực phần nằm phạm vi bị ảnh hưởng mà có sửa đổi chức thêm mới, đảm bảo thay đổi không gây lỗi chức vốn làm việc tốt Regression Test mức kiểm tra ( giống unit test, intergration testing, system test & acceptance test) Regression test thực mức kiểm tra Test Hồi Quy gì?  Mặc dù không mức kiểm tra, thực tế lại cho thấy Regression Test loại kiểm tra tốn nhiều thời gian công sức Tuy thế, việc bỏ qua Regression Test "khơng phép" dẫn đến tình trạng phát sinh tái xuất lỗi nghiêm trọng, ta "tưởng rằng" lỗi khơng có kiểm tra sửa chữa rồi! Re-test gì?   Re-test: Đồng nghĩa với confirmation testing (kiểm tra xác nhận) Là thực test để kiểm tra xem bug post có fixed hay chưa (kiểm tra lại xem hết bị lỗi mà gặp chưa) Nếu sửa xong báo cáo Close bug Ngược lại, cịn lỗi báo cáo re-open để DEV sửa lại Là loại kiểm thử thực để kiểm tra lỗi fix ok chưa Functional testing # Non-functional testing?   Kiểm thử Chức gì? Kiểm thử Phi Chức Functional testing gì?   Kiểm thử chức năng: tương tự black box testing (kiểm tra đến chức chương trình mà khơng quan tâm đến cấu chúc bên trong) kiểm thử chức tập trung kiểm tra chức ứng dụng có hoạt động khách hàng mong đợi khơng? Khi test dựa vào tài liệu yêu cầu (requirement) tài liệu mô tả chi tiết (specification) để test Functional testing nằm System testing: Defect/ Bug/ Fault Life Cycle ( vòng đời Lỗi)  Tester report bug (trạng thái New) > Xem xét xem có lỗi không:  Nếu lỗi Reject Closed  Nếu Lỗi chuyển sang trạng thái Open > Developer fix lỗi > Tester thực test lại > Nếu lỗi Pass Close Nếu Lỗi cịn lỗi lại Reopen cho Dev fix lại  Tóm lại: tester phát Bug, ghi Bug lên hệ thống quản lý Lỗi assign cho lập trình viên Lập trình viên fixed lỗi tester thực test lại Nếu OK closed, lỗi chuyển trạng thái bug reopen để lập trình viên xem xét sửa lỗi Redmine tool: Tool quản lý Defect Redmine tool: Màn hình viết defect Redmine tool: Màn hình Defect Fixed Redmine tool: Màn hình Chi tiết Lỗi Độ Ưu tiên ( Priority) & Độ nghiêm trọng (Severity) quản lý Bug   Trong kiểm thử phần mềm hai khái niệm Độ ưu tiên (Priority) Độ nghiêm trọng (Severity) không xa lạ, đặc biệt quản lý bug Phụ thuộc vào độ ưu tiên mà lập trình viên thực fix bug Độ nghiêm trọng: Severity Bug   Mức độ nghiêm trọng bug thường mức độ tác động bug đến sản phẩm Mỗi dự án hay sản phẩm có tiêu chí đánh giá độ nghiêm trọng khác thơng thường có mức độ khác từ nghiêm trọng đến nghiêm trọng hơn:  Mức độ (Critical): Rất nghiêm trọng, làm cho PM "chết cứng" không sử dụng  Mức độ (Major): Nghiêm trọng, buộc phải sửa chữa để sử dụng yêu cầu đề  Mức độ (Minor): Nhẹ, không làm PM ngưng chạy, làm cho việc sử dụng PM khó khăn gây bất tiện cho người dùng  Mức độ (Cosmetic): Không ảnh hưởng đến chức hay hiệu PM quy định yêu cầu (như vấn đề thẩm mỹ thơng báo sai tả) Thực tế việc xác định độ nghiêm trọng bug không hẳn lúc mang tính c chất trắng-đen tuyệt đối  Độ ưu tiên: Prority Bug  Đã bug phải sửa Tuy nhiên, có thực tế đội phát triển khó sửa hết tất bug lượt không đáng để sửa hết tất bug Do đó, đội phát triển phải cần đến độ ưu tiên bug để biết bug cần sửa trước bug sau Độ ưu tiên bug thường chia thành 3-4 cấp độ:  Mức độ (Immediate): Bug phải sửa lập tức, không công việc tiếp tục  Mức độ (High): độ ưu tiên cao; công việc bị ngăn trở nhiều lỗi chưa sửa  Mức độ (Medium): độ ưu tiên trung bình; cơng việc gặp vài khó khăn lỗi chưa sửa  Mức độ (Low): độ ưu tiên thấp nhất; công việc không bị ảnh hưởng lỗi phải sửa Độ ưu tiên: Prority Bug   Xác định độ ưu tiên? Bug sửa trước bug sửa sau (hoặc không sửa)? Dựa vào độ nghiêm trọng bug Bug nghiêm trọng nhất, tác động đến người dùng nhiều ưu tiên sửa trước Bug nghiêm trọng sửa sau Xác định độ ưu tiên khuyến khích kỹ sư kiểm thử khơng phải bắt buộc Chi phí Lỗi ( cost of defect) gì?   Nếu lỗi xảy phát bước Requirement, dễ dàng sửa với chi phí rẻ Tuy nhiên lỗi xảy bước Requirement lại phát bước Acceptance test phải tốn nhiều chi phí để sửa Bởi phải sửa lại cho với yêu cầu khách hàng sau phải design code lại theo yêu cầu sửa, việc tốn thời gian nỗ lực, chưa kể đến việc làm uy tín cơng ty Biểu đồ bên cạnh biểu thị chi phí gia tăng việc sửa Lỗi theo giai đoạn phát triển Question & Answer? TESTER là? T *Take care of quality (Chăm lo cho chất lượng) E *Eager for finding defect (Ham tìm lỗi) S *Standardize software (Chuẩn hóa phần mềm) T *Thought of logic (Tư lơgíc) E *Enjoyable job (Nghề thú vị) R *Raise of carefulness (Tăng thêm cẩn thận) Mức độ Cơ Kiểm thử học là? Có Mơ hình phát triển Phần mềm nào? Bài 4: Nội dung buổi học tuần sau: Học phần Nội dung QC làm cơng việc QA QC khác QA làm cơng việc nào? Thực hành viết testcases Tập viết testcases tập Hướng dẫn sử dụng Snagit tool Hướng dẫn sử dụng Snagit tool để phục vụ cho viết bug ... testing (kiểm thử hiệu năng) Stress testing: kiểm tra giới hạn hệ thống Security testing (kiểm thử bảo mật) Usability testing (kiểm thử tính khả dụng) Kiểm thử Hiệu ?       Kiểm thử hiệu... sửa lại Là loại kiểm thử thực để kiểm tra lỗi fix ok chưa Functional testing # Non-functional testing?   Kiểm thử Chức gì? Kiểm thử Phi Chức Functional testing gì?   Kiểm thử chức năng: tương... (Chuẩn hóa phần mềm) T *Thought of logic (Tư lơgíc) E *Enjoyable job (Nghề thú vị) R *Raise of carefulness (Tăng thêm cẩn thận) Mức độ Cơ Kiểm thử học là? Có Mơ hình phát triển Phần mềm nào? Bài 4:

Ngày đăng: 29/10/2021, 16:26

HÌNH ẢNH LIÊN QUAN

Redmine tool: Màn hình viết 1 defect - Bài giảng Kiểm thử phần mềm Bài 3
edmine tool: Màn hình viết 1 defect (Trang 19)
Redmine tool: Màn hình Chi tiết Lỗi - Bài giảng Kiểm thử phần mềm Bài 3
edmine tool: Màn hình Chi tiết Lỗi (Trang 21)
Có những Mô hình phát triển Phần mềm nào? - Bài giảng Kiểm thử phần mềm Bài 3
nh ững Mô hình phát triển Phần mềm nào? (Trang 30)