KỸ THUẬT lập TRÌNH CHƯƠNG 6 testing

CHƯƠ NG 6-Testing Mục đích • Giúp hiểu về: • Internal testing • External testing • General testing strategies • Vì sao? • Khó khẳng định CT lớn có làm việc chuẩn hay không • Khi XD CT lớn, LTV chuyên nghiệp dành thời gian cho việc viết test code không tg dành cho viết thân CT • LTV chuyên nghiệp người có khả năng, kiến thức rộng kỹ thuật chiến lược testing Testing and debugging • Testing & debugging với cặp: • Testing tìm errors; debugging định vị sửa chúng • Ta có mô hình “testing/debugging cycle”: Ta test, debug, lặp lại • Bất kỳ debugging nên áp dụng lại hàng loạt tests liên quan, đặc biệt tests hồi quy Điều giúp tránh nảy sinh lỗi debugging • Testing & debugging không nên thực người (thường không nên) Khái niệm Testing • Beizer: Việc thực test để chứng minh tính đắn phần tử đặc tả • Myers: Là trình thực CT với mục đích tìm lỗi • IEEE: Là trình kiểm tra hay đánh giá hệ thống hay thành phần hệ thống cách thủ công hay tự động để kiểm chứng thỏa mãn yêu cầu đặc thù để xác định khác biệt kết mong đợi kết thực tế Program Verification • Lý tưởng: Chứng minh CT ta xác, đắn • Có thể chứng minh thuộc tính CT? • Có thể CM điều kể CT kết thúc?!!! Specification Program Right/Wrong Checker program.c ? Program Testing • Thực dụng: Thuyết phục thân CT làm việc Specification program.c Testing Strategy Probably Right/Wrong External vs Internal Testing • Các loại testing • External testing • Thiết kế liệu để test program • Internal testing • Thiết kế program để CT tự test itself External Testing • External testing: TK liệu để test CT • External testing taxonomy (1) Kiểm chứng giá trị biên : Boundary testing (2) Kiểm chứng lệnh : Statement testing (3) Kiểm chứng có hệ thống : Path testing (4) Stress testing Boundary Testing (1) Boundary testing • “Là kỹ thuật kiểm chứng sử dụng giá trị nhập vào miền giới hạn đầu vào với giá trị đầu vào tạo đầu biên đầu ra.” ‒ Glossary of Computerized System and Software Development Terminology • Còn gọi kiểm tra điều kiện biên-corner case testing • Hầu hết lỗi đề u xảy điều kiện biên - boundary conditions • Nếu CT làm việc đk biên, làm việc với đk khác9 Boundary Testing Example • VD : đọ c dòng từ stdin đư a vào mảng ký tự int i; char s[MAXLINE]; for (i=0; (s[i]=getchar()) != '\n' && i < MAXLINE-1; i++) ; s[i] = '\0'; printf("String: |%s|\n", s); • Boundary conditions • Dòng rỗng -Input starts with '\n' • In empty string (“\0”) => in “||” , ok • Nếu gặp EOF - End of file trước '\n‘ • Tiếp tục gọi getchar() lưu ӱ vào s[i] • Nếu gặp EOF (empty file) • Tiếp tục gọi getchar() lưu ӱ vào s[i] 10 Testing Incrementally (cont.) (1) Testing incrementally (cont.) • Tạo “giàn giáo” - scaffolds “mẫu” -stubs để test đoạn code mà ta quan Scaffold: Đoạn code tâm • tạm thời gọi đến code gọi đến code mà ta quan tâm Hàm Mà ta quan tâm Đoạn code cần quan tâm Hàm gọi đoạn code cần quan tâm Hàm gọi •bởi đoạn code cần •quan tâm Stub: Đoạn code Tạm thời gọi Bởi đoạn code cần Quan tâm 38 So sánh cài đặ t (2) Compare implementations • Hãy chắn triển khai độc lập hành xử • Example: So sánh hành vi CT mà bạn dịch ( TB C++3.0 ) với GCC • Example: So sánh hành vi hàm bạn tạo str.h với hàm thư viện string.h • Đôi kq đc tính = cách khác nhau, toán giải = phương pháp, thuật toán # Ta xd CT, chúng có KQ khẳng định đúng, kq khách ct bị sai 39 Kiểm chứng tự độ ng - Automation (3) Automation • Testing thủ công nặng nhọc tốn nhàm chán chí không đủ đọ tin cậy • Ba trình kiểm chúng bao gồm : • Thực kiểm chứng nhiều lần • Dùng nhiều liệu nhập • Nhiều lần so sánh liệu xuất • cần kiểm chứng = chương trình để : tránh mệt mỏi, giảm bất cẩn … • Tạo testing code • Viết kiểm chứng để kiểm tra toàn chương trình có s ự thay đổi, sau biên dịch thành công • Cần biết chờ đợi • Tạo đầu ra, cho dễ dàng nhận biết hay sai • Tự động kiểm chứng cung cấp: • Tốt nhiều so với kiểm chứng thủ công 40 • Tự độ ng hóa kiểm chứng lùi • Tuần tự kiểm chứng so sánh phiên với phiên cũ tương ứng • Mục đích : đảm bảo việc sửa lỗi không làm ảnh hưởng phần khác trừ muốn • số hệ thống có công cụ trợ giúp kiểm chứng tự động : • Ngôn ngữ scripts : cho phép viết đoạn script để test • Unix : có thao tác tệp tin cmp diff để so sanh d ữ liệu xu ất, sort s ắp x ếp phần tử, grep để kiểm chứng liệu xuất, ưc, sum va freq để ttong kết liệu xuất • Khi kiểm chứng lùi, cần đảm bảo phiên cũ đúng, sai khó xác định kết không xác • Cần phải kiểm tra việc kiểm chứng lùi 41 cách định kỳ để đảm bảo hợp lệ • Tạo kiểm chứng độc lập • Kiểm chứng độc lập với giá trị nhập giá trị xuất mong đợi bổ xung cho kiểm chứng lùi • Ví dụ : dùng ngôn ngữ NewAwk thực kiểm chứng ct ngắn, liệu xuất đc ghi vào tệp tin, kq đc ghi vào tệp khác so sánh tệp, khác tbaos lỗi echo | newawk ‘{i=1; print ($si)++; print $i ,i}’ > out1 echo ‘3 1’ > out2 #két if ! Cmp –s out1 out2 # kq so sánh khác then echo ‘BAD: test failed’ Fi • Mọt lỗi cần nhiều thao tác kiểm chứng phải kiểm tra toàn lợp mới, thêm vào đoạn Ct bảo vệ để bắt đc lỗi CT 42 Bug-Driven Testing (4) Kiểm chứng hướ ng lỗi : Bug-driven testing • Tìm thấy bug => Ngay tạo test để bắt lỗi • Đơn giản hóa việc kiểm chứng lùi (5) Fault injection • Chủ động (tạm thời) cài bugs!!! • Rồi định tìm thấy chúng • Kiểm chứng thân kiểm chứng!!! 43 Ai test - Who Tests What • Programmers • White-box testing • Pro: Người triển khai nắm rõ luồng liệu • Con: Bị ảnh hưởng cách thức code đc thiết kê/viết • Quality Assurance (QA) engineers • Black-box testing • Pro: Không có khái niệm implementation • Con: Không muốn test logical paths • Customers • Field testing • Pros: Có cách sử dụng CT bất ngờ;dễ gây lỗi • Cons: Không đủ trường hợp; khách hàng không thích tham gia vào trình test ; 44 Testing Techniques • Black-Box: Testing dựa việc phân tích yêu cầu - requirements (unit/component specification, user documentation, v.v.) Còn gọi functional testing • White-Box: Testing dựa việc phân tích logic bên - internal logic (design, code, v.v.) (Nhưng kết mong đợi đến từ requirements.) Còn đc gọi structural testing 45 Levels or Phases of Testing • Unit: testing mẫu công việc nhỏ LTV để lập kế hoạch theo dõi hợp lý (vd : function, procedure, module, object class, ….) • Component: testing tập hợp units tạo thành thành phần (vd : program, package, task, interacting object classes, …) • Product: testing thành phần tạo thành sản phẩm ( subsystem, application, …) • System: testing toàn hệ thống • Testing thườ ng: • Bắt đầu = functional (black-box) tests, • Rồi thêm = structural (white-box) tests, • Tiến hành từ unit level đến system level với vài bước tích hợp 46 Tại không "test everything"? •Chi phí cho 'exhaustive' testing: 20 x x x 10 x x 100 = 480,000 tests •Nếu giây cho test, 8000 phút, 133 giờ, 17.7 ngày (not counting finger trouble, faults or retest) 10 secs = 34 wks, = yrs, 10 = 40 yrs 47 Bao nhiêu testing đủ ? - Không đủ ! - Khi bạn thực test mà bạn lên kế hoạch - Khi khách hàng/ngườ i sử dụng thấy thỏa mãn - Khi bạn chứng minh đc hệ thống hoạt độ ng đúng, xác - Khi bạn tin tưở ng HT hoạt độ ng tốt - Phụ thuộc vào risks for your system Càng thời gian, nhiều để  Thời gian để test có giới hạn  Dùng RISK để xác đị nh: - Cái phải test trước - Cái phải test nhiều - Mỗi phần tử cần test kỹ ? Tức đâu trọng tâm 48 - Cái khong cần test (thời điểm này) Nguyên tắc quan trọng Most important principle • Ưu tiên tests Để, Khi bạn kết thúc testing, Bạn thực việc test tốt quãng thời gian 49 The testing paradox • Mục đích testing: để tìm lỗi • Tìm thấy lỗi làm (hủy hoại) tự tin - confidence => Mục đích testing: hủy hoại tự tin • Nhưng mục đích testing: Xây dựng niềm tin, tự tin => Cách tốt để xây dựng niềm tin : Cố gắng hủy hoại 50 Summary • External testing taxonomy • Boundary testing • Statement testing • Path testing • Stress testing • Internal testing techniques • Checking invariants • Verifying conservation properties • Checking function return values • Changing code temporarily • Leaving testing code intact 51 Summary (cont.) • General testing strategies • Testing incrementally • Regression testing • Scaffolds and stubs • Automation • Comparing independent implementations • Bug-driven testing • Fault injection • Test the code, the tests – and the specification! • Kiểm chứng code, kiểm chứng việc kiểm chứng – kiểm chứng đặc tả ! 52 [...]... hoạt 16 động, tàu chìm !!! Statement Testing (2) Statement testing • Testing để thỏa mãn điều kiện rằng mỗi statement trong 1 CT phải thực hiện ít nhất trong khi testing. ” ‒ Glossary of Computerized System and Software Development Terminology 17 Statement Testing Example • Example pseudocode: if (condition1) statement1; else statement2; … if (condition2) statement3; else statement4; … Statement testing: ... statement4 18 Path Testing (3) Path testing • “Kiểm tra mỗi đường kiểm tra trình này Một đường để đáp ứng các tiêu chuẩn đảm bảo rằng dẫn logic xuyên suốt chương trình được Thường thì đường dẫn xuyên suốt chương được nhóm thành một tập hữu hạn các lớp dẫn từ mỗi lớp sau đó được kiểm tra " ‒ Glossary of Computerized System and Software Development Terminology • Khó hơn nhiều so với statement testing • Với... 27 Internal Testing • Internal testing: Thiết kế CT để CT tự test itself • Internal testing techniques (1) Kiểm tra bất biến - Testing invariants (2) Kiểm tra các thuộc tính lưu trữ -Verifying conservation properties (3) Kiểm tra các giá trị trả về -Checking function return values (4) Tạm thay đổi code -Changing code temporarily (5) Giữ nguyên mã thử nghiệm -Leaving testing code intact 28 Testing Invariants... nghiệm nội thể làm giảm độ rõ ràng của Code giảm chi bảo trì bộ có ! 35 Các chiến lượ c testing • General testing strategies (1) Kiểm chứng tăng dần -Testing incrementally (2) So sanh các cài đặt -Comparing implementations (3) Kiểm chứng tự động - Automation (4) Bug-driven testing (5) Tiêm, gài lỗi - Fault injection 36 ... kiểm tra đã phát hiện ra một vấn đề thiết kế, thậm chí có thể là một vấn đề đặc điểm kỹ thuật ! • Quyết định phải làm gì • Cắt những dòng quá dài? • Lưu phần còn lại để đọc như 1 dòng mới? 14 Vấn đề đạ o đứ c • Phức tạp, các trường hợp ranh giới lộn xộn thường là triệu chứng của việc thiết kế tồi hay mô tả đặc điểm kỹ thuật tồi • Xóa bỏ đặc tả nếu bạn có thể • Nếu không thể sửa specification, thì hãy... charCount = 0; while (getchar() != EOF) charCount++; printf("%hd\n", charCount); return 0; } Stress testing: Phải cung cấp very large inputs • Mục tiêu: Đế m và in số các kỹ tự trong stdin • Làm việc với tập dữ lieuj có kích thướ c phù hợp • Sẽ có lỗi với tập dữ liệu do máy tạo chứa hơn 32 767 characters 26 Uses of assert • Typical uses of assert • Validate formal parameters size_t Str_getLength(const... 23 Stress Testing (4) Stress testing • “Tiến hành thử nghiệm để đánh giá một hệ thống hay thành phần tại hoặc vượt quá các giới hạn của các yêu cầu cụ thể của nó” ‒ Glossary of Computerized System and Software Development Terminology • Phải tạo : • Một tập lớn đầu vào - Very large inputs • Các đầu vào ngẫu nhiên - Random inputs (binary vs ASCII) • Nên dùng máy tính để tạo đầu vào 24 Stress Testing Example... xuyên suốt code • Ngược lại, bằng các đầu vào ngẫu nhiên tạo các đường dẫn theo ct 19 Path Testing Example • Example pseudocode: if (condition1) statement1; else statement2; … if (condition2) statement3; else statement4; … • Đòi hỏi 4 tập dữ liệu: • condition1 là • condition1 là • condition1 là • condition1 là Path testing: Cần đả m bảo tất cả các đường dẫn được thực hiện true và condition2 là true true... Boundary Testing Example (cont.) • Rewrite the code int i; char s[MAXLINE]; for (i=0; i ... (1) Kiểm chứng tăng dần -Testing incrementally (2) So sanh cài đặt -Comparing implementations (3) Kiểm chứng tự động - Automation (4) Bug-driven testing (5) Tiêm, gài lỗi - Fault injection 36 Testing... nhiêu testing đủ ? - Không đủ ! - Khi bạn thực test mà bạn lên kế hoạch - Khi khách hàng/ngườ i sử dụng thấy thỏa mãn - Khi bạn chứng minh đc hệ thống hoạt độ ng đúng, xác - Khi bạn tin tưở ng... tốt - Phụ thuộc vào risks for your system Càng thời gian, nhiều để  Thời gian để test có giới hạn  Dùng RISK để xác đị nh: - Cái phải test trước - Cái phải test nhiều - Mỗi phần tử cần test kỹ