Đảm bảo và kiểm soát chất lượng - Chương 2: Các yếu tố cơ bản trong kiểm soát chất lượng phần mềm

ĐẢM BẢO VÀ KIỂM SOÁT CHẤT LƯỢNG HCM – 10/2012 Chương 2: Các yếu tố cơ bản trong kiểm soát chất lượng phần mềm 11/5/2016 Nội dung Quy trình phát triển phần mềm Tại sao phải kiểm thử (testing) phần mềm? Testing là gì? Những nguyên lý tổng quát trong kiểm thử Quy trình kiểm thử cơ bản Các kiểu kiểm thử 1/5/2016 Trang 2 Quy trình phát triển phần mềm 1/5/2016 Trang 3 Làm sao đi được tới ROME du lịch một chuyến nhỉ? Quy trình phát triển phần mềm 1/5/2016 Trang 4 Quy trình phát triển phần mềm 1/5/2016 Trang 5 Quy trình phát triển phần mềm 1/5/2016 Trang 6 Phần mềm Yêu cầu phần mềm Lập trình Thiết kế Lập trình Phân tích Thiết kế Lập trình Phân tích Thiết kế Lập trình Kiểm thử 1 2 3 4 Quy trình phát triển phần mềm 1/5/2016 Trang 7 Qui trình phần mềm là gì?  Chuỗi hoạt động  Theo thứ tự nhất định  Sản xuất phần mềm Qui trình công nghệ phần mềm là tổ hợp các bước, các giai đoạn phải trải qua khi thực hiện việc sản xuất phần mềm. Nội dung Quy trình phát triển phần mềm Tại sao phải kiểm thử (testing) phần mềm? Testing là gì? Những nguyên lý tổng quát trong testing Quy trình Testing cơ bản Các kiểu kiểm thử 1/5/2016 Trang 8 Tại sao phải kiểm thử (testing) phần mềm? Xét các phần mềm thực tế  Chuyển đổi tiền tệ  Hệ thống ATM  Hệ thống điều khiển máy bay, tàu điện, tên lửa Hoạt động không đúng – gây ra nhiều vấn đề:  Tiền bạc  Thời gian  Tổn hại tính mạng con người 1/5/2016 Trang 9 Những hậu quả do lỗi phần mềm gây ra Vụ sụp đổ của Ariane 5, 1996  Bị tan tành sau 40 giây cất cánh, bị thiệt hại khoảng ½ tỉ USD  Nguyên nhân: bị lỗi về xử dụng số thực. Do chuyển đổi từ 64bit integer sang 16 bit integer có dấu => bị tràn số Phóng tên lửa vào Sao Hỏa, 1999  Bị biến mất ngay khi bắt đầu, bị thiệt hại khoảng 125 triệu USD  Nguyên nhân: dùng sai đơn vị trong chương trình 1/5/2016 Trang 10 Tại sao phải kiểm thử (testing) phần mềm?  “Lỗi phần mềm là chuyện hiển nhiên của cuộc sống. Chúng ta dù cố gắng đến mức nào thì thực tế là ngay cả những lập trình viên xuất sắc nhất cũng không có thể lúc nào cũng viết được những đoạn mã không có lỗi. Tính trung bình, ngay cả một lập trình viên loại tốt thì cũng có từ 1 đến 3 lỗi trên 100 dòng lệnh. Người ta ước lượng rằng việc Testing để tìm ra các lỗi này chiếm phân nửa khối lượng công việc phải làm để có được một phần mềm hoạt động được”. (Software Testing Techniques, Second Edition, by Boris Beizer, Van Nostrand Reinhold, 1990, ISBN 1850328803). 1/5/2016 Trang 11 Nguyên nhân các khiếm khuyết 1/5/2016 Trang 12 Con người tạo ra lỗi ... Hệ quả là xuất hiện khiếm khuyết ... hệ thống thực hiện công việc sai xót Nguyên nhân các khiếm khuyết Con người tạo ra lỗi (error – mistake) Hệ quả là xuất hiện khiếm khuyết(sai lầm/ sai sót - fault, rối - bug)  Dòng mã, hệ thống, phần mềm, tài liệu • Dư thừa • Thiếu xót Khi mã thực thi, hệ thống thực hiện công việc sai xót -> thực hiện không mong đợi (failure – hỏng hóc) Hệ quả không mong đợi (Incident) 1/5/2016 Trang 13 Nguyên nhân các khiếm khuyết Khiếm khuyết có thể xảy ra bởi  Áp lực về thời gian  Mã phức tạp  Hạ tầng phức tạp  Thay đổi công nghệ  Tương tác nhiều hệ thống  Tác động từ bên ngoài  1/5/2016 Trang 14 Nội dung Tại sao phải kiểm thử (testing) phần mềm? Testing là gì? Những nguyên lý tổng quát trong kiểm thử Quy trình Kiểm thử cơ bản Triết lý của việc kiểm thử Những định nghĩa cơ bản Các kiểu kiểm thử 1/5/2016 Trang 15 Testing phần mềm là gì? Testing phần mềm là qui trình chứng minh phần mềm không có lỗi. Mục đích của Testing phần mềm là chỉ ra rằng phần mềm thực hiện đúng các chức năng mong muốn. Testing phần mềm là qui trình thi hành phần mềm với ý định tìm kiếm các lỗi của nó. Testing phần mềm được xem là qui trình cố gắng tìm kiếm các lỗi của phần mềm theo tinh thần "hủy diệt". 1/5/2016 Trang 16 Testing phần mềm là gì? Mục tiêu  Tìm khiếm khuyết  Ngăn ngừa khiếm khuyết  Chứng minh được phần mềm hoạt động đúng như đã thiết kế  Chứng minh được phần mềm đáp ứng yêu cầu của user  Góp phần chứng minh chất lượng của phần mềm  Tăng tin tưởng mức chất lượng và thông tin cung cấp 1/5/2016 Trang 17 Phần mềm đáp ứng yêu cầu của user 1/5/2016 Trang 18 Phần mềm đáp ứng yêu cầu của user 1/5/2016 Trang 19 Khác biệt giữa Gỡ rối(Debug) và Testing Testing:  Cho thấy các trường hợp không mong đợi do khiếm khuyết phần mềm  Testers Gỡ rối (Debug):  Hoạt động phát triển  Xác định nguyên nhân và sửa chữa mã lỗi  Testing lại khiếm khuyết có được sửa đúng  Developers 1/5/2016 Trang 20 Nội dung Tại sao phải kiểm thử (testing) phần mềm? Testing là gì? Những nguyên lý tổng quát trong testing Quy trình Testing cơ bản Triết lý của việc Testing Những định nghĩa cơ bản 1/5/2016 Trang 21 Những nguyên lý tổng quát trong testing Những nguyên lý này được đúc kết thông qua quá trình phát triển và qua các hướng dẫn tổng quát nhất cho việc testing Có 7+ nguyên lý chính  Testing để khơi bày các lỗi ra ngoài  Không thể vét cạn hết các trường hợp  Testing sớm  Gom nhóm các khiếm khuyết  Nghịch lý thuốc trừ sâu (Pesticide paradox)  Phụ thuộc ngữ cảnh  Ảo tưởng “không lỗi” (Absence-of-errors fallacy) 1/5/2016 Trang 22 Testing để khơi bày các lỗi ra ngoài Testing có thể khơi bày các lỗi ra ngoài, nhưng không chứng minh được chương trình hết lỗi Testing để giảm khả năng để xót lỗi lại trong chương trình 1/5/2016 Trang 23 Không thể vét cạn hết các trường hợp 1/5/2016 Trang 24 Hê thống có 20 màn hình Trung bình: 10 fields / screen 2 types input / field (date as Jan 3 or 3/1) (number as integer or decimal) Around 100 possible values Số lượng test cho toàn bộ: 20 x 4 x 3 x 10 x 2 x 100 = 480,000 tests Nếu 1 giây/test => 8000 phút = 133 giờ = 17.7 ngày Trung bình 4 menu 3 lựa chọn/ menu 10 giây = 34 tuần, 1 phút = 4 năm, 10 phút = 40 năm Không thể vét cạn hết các trường hợp 1/5/2016 Trang 25 Số lượng test cho trường hợp lỗi: Username: Giả sử chúng ta có 50 ký tự có thể nhập được gồm chữ thường, chữ hoa, số, ký tự đặt biệt thì ta cần 50 mũ 20 lần giá trị Password: tương tự như Username, chúng ta cũng có 50 mũ 20 lần giá trị Và chúng ta cũng cần tổ hợp Username và pasword lại nữa Nhiều nhất là 20 ký tự Không thể vét cạn hết các trường hợp Vì thời gian testing luôn có giới hạn  Việc quyết định bao nhiêu là đủ nên dựa vào: • Bảng miêu tả các rủi ro: Rủi ro kỹ thuật, nghiệp vụ, dự án • Các ràng buộc về thời gian lẫn ngân sách • Những yêu cầu đặc biệt của khách hàng  Qua đó giúp xác định: • Những phần nào nên test trước • Những phần nào nên tập trung • Những phần nào sẽ không test (trong thời gian này) 1/5/2016 Trang 26 Testing sớm Nên bắt đầu sớm nhất có thể trong chu kỳ phát triển  Việc phát hiện lỗi quá trễ thường sẽ tốn nhiều chi phí hơn để khắc phục: • Chịu áp lực về thời gian • Phải testing lại phần lớn những chức năng để ổn định trước đó  Giúp nắm rõ về các yêu cầu của hệ thống để có những bước chuẩn bị môi trường hay kế hoạch đào tạo (training) tốt hơn 1/5/2016 Trang 27 Gom nhóm các khiếm khuyết Thông thường một nhóm nhỏ các chức năng phần mềm gây ra phần lớn các khiếm khuyết của hệ thống Áp dụng nguyên lý Pareto: 80% lỗi có nguyên nhân từ 20% các chức năng  ⇒ cô lập và testing những chức năng khả nghi nhất. 1/5/2016 Trang 28 Nghịch lý thuốc trừ sâu (Pesticide paradox) Lặp lại cùng mẫu testing:  Không tìm thấy khiếm khuyết mới Kịch bản Testing cần rà soát và xem xét lại đều đặn Những phần mới hay khác biệt nên được viết lại để có thể kiếm được những lỗi tiềm ẩn mới 1/5/2016 Trang 29 Phụ thuộc ngữ cảnh Thực hiện khác nhau trong những ngữ cảnh khác nhau  Cùng bộ mẫu test không thể sử dụng cho tất cả mọi trường hợp bởi vì những sản phẩm phần mềm khác nhau sẽ có những tính năng và mục đích sử dụng khác nhau  Không phải tất cả phần mềm đều có cùng cấp độ rủi ro và không phải tất cả những khiếm khuyết đều có chung mức độ tàn phá 1/5/2016 Trang 30 Ảo tưởng “không lỗi” (Absence-of-errors fallacy) Tìm và khắc phục khiếm khuyết là vô nghĩa nếu hệ thống:  Không có giá trị  Không đáp ứng yêu cầu cần thiết  Không đáp ứng kỳ vọng người sử dụng 1/5/2016 Trang 31 Những nguyên lý khác  Nên được hoạch định trước khi thực hiện  Nên tiến hành từ nhỏ đến lớn: bắt đầu từ những module riêng biệt rồi sau đó tích hợp các module lại.  Nên được thực hiện bởi những đối tượng KHÔNG tham gia vào quá trình phát triển phần mềm.  Nguyên tắc ngẫu nhiên:  ‰Dữ liệu và chức năng được chọn, tuy có chủ đích nhưng không phải xuất hiện theo thứ tự nhất định.  Nguyên tắc "người sử dụng kém":  Người có trình độ thấp mức chấp nhận được dùng thử. • Có thể gây các sự cố không lường trước được  Nguyên tắc "kẻ phá hoại":  Hệ thống rơi vào tay có trình độ nghiệp vụ cao, chủ ý phá hoại. 1/5/2016 Trang 32 Nội dung Tại sao phải kiểm thử (testing) phần mềm? Testing là gì? Những nguyên lý tổng quát trong testing Quy trình Testing cơ bản Triết lý của việc Testing Những định nghĩa cơ bản Các kiểu kiểm thử 1/5/2016 Trang 33 Qui trình kiểm thử phần mềm 1/5/2016 Trang 34 Lập kế hoạch test Thiết kế test So sánh kết quả test với test case Chuẩn bị dữ liệu test Chạy ứng dụng với bộ dữ liệu test Test Report Test Results Test Data Test CaseTest plan Các hoạt động kiểm thử 1/5/2016 Trang 35 Cài đặt và chuẩn bị Test Bắt đầu Lập kế hoạch Test Thiết kế Test Test tích hợp Kết thúc Test hệ thống Tổng hợp, báo cáo Xem xét và Đánh giá kết quả test Chuẩn bị Test Phân tích kết quả Lập kế hoạch Các hoạt động kiểm thử 1/5/2016 Trang 36 Cài đặt và chuẩn bị Test Bắt đầu Lập kế hoạch Test Thiết kế Test Test tích hợp Kết thúc Test hệ thống Tổng hợp, báo cáo Xem xét và Đánh giá kết quả test Kế hoạch test Test case Test procedure Test scrip Test data Môi trường Lỗi Biên bản test Bcáo KQ test Đề xuất Bcáo tổng hợp test Hồ sơ       Các hoạt động kiểm thử 1/5/2016 Trang 37 Construction Thử nghiệm Construction Lập trình Solution Thiết kế kiến trúc Definition Xác định yêu cầu Cài đặt và chuẩn bị Test Bắt đầu Lập kế hoạch Test Thiết kế Test Test tích hợp Kết thúc Test hệ thống Tổng hợp, báo cáo Xem xét và Đánh giá kết quả test Termination (Kết thúc) Transition (Triển khai) Definition (Xác định yêu cầu) Solution (Thiết kế kiến trúc) Construction (Xây dựng) Coding (lập trình) Testing (thử nghiệm) Initiation (khởi động) Lập kế hoạch Test Định nghĩa Nhận dạng các chiến lược được dùng để Testing và đảm bảo rằng sản phẩm thỏa mãn đặc tả thiết kế phần mềm và các yêu cầu khác về phần mềm. Định nghĩa các mục tiêu và phạm vi của Test. Nhận dạng phương pháp luận mà đội Test sẽ dùng để thực hiện công việc Test. 1/5/2016 Trang 38 Lập kế hoạch Test Định nghĩa Nhận dạng phần cứng, phần mềm và các tiện ích cần cho Test. Nhận dạng các tính chất và chức năng sẽ được Test. Xác định các hệ số rủi ro gây nguy hại cho việc Test. Lập lịch Test và phân phối công việc cho mỗi thành viên tham gia. 1/5/2016 Trang 39 Kế hoạch Test Giới thiệu  Mục đích  Thông tin chung  Tài liệu liên quan  Phạm vi test  Ràng buộc  Liệt kê các rủi ro Chiến lược Test  Phương thức  Môi trường Test 1/5/2016 Trang 40 Tài Nguyên  Nhân lực  Hệ thống Các mốc thời gian chính (Milestones) Tiêu chí dừng Test Phân tích thiết kế Test-Case Mỗi testcase chứa các thông tin cần thiết để Test thành phần phần mềm theo 1 mục tiêu xác định. Thường testcase gồm bộ 3 thông tin:  Tập dữ liệu đầu vào  Trạng thái của thành phần phầm mềm  Tập kết quả kỳ vọng 1/5/2016 Trang 41 Phân tích thiết kế Test-Case Các phương pháp thiết kế testcase  Test hộp đen (Black box testing)  Test hộp trắng (White box testing) 1/5/2016 Trang 42 output Phân tích thiết kế Test-Case Xem xét cơ sở cho việc Test:„ yêu cầu, kiến trúc, thiết kế, giao tiếp (interface), Đánh giá khả năng test (testability) của các hệ thống và yêu cầu  Yêu cầu: hệ thống cần đáp ứng đủ nhanh khi user tương tác  => Hệ thống cần đáp ứng không quá 5s với 20 người cùng truy cập 1/5/2016 Trang 43 Phân tích thiết kế Test-Case Xác định và lập ưu tiên các điều kiện Test Thiết kế và lập ưu tiên các Test-case Xác định tập dữ liệu cần thiết hỗ trợ Test-case Thiết kế việc thiết lập môi trường Test cũng như hạ tầng và những công cụ cần thiết 1/5/2016 Trang 44 Thực hiện Test Testers sẽ được bố trí công việc bởi Test Leader để thi hành Testing  Lập thứ tự ưu tiên các testcase  Thi hành Testing theo từng testcase bằng tay hay tự động  Thực hiện Testing đặc biệt (ad-hoc)  Thực hiện kịch bản Testing mà không được định nghĩa trong testcase.  Testing lại các lỗi đã được sửa.  Tester sẽ tạo các báo cáo về lỗi trong suốt quá trình kiểm lỗi và theo dõi chúng cho đến khi chúng đã được xử lý. 1/5/2016 Trang 45 Thực hiện Test 1/5/2016 Trang 46 Nhận bản build thực hiện Test Sẳn sàng? Từ chối Build Tạo kết quả test No Tìm thấy lỗi? Đạt? Yes Thực hiện Test (test cases) Re-Test (Fixed defects) Đóng lỗi Yes No Đệ trình/ Re-Open Lỗi đến tracking system (*) No Yes (*) See more in Defects Workflow Thực hiện Test 1/5/2016 Trang 47 Thật sự lỗi? Đóng lỗi No Re-Test đạt? Yes Phân cho Tester Xem xét lại bởi Test Lead, Dev Lead, PM Yes No Lỗi trong hệ thống No Yes Không rõ lỗi? Phân ngược lại Tester để thêm thông tin Phân Developer để sửa Lỗi đã sửa? Lỗi chưa giải quyết Giải thích tại sao được chấp nhận Bởi PM/Leader Cập nhật thêm Thông tin Giải thích tại sao đóng lỗi Yes No Đánh giá - Lập báo cáo Tạo các báo cáo lỗi. Đánh giá các kết quả Testing, thống kê các yêu cầu thay đổi. Tính và phân phối các thông tin đo lường hoạt động Testing. Tạo bảng tổng kết đánh giá hoạt động Testing. Xác định xem đã đạt tiêu chí thành công và hoàn thành Testing chưa. 1/5/2016 Trang 48 Hoạt động kết thúc Testing Hoạt động này chỉ thực hiện khi:  Phần mềm đã được chuyển giao  Dự án bị hủy (Cancel)  Milestone được hoàn thành 1/5/2016 Trang 49 Hoạt động kết thúc Testing Công việc chính  Kiểm tra công việc đã phân theo kế hoạch và tất cả các khiếm khuyết đã được giải quyết  Hoàn tất và cất giữ các Testware (các scripts, môi trường Testing, hạ tầng) để sử dụng sau này  Bàn giao testware đến tổ chức bảo trì  Phân tích bài học học được 1/5/2016 Trang 50 Nội dung Tại sao phải kiểm thử (testing) phần mềm? Testing là gì? Những nguyên lý tổng quát trong testing Quy trình Testing cơ bản Các kiểu kiểm thử 1/5/2016 Trang 51 Các kiểu kiểm thử Testing Type Kiểm thử Chức năng - Function Test Kiểm thử Phi chức năng - Non-Functional Test Kiểm thử Hồi quy - Regression Test Kiểm thử cài đặt Kiểm thử khả năng tương thích Kiểm thử sự phá hủy Kiểm thử hiệu suất phần mềm Kiểm thử tính khả dụng Kiểm thử bảo mật Tính toàn cầu và bản địa hóa 1/5/2016 Trang 52 Kiểm thử chức năng Function Test  Chức năng là những gì mà chương trình có thể đáp ứng được mô tả rõ ràng trong các tài liệu:  Trường hợp sử dụng (Use case)  Yêu cầu chức năng  Có thể thực hiện tại tất cả các cấp độ Test  Không quan tâm đến các khía cạnh khác như giao diện đẹp, xấu, dễ sử dụng hay không, thời gian xử lý nhanh hay chậm,...  Test chức năng có thể được hoàn thành từ 2 hướng:  Dựa trên yêu cầu (Requirement) • Bản mô tả tóm lược những chức năng cần Test hay không cần Test  Dựa trên quy trình nghiệp vụ • Dựa trên những nghiệp vụ hằng ngày • Hay những trường hợp sử dụng thực tế 1/5/2016 Trang 53 Kiểm tra Phi chức năng Non-Functional Test Test những chức năng làm hệ thống tốt hơn, không có những chức năng này hệ thống vẫn hoạt động được nhưng rất khó được sự chấp nhận của người sử dụng Có thể thực hiện tại tất cả các cấp độ Test ISO/IEC 9126, 2001 đã định nghĩa rất nhiều tiêu chí chất lượng về Phi chức năng 1/5/2016 Trang 54 ISO/IEC 9126, 2001  Tính năng (Functionality)  Tính phù hợp (Suitability)  Tính chính xác (Accuracy)  Khả năng tương tác (Interoperability)  Tính bảo mật/an toàn (Security)  Tính tin cậy (Reability)  Tính hoàn thiện (Maturity)  Khả năng chịu lỗi (Fault tolerant)  Khả năng phục hồi (Recoverability)  Tính khả dụng (Usability)  Dễ hiểu (Understandability)  Dễ học (Learnability)  Khả năng vận hành (Operability)  Tính hấp dẫn (Attractiveness) 1/5/2016 Trang 55  Tính hiệu quả (Efficiency)  Thời gian xử lý (Time behavior)  Sử dụng tài nguyên (Utilization)  Khả năng bảo trì (Maintainability)  Khả năng phân tích (Analysability)  Khả năng thay đổi được (Changeability)  Tính ổn định (Stability)  Khả năng kiểm thử được (Testability)  Tính khả chuyển (Portability)  Khả năng thích nghi (Adaptability)  Khả năng cài đặt (Installability)  Khả năng chung sống (Co-existence)  Khả năng thay thế được (Replaceability) Kiểm thử hồi quy Regression Test Mỗi lần một module mới được thêm vào phần mềm sẽ thay đổi:  Các đường dẫn luồng dữ liệu mới  Các thay đổi có thể gây nên các vấn đề với các chức năng đã làm việc hoàn hảo trước đó. Kiểm thử hồi qui là việc thực hiện lại một số tập con các kiểm thử đã được thực hiện trước đó để đảm bảo rằng các thay đổi mới không sinh ra những hiệu ứng không mong muốn 1/5/2016 Trang 56 Kiểm thử hồi quy Regression Test  Kiểm thử hồi quy có thể thực hiện thủ công, bằng cách thực hiện lại tập con tất cả các trường hợp kiểm thử hoặc có thể thực hiện tự động  Bộ kiểm thử hồi quy (tập con các kiểm thử sẽ được thực thi) gồm ba lớp các trường hợp kiểm thử khác nhau:  Một mẫu đại diện của các kiểm thử sẽ thực hiện tất cả các chức năng chính của phần mềm  Các trường hợp kiểm thử bổ sung tập trung vào các chức năng phần mềm có khả năng bị tác động khi có sự thay đổi  Các kiểm thử tập trung vào các thành phần mới 1/5/2016 Trang 57 Kiểm thử hồi quy Regression Test  Ví dụ:  Một phần mềm đang phát triển khi kiểm tra nó chạy tốt các chức năng A, B và C.  Thay đổi code của chức năng C: • Nếu chỉ kiểm tra chức năng C thì chưa đủ, cần phải kiểm tra lại tất cả các chức năng khác liên quan đến chức năng C (A, B). • Lý do là khi C thay đổi, nó có thể sẽ làm A và B không còn làm việc đúng nữa.  Hệ quả của kiểm thử hồi quy:  Thường tốn rất nhiều thời gian và công sức.  Không được phép bỏ qua vì có thể dẫn đến tình trạng phát sinh hoặc tái xuất hiện những lỗi nghiêm trọng, mặc dù ta “tưởng rằng” những lỗi đó hoặc không có hoặc đã được kiểm tra và sửa chữa rồi. 1/5/2016 Trang 58 Các kiểu kiểm thử khác Kiểm thử cài đặt  Đảm bảo rằng hệ thống được cài đặt đúng theo file hướng dẫn trên thiết bị thực tế Kiểm thử khả năng tương thích  Với các hệ điều hành  Hoặc với các phần mềm ứng dụng khác (có thể là các phiên bản cũ hay mới của hệ điều hành)  Hoặc môi trường thiết bị phần cứng khác như trên destop, laptop, tablet hay smart phone 1/5/2016 Trang 59 Các kiểu kiểm thử khác Kiểm thử sự phá hủy  Cố gắng làm hỏng phần mềm hoặc một hệ thống con.  Nó xác minh rằng các phần mềm có chức năng đúng ngay cả khi nó nhận được đầu vào không hợp lệ hoặc không mong muốn Kiểm thử hiệu suất phần mềm Kiểm thử tính khả dụng Kiểm thử bảo mật Tính toàn cầu và bản địa hóa 1/5/2016 Trang 60 ĐẢM BẢO VÀ KIỂM SOÁT CHẤT LƯỢNG 611/5/2016 Bài tập  1) Hãy nêu ra những cách thức để có thể test được phần lớn các trường hợp của màn hình bên dưới với chi phí thấp nhất và hiệu quả có thể chấp nhận được 1/5/2016 Trang 62 Bài tập  2) Viết 1 kế hoạch Test theo mẫu cho 1 dự án cụ thể  3) Viết những test ca