Lịch sử về lỗi phần mềm, những khái niệm cơ bản về lỗi phần mềm
Các kỹ năng nền tảng của việc kiểm thử phần mềm
Những yếu tố cơ bản cần kiểm thử trong một phần mềm
Các giai đoạn trong khi kiểm thử một phần mềm
Làm việc với các tài liệu kiểm thử: lập kế hoạch, viết và theo dõi các test case, báo cáo lỗi
Chuẩn quốc tế của một phần mềm tốt
25 trang |
Chia sẻ: mamamia | Lượt xem: 3010 | Lượt tải: 3
Bạn đang xem trước 20 trang tài liệu Giáo trình Software testing, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
Nguyễn Thị Thu Hiền * * NỘI DUNG MÔN HỌC Lịch sử về lỗi phần mềm, những khái niệm cơ bản về lỗi phần mềm Các kỹ năng nền tảng của việc kiểm thử phần mềm Những yếu tố cơ bản cần kiểm thử trong một phần mềm Các giai đoạn trong khi kiểm thử một phần mềm Làm việc với các tài liệu kiểm thử: lập kế hoạch, viết và theo dõi các test case, báo cáo lỗi Chuẩn quốc tế của một phần mềm tốt * * PHẦN I. NỀN TẢNG CỦA SOFTWARE TESTING Bài 1: Cơ bản về software testing Bài 2: Quy trình phát triển phần mềm * * BÀI 1. CƠ BẢN VỀ SOFTWARE TESTING* Những bug phần mềm nghiêm trọng trong lịch sử Thế nào là một bug? Tại sao bug xuất hiện? Chi phí cho việc sửa bug Tester làm những gì? Những yếu tố nào tạo nên một tester tốt * * 1.1. NHỮNG LỖI PHẦN MỀM NGHIÊM TRỌNG TRONG LỊCH SỬ Trò chơi “Vua sư tử” của Disney, 1994 – 1995 Lỗi chia dấu phẩy động của bộ vi xử lý Intel Pentium, 1994 Tàu vũ trụ của NASA đáp xuống địa cực của Mars, 1999 Hệ thống phòng thủ tên lửa Patriot, 1991 Sự cố Y2K (năm 2000), khoảng 1974 Mối hiểm nguy của Virus, năm 2004 * * 1.2. THẾ NÀO LÀ MỘT LỖI? Lỗi phần mềm có thể dẫn đến những phiền phức, thậm chí là gây ra những thảm họa khủng khiếp, tiêu tốn hàng triệu dollar Đôi khi lỗi phần mềm rất đơn giản và tinh vi, có khi quá nhỏ đến nỗi không thể phân biệt được cái nào là lỗi và cái nào không phải là lỗi * * 1.2. THẾ NÀO LÀ MỘT LỖI? Mỗi công ty có sự lựa chọn 1 trong các thuật ngữ sau để ám chỉ lỗi phần mềm: Defect nhược điểm Fault khuyết điểm Failure sự thất bại Anomaly sự 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 sự mâu thuẫn * * 1.2. THẾ NÀO LÀ MỘT LỖI? Một số thuật ngữ trợ giúp (supporting term): product specification Spec product spec Specification Spec định nghĩa phần mềm chi tiết là gì, hành động như thế nào, sẽ làm gì, và sẽ không làm gì? Spec là luận cứ của cả nhóm phát triển phần mềm * * 1.2. THẾ NÀO LÀ MỘT LỖI? Như thế nào là lỗi phần mềm? * * 1.2. THẾ NÀO LÀ MỘT LỖI? Một lỗi phần mềm xuất hiện khi một trong 5 quy tắc sau xuất hiện: Phần mềm không thực hiện một số thứ giống như mô tả trong Spec Phần mềm thực hiện một số việc mà spec yêu cầu nó không được thực hiện Phần mềm thực hiện một số chức năng mà spec không đề cập tới Phần mềm không thực hiện một số việc mà spec không đề cập tới, nhưng là những việc nên làm Trong con mắt của tester, phần mềm là khó hiểu, khó sử dụng, chậm đối với người sử dụng * * 1.2. THẾ NÀO LÀ MỘT LỖI? Quan trọng là các lỗi phần mềm bạn đưa ra phải hợp lý Định nghĩa trên về lỗi của một phần mềm đã bao quát những vấn đề cơ bản Sử dụng tất cả 5 quy tắc trên sẽ giúp bạn định nghĩa được các loại vấn đề khác nhau trong phần mềm mà bạn đang kiểm thử. * * 1.3. TẠI SAO BUG XUẤT HIỆN? Hình 1.1: Các lỗi có thể bị phát sinh do nhiều lý do, nhưng trong quá trình phân tích các dự án mẫu thì lý do chính phát sinh bug là quá trình truy vết theo bản đặc tả. * * 1.3. TẠI SAO BUG XUẤT HIỆN Nguyên nhân chính làm xuất hiện lỗi là specification: Một số spec không viết cụ thể, không đủ kỹ lưỡng Spec liên tục thay đổi, nhưng lại không có sự phối hợp, trao đổi thông tin kịp thời với các đội phát triển dự án. Nếu spec được xây dựng không đúng, lỗi sẽ phát sinh * * 1.3. TẠI SAO BUG XUẤT HIỆN Nguyên nhân chính làm xuất hiện lỗi là specification: Quá trình design cũng dễ phát sinh lỗi: Bản thiết kế (design) không chi tiết Khi design thay đổi, nhưng nhóm phát triển chưa kịp cập nhật Design không đúng dẫn đến phần mềm xây dựng sai * * 1.3. TẠI SAO BUG XUẤT HIỆN Nguyên nhân chính làm xuất hiện lỗi là specification: Quá trình design cũng dễ phát sinh lỗi: Lỗi do quá trình viết code: Code không đáp ứng đúng yêu cầu của spec, design Code đáp ứng chưa đủ yêu cầu của spec, design Code không cập nhật kịp thời các bản spec, design * * 1.3. TẠI SAO BUG XUẤT HIỆN Nguyên nhân chính làm xuất hiện lỗi là specification: Quá trình design cũng dễ phát sinh lỗi: Lỗi do quá trình viết code: Lỗi khác: Một số lỗi nhân bản, bắt nguồn từ 1 nguyên nhân Lỗi do quá trình kiểm thử sai Những bug tưởng là lỗi, nhưng lại không hẳn là lỗi * * 1.4. CHI PHÍ CHO VIỆC SỬA LỖI Hình 1.2: Chi phí cho việc sửa lỗi có thể tăng đột ngột trên toàn bộ dự án Ví dụ: - The Lion King animate StoryBook - Floating point division * * 1.5. TESTER PHẢI LÀM NHỮNG GÌ? Mục đích của tester là tìm ra lỗi phần mềm Ví dụ: ô textbox nhập ngày tháng, nhập đúng => pass => dễ bỏ quên những trường hợp nhập sai định dạng Đôi khi phải trả giá rất đắt bởi quá trình kiểm tra lỗi không phát hiện ra vấn đề * * 1.5. TESTER PHẢI LÀM NHỮNG GÌ? Mục đích của tester là tìm ra lỗi phần mềm Mục đích của tester là tìm các lỗi và tìm thấy chúng một cách sớm nhất có thể Mục đích của tester là tìm các lỗi, tìm thấy chúng một cách sớm nhất có thể, và đảm bảo rằng chúng sẽ được sửa * * 1.5. TESTER PHẢI LÀM NHỮNG GÌ? Chú ý: Tester là một người đi tìm kiếm sự hoàn hảo Nhưng một phần mềm được sửa không có nghĩa rằng phần mềm đã hoàn hảo Tester phải biết lập kế hoạch, biết dừng quá trình kiểm thử đúng lúc * * 1.6. NHỮNG YẾU TỐT NÀO TẠO NÊN MỘT TESTER TỐT So sánh công việc của tester với programer Hai công việc đều phải sử dụng nhiều kỹ năng giống nhau Tester không nhất thiết phải biết lập trình, nhưng họ cũng tạo ra những khoản lợi nhuận khổng lồ * * 1.6. NHỮNG YẾU TỐT NÀO TẠO NÊN MỘT TESTER TỐT So sánh công việc của tester với programer So sánh các công ty được khách hàng ưa chuộng (1) và các công ty bị nhiều khách hàng tẩy chay (2) (1): tạo ra những phần mềm tốt, tester được coi như 1 kỹ sư thực sự (2): khách hàng ko ưa thích nhứng phần mềm còn nhiều lỗi, họ không đánh giá đúng vai trò của tester * * 1.6. NHỮNG YẾU TỐT NÀO TẠO NÊN MỘT TESTER TỐT Những đặc điểm mà tester nên có: Là người thích khám phá Là người thợ sửa chữa Là người nghiêm khắc Là người sáng tạo Là người cầu toàn Là người có óc phán đoán Là người khéo léo và biết ngoại giao, có khả năng thuyết phục người khác * * 1.6. NHỮNG YẾU TỐT NÀO TẠO NÊN MỘT TESTER TỐT Nếu tester có kiến thức về lập trình Kiểm thử mã nguồn Kiểm thử tự động Nếu tester là một chuyên gia trong lĩnh vực khác Nó trợ giúp đắc lực cho quá trình phát hiện lỗi của phần mềm ở lĩnh vực đó * * BÀI 1. TỔNG KẾT Kiểm thử phần mềm là một công việc có tính chất phê bình. Với tầm cỡ và độ phức tạp của các phần mềm ngày nay, thì yêu cầu cấp bách là kiểm thử phần mềm cần được thực thi một cách chuyên nghiệp và hiệu quả. Trong các chương tiếp sau của phần I, bạn sẽ được tìm hiểu về quy trình phát triển phần mềm và cách mà tester làm các vấn đề ăn khớp lại với nhau. Những hiểu biết của bạn sẽ giúp bạn đánh giá và áp dụng những kỹ thuật kiểm thử đặc biệt trong toàn bộ nội dung còn lại môn học này. * * BÀI 1. CÂU HỎI Trong sự cố Y2K, Dave đã làm gì sai? Khi kiểm thử 1 phần mềm thì tester phải nắm bắt toàn bộ các lỗi và đảm bảo phần mềm hoạt động một cách hoàn hảo. Đúng hay sai? 5 quy tắc để phát hiện lỗi là gì? Chi phí cho việc sửa lỗi được tìm thấy sau khi sản phẩm được tung ra thị trường, và việc phát hiện lỗi đó ngay khi bắt đầu dự án, khác nhau ntn? Mục đích của kiểm thử phần mềm là gì? Một tester giỏi luôn lỗ lực cố gắng để đạt đến sự hoàn hảo, đúng hay sai? Hãy đưa ra một vài lý do giải thích tại sao đặc tả phần mềm luôn là nguồn phạm vi rộng lớn của các lỗi trong sản phẩm phần mềm * *