TESTING (kỹ THUẬT lập TRÌNH SLIDE)

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à q 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ác 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, tốn giải = phương pháp, thuật toán # Ta xd CT, chúng có KQ khẳng định đúng, cịn 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 q 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 tồn chương trình m ỗi có 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 tồ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 q 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 tồ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 ln 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 - Cái khong cần test (thời điểm này) 48 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 ... 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”:... 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... đí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