Bài giảng Quản lý dự án phần mềm - Chương 5: Validation (Kiểm chứng sản phẩm) - Nguyễn Anh Hào

Nguyễn Anh Hào Khoa CNTT2 Học viện CNBCVT – Cs Tp.HCM S W Q u a lit y A ss u ra n ce S W Q u a lit y A ss u ra n ce 05. Validation (kiểm chứng sản phẩm)  1 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,.. 2 1.Dùng mẫu thử 3 Mẫu thử Mẫu thử được dùng để sửa hoặc thêm yêu cầu Prototype4 2. Software errors DEBUG CODE DESIGN ANALISYS 5 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  6 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). 7 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. 8 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 9 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 10 SW testing and quality assurance from theory to practice.pdf P16 Testing levels11 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) Testing Levels12 SW testing and quality assurance from theory to practice.pdf P16 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 13 Test case design14 Thiết kế test-case: verification Thực thi test-case: validation 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 15 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) 16 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) 17 Control flow graph (CFG)18 Basis_Path_Testing.pdf SW testing & QA theory & practice.pdf (trang 89) Control flow graph (CFG)19 Control flow graph: example 120 Cyclomatic complexity (McCabe,1976)21 Cyclomatic complexity22 Cyclomatic complexity23 Basis set of paths from example 124 Generate test cases25 Ý nghĩa của CFG26 1. Độ phức tạp V(G) từ công thức McCabe là số lượng tối thiểu các test-case khác nhau cần đưa ra để test tất cả các hành vi của phần mềm (mỗi hành vi là 1 path) 2. CFG hổ trợ phân hoạch miền giá trị của dữ liệu đầu vào cho từng path, dựa trên data flow và các điều kiện rẽ nhánh.  Mỗi miền giá trị được phân hoạch của một input (một biến) là một lớp tương đương. - Lớp tương đương (equivalence class)27  2 inputs cùng thuộc 1 lớp tương đương nếu chúng được hệ thống xử lý như nhau. ◦ Nếu miền giá trị hợp lệ của trường dữ liệu trong khoảng 1-50 thì các giá trị 20, 38, 1, 47 đều cùng thuộc 1 lớp tương đương. ◦ Nếu trường dữ liệu có 2 miền giá trị (true và false) → nó có 2 lớp tương đương.  =>Chỉ cần kiểm thử bằng 1 giá trị đại diện trong lớp thay vì kiểm thử mọi trường hợp.  Kiểm thử thêm các trường hợp không thuộc lớp để kiểm tra khả năng ứng xử với dữ liệu input sai của PM. - Ốc đảo (dependency islands)28 Giả sử P có 6 inputs I1,.. I6 và 3 outputs O1,O2,O3 Nếu mỗi input có 5 lớp tương đương thì để test cho 6 inputs cần thực hiện khoảng 56 = 15.625 test cases ! Giả sử: O1 chỉ phụ thuộc I1, I2, I3 → {I1, I2, I3 } là ốc đảo của O1 O2 chỉ phụ thuộc I4, I5 → {I4, I5 } là ốc đảo của O2 O3 chỉ phụ thuộc I6 → {I6 } là ốc đảo của O3 Như vậy: Đối với O1: chỉ cần test bộ I1, I2, I3 : 5 3 test cases Đối với O2: chỉ cần test bộ I4, I5 : 5 2 test cases Đối với O3: chỉ test I6 : 5 test cases Theo cách này, tổng số test cases cần thực hiện là 53+52+5 = 155 (thay vì 15.626) test cases. Integration test29 Type of unit integration30 Integration basic path test: example 31 Complexity = 5 Bottom-up approach32 Driver: là một mô-đun “rỗng” (b, c) dùng để tạo ra các lệnh gọi tới các mô-đun mức thấp (E, F, G) để kiểm tra các mô- dun mức thấp có hoạt động đúng không. Các mô-đun chương trình nằm ở mức thấp nhất được kiểm tra trước, rồi đến các mô-đun ở trên, là các mô-đun có lời gọi đến các mô-đun mức dưới. b E F Driver c G Driver(1) a B C D E F G Driver(2) A B C D E F G (3) Top-down approach33 Stubs: là các mô-đun “rỗng” (b, c, d) thay thế cho mô-đun thật (B, C, D) để xem mô-đun mức cao (A) có hoạt động đúng không. Các stubs chỉ được cài đặt các giao tiếp (inputs, outputs) và các bảng chuyển đổi inputs-outputs tính sẵn cho các testcases chứ không được cài đặt code chính thức. A B C D Stubs b c d Testing(1) A B C D E F G e f g (2) A B C D E F G (3) Bottom-up vs Top-down Top-Down: các mô-đun chính được viết và test trước (đối chiếu với chức năng) - như vậy tính logic được nâng cao khi các mô-đun được kiểm thử xong. Bottom-Up: không có chương trình chạy được cho tới khi mô-đun cuối cùng được test và tích hợp – lúc này các lỗi thiết kế mới có thể phát hiện và có thể phải làm lại các mô-đun đã qua kiểm thử ! 34 - Nguyên lý Paretto (luật 20/80)35 Những lỗi nghiêm trọng (có tần suất xuất hiện cao) được ưu tiên kiễm thử và sửa trước, để giảm tối đa khả năng gây lỗi của PM - Gieo lỗi  Gieo lỗi để ước tính số lỗi có trong phần mềm  đếm cá trong ao: 1. Bắt N con cá trong hồ nuôi cá. Đánh dấu hết toàn bộ và thả lại vào ao (vậy trong ao có đúng N con cá có đánh dấu) 2. Quăng 1 mẽ lưới để bắt M con cá trong ao; trong đó có n con có đánh dấu, và M-n con không đánh dấu. 3. Gọi X là tổng số cá trong ao, thì: n / N = M / X = (M-n) / (X – N)  Hệ số phát hiện lỗi Cf được ước tính là: detected seeds (n) = detected non seeds (M-n) total seeds (N) total non seeds (X-N) Cf = 36 Nếu 1 - Cf không đáng kể thì không cần test nữa Các kỹ thuật debuging Bruce force: cung cấp dấu vết thực thi của chương trình bằng cách đặt lệnh in ra màn hình các câu lệnh và giá trị của biến. Cause elimination : phép quy nạp và diễn dịch trên các biểu hiện của lỗi để giới hạn phạm vi gây ra lỗi Back tracking : dò vết ngược từ biểu hiện của lỗi đến câu lệnh gây lỗi 37 SW testing and quality assurance from theory to practice.pdf P68 Unit testing framework  jUnit, CPPUnit, Nunit, PyUnit, gọi chung là xUnit. Hàm assert?() thực thi lệnh / hàm và đối chiếu với kết quả được mong đợi để đánh giá. assertTrue(Boolean condition) assertEquals(Object expected, Object actual) assertEquals(int expected, int actual) assertSame(Object expected, Object actual)  38 SW testing and quality assurance from theory to practice.pdf P73