Kiểm thử Phần mềm – Software Testing Chương 3: Chiến lược kiểm thử phần mềm

Click to edit Master text styles Second level Third level Fourth level Fifth level ‹#› Click to edit Master title style 1 Kiểm thử Phần mềm – Software TestingChươ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 TpHCM 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 Test 3 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ụ Unit Test 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 Test 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 Test 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) Pass (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 Test? My Unit Test 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 Lợi ích từ Unit Test Đả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ế. Assert, Mock Object, TDD ASSERT 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… Mock Object 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. Test Driven Development 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 ích Test Driven Development Đị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ụ cho Unit Test 3.2 Kiểm thử tích 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 cho phép kiểm tích 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. VIP Seat Interface (in Vehicle Subsystem) Seat Implementation Stub Code Real Seat Simulated Seat (SA/RT) Ví dụ: Phân cấp 3 lớp A B C D G F E Layer I Layer II Layer III 3.2.1 Kiểm thử big bang Kiểm thử big bang (big bang testing) 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 F Unit Test E Unit Test D Unit Test C Unit Test B Unit Test A System Test Đừng cố! 3.2.2 Kiểm thử dưới lên Là quá trình tích hợp và kiểm thử với các mô đun ở mức độ thấp trước. Thông thường người ta không thuần túy kiểm thử tất cả các mô đun ở tầng dưới cùng mà nhóm các mô đun này thành các nhóm chức năng, tích hợp và kiểm thử chúng theo từng nhóm. Tiến hành tích hợp và kiểm thử một số mô đun cấp trên trước 3.2.2 Kiểm thử dưới lên VD: A B C D E F K Nhóm chức năng G H I 3.2.2 Kiểm thử dưới lên A B C D G F E Layer I Layer II Layer III Test F Test E Test G Test C Test D,G Test B, E, F Test A, B, C, D, E, F, G 3.2.2 Kiểm thử dưới lên Kiểm thử dưới lên có một số ưu điểm: Tránh phải tạo các stub phức tạp hay tạo các kết quả nhân tạo Thuận tiện cho phát triển các mô đun thứ cấp dùng lại được Nhược điểm của phương pháp bottom-up: Phát hiện chậm các lỗi thiết kế Chậm có phiên bản thực hiện được của hệ thống Khi nào cần dùngchiến lược từ dưới lên Không tốt cho các hệ thống phân rã theo chức năng: Kiểm thử hệ thống con quan trọng nhất sau cùng Hữu dụng để tích hợp cho các hệ thống sau: Các hệ thống hướng đối tượng Các hệ thống thời gian thực Các hệ thống có yêu cầu việc thực thi nghiêm ngặt 3.2.3 Kiểm thử trên xuống Kiểm thử trên xuống tiến hành kiểm thử với các mô đun ở mức cao trước, các mô đun mức thấp được tạm thời phát triển với các chức năng hạn chế. Thông thường, để sớm có một phiên bản thực hiện người ta thường tích hợp theo một nhánh cho đến các mô đun cấp thấp nhất. 3.2.3 Kiểm thử trên xuống VD: A B C D E F G 3.2.3 Kiểm thử trên xuống A B C D G F E Layer I Layer II Layer III Test A Layer I Test A, B, C, D Layer I + II Test A, B, C, D, E, F, G All Layers Ưu điểm Kiểm thử trên xuống Ưu điểm của kiểm thử trên xuống Phát hiện sớm các lỗi thiết kế Có phiên bản hoạt động sớm Nhược điểm của kiểm thử trên xuống Khó có thể mô phỏng được các chức năng của mô đun cấp thấp phức tạp Không kiểm thử đầy đủ các chức năng Trên thực tế người ta thường tìm cách phối hợp hai chiến lược này, gọi là sandwich testing Khi nào cần dùng kiểm thử từ trên xuống Test cases có thể được định nghĩa dưới dạng chức năng hệ thống (yêu cầu chức năng) Viết stubs có thể khó: Stubs phải cho phép tất cả điều kiện có thể xảy ra được kiểm. Có thể cần số lượng rất lớn stubs, đặc biệt nếu lớp thấp nhất của hệ thống chứa nhiều phương pháp. Một giải pháp để tránh quá nhiều stubs: Điều chỉnh chiến lược từ trên xuống. Kiểm mỗi tầng của hệ thống trước khi trộn các tầng. Khuyết điểm của kiểm thử từ trên xuống có điều chỉnh: Cả hai, stubs và drivers đều cần. 3.2.4 Kiểm thử Sandwich Kết hợp từ trên xuống và từ dưới lên Hệ thống xem như có 3 lớp: Lớp mục tiêu ở giữa Lớp trên Lớp dưới Kiểm thử tập trung vào lớp giữa Nếu có hơn 3 lớp thì lớp giữa là lớp nào? Mẹo: Cố gắng cực tiểu hoá số stubs và drivers Chiến lược Sandwich A B C D G F E Layer I Layer II Layer III Test E Test D,G Test B, E, F Test A, B, C, D, E, F, G Test F Test G Test A Bottom Layer Tests Top Layer Tests Test A,B,C, D Khi nào dùng Sandwich Thực hiện song song lớp Trên và Dưới. Không kiểm các lớp con riêng lẻ kỹ trước khi tích hợp. Giải pháp: Điều chỉnh chiến lược sandwich Điều chỉnh chiến lược Sandwich Kiểm song song: Lớp giữa với drivers và stubs Lớp trên với stubs Lớp dưới với drivers Kiểm song song: Tầng trên truy xuất tầng giữa (lớp trên thay drivers) Tầng giữa truy xuất tầng dưới (lớp dưới thay stubs) Điều chỉnh chiến lược Sandwich A B C D G F E Layer I Layer II Layer III Test F Test E Test B Test G Test D Test A Test C Test B, E, F Triple Test I Triple Test I Test D,G Double Test II Double Test II Double Test I Double Test I Test A,C Test A, B, C, D, E, F, G Lập lịch kiểm Sandwich: Ví dụ Unit Tests Double Tests Triple Tests SystemTests Các bước kiểm tích hợp . 1. Dựa trên chiến lược tích hợp, chọn một thành phần để kiểm. Kiểm đơn vị tất cả các lớp trong thành phần. 2. Đặt thành phần được chọn vào với nhau; thực hiện bất cứ sự sắp đặt sơ bộ cần thiết để kiểm thử tích hợp chức năng (drivers, stubs) 3. Thực hiện kiểm thử chức năng: Định nghĩa test cases thuộc tất cả uses cases với thành phần được chọn. 4. Thực hiện kiểm cấu trúc: Định nghĩa test cases thuộc thành phần được chọn. 5. Thi hành kiểm thử công suất. 6. Giữ các hồ sơ của test cases và các hoạt động kiểm thử. 7. Lặp các bước 1 đến 7 cho đến khi toàn hệ thống được kiểm. Mục tiêu nguyên thuỷ của kiểm tích hợp là xác định lỗi trong cấu hình thành phần hiện hành. Chiến lược tích hợp nào nên dùng? Các yếu tố xem xét Khối lượng stubs &drivers Xác định các phần quan trọng trong hệ thống Khả năng phần cứng Khả năng các thành phần Sắp xếp các mối quan tâm Hướng từ dưới lên Phù hợp cho các phương pháp thiết kế hướng đối tượng. Các giao diện driver kiểm thử phải khớp các giao diện thành phần. Các thành phần ở tầng trên thường quan trọng và không thể xem thường vào giai đoạn cuối của việc kiểm thử. Dò tìm các lỗi thiết kế được hoãn lại ở cuối giai đoạn kiểm thử. Hướng từ trên xuống Test cases có thể được định nghĩa theo các chức năng đang xét. Cần duy trì tính đúng đắn của test stubs Viết stubs có thể khó khăn. 3.3 Kiểm thử hệ thống Kiểm thử chức năng Kiểm thử cấu trúc Kiểm thử hiệu suất Kiểm thử chấp nhận Kiểm thử cài đặt 3.3 Kiểm thử hệ thống Ảnh hưởng của yêu cầu đối với kiểm thử hệ thống: Yêu cầu càng tường minh, càng dễ kiểm thử. Chất lượng use cases xác định độ dễ của kiểm thử chức năng. Chất lượng việc phân rã các hệ thống con xác định độ dễ của kiểm cấu trúc. Chất lượng các yêu cầu phi chức năng và các ràng buộc xác định độ dễ của kiểm thử hiệu suất: Kiểm thử cấu trúc Giống với kiểm hộp trắng. Mục tiêu: Phủ tất cả các đường trong thiết kế hệ thống Thử tất cả các tham số đầu vào và đầu ra của thành phần. Thử tất cả các thành phần và tất cả lời gọi hàm (mỗi thành phần được gọi ít nhất 1 lần và mọi thành phần được gọi bởi tất cả các nơi có thể gọi.) Dùng kiểm thử điều kiện và lặp như trong unit testing. Kiểm chức năng . . Giống như kiểm hộp đen Mục tiêu: Kiểm chức năng của hệ thống Test cases được thiết kế từ tài liệu phân tích yêu cầu (tốt hơn là: tài liệu hướng dẫn sử dụng) và tập trung vào các yêu cầu xung quanh và các chức năng cơ bản (use cases) Hệ thống được xử lý như hộp đen. Unit test cases có thể tái sử dụng, nhưng người dùng cuối hướng đến test cases mới cũng được. Kiểm thử năng suất Stress Testing Stress limits of system (maximum # of users, peak demands, extended operation) Volume testing Test what happens if large amounts of data are handled Configuration testing Test the various software and hardware configurations Compatibility test Test backward compatibility with existing systems Security testing Try to violate security requirements Timing testing Evaluate response times and time to perform a function Environmental test Test tolerances for heat, humidity, motion, portability Quality testing Test reliability, maintain- ability & availability of the system Recovery testing Tests system’s response to presence of errors or loss of data. Human factors testing Tests user interface with user Test Cases cho kiểm thử năng suất Đưa hệ thống đã tích hợp vào đúng giới hạn. Mục tiêu: Cố gắng phá hệ thống con Kiểm tra hệ thống xử lý thế nào khi quá tải. Thử thứ tự thi hành khác thường Gọi receive() trước send() Kiểm tra phản ứng của hệ thống trước khối lượng dữ liệu lớn Nếu hệ thống có thể kiểm soát 1000 mục, thử 1001 mục. Xét thời gian thực hiện trong các use case khác nhau Acceptance Testing Mục tiêu: Hệ thống sẵn sàng sử dụng Khách hàng thực hiện Có thể thực hiện ở giai đoạn tích hợp Lập trình viên không kiểm thử ở giai đoạn này. Phần lớn các bugs trong phần mềm do khách hàng tìm thấy sau khi hệ thống đưa vào sử dụng. Vì vậy có 2 loại kiểm ở giai đoạn này: Alpha test: Khách hàng kiểm ngay tại nơi viết phần mềm. Lập trình viên sẵn sàng fix bugs khi tìm thấy. Beta test: Khách hàng xài thử Phần mềm đang ở trong môi trường thực Khách hàng tiềm năng có thể không hài lòng Kiểm thử có chu kì sống riêng của nó Thiết lập các mục tiêu kiểm Thiết kế test cases Viết test cases Kiểm test cases Thực thi the tests Đánh giá các kết quả kiểm Thay đổi hệ thống Thực hiện kiểm hồi qui Đội Test Test Analyst Team User Programmer too familiar with code Professional Tester Configuration Management Specialist System Designer 3.4. Kiểm tra chấp nhận Mục tiêu Xác nhận từ phía ngườisửdụng Điềukiện Kiểm tra hồi hệ thống và hồi quy hoàn tất Người Quản lý cấu hình Test data Tài liệuhướng dẫncuối cùng đã sẵn sàng Đã xét các thủ tục kiểm thử Điều kiện thoát Các thủ tục đặc biệt Tiêu chuẩn chấp nhận phải được lập tài liệu Acceptance Testing Người chịu trách nhiệm 48 3.4. Kiểm tra chấp nhận 49 3.4. Kiểm tra chấp nhận Kỳ vọng: Xác nhận từ phía ngườ isử dụng Kiểm tra thực thi được đánh giá lại Kéo dài thời gian Hướng dẫn cho người kiểm thử Các yêu cầu không có khả năng kiểm thử Rà soát bởi người tài trợ và NSD Kế hoạch cho việc hiện thực 50 3.5 Kiểm tra hồi quy Regression Test 51 3.5. Kiểm tra hồi qui Tiến trình kiểm tra lại PM sau khi đã sửa chữa chương trình. Regression test có thể thực hiện tại mọi mức kiểm tra. 52 3.5. Kiểm tra hồi qui Mục đích: Định vị lỗi ‰Gia tăng tin cậy tính đúng chương trình ‰Bảo đảm chất lượng ‰Bảo đảm hoạt động liên tục ‰Kiểm tra tính đúng đắn của “phần mới” ‰Đảm bảo các phần không được sửa thực hiện vẫn đúng. 53 3.5. Kiểm tra hồi qui – Ví dụ Một PM đang phát triển khi kiểm tra nó chạy tốt các chức năng A, B và C. Thay đổi code của chức năng C: Nếu chỉ kiểm tra chức năng C thì chưa đủ, cần phải kiểm tra lại tất cả các chức năng khác liên quan đến chức năng C (A, B). Lý do là khi C thay đổi, nó có thể sẽ làm A và B không còn làm việc đúng nữa. 54 3.5. Kiểm tra hồi qui Rất tốn nhiều thời gian và công sức. Không được phép bỏ qua vì có thể dẫn đến tình trạng phát sinh hoặc tái xuất hiện những lỗi nghiêm trọng, mặc dù ta “tưởng rằng” những lỗi đó hoặc không có hoặc đã được kiểm tra và sửa chữa rồi. 55 Tóm tắt Kiểm thử vẩn là ma thuật, nhưng có nhiều luật và mẹo có thể dùng được. Kiểm thử bao gồm unit testing, integration testing và system testing Các mẫu thiết kế (Design Patterns) có thể được dùng để kiểm tích hợp. Kiểm thử có chu kì sống riêng của nó. Cảm ơn Bài giảng này tham khảo và hiệu chỉnh từ: Slide Kiểm định Phần mềm, Nguyễn Quốc Huy, ĐH Sài Gòn. Slide Lý thuyết Kiểm tra Phần mềm, Nguyễn Ngọc Tú, ĐH Hoa Sen Slide Kiểm chứng Phần mềm, Lê Duy Hoàng, ĐH KHTN TpHCM. 57 Câu hỏi và thảo luận ? Thank you!!!