Bài giảng Software quality assurance: Kiểm chứng sản phẩm - Nguyễn Anh Hào

Chia sẻ: Minh Nhân | Ngày: | Loại File: PDF | Số trang:38

Thêm vào BST

Báo xấu

30
lượt xem 2
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Bài giảng "Software quality assurance: Kiểm chứng sản phẩm" cung cấp cho người học các kiến thức: Dùng mẫu thử, software errors, lỗi phần mềm, kiểm thử phần mềm, testing levels, black box and White box testing,...Mời các bạn cùng tham khảo.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Bài giảng Software quality assurance: 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, reports)  Trình tự các bước thực hiện (schedule)  Yêu cầu về phần cứng, phần mềm và các ràng buộc trong khi test (thiết lập môi trường test)
17 Bao nhiêu cái test-case thì đủ ?  Nếu một chương trình đã được test và sửa lỗi thì có phải là nó không còn lỗi, hay bộ testcase chưa đủ để phát hiện các lỗi còn lại ?  Nguyên lý McCabe: chỉ ra số test-case tối thiểu cho một function (→coverage)
18 Control flow graph (CFG) Basis_Path_Testing.pdf SW testing & QA theory & practice.pdf (trang 89)
19 Control flow graph (CFG)
20 Control flow graph: example 1