Đang tải... (xem toàn văn)
MỤC LỤC BÀI 1. CƠ BẢN VỀ KIỂM THỬ PHẦN MỀM 6 1.1. Những lỗi (bug) phần mềm nghiêm trọng trong lịch sử 6 1.1.1. Lỗi chia dấu phẩy động của bộ vi xử lý Intel Pentium (Intel Pentium Floating – Point Division Bug), 1994 8 1.1.2. Tàu vũ trụ của NASA đáp xuống địa cực của sao Hỏa (NASA Mars Polar Lander), 1999 9 1.1.3. Hệ thống phòng thủ tên lửa Patriot, 1991 10 1.1.4. Sự cố Y2K (năm 2000), khoảng 1974 11 1.1.5. Mối hiểm nguy của Virus, năm 2004 11 1.2. Lỗi (bug) là gì? 12 1.3. Tại sao lỗi xuất hiện? 17 1.4. Chi phí cho việc sửa lỗi 19 1.5. Người kiểm thử phần mềm (software tester) làm những gì? 20 1.6. Những tố chất nào tạo nên một tester tốt? 22 1.7. Bảy nguyên tắc kiểm thử phần mềm 24 BÀI 2. QUY TRÌNH PHÁT TRIỂN PHẦN MỀM 27 2.1. Quy trình phát triển phần mềm 27 2.1.1. Các thành phần của phần mềm (product components) 27 2.1.2. Các nhân lực của dự án phần mềm (Software Project Staff) 34 2.2. Thực trạng của quá trình kiểm thử phần mềm 36 2.2.1. Phương châm của việc kiểm thử 37 2.2.2. Các định nghĩa và thuật ngữ kiểm thử phần mềm 48 2.3. Quá trình nghiên cứu bản đặc tả phần mềm 53 2.3.1. Khởi đầu 54 2.3.2. Thực thi quá trình xem xét bản đặc tả ở mức cao 59 2.3.3. Kỹ thuật kiểm thử đặc tả mức thấp 63 2.4. Các mô hình vòng đời phát triển phần mềm (Software Development Lifecycle Models) 65 2.4.1. Mô hình Big bang 66 2.4.2. Mô hình Code – and – fix 67 2.4.3. Mô hình Waterfall 69 2.4.4. Mô hình Spiral 70 BÀI 3. QUY TRÌNH KIỂM THỬ PHẦN MỀM 73 3.1. Lập kế hoạch kiểm tra ( Test Plan) 73 3.1.1. Đầu vào 73 3.1.2. Mô tả 73 3.1.3. Các bước lập kế hoạch 75 3.1.4. Kết quả 75 3.1.5. Người thực hiện 76 3.2. Chuẩn bị môi trường kiểm tra 76 3.2.1. Đầu vào 76 3.2.2. Mô tả 76 3.2.3. Các công việc cần thực hiện 76 3.2.4. Kết quả 76 3.2.5. Người thực hiện 76 3.3. Thiết kế kiểm tra ( Test Design) 76 3.3.1. Đầu vào 76 3.3.2. Mô tả 77 3.3.3. Các bước thiết kế kiểm tra 78 3.3.4. Kết quả 81 3.3.5. Người thực hiện 81 3.4. Thực hiện kiểm tra ( Test Execute) 81 3.4.1. Đầu vào 81 3.4.2. Mô tả 81 3.4.3. Các bước thực hiện kiểm tra 82 3.4.4. Kết quả 84 3.4.5. Người thực hiện 84 3.5. Thẩm tra và đánh giá kết quả kiểm tra 84 3.5.1. Đầu vào 84 3.5.3. Các bước thẩm tra và đánh giá kết quả kiểm tra 85 3.5.4. Đầu ra 85 3.5.5. Người thực hiện 85 3.6. Ghi nhận và xử lý lỗi 85 3.6.1. Đầu vào 85 3.6.3. Các bước ghi nhận và xử lý lỗi 86 3.6.4. Đầu ra 87 3.6.5. Người thực hiện 87 3.7. Lập kế hoạch và triển khai test lại 87 3.7.1. Đầu vào 87 3.7.2. Mô tả 88 3.7.3. Các bước lập kế hoạch và triển khai test lại 88 3.7.4. Kết quả 88 3.7.5. Người thực hiện 88 3.8. Thông báo phát hành sản phẩm 89 3.8.1. Đầu vào 89 3.8.2. Mô tả 89 3.8.3. Quá trình thực hiện 89 3.8.4. Kết quả 89 3.8.5. Người thực hiện 89 BÀI 4. CÁC MỨC ĐỘ KIỂM THỬ PHẦN MỀM – TEST LEVELS 90 4.1. Unit Test – Kiểm tra mức đơn vị 90 4.2. Integration Test – Kiểm tra tích hợp 97 4.3. System Test Kiểm tra mức hệ thống 101 4.4. Acceptance Test Kiểm tra chấp nhận sản phẩm 103 4.5. Regression Test Kiểm tra hồi quy 105 BÀI 5. CÁC LOẠI KIỂM THỬ PHẦN MỀM 107 5.1. Kiểm thử giao diện 107 5.1.1. Khái niệm kiểm thử giao diện 107 5.1.2. Các vấn đề liên quan đến kiểm thử giao diện 107 5.1.3. Một số chú ý khi kiểm thử giao diện 114 5.2. Kiểm thử chức năng 115 5.2.1. Khái niệm kiểm thử chức năng 115 5.2.2. Mục đích của test chức năng 115 5.2.3. Các vấn đề liên quan đến kiểm thử chức năng 115 5.2.4. Một số công cụ kiểm thử 121 5.3. Kiểm thử cấu hình và khả năng tương thích 122 5.3.1. Khái niệm kiểm thử cấu hình và khả năng tương thích 122 5.3.2. Mục đích 123 5.3.3. Các vấn đề liên quan đến kiểm thử cấu hình và khả năng tương thích 123 5.3.4. Kết luận 125 5.4. Kiểm thử hiệu năng 125 5.4.1. Khái niệm 125 5.4.2. Các yếu tố quan trọng của kiểm thử hiệu năng 126 5.4.3. Ba giai đoạn của kiểm thử hiệu năng 128 5.4.4. Tìm hiểu các loại kiểm thử hiệu năng thường sử dụng 129 5.4.5. Một số công cụ kiểm thử 139 5.5. Kiểm thử bảo mật 143 5.5.1. Khái niệm 143 5.5.2. Mục đích của kiểm thử bảo mật 144 5.5.3. Các vấn đề liên quan đến kiểm thử bảo mật 144 5.5.4. Các công cụ kiểm thử bảo mật 149 5.6. Kiểm thử khả năng tiện dụng 151 5.6.1. Khái niệm kiểm thử khả năng tiện dụng 151 5.6.2. Mục đích kiểm thử khả năng tiện dụng 152 5.6.3. Các vấn đề trong kiểm thử khả năng tiện dụng 152 5.6.4. Làm thế nào để thiết kế cho khả năng sử dụng cao 154 5.6.5. Một số công cụ 155 5.7. Kiểm thử ngôn ngữ 157 5.7.1. Khái niệm 157 5.7.2. Các vấn đề liên quan đến kiểm thử ngôn ngữ 157 5.8. Kiểm thử tài liệu 166 5.8.1. Khái niệm 166 5.8.2. Các vấn đề về kiểm thử tài liệu 166 5.9. Kiểm thử khả năng phục hồi 170 5.9.1. Khái niệm 170 5.9.2. Mục đích của kiểm thử khả năng phục hồi 170 5.9.3. Các vấn đề liên quan đến kiểm thử khả năng phục hồi 170 5.9.4. Công cụ kiểm thử khả năng phục hồi 172 BÀI 6. THIẾT KẾ TEST – TEST DESIGN 173 6.1. Tổng quan về test design 173 6.2. Cấu trúc test design 173 6.3. Ví dụ về test design 177 BÀI 7. TEST CASE VÀ CÁC KỸ THUẬT THIẾT KẾ TEST CASE 180 7.1. Khái niệm test case 180 7.2. Quy trình tạo test case 180 7.3. Những tiêu chí tạo nên test case tốt 180 7.4. Các kỹ thuật thiết kế test case 180 7.4.1. Kiểm thử hộp trắng (whitebox) 180 7.4.2. Kiểm thử hộp đen (blackbox) 191 7.5. Cấu trúc bản Test case 212 7.6. Ví dụ test case 217 8.1. Các thành phần của lỗi 218 8.1.1. Nội dung lỗi Defect concept 218 8.1.2. Trạng thái lỗi – Defect status 220 8.1.3. Mức độ nghiêm trọng của lỗi Defect Severity 220 8.1.4. Các kiểu lỗi Defect type 222 8.2. Mẫu Defect log 224 BÀI 9. BÁO CÁO KIỂM THỬ TEST REPORT 226 9.1. Tổng quan 226 9.2. Quy trình test report 226 9.3. Cấu trúc của test report 227 9.4. Ví dụ test report 228 BÀI 10. KIỂM THỬ TỰ ĐỘNG PHẦN MỀM 229 10.1. Giới thiệu về lý thuyết kiểm thử tự động 229 10.2. Phân loại 229 10.2.1. Công cụ kiểm thử tự động mã trình 229 10.2.1. Công cụ kiểm thử tự động dữ liệu 229 10.2.2. Công cụ kiểm thử tự động cài đặt 229 10.3. Giới thiệu một số công cụ kiểm thử tự động 230 10.3.1. Kiểm thử hiệu năng với phần mềm Quick test professional 230 10.3.1.1. Giới thiệu 230 10.3.1.2. Giao diện 231 10.3.1.3. Các thành phần quan trọng của QTP 233 10.3.1.3.1. Action 233 10.3.1.3.2. DataTable 233 10.3.1.3.3. Object Repository (OR) 233 10.3.1.3.4. Checkpoint 234 10.3.1.3.5. Tham số 235 10.3.1.3.6. Function Library 236 10.3.1.4. VBScript 236 10.3.1.4.1. Khái niệm 236 10.3.1.4.2. Các thành phần cơ bản 237 10.3.1.4.3. Ví dụ 244 10.3.1.4.4. Yêu cầu hệ thống 247 10.3.2. Kiểm thử khả năng chịu tải với phần mềm Load Runner 248 10.3.2.1. Giới thiệu 248 10.3.2.2. Công cụ kiểm thử hiệu năng tự động LoadRunner 249 10.3.2.3. Các thuật ngữ liên quan 249 10.3.2.4. Các thành phần trong LoadRunner 250 10.3.2.5. Lợi ích của LR so với các phần mềm khác 251 10.3.2.6. Hướng dẫn cài đặt và sử dụng 253 10.3.3.1. Cài đặt 253 10.4.3.2. Hướng dẫn sử dụng 260 BÀI 11. THỰC HÀNH LẬP KẾ HOẠCH KIỂM THỬ TEST PLAN 302 11.1. Yêu cầu 302 11.2. Hướng dẫn thực hiện 302 BÀI 12. THỰC HÀNH THIẾT KẾ KIỂM THỬ TEST DESIGN 308 12.1. Yêu cầu 308 12.2. Hướng dẫn thực hiện 308 BÀI 13. THỰC HÀNH TRƯỜNG HỢP KIỂM THỬ TEST CASE 313 13.1. Yêu cầu 313 13.2. Hướng dẫn thực hiện 313 BÀI 14. THỰC HÀNH QUẢN LÝ LỖI BUG MANAGEMENT 319 14.1. Yêu cầu 319 14.2. Hướng dẫn thực hiện 319 BÀI 15. THỰC HÀNH BÁO CÁO KIỂM THỬ TEST REPORT 320 15.1. Yêu cầu 320 15.2. Hướng dẫn thực hiện 320 BÀI 16. THỰC HÀNH KIỂM THỬ TỰ ĐỘNG TEST AUTOMATIC 326 16.1. Yêu cầu 326 16.2. Hướng dẫn thực hiện 326 16.3. Yêu cầu 326 TÀI LIỆU THAM KHẢO 327
Kiểm thử phần mềm – Software Testing MỤC LỤC MỤC LỤC BÀI CƠ BẢN VỀ KIỂM THỬ PHẦN MỀM BÀI QUY TRÌNH PHÁT TRIỂN PHẦN MỀM 22 BÀI QUY TRÌNH KIỂM THỬ PHẦN MỀM 66 BÀI THIẾT KẾ TEST – TEST DESIGN 159 BÀI TEST CASE VÀ CÁC KỸ THUẬT THIẾT KẾ TEST CASE .166 TÀI LIỆU THAM KHẢO .309 Bộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên Trang Kiểm thử phần mềm – Software Testing BÀI CƠ BẢN VỀ KIỂM THỬ PHẦN MỀM Năm 1947, máy tính cỡ lớn (to tòa nhà) điểu khiển dựa relay sức nóng ống chân không Điển hình cho máy tính giai đoạn Mark II, máy tính khổng lồ xây dựng trường đại học Harvard Các kỹ thuật viên bước chạy máy tính dừng làm việc Họ nhiều công sức để tính toán xem họ khám phá ra: họ bị mắc kẹt tập relay sâu bên ruột máy tính Dường như, chúng bị căng phồng lên hệ thống ánh sáng sức nóng, bị hạ gục điện áp cao hoạt động relay Như vậy, trình lập trình để điều khiển hoạt động máy tính có vấn đề không ổn Vì mà đến với học môn Software testing Nội dung môn học bao gồm: - Lịch sử lỗi phần mềm, khái niệm lỗi phần mềm - Các kỹ tảng việc kiểm thử phần mềm - Những yếu tố cần kiểm thử phần mềm - Các giai đoạn kiểm thử phần mềm - Làm việc với tài liệu kiểm thử: lập kế hoạch, viết theo dõi test case, báo cáo lỗi - Chuẩn quốc tế phần mềm tốt Trong này, tìm hiểu lịch sử lỗi phần mềm kiểm thử phầm mềm Những điểm cần ý bao gồm: - Các lỗi phần mềm tác động đến sống nào? - Lỗi chúng xuất hiện? - Các tester họ phải làm gì? 1.1 Những lỗi (bug) phần mềm nghiêm trọng lịch sử - Hãy đánh giá thử xem phần mềm thâm nhập vào sống Bộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên Trang Kiểm thử phần mềm – Software Testing o Sau năm 1947, máy tính Mark II yêu cầu hàng tá nhà lập trình phải bảo trì liên miên Những người bình thường không tưởng tượng ngày nhà họ có máy tính họ o Bây giờ, máy tính tràn ngập khắp nơi, không đến với gia đình, mà đến với cá nhân Những đĩa CD phần mềm miễn phí với đoạn video game cho trẻ em, tặng kèm theo hộp ngũ cốc nhiều phần mềm tàu thoi - Hãy thử so sánh phát triển máy nhắn tin buồng điện thoại, dịch vụ chuyển phát nhanh… với phát triển máy tính phần mềm máy tính Dường không theo kịp bùng nổ ngành công nghiệp đầy chất xám Bây giờ, không sử dụng dịch vụ chuyển phát nhanh…, bắt đầu ngày mà không vào mạng kiểm tra thư điện tử - Phần mềm khắp nơi Tuy nhiên, viết nhiều người, mà không hoàn hảo Chúng ta tìm hiểu số ví dụ đây: 1.1.1 Disney’s Lion King, 1994 – 1995 Vào cuối năm 1994, công ty Disney tung thị trường trò chơi đa phương tiện cho trẻ em, The Lion King Animated StoryBook Mặc dù nhiều công ty khác quảng bá chương trình cho trẻ em nhiều năm, lần Disney mạo hiểm lao vào thị trường Nó xúc tiến quảng cáo mạnh mẽ Số lượng bán vô đồ sộ Nó mệnh danh “the game to buy” cho trẻ em kỳ nghỉ Tuy nhiên, chuyện xảy đến? Đó thất bại khủng khiếp Vào 26/12, sau ngày Giáng Sinh, khách hàng Disney liên tục gọi điện Ngay lập tức, kỹ thuật viên trợ giúp điện thoại bị sa lầy với gọi từ bậc cha mẹ giận đứa trẻ khóc, chúng cho phần mềm làm việc Nhiều câu chuyện xuất mặt báo tin TV …Disney thất bại không kiểm tra phần mềm rộng dãi nhiều mô hình máy tính khác có sẵn thị trường Phần mềm làm việc vài hệ thống mà các lập trình viên Disney dùng để tạo trò game này, hệ thống phổ biến mà người dùng hay sử dụng Bộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên Trang Kiểm thử phần mềm – Software Testing 1.1.1 Lỗi chia dấu phẩy động vi xử lý Intel Pentium (Intel Pentium Floating – Point Division Bug), 1994 Hãy mở phần mềm Calculator máy tính bạn thực phép toán sau: (4195835 / 3145727) * 3145727 – 4195835 Nếu kết 0, máy tính bạn hoạt động tốt Nếu bạn nhận kết khác, bạn sở hữu Intel Pentium CPU với lỗi floating – point division (chia dấu phẩy động) – lỗi phần mềm làm nóng chip bạn mà tái sản xuất liên tục Ngày 30/10/1994, Thomas R Nicely thuộc trường cao đẳng Lynchburg (Virgnia) phát kết không mong muốn thực phép chia (division) máy tính ông Ông công bố kết nghiên cứu internet ông làm bùng lên lửa với số lượng lớn người gặp vấn đề ông Và họ tìm thêm tình máy tính đưa câu trả lời sai May thay trường hợp thấy kết đưa câu trả lời sai trường hợp phục vụ cho Toán học chuyên sâu, Khoa học, Tính toán kỹ thuật Hầu hết người không bắt gặp chúng thực tính toán thông thường chạy ứng dụng thương mại họ Điều làm cho vấn đề đáng ý không Intel coi bug, mặt khác cách mà Intel điều khiển tình hình: - Họ phát vấn đề thực thi test họ trước chip tung thị trường Các nhà quản lý Intel định vấn đề không đủ nghiêm trọng khả xảy để cần thiết phải fixing (sửa) chí publicizing (công khai) - Lỗi bị phát hiện, Intel cố gắng để giảm bớt tính chất nghiêm trọng vấn đề bị nhận cách công bố công khai (press release) Bộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên Trang Kiểm thử phần mềm – Software Testing - Khi bị gây áp lực, Intel ngỏ ý muốn thay miến phí chip bị lỗi, với điều kiện người sử dụng phải chứng minh bị ảnh hưởng lỗi (bug) - Họ gặp phải phản đối kịch liệt Các diễn đàn Internet tạo sức ép với giận khách hàng khó tính, đòi Intel phải fix vấn đề Các tin vẽ lên hình ảnh Intel giống công ty vô trách nhiệm với khách hàng Cuối cùng, Intel phải xin lỗi cách điều chỉnh bug phải bỏ 400 triệu dollar để chi trả cho trình thay chip bị lỗi Bây giờ, Intel công khai vấn đề Website họ cẩn trọng giám sát hồi đáp khách hàng diễn đàn (newsgroups) Chú ý: Vào ngày 28/08/2000, thời gian ngắn trước phiên sách sản xuất, Intel thông báo việc thu hồi tất vi xử lý Pentium III 1.13MHz, sau chip tung thị trường khoảng tháng Một vấn đề bị phát Vì họ phải thực thi cho lời khẳng định chắn ứng dụng chạy ổn định Họ phải lập kế hoạch để thu hồi máy tính tới tay khách hàng tính toán giá thành để thay cho chip bị lỗi 1.1.2 Tàu vũ trụ NASA đáp xuống địa cực Hỏa (NASA Mars Polar Lander), 1999 Ngày 3/12/1999, Tàu vũ trụ NASA đáp xuống địa cực Hỏa biến khỏi vòng kiểm soát cố gắng đáp xuống bề mặt Hỏa Ban Báo Cáo cố điều tra cố xác định nguyên nhân xảy cố việc cài đặt bit liệu đơn lẻ Điều đáng ý cố lại chưa xảy thí nghiệm nội Theo lý thuyết, kế hoạch đáp tàu sau: tàu đáp xuống bề mặt, sẽ mở dù nhằm làm giảm tốc độ Một vài giây sau mở dù, chân máy dò mở chết vị trí đáp Khi máy dò vị trí cách bề mặt hỏa 1.800m nhả dù đốt nóng (thruster) để giảm khoảng cách lại so với bề mặt hỏa Bộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên Trang Kiểm thử phần mềm – Software Testing Để tiết kiệm, NASA đơn giản máy định thời gian ngắt Thay Rada đắt tiền tàu vũ trụ, họ cài đặt công tắc tiếp xúc (Contact switch) chân máy dò Nói cách đơn giản, chân máy rò mở bật công tắc để động đốt cháy chân chạm đất Thật không may ban báo cáo cố phát trình kiểm tra họ chân tách để chạm tới đất, rung động máy làm trượt công tắc đốt cháy việc thiết đặt bit gây tai họa Đây vấn đề nghiêm trọng, máy tính tắt phận đốt nóng tàu bị vỡ mảnh sau rơi từ độ cao 1.800m xuống bề mặt Hỏa Kết thật thê thảm, lý lại đơn giản Con tàu thám hiểm kiểm tra nhiều đội Một đội kiểm tra chức mở chân tàu đội khác kiểm tra việc đáp tàu xuống mặt đất Đội rằng: bit thiết đặt cho việc mở chân tàu không nằm vùng kiểm tra họ Đội thứ luôn thiết lập lại máy tính, xóa bit liệu trước bắt đầu kiểm tra Cả đội làm việc độc lập hoàn thành nhiệm vụ hoàn hảo Nhưng lại không hoàn hảo kết hợp nhiệm vụ với 1.1.3 Hệ thống phòng thủ tên lửa Patriot, 1991 Hệ thống phòng thủ tên lửa Patriot (người yêu nước) Mỹ phiên scaled-back chương trình khởi động chiến lược phòng thủ “Star Wars” khởi động tổng thống Ronald Reagan Nó đặt móng cho chiến tranh Vùng Vịnh (Gulf war) hệ thống phòng thủ tên lửa Iraqi Scub Mặc dù có nhiều câu chuyện quảng bá thành công hệ thống, nhiên tồn lỗi chống lại vài tên lửa Một số giết chết 28 lính Mỹ Dhahran, Saudi Arabia Quá trình phân tích cho thấy rằng, phần mềm bị lỗi nghiêm trọng Một thời gian trễ nhỏ đồng hồ hệ thống tích lũy lại sau 14h, hệ thống theo dõi không xác Trong công Dhahran, hệ thống điều hành 100h 1.1.4 Sự cố Y2K (năm 2000), khoảng 1974 Bộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên Trang Kiểm thử phần mềm – Software Testing Vào đầu năm 1970, lập trình viên, tên Dave, làm việc cho hệ thống trả tiền công ty Máy tính mà sử dụng có nhớ lưu trữ nhỏ, buộc phải giữ gìn byte cuối mà có Dave tự hào đóng gói chương trình cách chặt chẽ (tightly) so với vài đồng nghiệp Một phương thức mà sử dụng chuyển định dạng ngày tháng từ chữ số, ví dụ 1973 thành định dạng chữ số, ví dụ 73 Bởi vì, hệ thống trả tiền (Payroll) phụ thuộc nặng vào xử lý ngày tháng, nhờ Dave giữ lại không gian nhớ có giá trị Trong thời gian ngắn, xem xét vấn đề xuất đến thời điểm năm 2000 hệ thống bắt đầu thực công việc tính toán với năm đại diện 00, 01… Anh ta nhận thấy rằng, có vài vấn đề xảy đến, nghĩ chương trình thay cập nhật vòng 25 năm, nhiệm vụ quan trọng kế hoạch tương lai xa Và thời hạn đến Năm 1995, chương trình Dave sử dụng, Dave nghỉ hưu Và không biết làm để vào hệ thống kiểm tra xem đến năm 2000 chuyện xảy Chỉ Dave biết cách để fix Người ta ước tính rằng, phải đến vài trăm tỷ dollar để cập nhật fix lỗi tiềm tàng vào năm 2000, cho chương trình máy tính toàn giới có sử dụng hệ thống Dave 1.1.5 Mối hiểm nguy Virus, năm 2004 01/04/1994, thông điệp gửi tới vài nhóm người sử dụng internet sau truyền bá email có chứa loại virus ẩn ảnh có định dạng JPEG internet Người ta cảnh báo cần thao tác mở xem tranh bị nhiễm dẫn đến việc cài đặt virus PC bạn Sự thay đổi lời cảnh báo nói rõ virus làm hỏng hình máy tính bạn hình Sony Trinitron “đặc biệt nhạy cảm” Bộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên Trang Kiểm thử phần mềm – Software Testing Nhiều người ý tới lời cảnh báo làm file ảnh JPEG hệ thống họ Thậm chí, số người quản trị hệ thống tìm hiểu sâu bên khối ảnh JPEG nhận từ email hệ thống họ Cuối cùng, người nhận thấy rằng, thông điệp ban đầu gửi vào ngày cá tháng (“April Fools Day”) thật chuyện cả, câu chuyện đùa xa Các chuyên gia rung hồi chuông cảnh báo rằng: cách khả thi để ảnh JPEG có khả làm máy tính bạn bị nhiễm virus Sau tất cả, người ta khẳng định tranh liệu, thực thi mã chương trình Mười năm sau, vào mùa thu năm 2004, virus proof-of-concept tạo ra, chứng minh ảnh JPEG tải với virus Nó gây ảnh hưởng tới hệ thống sử dụng để xem Những mẩu tin (software patches) tạo cách nhanh chóng thông báo rộng khắp để ngăn chặn virus lan tràn Tuy nhiên, vấn đề thời gian họ khống chế vấn đề internet cách làm ảnh đường truyền 1.2 Lỗi (bug) gì? Bạn vừa tìm hiểu số vấn đề xảy phần mềm bị lỗi Nó dẫn đến phiền phức, giống máy chơi game làm việc cách hợp lý, dẫn đến thảm họa khủng khiếp Số tiền để giải vấn đề sửa lỗi lên tới hàng triệu dollar Trong ví dụ trên, rõ ràng phần mềm không hoạt động dự tính ban đầu Nếu tester, bạn phải tìm thấy hầu hết lỗi phần mềm Hầu hết lỗi đơn giản tinh vi, có nhỏ phân biệt lỗi lỗi NHỮNG THUẬT NGỮ VỀ CÁC LỖI PHẦN MỀM: Phụ thuộc vào nơi mà bạn làm việc (như tester), bạn sử dụng thuật ngữ khác để mô tả: điều xảy đến phần mềm bị lỗi Dưới số thuật ngữ: Defect nhược điểm Bộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên Trang Kiểm thử phần mềm – Software Testing Fault khuyết điểm Failure thất bại Anomaly dị thường Variance biến dị Incident việc rắc rối Problem vấn đề Error lỗi Bug lỗi Feature đặc trưng Inconsistency mâu thuẫn (Chúng ta có danh sách thuật ngữ không nên nhắc đến, hầu hết chúng sử dụng riêng biệt, độc lập lập trình viên) Bạn thấy ngạc nhiên có nhiều từ để mô tả lỗi phần mềm Tại lại vậy? Có phải tất chúng thật dựa văn hóa công ty trình mà công ty sử dụng để phát triển phần mềm họ Nếu bạn tra từ từ điển, bạn thấy tất chúng có ý nghĩa khác không đáng kể Chúng có ý nghĩa suy từ cách mà chúng sử dụng đàm thoại hàng ngày Ví dụ, fault, failure defect có xu hướng ám vấn đề thật quan trọng, chí nguy hiểm Dường không gọi biểu tượng (icon) không tô màu lỗi (fault) Những từ thường ám lời khiển trách: (fault) mà phát sinh lỗi phần mềm (software failure) (“it’s his fault that the software failure.”) Anomaly, incident, variance không tiêu cực thường sử dụng để đề cập tới vận hành không dự tính trước thay hoàn toàn lỗi (allBộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên Trang Kiểm thử phần mềm – Software Testing out failure) “Tống thống tuyên bố dị thường phần mềm làm cho tên lửa sai lịch trình nó” ("The president stated that it was a software anomaly that caused the missile to go off course.") Có lẽ, Problem, error bug thuật ngữ chung thường sử dụng Một điều thú vị số công ty đội sản xuất tiêu tốn nhiều thời gian quý báu trình phát triển phần mềm vào việc thảo luận tranh cãi thuật ngữ sử dụng Một công ty máy tính tiếng hàng tuần để thảo luận với kỹ sư họ trước định đổi tên Product Anomaly Report (PARs) thành Product Incident Report (PIRs) Một số tiền lớn sử dụng cho việc định thuật ngữ tốt Một định đưa (Once the decision was made), tất công việc liên quan đến giấy tờ, phần mềm, định dạng… phải cập nhật để phản ảnh thuật ngữ Nó tới gây khác biệt hiệu làm việc lập trình viên tester Vậy, phải đưa chủ đề này? Thực quan trọng tester hiểu khả cá nhân đằng sau nhóm phát triển phần mềm mà bạn làm việc Cách thức họ đề cập tới vấn đề phần mềm họ dấu hiệu thông thường cách họ tiếp cận trình phát triển toàn họ Mặc dù tổ chức bạn chọn tên khác, sách tất các vấn đề phần mềm gọi bug Không thành vấn đề lỗi lớn, nhỏ, dự định, hay dự định, cảm giác bị tổn thương họ tạo chúng Không có lý để mổ xẻ từ A bug's a bug's a bug ĐỊNH NGHĨA VỀ LỖI PHẦN MỀM: Các vấn đề software problems bug nghe đơn giản, chưa hẳn giải Bây giờ, từ problem cần định nghĩa Để tránh việc định nghĩa vòng quanh (circular definitions), điều quan trọng phải mô tả lỗi gì? Đầu tiên, bạn cần thuật ngữ trợ giúp (supporting term): đặc tả phần mềm (product specification) Đặc tả phần mềm gọi cách đơn giản spec Bộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên Trang 10 Kiểm thử phần mềm – Software Testing BÀI 13 THỰC HÀNH TRƯỜNG HỢP KIỂM THỬ - TEST CASE 13.1 Yêu cầu Tạo test case cho dự án quản lý sinh viên lập kế hoạch, theo mẫu 13.2 Hướng dẫn thực - Sử dụng thành thạo công cụ Excel - Thực hành theo mẫu đây: Tạo mẫu biểu Sử dụng công thức tính toán Mẫu 01: Cover TEST CASE Project Name Project Code Document Name Author Reviewer/Approver Issue Date Version Record of change: Bộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên Trang 295 Kiểm thử phần mềm – Software Testing Effective Date Version Change Item *A,D,M Change description Bộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên Reference Trang 296 Kiểm thử phần mềm – Software Testing Mẫu 02: GUI Graphic User Interface TOC Total: Passed: Failed: Not yet tested: Cancelled: Screen Name 0 0 Field Name Expected result Type Madatory Editable Default value Test Status Max Length Test Date Range/ Value Module Name Precondition/Context: [Module Name] [Screen Name] Common case Note: Common cases apply for all new/edit/display pages of all modules Audit trail Bộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên Trang 297 Note Kiểm thử phần mềm – Software Testing Mẫu 03: Modules TEST CASE Module Code Test requirement Pass Tester Fail Pass Fail Untested N/A 0 Number of Test cases Untesed N/A [Module Name] Function Name [Function Name-1］ abc [Function Name-2］ def [Function Name-3］ dd [Function Name-4］ dd [Function Name-5］ dd [Function Name-6］ dd Bộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên Trang 298 Kiểm thử phần mềm – Software Testing TEST CASE Module Code Test requirement Subject Management Pass Tester Fail Pass Fail Untested N/A 0 Number of Test cases Untesed N/A Subject Management [Subject Aaa Management-1］ [Subject Bbb Management-2］ [Subject Ccc Management-3］ [Subject Ddd Management-4］ [Subject Eee Management-5］ Bộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên Trang 299 Kiểm thử phần mềm – Software Testing [Subject Fff Management-6］ [Subject Ggg Management-7］ Mẫu 04: Picture Chụp form giao diện chức dự án cần test Bộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên Trang 300 Kiểm thử phần mềm – Software Testing BÀI 14 THỰC HÀNH QUẢN LÝ LỖI - BUG MANAGEMENT 14.1 Yêu cầu Tạo bug management cho dự án quản lý sinh viên lập kế hoạch, theo mẫu 14.2 Hướng dẫn thực - Sử dụng thành thạo công cụ Excel - Thực hành theo mẫu đây: Tạo mẫu biểu Defect ID Module Title section Description Ex: Default value of Status field = blank is incorrect Expected result: when create new document, default value of [Status] field must be "Oppened" Type Severity Ex: User Interface Ex: Cosmetic Priority Ex: High Status Ex: Assigned Created Date Ex: 21-Sep2008 Bộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên Assigned to Ex: TungNT Corrective Action Ex: change code to update correct status Trang 301 Kiểm thử phần mềm – Software Testing BÀI 15 THỰC HÀNH BÁO CÁO KIỂM THỬ - TEST REPORT 15.1 Yêu cầu Tạo test report cho dự án quản lý sinh viên lập kế hoạch, theo mẫu 15.2 Hướng dẫn thực - Sử dụng thành thạo công cụ Excel - Thực hành theo mẫu đây: Tạo mẫu biểu Sử dụng công thức tính toán Vẽ biểu đồ với số liệu tổng hợp tính toán Bộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên Trang 302 Kiểm thử phần mềm – Software Testing Mẫu 01: Test report TEST REPORT Project Name Project Code Document Name Student Management SM-2009 SM-2009_Test Report_vx.x Creator Reviewer/Approver Issue Date Ha Thi Thu Huong Van Kim Ngan Notes No Module code Account Management Subject Management GUI Sub total Test coverage Test successful coverage Pass 0 Fail 0 Untested N/A 0 Number of test cases 0 0 16 0 16 0.00 0.00 % % Bộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên Trang 303 Kiểm thử phần mềm – Software Testing Ví dụ mẫu test report: TEST REPORT Project Name Creator Project Code Document Code Review/Appove Issue Date Notes No Module Code Login Student Management Subject Management Tổng Pass 12 33 12 57 Test coverage Test successful coverage Fail 3 10 Untested 11 N/A 0 0 Number of Test case 19 38 21 78 100 % 73.1 % Bộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên Trang 304 Kiểm thử phần mềm – Software Testing Ví dụ mẫu: Defect report Serverity Fatal Serious Medium Cosmetic Total Status Total W.def Opended Defect Erro Assigned Fixing r 136 570 177 575 325 1745 1286 Corrected 1 Confirmed No 139 749 903 3038 Delivered Validate d 3 Fixed Defect Approve Accepted Cancelled Closed d 2 12 1 15 75 22 181 2 40 270 87 486 Bộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên No 15 97 204 319 600 Trang 305 12 154 846 210 1222 3638 Kiểm thử phần mềm – Software Testing Ví dụ mẫu Defect distribute: QC Activity Acceptance test After Release review After Release test Beaseline Audit Code Review Document Review Final inspection Integration test Other test Prototype review System test Unit test Total Requirement F S M C W F S Design M C W F S 3 36 51 26 20 Coding M C W 10 138 19 11 749 25 F S Test M C 1 2 W 28 35 2307 11 737 3112 3 26 F Other S M C 10 1 1 10 25 13 26 28 212 54 2427 10 757 3551 20 22 114 1 13 15 196 43 58 28 36 160 130 135 33 768 93 Bộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên W Trang 306 Kiểm thử phần mềm – Software Testing Bộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên Trang 307 Kiểm thử phần mềm – Software Testing BÀI 16 THỰC HÀNH KIỂM THỬ TỰ ĐỘNG - TEST AUTOMATIC 16.1 Yêu cầu Thực kiểm thử tự động hiệu khả chịu tải cho dự án Quản lý sinh viên xây dựng tài liệu test 16.2 Hướng dẫn thực - Sử dụng thành thạo công cụ Quicktest Load Test 16.3 Yêu cầu 16.3.1 Thực hành thành phần phần mềm Quicktest professional với phần mềm đặt vé máy bay flight - Checkpoint - Data table - Import/ export data - Output - Action - Recovery Management - Object Responsibility Manager 16.3.2 Thực hành thành phần phần mềm Load runner với website đặt vé máy bay - Công cụ VuGen (Virtual User Generator) - Công cụ Controller - Công cụ Load Generator - Công cụ Analysis Bộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên Trang 308 Kiểm thử phần mềm – Software Testing TÀI LIỆU THAM KHẢO [1].Lý thuyết kiểm tra phần mềm [2].Phân tích thiết kế HTTT theo UML [3].C.Sharp Database Programming [4].Guideline_Software Testing [5].Windows Forms Programming With C# [6] http://qtp.blogspot.com [7] Http://www.msdn.microsoft.com [8] Http://testingvn.com Bộ môn CNPM- Khoa CNTT – Trường ĐH SP KT Hưng Yên Trang 309