Bài giảng Đảm bảo chất lượng phần mềm: Kiểm chứng sản phẩm - Nguyễn Anh Hào

Bài giảng Đảm bảo chất lượng phần mềm: Kiểm chứng sản phẩm giới thiệu nội dung về dùng mẫu thử, lỗi phần mềm, kiểm thử phần mềm, thiết kế testcase, các kỹ thuật debuging. mời các bạn tham khảo nội dung chi tiết.
Nội dung trích xuất từ tài liệu:
Bài giảng Đảm bảo chất lượng phần mềm: Kiểm chứng sản phẩm - Nguyễn Anh Hào 1 SW Quality Assurance 05. Validation (kiểm chứng sản phẩm)  Nguyễn Anh Hào Khoa CNTT2 Học viện CNBCVT – Cs Tp.HCM 2 Validation 1. Là hành động để bảo đảm rằng đặc tả yêu cầu cho phần mềm là đúng và đầy đủ so với mong đợi Ví dụ: hiện thực hoá những hiểu biết về PM thành mẫu thử để đối chiếu với mong muốn. 2. Là hành động để bảo đảm rằng PM được làm ra sẽ hoặc đã thỏa mãn mọi yêu cầu đã được cam kết.  Thường được hiểu là hết lỗi, ie, không tìm được chứng cứ của lỗi trong PM. Vd: Định nghĩa và thực hiện hết các testcase trong unit-test, system test, acceptance test,.. 3 1.Dùng mẫu thử Mẫu thử Mẫu thử được dùng để sửa hoặc thêm yêu cầu 4 Prototype 5 2. Software errors ANALISYS DESIGN CODE DEBUG 6 Lỗi phần mềm 1. Tình huống nào thì phần mềm được cho là có lỗi ?  Thực hiện sai yêu cầu  Không thực hiện được chức năng  Không thỏa mãn yêu cầu về tính năng  … 7 Lỗi phần mềm : ngôn từ  Error: là “sự hư hỏng” trong bản thân chương trình (vd: logic bị sai).  Fault: là “sự hư hỏng” trong chức năng xử lý của chương trình do error gây ra.  Failure : là “sự hư hỏng” nhận biết được, khi phần mềm đang chạy đụng đến fault. Không chắc là fault sẽ luôn luôn gây ra failure.  Defect: là khiếm khuyết của chương trình theo cách đánh giá của người dùng (không hẳn là do failures). 8 Lỗi phần mềm: vài nguyên nhân 1. Người yêu cầu (khách hàng) định nghĩa sai yêu cầu cho phần mềm. 2. Hiểu lầm giữa khách hàng và người phát triễn. 3. Người phát triễn pm hiểu sai yêu cầu 4. Sai thiết kế luận lý (sai thiết kế về mặt ý niệm) 5. Sai mã lệnh. 6. Chương trình thực thi không đúng với yêu cầu 7. Thiếu kiểm thử 8. Lỗi sai trong thủ tục vận hành 9. Lỗi sai trong các tài liệu hướng dẫn sử dụng. 9 Kiểm thử phần mềm : quan điểm 1. Phần mềm có chất lượng tốt là phần mềm không có failure => kiễm thử mọi test case ?  Dijkstra: kiểm thử chỉ khẳng định PM có lỗi, không thể khẳng định PM hết lỗi, do tổ hợp input-output quá lớn, điều khiển phức tạp hoặc môi trường sử dụng đa dạng (SW Testting & QA from theory to practice, P13) 2. Phát hiện để sửa lỗi trên các ấn phẩm ban đầu (đặc tả yêu cầu, bản thiết kế) trước khi sử dụng là rất cần thiết, để tránh phải làm lại.  Chứng minh cho cách làm và kiễm thử sản phẩm là 2 hành động hổ trợ lẫn nhau; ie ta cần chọn lựa hành động cho phù hợp. 3. Ngăn ngừa lỗi vẫn tốt hơn là sửa lỗi. 4. Tự động hoá kiễm thử là cần thiết 10 Testing  Là hành động tìm chổ sai trong các ấn phẩm của PM so với yêu cầu, bằng cách thực thi SP PM hoặc mẫu thử của ấn phẩm.  Có 4 mức: Unit, integration, system & Acceptance test  Regression test : tìm hiệu ứng lề khi cập nhật ấn phẩm; nó là một phần trong 4 loại test trên  Testing còn gọi là kiểm thử có thực thi ≠ kiểm thử phi thực thi (verification) : code inspection, code walk-through,…  Testing ≠ Debug: để hiểu cách thực thi của PM SW testing and quality assurance from theory to practice.pdf P16 11 Testing levels 1. Kiểm thử trên từng mô đun (unit)  Mô-đun có được thực thi đúng ? 2. Kiểm thử tích hợp nhiều mô đun (integration)  Các mô-đun có kết hợp được thành hệ thống ?  Giao tiếp giữa các mô-đun có đúng ? 3. Kiểm thử hệ thống (system)  Xem xét mức độ thỏa mãn yêu cầu của PM trong môi trường chạy (functionality, performance, reliability, security,…) 4. Kiểm thử chấp nhận (acceptance)  Chạy PM trong môi trường sử dụng của users  PM có thoả yêu cầu ? (peak workload performance, response-time, human factors test, procedures, backup & recovery) 12 Testing Levels SW testing and quality assurance from theory to practice.pdf P16 13 Black box & White box testing  Black box testing = functional testing: không cần biết cách thực thi chương trình, chỉ cần biết logic của chức năng để định nghĩa dữ liệu test (inputs, expected outcome)  White box testing = structural testing: xem xét source code (data flow & control flow) để đưa ra các testcase 14 Test case design Thiết kế test-case: verification Thực thi test-case: validation 15 Thiết kế testcase : test case gì cần ? 1. Từ usecase & tương tác trong usecase (requirements) 2. Xem xét các trạng thái chấp nhận được và không chấp nhận được từ mỗi hành động xử lý của usecase trong lược đồ hoạt động, tuần tự, trạng thái 3. Lập ra các test-case 4. Lập test procedures/scripts theo UI design 5. Lập ra test plan 16 Test plan  Test cases, dựa trên chức năng của PM  Test scripts, dựa trên cách xử lý của chức năng  Test data (inputs, expected outcome) dựa trên logic của chức năng  Thủ tục lưu trữ & sử dụng kết quả test (pass, fail, inconclusive, ...