Bài 4. các kỹ thuật kiểm thử

BÀI 4. CÁC KỸ THUẬT KIỂM THỬ 4.1. Phân chia lớp tương đương (Equivalence class partitioning) 4.2. Kiểm tra luồng điều khiển (Control flow testing) 4.3. Kiểm tra luồng dữ liệu (Data flow testing) 4.4. Kiểm tra sự giao dịch (Transaction testing) 4.5. Kiểm tra miền (Domain testing) 4.6. Kiểm tra lặp (Loop testing) 4.7. Kiểm tra cú pháp (Syntax testing) 4.8. Kiểm tra trạng thái (State machine testing) 4.9. Kiểm tra khả năng thực thi, chịu tải và vận hành PM (Performance, Load and stress testing) * * 4.1. PHÂN CHIA LỚP TƯƠNG ĐƯƠNG (EQUIVALENCE PARTITIONING) Equivalence partitioning (equivalence class) ) là quá trình làm giảm số lượng các test case nhưng vẫn đảm bảo đạt được hiệu quả tương đương như khi kiểm thử với số lượng các test case cũ Ví dụ về Windows calculator: 1+1, 1+2, 1+3,… => đại diện bởi 1+13 1+ 99999999999999999999999999999999 * * 4.1. PHÂN CHIA LỚP TƯƠNG ĐƯƠNG (EQUIVALENCE PARTITIONING) Equivalence partitioning (equivalence class) là một tập các test case kiểm tra những trường hợp tương tự nhau hoặc để khám phá ra những lỗi tương tự nhau Khi tìm kiếm những equivalence partition: 1 equivalence partition nhóm những dữ liệu đầu vào tương tự nhau, dữ liệu đầu ra tương tự nhau, và những điều khiển tương tự của phần mềm 2 trường hợp, mà phần mềm có cách điều khiển khác nhau, nằm trong 2 equivalence partition khác nhau Nếu tester có kiến thức về lập trình => thuận lợi hơn * * 4.1. PHÂN CHIA LỚP TƯƠNG ĐƯƠNG (EQUIVALENCE PARTITIONING) Ví dụ 1: 5 cách thực hiện copy trong Windows Calculator: Click menu “Edit” => click “copy” Click menu “Edit” => Nhấn “Shift +c” Click menu “Edit” => Nhấn “c” Nhấn “Ctrl + Shift +c” Nhấn “Ctrl + c” Phân làm 3 Equivalence partitioning Thậm chí, là 1 Equivalence partitioning * * 4.1. PHÂN CHIA LỚP TƯƠNG ĐƯƠNG (EQUIVALENCE PARTITIONING) Ví dụ 2: Kiểm tra khả năng đưa một “file name” vào hộp thoại “Save As” chuẩn của Windows: Một filename của Windows của thể chứa các ký tự, ngoại trừ \/ : * ? " | và có thể có từ 1 đến 25 ký tự: (4 EP) Ký tự hợp lý Ký tự không hợp lý Tên với độ dài hợp lý Tên quá ngắn hoặc tên quá dài. * * 4.1. PHÂN CHIA LỚP TƯƠNG ĐƯƠNG (EQUIVALENCE PARTITIONING) Việc phân chia các equivalence partitioning: Mang tính chủ quan Đảm bảo tính khoa học, nhưng không theo khuôn mẫu Chứa đầy rủi ro => tester phải thận trọng Phân các test cases vào các class. Mỗi class là một nhóm các test cases tương tự nhau Trong mỗi class chọn test chỉ một vài test case Nên test nhiều class thay cho test nhiều test cases của cùng một class * * * Tổng kết Các class lại có thể xếp vào 2 nhóm: Positive tests (clean tests): Test dựa trên defined requirements Test những trường hợp, hoàn cảnh sử dụng thông thường Negative tests (dirty tests): Test nhằm tìm ra lỗi Test những trường hợp, hoàn cảnh sử dụng đặc biệt, bất thường (như invalid input, vượt quá trị biên, chịu stress,…) 4.1. PHÂN CHIA LỚP TƯƠNG ĐƯƠNG (EQUIVALENCE PARTITIONING) * * Ví dụ: Phương thức đọc 10 ký tự từ bàn phím Example program: Begin Read (AAAAAAAAAA) Print End Phân chia lớp tương đương như thế nào? 4.1. PHÂN CHIA LỚP TƯƠNG ĐƯƠNG (EQUIVALENCE PARTITIONING) * * Equivalence classes for “positive” tests: All 10 inputs consist of the same character in upper case, repeated for each letter of the alphabet. ALL 10 inputs consist of the same character in lower case, repeated for each letter of the alphabet. All 10 inputs are different, mixed case. Test Cases: TC01 - Input: AAAAAAAAAA TC26 - Input: ZZZZZZZZZZ TC28 - Input: aaaaaaaaaa TC53 - Input: zzzzzzzzzz TC54 - aBcDeFgHiK TC55 - IhGfEdCbAe 4.1. PHÂN CHIA LỚP TƯƠNG ĐƯƠNG (EQUIVALENCE PARTITIONING) Ví dụ: * * Ví dụ: Equivalence classes for “negative” tests: All 10 inputs are numeric. Mixed numeric and alphabetic inputs. Embedded blanks Input consists of one valid character. Input consists of one invalid character. Input includes special characters (*, & %, etc.) Input consists of 11 characters. What would be a correct output for these cases? 4.1. PHÂN CHIA LỚP TƯƠNG ĐƯƠNG (EQUIVALENCE PARTITIONING) * * Control flow testing Là một kỹ thuật testing căn bản Sử dụng sơ đồ luồng xử lý (control flow graph) Đó là sơ đồ mô hình hoá hành vi của hệ thống, chứ không phải là sơ đồ mô tả các câu lệnh trong code Áp dụng được cho hầu hết các phần mềm, và có hiệu quả Áp dụng được trong mọi testing stages 4.2. CONTROL FLOW TESTING * * Sơ đồ luồng xử lý * 4.2. CONTROL FLOW TESTING * Bài tập: Hãy lập sơ đồ mô phỏng hành vi của một hệ thống/kênh bạn cần test Hãy lập sơ đồ mô phỏng hành vi của một tiểu hệ thống/chức năng trong hệ thống đó Hãy lập sơ đồ luồng xử lý đối với một form/item cần test. * 4.2. CONTROL FLOW TESTING * Áp dụng cho các hệ thống “data-intensive” Ví dụ các hệ thống sản sinh báo cáo, thống kê. Ví dụ các hệ thống có tính toán thay đổi số liệu. Phương pháp xây dựng test case: Lập sơ đồ luồng dữ liệu (Data flow diagram) Lần theo từng đường dẫn trong sơ đồ Bắt đầu từ node output Lần ngược lại tới khi gặp node input Ta đã được một test case * 4.3. DATA FLOW TESTING * Áp dụng cho các hệ thống xử lý giao dịch (như đặt vé máy bay, đặt phòng khách sạn, …) Sử dụng mô hình xử lý của hệ thống, chú trọng đến điểm bắt đầu, điểm kết thúc của từng xử lý, chú trọng tới hàng đợi (queue) * 4.4. TRANSACTION TESTING * Áp dụng cho các xử lý mà có xác định phạm vi (range) giá trị dữ liệu Chú trọng test các giá trị biên on và off * 4.5. DOMAIN TESTING Kiểm thử miền là kiểm tra những thông tin mà người sử dụng đưa vào, các kết quả nhận được, và xem xét chúng có đúng không Số lượng test case quá lớn Bí quyết để kiểm thử tốt là: giảm lượng test case bằng equivalence partitioning dựa trên 1 số khái niệm cơ bản: boundary condition sub - boundary condition Null bad data * * 4.5. DOMAIN TESTING Các điều kiện biên (boundary conditions) Các loại điều kiện biên (Types of Boundary Conditions) Kiểm thử những trường hợp biên (Testing the Boundary Edges) Các điều kiên biên con (Sub-Boundary Conditions) Default, Empty, Blank, Null, Zero, và None Invalid, Wrong, Incorrect, và Garbage (vô nghĩa) Data * * 4.5. DOMAIN TESTING Các điều kiện biên (boundary conditions) Nếu phần mềm có thể điều khiển trên những vùng biên => gần như nó sẽ được điều khiển tốt với những điều kiện thông thường Ví dụ: Dim data(10) As Integer Dim i As Integer For i = 1 To 10 data(i) = 1 Next i End * * 4.5. DOMAIN TESTING Các điều kiện biên (boundary conditions) Nếu phần mềm có thể điều khiển trên những vùng biên => gần như nó sẽ được điều khiển tốt với những điều kiện thông thường Ví dụ: Dim data(10) As Integer Dim i As Integer For i = 1 To 10 data(i) = 1 Next i End * * 4.5. DOMAIN TESTING Các loại điều kiện biên (Types of Boundary Conditions) Nhiều điểm mập mờ, chưa rõ ràng => thường nằm trên các giá trị biên Điều kiên biên là trạng thái ở cạnh hay ở những giá trị giới hạn của phần mềm * * 4.5. DOMAIN TESTING Các loại điều kiện biên (Types of Boundary Conditions) Numeric Speed Character Location Position Size Quantity * * 4.5. DOMAIN TESTING Các loại điều kiện biên: để tìm ra các điều kiên biên, tester cần chú ý đến những từ ngữ sau trong bản đặc tả: * * 4.5. DOMAIN TESTING Kiểm thử những trường hợp biên (Testing the Boundary Edges) phân chia tập dữ liệu lộn xộn thành các equivalence partition Phân vùng 1: chứa data mà hi vọng phần mềm làm việc tốt (dữ liệu trong biên) Phân vùng 2: chứ data mà phần mềm dễ phát sinh lỗi (dữ liệu tại 2 đầu của biên) * * 4.5. DOMAIN TESTING Kiểm thử những trường hợp biên Kiểm tra giá trị biên: (thêm, bớt các giá trị max, min 1 đơn vị): First-1/Last+1 Start-1/Finish+1 Less than Empty/More than Full Even Slower/Even Faster Largest+1/Smallest-1 Min-1/Max+1 Just Over/Just Under Even Shorter/Longer Even Sooner/Later Highest+1/Lowest-1 * * 4.5. DOMAIN TESTING Kiểm thử những trường hợp biên. Ví dụ: VD1: Nhập 1 số giới hạn [0-255] VD2: Chương trình đọc và ghi CD-R VD3: Phần mềm cho phép in nhiều trang trên 1 khổ giấy (trong spec mô tả PM có thể in tối đa 8 trang/1 khổ giấy) VD4: Chương trình mô phỏng các chuyến bay * * 4.5. DOMAIN TESTING Các điều kiên biên con (Sub-Boundary Conditions hay internal boundary conditions). Ví dụ: Phần mềm sử dụng ASCII, có 1 testbox cho phép nhập A-Z và a-z * * 4.5. DOMAIN TESTING Default, Empty, Blank, Null, Zero, và None Phần mềm yêu cầu nhập thông tin => người dùng không nhập => Ok => sinh lỗi. Spec thường không mô tả, coder dễ bỏ qua Ví dụ: phần mềm Windows Paint * * 4.5. DOMAIN TESTING Invalid, Wrong, Incorrect, và Garbage (vô nghĩa) Data Sau khi Test – to – pass với các boundary testing, sub-boundary testing, và default testing, tester thấy phần mềm hoạt động tốt Giờ, cần Test – to – fail để tìm ra lỗi với các các invalid, wrong, incorrect, và garbage data. Không có một quy tắc nào cho quá trình kiểm tra này cả, mà tester hãy “to break the software”, “Be creative (sáng tạo)”, “Be devious (láu cá, xảo quyệt)”. Rất thú vị! * * 4.5. DOMAIN TESTING * Áp dụng trong whitebox testing: quan tâm đến vòng lặp trong code Áp dụng trong backbox testing: quan tâm đến vòng lặp trong hành vi của hệ thống Ví dụ khi hệ thống phải tìm ra tất cả các bản ghi thoả mãn một tiêu chí tìm kiếm nào đó Giả sử khả năng hệ thống có thể hỗ trợ tối đa Max vòng lặp, chỉ cần chọn thực hiện những test case sau là đủ: 0 lần, 1 lần, 2 lần qua vòng lặp X lần (X: số ngẫu nhiên, giữ khoảng 0 và Max) Max -1, Max, Max+1 lần * 4.6. LOOP TESTING * Là kỹ thuật dùng để: Test các câu lệnh (commands) Test việc xử lý các trường phải tuân theo một định dạng xác định Ví dụ về syntax: Ngày tháng Địa chỉ email Công thức toán học do NSD định nghĩa … * 4.7. SYNTAX TESTING * Trình tự thực hiện: Phân tích, nắm rõ qui tắc syntax Thiết kế các positive test cases, sử dụng kỹ thuật Equivalence class partitioning Thiết kế các negative test Mỗi lần làm sai một phần tử trong syntax Thực hiện test * 4.7. SYNTAX TESTING * Áp dụng khi: Test các “menu driven application” Test các hệ thống thiết kế bằng phương pháp hướng đối tượng Test bất cứ hệ thống nào có sơ đồ chuyển đổi trạng thái (state) Ví dụ về trạng thái: Account sử dụng Portal chưa có hiệu lực (inactive account) Account sử dụng Portal có hiệu lực (active account) * 4.8. STATE MACHINE TESTING * Đặc trưng của trạng thái: Ở mỗi trạng thái, có một số hành động được phép thực hiện và một số khác thì không Phương pháp: Vẽ một sơ đồ chuyển đổi trạng thái cho đối tượng cần test Positive tests: thiết kế test cases cho từng lần chuyển đổi trạng thái Negative tests: thiết kế các test cases nhằm cố chuyển đổi trạng thái một cách bất hợp lệ * 4.8. STATE MACHINE TESTING Kiểm tra luồng dữ liệu logic của phần mềm (Testing the Software's Logic Flow) Tạo một bản đồ chuyển trạng thái (Creating a State Transition Map) Làm giảm số lượng các trạng thái và sự chuyển trạng thái để kiểm tra (Reducing the Number of States and Transitions to Test) Những gì cần được kiểm tra trong bản đặc tả (What to Specifically Test) Kiểm thử trạng thái để phát hiện lỗi (Testing States to Fail) * * 4.8. STATE MACHINE TESTING Kiểm tra luồng dữ liệu logic của phần mềm: Để kiểm tra luồng logic, tester phải tới thăm tất cả các state bằng mọi path Trừ những chương trình rất đơn giản, tester không thể thực hiện được tất cả các path để đi tới tất cả các state Ví dụ: bài toán nổi tiếng: “đi du lịch tới các thành phố” Áp dụng kỹ thuật equivalence partition để lựa chọn các state và các path 1 cách thông minh => hạn chế tối đa sự rủi ro * * 4.8. STATE MACHINE TESTING Tạo một bản đồ chuyển trạng thái: Trước tiên, tạo một sơ đồ chuyển trạng thái của phần mềm => coi là một phần của bản đặc tả phần mềm Thực hiện test sơ đồ này bằng kỹ thuật statically test * * 4.8. STATE MACHINE TESTING Tạo một bản đồ chuyển trạng thái: Sơ đồ trạng thái (Transition Map) mô tả các nội dung sau: Tập các trạng thái của phần mềm Điều kiện để chuyển từ trạng thái này đến trạng thái tiếp theo Tập các điều kiện và thủ tục output khi đi vào hoặc đi ra một trạng thái * * 4.8. STATE MACHINE TESTING Làm giảm số lượng các trạng thái và sự chuyển trạng thái: Kiểm tra mọi path, mọi state chỉ thực hiện được khi tester có thời gian vô tận Thực tế, tester chỉ phải kiểm tra 1 bộ phận của phần mềm * * 4.8. STATE MACHINE TESTING Làm giảm số lượng các trạng thái và sự chuyển trạng thái: Ngoài kỹ thuật equivalence partitioning cho data, còn áp dụng kỹ thuật này cho các state: Tới thăm mỗi state ít nhất 1 lần Kiểm tra sự chuyển từ trạng thái state – to - state chung nhất và phổ biến nhất Hãy kiểm tra những path thông dụng nhất giữa các state Hãy tìm tất cả các trạng thái lỗi và quay trở lại từ các lỗi này Kiểm tra sự chuyển trạng thái một cách ngẫu nhiên * * 4.8. STATE MACHINE TESTING Những gì cần được kiểm tra trong bản đặc tả : Ví dụ 1: danh sách các state variable trong trạng thái khởi động của Paint: Cỡ của cửa sổ được thiết đặt khi vừa mở Windows Paint. Vùng để vẽ là trống Tool box, color box và thanh trạng thái được hiển thị Chỉ công cụ pencil được lựa chọn Màu mặc định: foreground là black và background là white Tên mặc định của picture là untitled Một số đặc điểm chưa có trong spec thì tester bổ sung và trao đổi với coder và người viết bản đặc tả * * 4.8. STATE MACHINE TESTING Những gì cần được kiểm tra trong bản đặc tả : Ví dụ 2: the dirty document flag – cờ báo trạng thái dữ liệu. Yêu cầu: Trước tiên, phần mềm load dữ liệu (ảnh, văn bản…) vào chương trình => tài liệu ở trạng thái “clear state” => đóng lại bình thường Thực hiện thao tác sửa tài liệu => tài liệu ở trạng thái “dirty state” => đóng lại => nhắc ghi lại tài liệu Chỉnh sửa => trạng thái “dirty” => undo => trạng thái “clear” => đóng lại => không có lời nhắc * * 4.8. STATE MACHINE TESTING Kiểm thử trạng thái để phát hiện lỗi Race Conditions và Bad Timing: Các hệ điều hành có thể thực thi đa nhiệm (multitasking) Nếu có 2 hoặc nhiều hơn các sự kiện làm rối loạn chương trình => race condition Phần mềm không thể ngắt giữa các điều khiển của nó khi thực thi đa nhiệm => bad timing * * 4.8. STATE MACHINE TESTING Kiểm thử trạng thái để phát hiện lỗi Race Conditions và Bad Timing: Một số ví dụ về Race Conditions: Save và load cùng một tài liệu tại một thời điểm với 2 chương trình khác nhau Chia sẻ cùng máy in, cổng giao tiếp, hoặc thiết bị ngoại vi khác Nhấn phím và kích chuột trong khi phần mềm đang load hoặc thay đổi trạng thái Shutting down hoặc starting up 2 hoặc nhiều hơn các instances (trường hợp) của phần mềm tại cùng một thời điểm. Sử dụng những chương trình khác để đồng thời truy cập vào cơ sở dữ liệu chung (common database) * * 4.8. STATE MACHINE TESTING * Performance testing: nhằm xác định tốc độ, khả năng phân tải và mức độ tin tưởng của PM trong môi trường nhiều người dùng, hoặc có nhiều hoạt động đồng thời. Từ đó đưa ra kết luận ứng dụng hoạt động tốt nhất trong điều kiện nào.Ví dụ: Xác định giới hạn số lượng truy cập đồng thời của 1 website Xác định giới hạn số lượng giao dịch đồng thời trên phần mềm Xác định giới hạn khả năng xử lý đồng thời của phần mềm * 4.9. PERFORMANCE, LOAD, STRESS TESTING * Load testing: bắt hệ thống phải chịu tải lớn (thực hiện nhiều xử lý), ví dụ: Có nhiều client cùng lúc truy cập Có nhiều giao dịch cùng một lúc Xử lý file rất lớn Xử lý cùng lúc nhiều file * 4.9. PERFORMANCE, LOAD, STRESS TESTING * Stress testing: bắt hệ thống vận hành trong điều kiện bất thường, ví dụ: Thiếu bộ nhớ Kết nối mạng bị ngắt khi đang vận hành Database server down Nhiều giao dịch thực hiện đồng thời trong 1 thời gian dài * 4.9. PERFORMANCE, LOAD, STRESS TESTING BÀI 4. TỔNG KẾT Chương này cung cấp 1 số kỹ thuật rất cơ bản được áp dụng thường xuyên trong quá trình kiểm thử phần mềm * * BÀI 4. CÂU HỎI Khởi động Windows WordPad/Print. Trong Print range đâu là những điều kiện biên? * * BÀI 4. CÂU HỎI Giả sử rằng bạn có một textbox điền ZIP code có độ rộng10 ký tự số, như biểu diễn trong hình dưới. Bạn sẽ tạo những phân vùng tương đương nào cho textbox nào? Tester phải đến thăm tất cả các trạng thái mà một chương trình phải đảm bảo bằng cách chuyển đổi giữa các trạng thái đó. Điều này đúng hay sai? * * BÀI 4. CÂU HỎI Lấy ví dụ về những hành động thực hiện trên phần mềm khi bạn cố gắng để phơi bày các lỗi race condition? So sánh performance test, load test, stress test? * *