intTypePromotion=1
zunia.vn Tuyển sinh 2024 dành cho Gen-Z zunia.vn zunia.vn
ADSENSE

Bài giảng Công nghệ phần mềm: Chương 5 - Hoàng Thị Hà

Chia sẻ: Khánh Thành | Ngày: | Loại File: PDF | Số trang:61

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

Bài giảng Công nghệ phần mềm: Chương 5 Kiểm thử phần mềm, cung cấp cho người học những kiến thức như: Kiểm thử là gì; Mục đích (Testing objectives); Nguyên tắc kiểm thử (Testing principles); Các kỹ thuật kiểm thử; Các phương pháp thiết kế test case; Các mức độ (giai đoạn) kiểm thử. Mời các bạn cùng tham khảo!

Chủ đề:
Lưu

Nội dung Text: Bài giảng Công nghệ phần mềm: Chương 5 - Hoàng Thị Hà

  1. Chương 5: Kiểm thử phần mềm (Software testing) GV: Hoàng Thị Hà Email: htha@vnua.edu.vn
  2. Nội dung 1. Kiểm thử là gì 2. Mục đích (Testing objectives) 3. Nguyên tắc kiểm thử (Testing principles) 4. Các kỹ thuật kiểm thử 5. Các phương pháp thiết kế test case – Kiểm thử theo phân vùng tương đương (Equivalence partitioning) – Kiểm thử theo đường cơ bản (Basic path) – Kiểm thử theo giá trị biên (Boundary value analysis) 6. Các mức độ (giai đoạn) kiểm thử 05/10/2018 2
  3. 1. Kiểm thử là gì • “Test chứng tỏ sự có mặt của lỗi, không chứng tỏ rằng không có lỗi.” —Edsger W. Dijkstra • Một lỗi (fault, “defect”, “bug,”) là một phần tử phần cứng hoặc phần mềm có sai sót mà có thể gây sự cố hệ thống • Mục tiêu: Tìm lỗi 05/10/2018 3
  4. “Program testing can be used to show the presence of bugs, but never to show their absence!” Edsgar Dijkstra Notes on Structured Programming, 1970 05/10/2018 4
  5. 2. Mục đích của kiểm thử (Verification,Validation và Testing) • Kiểm chứng (Verification) – có đúng đặc tả không, có đúng thiết kế không – phát hiện lỗi lập trình – Một test thành công là test cho thấy hệ thống hoạt động không đúng • Thẩm định (Validation) – có đáp ứng nhu cầu người dùng không – có hoạt động hiệu quả không – phát hiện lỗi phân tích, lỗi thiết kế (lỗi mức cao) • Test = Verification and Validation – Mục tiêu là phát hiện lỗi PM, đánh giá tính dùng được của PM – Thứ tự thực hiện: Verification -> Validation 05/10/2018 5
  6. 3. Các nguyên tắc kiểm thử • Kiểm thử không phải là gỡ rối (Debugging) • Kiểm thử không bao giờ có thể phát hiện hoàn toàn 100% lỗi • Các phép kiểm thử phải tương ứng với các yêu cầu hệ thống • Mỗi phép kiểm thử nên được lập kế hoạch từ rất sớm trước khi tiến hành kiểm thử 05/10/2018 6
  7. Yêu cầu kiểm thử • Tính lặp lại – kiểm thử phải lặp lại được (kiểm tra xem lỗi đã được sửa hay chưa) – dữ liệu/trạng thái phải mô tả được • Tính hệ thống – đảm bảo kiểm tra hết các trường hợp (coverage) • Được lập tài liệu 05/10/2018 7
  8. Ca kiểm thử (test case) • Một test case (ca kiểm thử) là một lựa chọn cụ thể về input được dùng khi kiểm thử hoạt động của chương trình • Ca kiểm thử tốt • được thiết kế để phát hiện một lỗi của chương trình • Kiểm thử thành công: phát hiện ra lỗi • Mục đích: • − Chứng minh được sự tồn tại của lỗi • − Không chứng minh được sự không có lỗi 05/10/2018 8
  9. Nôi dung của test case 05/10/2018 9
  10. Quy trình kiểm thử phần mềm Dữ liệu Kết quả Test case test test Chạy So sánh Thiết kế các Chuẩn bị chương trình kết quả với test case dữ liệu test với dữ liệu test các test case Báo cáo kiểm thử (test report) 05/10/2018 10
  11. Testing policies Chính sách kiểm thử • Chỉ có kiểm thử toàn diện vét cạn tất cả các trường hợp thực thi (exhaustive testing) mới có thể chứng tỏ rằng một chương trình không có lỗi – Kiểm thử toàn diện là bất khả thi • Thực tế, việc kiểm thử chỉ thực hiện với một tập con của tập tất cả các trường hợp có thể xảy ra. • Chính sách kiểm thử xác định phương pháp chọn các test hệ thống. Ví dụ – Test tất cả các chức năng truy nhập được từ các menu; – Test các tổ hợp chức năng truy nhập được từ cùng một menu; – Ở đầu cần đến input của người dùng, test tất cả các chức năng với cả input sai và input đúng. 05/10/2018 11
  12. 4. Các kỹ thuật kiểm thử chương trình • Kiểm thử chức năng (functional testing) – dựa trên đặc tả chức năng – phát hiện các sai sót về chức năng – không quan tâm đến cách cài đặt • Kiểm thử cấu trúc (structured testing) – kiểm thử có nghiên cứu mã nguồn – phân tích thứ tự thực hiện các lệnh 05/10/2018 12
  13. Kiểm thử chức năng • Functional testing / Black box testing – Dựa trên đặc tả chức năng • Test case được thiết kế để kiểm tra chức năng • Phát hiện các khiếm khuyết so với đặc tả • Không quan tâm đến cách cài đặt (mã nguồn) – Phát hiện sai sót, thiếu sót chức năng – Sai sót về giao diện của mô đun – Kiểm tra tính hiệu quả – Phát hiện lỗi khởi tạo, lỗi kết thúc,… 05/10/2018 13
  14. Kiểm thử cấu trúc • Structural testing / White box testing – Xây dựng ca kiểm thử dựa trên phân tích mã nguồn – Xây dựng bộ test case để kiểm tra mọi dòng lệnh – Phân tích các lệnh rẽ nhánh, vòng lặp – Phù hợp với các mô đun nhỏ – Là sự bổ sung cho kiểm thử chức năng 05/10/2018 14
  15. 5. Các phương pháp thiết kế test case 05/10/2018 15
  16. 5.1. Phân hoạch tương đương • Equivalence partitioning – Không thể kiểm thử mọi trường hợp – Chia dữ liệu thành các miền có cùng hành vi – Tạo một test case cho từng miền – Tạo test case cho biên của các miền • nhiều lỗi xuất hiện với giá trị biên 05/10/2018 16
  17. Partition testing • Input và output thường tập trung thành các nhóm, mỗi nhóm chứa các thành viên có tính chất giống nhau. • Mỗi nhóm đó là một phân hoạch tương đương (equivalence partition) hoặc miền (domain) mà với mỗi điểm trong đó chương trình hoạt động gần như nhau • Cần chọn test case cho từng phân hoạch equivalence partition 05/10/2018 17
  18. Binary search equiv. partitions 05/10/2018 18
  19. Phân hoạch tương đương - Ví dụ 05/10/2018 19
  20. Mở rộng các test case • Tạo test case cho các trường hợp đặc biệt – biên của số trong máy tính • (vd. 32767, -32768) – -số không (0) – số âm, số thập phân – dữ liệu sai kiểu – dữ liệu ngẫu nhiên 05/10/2018 20
ADSENSE

CÓ THỂ BẠN MUỐN DOWNLOAD

 

Đồng bộ tài khoản
2=>2