1 / 101

TESTING OVERVIEW

TESTING OVERVIEW. Người trình bày: Tô Lan Phương Phòng: PQA. Mục tiêu. Sau buổi seminar này, các thành viên tham dự cùng nắm được:. Mục đích và vị trí của testing trong toàn bộ chu trình phát triển phần mềm. Vai trò của các tester và nhóm tester độc lập Qui trình test. Các giai đoạn test.

ingo
Download Presentation

TESTING OVERVIEW

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. TESTING OVERVIEW Người trình bày: Tô Lan Phương Phòng: PQA

  2. Mục tiêu Sau buổi seminar này, các thành viên tham dự cùng nắm được: • Mục đích và vị trí của testing trong toàn bộ chu trình phát triển phần mềm. • Vai trò của các tester và nhóm tester độc lập • Qui trình test. • Các giai đoạn test. • Các phương pháp, kỹ thuật test trong từng giai đoạn test được áp dụng. • Vòng đời của 1 lỗi. • Bugs tracking (sử dụng testtrackpro). • Các tài liệu test cần có. Tài liệu đào tạo nội bộ

  3. Nội dung • Testing overview. • Mô hình chữ V. • Vai trò của các tester. • Các khái niệm phân loại test. • Mô tả và phân loại lỗi (sử dụng TestTrackPro). • Vòng đời của lỗi. • Cách lập các testcase từ các usecase. • Thực hiện test và test thế nào cho đủ. • Các tài liệu test cần có. Tài liệu đào tạo nội bộ

  4. 1. Mục đích của testing • Testing là gì? • Testing là quá trình chạy thử một chương trình nhằm tìm ra lỗi. • Khi nào ta nói: “Lỗi!”? Tài liệu đào tạo nội bộ

  5. 1. Mục đích của testing (tiếp) • Mục đích của Testing? • Để tìm lỗi! • Testing có thể chứng minh sự có mặt của lỗi, nhưng không thể chứng minh được điều gì? • Testing không thể chứng minh sự vắng mặt của lỗi! Tài liệu đào tạo nội bộ

  6. 1. Mục đích của testing (tiếp) • Vậy test để làm gì? • Để chứng minh phần mềm hoạt động được? • Để chứng minh phần mềm không hoạt động? • Không để chứng minh điều gì cả, chỉ để làm giảm khả năng phần mềm không hoạt động tới mức chấp nhận được? • Testing không phải là việc làm đơn giản. Testing là một nghề đòi hỏi trí tuệ, nhằm đem lại: • Một phần mềm ít rủi ro • Mà không tốn quá nhiều công sức cho việc test Tài liệu đào tạo nội bộ

  7. 1. Mục đích của testing (tiếp) • Đặc điểm của testing? • Phải giả định là có lỗi! • Lấy mục tiêu là lỗi phần mềm, chứ không phải là chỉ ra phần mềm đang hoạt động đúng. • Không bao giờ chứng tỏ được rằng phần mềm không còn lỗi. • Bản thân việc test không nâng cao chất lượng phần mềm. Để nâng cao chất lượng phần mềm, cần phát triển tốt hơn, thay vì test nhiều hơn! Tài liệu đào tạo nội bộ

  8. 1. Mục đích của testing (tiếp) • Cái khó của testing là gì? • Là biết khi nào thì dừng lại! • Là quyết định thực hiện những test case nào cho hiệu quả! • Thuật ngữ: • Test case: là một tập hợp các giá trị đầu vào, các điều kiện thực hiện, và các kết quả mong muốn; nhằm test phần mềm. • Test case hiệu quả: là test case khi thực hiện thì đem lại lỗi! Tài liệu đào tạo nội bộ

  9. Tóm tắt nội dung 1 • Testing là săn tìm lỗi. • Testing là để đảm bảo phần mềm “đủ tốt”, với ràng buộc công sức test không quá lớn, và nhiều ràng buộc khác. • Tester phải biết tưởng tượng, chọn lọc, sắp xếp các test case,… • Làm Tester là một nghề đầy thách thức. Tài liệu đào tạo nội bộ

  10. Nội dung • Testing overview. • Mô hình chữ V. • Vai trò của các tester. • Các khái niệm phân loại test. • Mô tả và phân loại lỗi (sử dụng TestTrackPro). • Vòng đời của lỗi. • Cách lập các testcase từ các usecase. • Thực hiện test và test thế nào cho đủ. • Các tài liệu test cần có. Tài liệu đào tạo nội bộ

  11. Install Software V&V Plan Project Plan Acceptance Demonstration Plan Acceptance Demonstration Requirements Spec System Test Plan System Test Integration Test Plan Architectural Design Spec Integration Test Unit Test Plan Detailed Design Spec Unit Test Code 2. Mô hình chữ V Software Development Phases Test Planning Phase Test Execution Phase Theo “Strategies for Effective Software Testing”, Jessee Ring, Software Quality First liên kết với Alliant, tháng 8/2004 Tài liệu đào tạo nội bộ

  12. 2. Mô hình chữ V (tiếp) Testing, cũng như bất kỳ việc gì khác: • Phải bắt đầu bằng xác định mục tiêu • Phải có kế hoạch. • Tester nên được tham gia/thông tin về phần mềm ngay từ đầu. • Test plan được lập càng sớm càng tốt. • Sẽ là quá muộn nếu lập test plan khi phần mềm đã ra lò. Tài liệu đào tạo nội bộ

  13. Nội dung • Testing overview. • Mô hình chữ V. • Vai trò của các tester. • Các khái niệm phân loại test. • Mô tả và phân loại lỗi (sử dụng TestTrackPro). • Vòng đời của lỗi. • Cách lập các testcase từ các usecase. • Thực hiện test và test thế nào cho đủ. • Các tài liệu test cần có. Tài liệu đào tạo nội bộ

  14. 3. Vai trò của các tester • 3.1. Vai trò của nhóm tester độc lập • 3.2. Tổ chức nhóm tester theo dự án • 3.3. Vai trò của test leader • 3.4. Vai trò của tester thành viên Tài liệu đào tạo nội bộ

  15. 3.1. Vai trò của nhóm tester độc lập • Tự test code của mình: không hiệu quả! • Tester cần được độc lập với nhóm phát triển. • Tester cần được quản lý theo “ngành dọc” • Nhóm tester độc lập: • Tổ chức, bố trí testers cho các dự án. • Độc lập báo cáo về chất lượng và mức độ hoàn thành các phần mềm. • Trao đổi kinh nghiệm, bồi dưỡng kỹ thuật testing cho các thành viên trong nhóm Tài liệu đào tạo nội bộ

  16. 3.2. Tổ chức nhóm tester theo dự án • Các role test trong một dự án: • Test leader: làm test plan, test evaluation report, phân công tester • Test designer: thiết kế test cases, sắp xếp thứ tự test • Test worker: thực hiện test, làm test result report. • Số tester trong một dự án: >=1 • Thực tế các role “test designer” và “test worker” thường do cùng một người đảm nhận, gọi chung là “tester” Tài liệu đào tạo nội bộ

  17. 3.3. Vai trò của test leader • Lead nhóm tester của dự án: • Giao việc và giám sát công việc cho các tester • Đảm bảo các test cases giao cho các tester được thiết kế đúng, được thực hiện đủ • Đảm bảo tất cả các lỗi được ghi vào phần mềm ghi lỗi • Đảm bảo tất cả các lỗi developer báo fixed phải được test lại. • Hỗ trợ chuyên môn cho các tester • Đảm bảo việc test được thực hiện đúng kế hoạch, đúng tiến độ, với đủ các tài liệu test cần thiết • Review các lỗi, hỗ trợ và thúc giục team lead cho fix lỗi theo đúng yêu cầu. • Chịu trách nhiệm báo cáo về sản phẩm được test • Báo cáo công việc của nhóm lên trưởng nhóm testers. Tài liệu đào tạo nội bộ

  18. 3.4. Vai trò của tester • Thiết kế test cases và phân mức ưu tiên thực hiện chúng • Thực hiện các test cases • Ghi lỗi, theo dõi lỗi, trực tiếp trao đổi về lỗi với developer • Làm báo cáo về các test cases được giao • Hỗ trợ test leader chuẩn bị kế hoạch test • Hỗ trợ test leader làm các nhiệm vụ khác nếu cần Tài liệu đào tạo nội bộ

  19. Tóm tắt nội dung 3 • “Độc lập” là yếu tố quan trọng để đảm bảo testing thành công • Testing là một chuyên môn cần được cập nhật thường xuyên • Test leader là một vị trí đòi hỏi tầm bao quát cao • Tester là công việc đòi hỏi nhiều tố chất tốt. Tài liệu đào tạo nội bộ

  20. Nội dung • Testing overview. • Mô hình chữ V. • Vai trò của các tester. • Các khái niệm phân loại test. • Mô tả và phân loại lỗi (sử dụng TestTrackPro). • Vòng đời của lỗi. • Cách lập các testcase từ các usecase. • Thực hiện test và test thế nào cho đủ. • Các tài liệu test cần có. Tài liệu đào tạo nội bộ

  21. 4. Các khái niệm phân loại test 4.1. Testing approaches: các phương pháp test 4.2. Testing stages: các giai đoạn test 4.3. Testing techniques: các kỹ thuật test Tài liệu đào tạo nội bộ

  22. INPUT INPUT OUTPUT OUTPUT 4.1. Testing approaches • White box testing – test hộp trắng • Còn gọi là structural testing • Test dựa trên cấu trúc của code • Black box testing – test hộp đen • Còn gọi là functional testing, behavioural testing • Test không quan tâm đến code, test dựa trên hành vi của hệ thống Tài liệu đào tạo nội bộ

  23. Integration Testing System Testing Unit Testing Code Developers Independent Test Group 4.2. Testing stages Tài liệu đào tạo nội bộ

  24. 4.2. Testing stages (tiếp) • Unit testing • Unit là phần nhỏ nhất có thể được compiled, linked, và loaded • Unit testing được thực hiện bởi Developer • Sử dụng phương pháp test hộp trắng Tài liệu đào tạo nội bộ

  25. 4.2. Testing stages (tiếp) • Integration testing – test tích hợp • Software Integration là quá trình hợp nhất các unit đơn lẻ vào thành một hệ thống (hoặc một tiểu hệ thống). • Integration testing là test các liên kết giữa các unit thành phần • Có 3 cách intergration: top-down, bottom-up, big-bang. Tương ứng là các cách test. Tài liệu đào tạo nội bộ

  26. 4.2. Testing stages (tiếp) • Integration testing – test tích hợp • Integration testing đòi hỏi các module phải được unit test trước. • Nếu có nhiều lỗi lẽ ra phải tìm thấy từ Unit testing, thì ngừng Integration testing, trả module nhiều lỗi về cho developer. Send a parameter Action: Display message Acknowledge Module or subsystem Module or subsystem Tài liệu đào tạo nội bộ

  27. 4.2. Testing stages (tiếp) • System testing • Khi integration đã được hoàn tất • Sử dụng phương pháp test hộp đen • Test dựa trên requirements • Là sân của nhóm tester độc lập • Cần có một cơ chế để nhập inputs và quan sát reponses của hệ thống, ví dụ như GUI. Tài liệu đào tạo nội bộ

  28. 4.2. Testing stages (tiếp) • Requirements cho System testing: • System Requirements Specification • Interface Specifications • Users Guide • Use Cases • Customers • Domain Experts • Bug Data • Re-engineering Tài liệu đào tạo nội bộ

  29. 4.2. Testing stages (tiếp) • Acceptance test • Nên được gọi là Acceptance Demonstration thay cho Acceptance Test • Để chứng minh phần mềm đã đủ sẵn sàng để bàn giao cho khách hàng • Khi tất cả các testing stages khác đã được hoàn tất • Dựa trên cơ sở là toàn bộ hay một phần của system requirements • Các thủ tục test/demo phải được khách hàng chấp nhận trước khi thực hiện để nghiệm thu. Tài liệu đào tạo nội bộ

  30. Software System After Modification Regression bug Actual bug distribution after modifications are made. 4.2. Testing stages (tiếp) • Regression testing • Nhằm tìm lỗi trong các phần “unchanged” của một software có các phần khác “changed” • Khi bảo trì hay nâng cấp phần mềm lên version mới • Khi tích hợp các phần của một phần mềm Tài liệu đào tạo nội bộ

  31. 4.3. Testing techniques 4.3.1. Equivalence class partitioning 4.3.2. Control flow testing 4.3.3. Data flow testing 4.3.4. Transaction testing 4.3.5. Domain testing 4.3.6. Loop testing 4.3.7. Syntax testing 4.3.8. State machine testing 4.3.9. Load and stress testing Tài liệu đào tạo nội bộ

  32. 4.3. Testing techniques • 4.3.1. - Equivalence class partitioning: • 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 • 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,…) Tài liệu đào tạo nội bộ

  33. 4.3. Testing techniques (tiếp) • 4.3.1. Equivalence class partitioning: ví dụ Example program: • Begin • Read (AAAAAAAAAA) • Print • End What are the equivalence classes? Tài liệu đào tạo nội bộ

  34. 4.3. Testing techniques (tiếp) • 4.3.1. Equivalence class partitioning: ví dụ • 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 - aBcDeFgHi • TC55 - IhGfEdCbA Tài liệu đào tạo nội bộ

  35. 4.3. Testing techniques (tiếp) • 4.3.1. Equivalence class partitioning: ví dụ (tiếp) • 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? Tài liệu đào tạo nội bộ

  36. 4.3. Testing techniques (tiếp) • 4.3.1. Equivalence class partitioning: Exercises • Bạn phải test một kênh quản lý phòng họp: • Cho một cơ quan có nhiều phòng họp, to nhỏ khác nhau • NSD đăng ký sử dụng phòng: chọn phòng, nhập ngày giờ họp • Nếu có conflict thì chương trình đưa ra cảnh báo và gợi ý cho NSD. • Một số class phải test? • Về nhà: • Trình bày một yêu cầu test trong phần mềm bạn đang phải test • Bạn sẽ phân chia các test cases thành các class như thế nào? Tài liệu đào tạo nội bộ

  37. 4.3. Testing techniques (tiếp) • 4.3.2. 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 Tài liệu đào tạo nội bộ

  38. 4.3. Testing techniques (tiếp) • 4.3.2. Control flow testing • Sơ đồ luồng xử lý Process 1 ? Yes No Process 2 Process 3 More Processing Tài liệu đào tạo nội bộ

  39. 4.3. Testing techniques (tiếp) • 4.3.2. Control flow testing: Exercise • 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. Tài liệu đào tạo nội bộ

  40. 4.3. Testing techniques (tiếp) • 4.3.3. Data 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 Tài liệu đào tạo nội bộ

  41. 4.3. Testing techniques (tiếp) • 4.3.4. Transaction 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.3.5. Domain 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 Tài liệu đào tạo nội bộ

  42. 4.3. Testing techniques (tiếp) • 4.3.6. Loop 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 Tài liệu đào tạo nội bộ

  43. 4.3. Testing techniques (tiếp) • 4.3.7. Syntax 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 • … Tài liệu đào tạo nội bộ

  44. 4.3. Testing techniques (tiếp) • 4.3.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 Tài liệu đào tạo nội bộ

  45. 4.3. Testing techniques (tiếp) • 4.3.7. State machine 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) • Đặ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. Tài liệu đào tạo nội bộ

  46. 4.3. Testing techniques (tiếp) • 4.3.8. State machine testing: 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ệ Tài liệu đào tạo nội bộ

  47. 4.3. Testing techniques (tiếp) • 4.3.9. 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 • 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 Tài liệu đào tạo nội bộ

  48. Tóm tắt nội dung 4 • Testing approaches: • white box & black box • Independent testing hiện chỉ làm black box testing. • Testing stages: • unit  integration  system  acceptance, và regression. • Developer testing và indepedent testing cần bổ trợ nhau • Testing types: • gắn với các quality dimension • quen thuộc nhất, là: function testing, securiry testing, usability testing, installation testing. • cần sớm bổ sung thêm load testing & stress testing • Testing techniques: • Để test một hệ thống cần kết hợp sử dụng nhiều testing techniques • Quyết định sử dụng những techniques nào là nhiệm vụ quan trọng của test design Tài liệu đào tạo nội bộ

  49. Nội dung • Testing overview. • Mô hình chữ V. • Vai trò của các tester. • Các khái niệm phân loại test. • Mô tả và phân loại lỗi (sử dụng TestTrackPro). • Vòng đời của lỗi. • Cách lập các testcase từ các usecase. • Thực hiện test và test thế nào cho đủ. • Các tài liệu test cần có. Tài liệu đào tạo nội bộ

  50. 5. Mô tả và phân loại lỗi • Làm gì ngay sau khi tìm thấy lỗi? • Lặp lại một lần nữa các thao tác dẫn đến bug • Tìm cách tổng quát hoá trường hợp dẫn đến bug. • Xét xem liệu còn những thao tác nào khác dẫn cũng dẫn bug? • Tìm ra các thao tác tối thiểu dẫn đến bug • Để ý xem dữ liệu test , cấu hình (settings) hay các option hiện tại có gì đặc biệt? • Xét xem liệu bug này có thể dẫn đến các hậu quả gì khác? • Tìm lướt xem bug này đã từng được ghi hay chưa? Tài liệu đào tạo nội bộ

More Related