Bài giảng Kiểm thử phần mềm: Chương 1 - TS. Nguyễn Thanh Hùng

Chia sẻ: _ _ | Ngày: | Loại File: PDF | Số trang:48

Thêm vào BST

Báo xấu

49
lượt xem 10
download

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

Bài giảng "Kiểm thử phần mềm - Chương 1: Giới thiệu về kiểm thử phần mềm" cung cấp các kiến thức giúp người đọc, các định nghĩa và chi phí của các khiếm khuyết (defect), các định nghĩa và mục tiêu của kiểm thử phần mềm, mục tiêu và quy trình làm việc của người kiểm thử... 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 Kiểm thử phần mềm: Chương 1 - TS. Nguyễn Thanh Hùng

Trường Đại Học Bách Khoa Hà Nội Kiểm thử phần mềm Giới thiệu về kiểm thử phần mềm TS. Nguyễn Thanh Hùng Bộ môn Công Nghệ Phần Mềm Viện Công Nghệ Thông Tin và Truyền Thông Email: hungnt@soict.hust.edu.vn CuuDuongThanCong.com https://fb.com/tailieudientucntt 1
Mục tiêu môn học  Các khái niệm, định nghĩa về kiểm thử và chất lượng phần mềm  Các mức độ kiểm thử phần mềm  Các kỹ thuật, tiến trình kiểm thử  Hiểu và tạo được các trường hợp kiểm thử cho các chương trình đơn giản  Quản lý chất lượng phần mềm 2 @ ISR-CMU 2010 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Kiến thức cần thiết  Ngôn ngữ (nói , hiểu, viết): tiếng việt, tiếng anh  Cơ bản của IT  Kỹ năng lập trình (debug và kiểm tra lỗi)  Cơ bản của SE, quy trình phát triển phần mềm  Ngôn ngữ mô tả lôgic ( phản ứng) : tiến trình algebra, state machines, petri nets.  Toán học:  Logic, tập hợp  Thống kê. 3 @ ISR-CMU 2010 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Tài liệu tham khảo  Ian Sommerville: “Software Engineering”, 7th Ed., 2004.  Roger S. Pressman: “Software Engineering: A Practitioner's Approach”, 6th Ed., McGraw-Hill, 2004.  John Musa: “Software Reliability Engineering”, McGraw-Hill 4 @ ISR-CMU 2010 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Q&A Kiểm thử phần mềm là gì? Kiểm thử phần mềm là quá trình thực thi 1 hệ thống phần mềm để xác định xem phần mềm có đúng với đặc tả không và thực hiện trong môi trường như mong đợi hay không? 5 @ ISR-CMU 2010 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Q&A Thú vị nghề kiểm thử phần mềm?  Nghề chuyên đi tìm…lỗi.  Cảm giác rất “Yomost”! 6 @ ISR-CMU 2010 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Thuật ngữ ? TEST ERROR ? FAULT ? DEBUG FAILURE 7 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Chi phí thay đổi 60-100x 1.5-6x 1x Xác định yêu cầu Phát triển Sau khi đã phát hành 4 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Mục tiêu  Khám phá nền tảng của kiểm thử phần mềm để mọi người hiểu 6 ý chính sau: 1. Các định nghĩa và chi phí của các khiếm khuyết (defect). 2. Các định nghĩa và mục tiêu của kiểm thử phần mềm. 3. Mục tiêu và quy trình làm việc của người kiểm thử. 4. Điều gì làm nên một người kiểm thử giỏi. 5. Thực tiễn của kiểm thử phần mềm. 6. Các thuật ngữ của kiểm thử phần mềm. 9 @ ISR-CMU 2010 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Ví dụ  Giả sử có một hàm của một phần mềm nào đó được xác định như sau: nextDate (tháng, ngày, năm): hàm mà kết quả đầu ra là ngày tiếp theo của ngày đầu vào. 1 ≤ tháng ≤ 12, 1 ≤ ngày ≤ 31,1900 ≤ năm ≤ 2060. Hàm này đã được cài đặt bởi ngôn ngữ java.  Nếu chỉ có các đặc tả và các file .class, làm thế nào có thể chắc chắn rằng hàm đó đã được cài đặt chính xác?  Nếu đã cài đặt hàm, có nghĩa là, có các file .java, làm thế nào có thể chắc chắn rằng code là chính xác? 6 @ ISR-CMU 2010 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Ví dụ 1 (1)  Nếu bạn có các đặc tả và các file.class, có lẽ có thể tiếp tục như sau: 1. Suy nghĩ một vài phút dựa trên các đặc tả và chọn ngày 2006/06/16 như là một đầu vào cho chương trình. 2. Bắt đầu chương trình. 3. Nhập 6 vào trường tháng, 16 vào trường ngày và 2006 vào trường năm. 4. Nhấp vào nút cho biết. 5. Xem kết quả: 2006/06/17. Cuối cùng: kết quả là chính xác như mong muốn. =>hàm đúng. - Giả sử: đầu vào là ngày 2006/12/31. + Lặp lại các bước từ 2 đến 5. + Kết quả: 1/32/2007. 11 @ ISR-CMU 2010 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Ví dụ 1(2) B1: Mở giao diện Next Date B2: Nhập: 6 vào ô Month 16 vào ô Date 2006 vào ô Year B3: Click vào nút Tell và xem kết quả hiện lên là ngày 16/6/2006 12 @ ISR-CMU 2010 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Ví dụ 1(3) B1: Mở giao diện Next Date. B2: Nhập: 12 vào ô month 31 vào ô Date 2006 vào ô Year B3:Click vào nút Tell và kết quả hiện lên là 32/1/2007 13 @ ISR-CMU 2010 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Ví dụ 2 (1)  Khi đã thực hiện 1 chức năng , tức là đã có mã nguồn của nó. Nhưng làm sao để biết được code đó là chính xác. Hãy xem ví dụ dưới đây : 14 @ ISR-CMU 2010 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Ví dụ 2 (2)  Để kiểm tra code, thì mỗi dòng sẽ được chạy ít nhất một lần. Nhưng file Year.java chỉ là một phần của chương trình, nó không thể chạy một mình. Vì vậy cần code thêm 1 đoạn để kiểm tra xem 1 năm nào đó có phải là năm nhuận hay không. 15 @ ISR-CMU 2010 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Kết luận  Hai ví dụ cho ta biết được rằng chắc chắn sẽ có một số sai lầm trong chương trình. Trong thử nghiệm phần mềm, đây được gọi là một lỗi(defect).  Những ví dụ này là hai phương pháp tiếp cận khác nhau, đều có thể áp dụng để tìm lỗi. Một được gọi là kiếm tra chức năng như trong ví dụ 1, ví dụ 2 được gọi là kiểm tra cấu trúc  Bây giờ bạn có thể tự hỏi mình rằng là lý do tại sao chúng ta phải tìm các lỗi(defect)? 16 @ ISR-CMU 2010 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Tại sao lỗi lại phát sinh trong phần mềm?  Phần mềm được tạo ra bởi chính chúng ta  Chúng ta có thể biết nhiều thứ những chúng ta không thể biết được tất cả mọi thứ.  Các lập trình viên đều có kỹ năng, nhưng không phải ai cũng hoàn hảo.  1 số lập trình viên không có những quy tắc khắt khe với các đoạn mã của mình.  Các lập trình viên là những người dễ gây ra sai sót (lỗi).  Làm việc dưới áp lực ngày càng tăng để đảm bảo đúng thời hạn  Không có thời gian để kiểm tra, các chức năng có thể bị làm sai.  Hệ thống có thể không đáp ứng đầy đủ các yêu cầu ban đầu.  Phần mềm thực sự phức tạp, trừu tượng và vô hình  Khó có thể xem phần mềm nếu nó là chưa hoàn chỉnh hoặc hoạt động thiếu chính xác.  Khó có ai có thể hiểu hết hoàn toàn 1 hệ thống lớn.  Quá nhiều giao diện bên ngoài không cần thiết. 17 @ ISR-CMU 2010 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Tại sao phải tìm kiếm các lỗi  Phần mềm được viết bởi con người. Và họ tạo ra những sai sót . Chi phí của các lỗi có thể là rất cao.  Từ góc nhìn của 1 người phát triển phần mềm: • Phải mất rất nhiều thời gian và nỗ lực để sửa chữa các lỗi. Một cuộc khảo sát cho thấy khoảng 50% thời gian làm việc của người lao động phần mềm được chi tiêu vào việc tìm kiếm và sửa lỗi. • Càng sớm tìm ra lỗi thì chúng ta càng tiết kiệm được chi phí • Bài giảng 11 sẽ có thông tin chi tiết hơn  Từ góc nhìn của 1 người dùng cuối: • Không ai thích 1 phần mềm mà sử dụng thì hay bị treo. • Với việc sử dụng nhiều hơn và thường xuyên hơn của phần mềm trong cuộc sống hàng ngày ,chúng ta cần các phần mềm có chất lượng hơn, đáng tin cậy hơn và an toàn hơn.  Kết luận  Phải cần kỹ thuật để tìm các lỗi và đó là mục đích của kiểm thử phần mềm 18 @ ISR-CMU 2010 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Nguồn gốc của các lỗi  Khâu định hướng  Người phát triển không hiểu họ đang làm gì  Thiếu sự đào tạo thích hợp dẫn đến lỗi trong đặc tả, thiết kế , coding và kiếm thử  Khâu kết nối  Người phát triển không đủ hiểu biết và các kiến thức cần thiết.  Thông tin không đạt được ở tất cả các bên liên quan.  Thông tin bị mất.  Khâu giám sát  Bỏ qua những thứ cần thiết 19 @ ISR-CMU 2010 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Lỗi (defect) là gì ? (1)  Định nghĩa về lỗi:  Không có 1 định nghĩa tiêu chuẩn  Các tổ chức khác nhau có những định nghĩa khác nhau.  Những điều được chấp nhận bởi các chuyên gia: 1. Các phần mềm không làm được cái gì đó mà nó nên làm 2. Các phần mềm làm 1 cái gì đó mà đặc tả bảo nó không nền làm 3. Làm cái gì đó mà đặc tả không đề cập đến 4. Các phần mềm không làm 1 cái gì đó mà các đặc điểm kĩ thuật không đề cập đến nhưng lại là nên làm 5. Phần mềm khó hiểu , khó sử dụng , chậm hoặc không đúng 20 @ ISR-CMU 2010 CuuDuongThanCong.com https://fb.com/tailieudientucntt