Kiểm định phần mềm - Chiến lược kiểm thử

*ThS Nguyễn Quốc Huy*Chiến lược kiểm thửKhoa CNTT – ĐH Sài GònChiến lược kiểm thử tích hợpToà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 bangTích hợp từ dưới lênTích hợp từ trên xuốngKiểm thử SandwichBiến dạng các cách trênDù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ớmDù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.VIPSeat Interface(in Vehicle Subsystem)Seat ImplementationStub CodeReal SeatSimulatedSeat (SA/RT)Ví dụ: Phân cấp 3 lớpABCDGFELayer ILayer IILayer IIIKiểm tích hợp: Hướng Big-BangUnit Test FUnit Test EUnit Test DUnit Test CUnit Test BUnit Test ASystem TestĐừng cố!Chiến lược từ dưới lênHệ thống con ở lớp thấp nhất trong phân cấp được kiểm riêng lẻ.Sau đó các hệ thống con tiếp theo được kiểm thì gọi các hệ thống con được kiểm trước đó.Việc này thực hiện lập đi lặp lại cho đến khi tất cả các hệ thống con được kiểm.Chương trình đặc biệt cần để kiểm, Test Driver: Lộ trình gọi một hệ thống con và vượt qua test case của nóSeatDriver(simulates VIP)Seat Interface(in Vehicle Subsystem)Seat ImplementationStub CodeReal SeatSimulatedSeat (SA/RT)Tích hợp từ dưới lênABCDGFELayer ILayer IILayer IIITest FTest ETest GTest CTest D,GTest B, E, FTest A, B, C, D,E, F, GKhi nào dùng chiến lược từ dưới lênKhô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ùngHữu dụng để tích hợp cho các hệ thống sau:Các hệ thống hướng đối tượngCác hệ thống thời gian thựcCác hệ thống có yêu cầu việc thực thi nghiêm ngặtChiến lược từ trên xuốngKiểm tầng trên cùng hay hay các hệ thống con quan trọng trướcRồi kết nối tất cả các hệ thống con đã được kiểm và kiểm tập kết quả các hệ thống con.Thực hiện cho đến khi kiểm tất cả các hệ thống con được kết hợp.Chương trình đặc biệt cần để kiểm, Test stub :Chương trình hay là phương pháp giả lập hoạt động của hệ thống con bị thiếu bằng cách trả lời một loạt lời gọi hệ thống con và trả về dữ liệu giả.Kiểm từ trên xuốngABCDGFELayer ILayer IILayer IIITest ALayer ITest A, B, C, DLayer I + IITest A, B, C, D,E, F, GAll LayersKhi nào dùng chiến lược từ trên xuốngTest 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.Chiến lược SandwichKết hợp từ trên xuống và từ dưới lênHệ thống xem như có 3 lớp:Lớp mục tiêu ở giữaLớp trênLớp dướiKiểm thử tập trung vào lớp giữaNế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à driversChiến lược SandwichABCDGFELayer ILayer IILayer IIITest ETest D,GTest B, E, FTest A, B, C, D,E, F, GTest FTest GTest ABottomLayerTestsTopLayerTestsTest A,B,C, DKhi nào dùng SandwichThự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 SandwichKiểm song song:Lớp giữa với drivers và stubsLớp trên với stubsLớp dưới với driversKiể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 SandwichABCDGFELayer ILayer IILayer IIITest FTest ETest BTest GTest DTest ATest CTest B, E, FTripleTest ITripleTest ITest D,GDoubleTest IIDoubleTest IIDoubleTest IDoubleTest ITest A,CTest A, B, C, D,E, F, GLập lịch kiểm Sandwich: Ví dụUnit TestsDouble TestsTriple TestsSystemTestsCá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étKhối lượng stubs &driversXác định các phần quan trọng trong hệ thốngKhả năng phần cứngKhả năng các thành phầnSắp xếp các mối quan tâmHướng từ dưới lênPhù 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ốngTest 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.Kiểm thử hệ thốngKiểm thử chức năngKiểm thử cấu trúcKiểm thử hiệu suấtKiểm thử chấp nhậnKiểm thử cài đặtẢ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úcGiố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ốngThử 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 đenMục tiêu: Kiểm chức năng của hệ thốngTest 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ấtStress TestingStress limits of system (maximum # of users, peak demands, extended operation)Volume testingTest what happens if large amounts of data are handledConfiguration testingTest the various software and hardware configurations Compatibility testTest backward compatibility with existing systemsSecurity testingTry to violate security requirementsTiming testingEvaluate response times and time to perform a functionEnvironmental testTest tolerances for heat, humidity, motion, portabilityQuality testingTest reliability, maintain- ability & availability of the systemRecovery testingTests system’s response to presence of errors or loss of data.Human factors testingTests user interface with userTest 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 conKiể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ớnNế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 nhauAcceptance TestingMục tiêu: Hệ thống sẵn sàng sử dụngKhách hàng thực hiệnCó thể thực hiện ở giai đoạn tích hợpLậ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ựcKhách hàng tiềm năng có thể không hài lòngKiểm thử có chu kì sống riêng của nóThiết lập các mục tiêu kiểmThiết kế test casesViết test casesKiểm test casesThực thi the testsĐánh giá các kết quả kiểmThay đổi hệ thốngThực hiện kiểm hồi quiĐội TestTestAnalystTeamUserProgrammertoo familiarwith codeProfessionalTesterConfiguration ManagementSpecialistSystem DesignerTóm tắtKiể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 testingCá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ó.