Nhập môn Công nghệ phần mềm: Chương 3 - Lương Trần Hy Hiến

Chia sẻ: Lê Quang Sáng | Ngày: | Loại File: PPTX | Số trang:59

Thêm vào BST

Báo xấu

136
lượt xem 16
download

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

Nhập môn Công nghệ phần mềm - Chương 3: Chiến lược kiểm thử phần mềm trình bày các nội dung: kiểm tra mức đơn vị (Unit Testing), kiểm tra tích hợp (Integration Testing), kiểm tra mức hệ thống (System Testing), kiểm tra chấp nhận sản phẩm (Acceptance Testing), kiểm tra hồi qui (Regression Testing).

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Nhập môn Công nghệ phần mềm: Chương 3 - Lương Trần Hy Hiến

Kiểm th ử Ph ần m ềm – S o ftware Te s ting Ch ương 3: Chiến lược kiểm th ử ph ần m ềm Lương Trần Hy Hiến, Khoa CNTT, ĐH S ư ph ạm 1
Nội dung • Kiểm tra mức đơn vị (Unit Testing) • Kiểm tra tích hợp (Integration Testing) • Kiểm tra mức hệ thống (System Testing) • Kiểm tra chấp nhận sản phẩm (Acceptance Testing) • Kiểm tra hồi qui (Regression Testing)
3.1 Kiểm th ử đ ơn v ị - Unit Te s t Unit Test là gì? Những Lợi ích từ UT Assert, Mock Object, TDD Công cụ cho Unit Test Demo công cụ 3
Unit Te s t là gì? • Unit Test là kỹ thuật kiểm nghiệm các hoạt động của mọi đơn vị mã nguồn (unit of code) với một quy trình tách biệt với quy trình phát triển phần mềm, giúp phát hiện sai sót kịp thời. • Unit Test là một phần mã nguồn dùng để kiểm tra một phần mã nguồn khác. • Unit Test là kỹ thuật quan trọng trong Test Driven Development.
Unit Te s t là gì? • Unit Test là phương pháp bổ sung cho các phương pháp kiểm thử khác, giúp phát hiện lỗi từ sớm, ngay từ ý tưởng thiết kế (reviews code, walkthroughs…) • Unit Test được viết bởi Developers. Test “White Box”, “Black-Box” trong quá trình PTPM. Các Khái Niệm: § Unit of Code : Mỗi đơn vị mã nguồn có thể là individual program, function, Procedure, class, methods… § White-Box, Black-Box :
Unit Te s t là gì? Unit Test có 3 trạng thái: § Fail (trạng thái lỗi) § Ignore (tạm ngừng thực hiện) § Pas s (trạng thái làm việc đúng)
Th ực hiện UT nh ư th ế nào? Mỗi Unit Test đều được tiết kế theo trình tự: • Thiết lập các điều kiện cần thiết: khởi tạo các đối tượng. • Xác định tài nguyên cần thiết, xây dựng các dữ liệu giả... • Triệu gọi các phương thức cần kiểm tra. • Kiểm tra sự hoạt động đúng đắn của các phương thức. • Dọn dẹp tài nguyên sau khi kết thúc kiểm tra.
How to write a Unit Te s t?
My Unit Te s t is good? § Tự động kiểm tra trạng thái (Pass/False/Ignore). § Đầy đủ (phủ hết các trường hợp). § Tái sử dụng được. § Tính độc lập (very important). § Theo chuẩn code. § Khả năng thực thi nhanh. § Đơn giản để thực hiện. Unit Testing Still Not Mainstream http://www.telerikwatch.com/2008_05_01_archive.html
Lợi íc h từ Unit Te s t Đảm bảo chất lượng từng Unit trong phần mềm. Phát hiện lỗi sớm và chỉnh sửa kịp thời. Giảm chi phí bảo trì và kiểm thử. Dễ tích hợp. Tài liệu hóa. Giúp Thiết Kế.
As s e rt, Moc k Objec t, TDD • AS S ERT – là một macro dùng để phát hiện lỗi của phần mềm trong quá trình phát triển bằng cách thực thi biểu thức trong assert. Dùng assert() để phát hiện ra những bugs do những người lập trình vì vô tình mà gây ra : gọi một hàm với những tham s ố không hợp lệ, sử dụng sai thuật toán, v.v…
Moc k Objec t • Là một đối tượng ảo mô phỏng các tính chất và hành vi giống hệt như đối tượng thực, được dùng để kiểm tra tính đúng đắn của một đơn vị chương trình. • Đơn giản hơn đối tượng thực nhưng vẫn giữ được sự tương tác với các đối tượng khác. – Đảm bảo công việc kiểm nghiệm không bị gián đoạn . – Giúp tiếp cận hướng đối tượng tốt hơn – Giúp phát hiện interface cần tách ở một số lớp. – Dễ dàng cho việc kiểm nghiệm. Thay vì gọi các đối tượng thực vận hành nặng nề, chúng ta có thể gọi các MO đơn giản hơn để kiểm tra nhanh liên kết giữa các thủ tục, công việc kiểm nghiệm có thể tiến hành nhanh hơn.
Te s t Drive n De ve lopme nt • TDD là một chiến lược phát triển sử dụng kỹ thuật UT theo nguyên tắc tạo ra các công đoạn kiểm nghiệm trước khi xây dựng mã.
Lợi íc h Te s t Drive n De ve lopme nt • Định hình ý tưởng thiết kế hơn là kiểm nghiệm mã chương trình. • Lập trình đôi. • Định hướng cho nhóm thiết kế vận dụng tốt các phương pháp hướng đối tượng. ü Loosely-Coupled. ü Highly-Cohesive. • Mã chất lượng và an toàn, tập trung hơn, giảm phân mảnh mã và giảm rủi ro xảy ra ngoài dự kiến.
Công c ụ c ho Unit Te s t
3.2 Kiểm th ử tíc h h ợp • Toàn hệ thống xem như là tập các hệ thống con được xác định trong suốt quá trình thiết kế hệ thống và đối tượng. • Chiến lược kiểm là thứ tự mà các hệ thống con được chọn để kiểm và tích hợp. – Tích hợp Big bang – Tích hợp từ dưới lên – Tích hợp từ trên xuống – Kiểm thử Sandwich – Biến dạng các cách trên • Dùng cách phân rã hệ thống từ bản thiết kế
Dùng m ẫu trung gian c ho phé p kiểm tíc h h ợp s ớm • Dùng mẫu trung gian để cung cấp nhiều cách thực thi dưới 1 giao diện. • Giao diện cho thành phần không hoàn chỉnh, chưa biết hay không thể xài suốt quá trình kiểm. Seat Interface Seat Implementation VIP (in Vehicle Subsystem) Simulated Stub Code Real Seat Seat (SA/RT)
Ví d ụ: Phân c ấp 3 lớp A Layer I B C D Layer II E F G Layer III
3.2.1 Kiểm th ử big bang • Kiểm thử big bang (big bang te s ting) là một chiến lược kiểm thử hệ thống tiến hành một lần duy nhất khi đã phát triển toàn bộ các mô đun và tích hợp thành một phần mềm hoàn chỉnh. • Phương pháp này vẫn thường được tiến hành khi phát triển các phần mềm có kích thước nhỏ.
3.2.1 Kiểm th ử Big-Bang Unit Test A Đừng cố! Unit Test B Unit Test C System Test Unit Test D Unit Test E Unit Test F