Kỹ thuật lập trình - Bài 7: Kiểm thử

62 trang vanle 1970

Download

Bạn đang xem 20 trang mẫu của tài liệu "Kỹ thuật lập trình - Bài 7: Kiểm thử", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

ky_thuat_lap_trinh_bai_7_kiem_thu.pdf

Nội dung text: Kỹ thuật lập trình - Bài 7: Kiểm thử

Mục đích – Khó có thể khẳng định 1 chương trình lớn có làm việc chuẩn hay không – Khi xây dựng 1 chương trình lớn, 1 lập trình viên chuyên nghiệp sẽ dành thời gian cho việc viết test code không ít hơn thời gian dành cho viết bản thân chương trình – Lập trình viên chuyên nghiệp là người có khả năng, kiến thức rộng về các kỹ thuật và chiến • © Copyright Copyright © Showeet.com lược testing 3
Testing and debugging • Test & debug đi cùng với nhau như 1 cặp: – Testing tìm error; debug định vị và sửa chúng. – Ta có mô hình “testing/debugging cycle”: Ta test, rồi debug, rồi lặp lại. – Bất kỳ 1 debugging nào nên được tiếp theo là 1 sự áp dụng lại của hàng loạt các test liên quan, đặc biệt là các bài test hồi quy. Điều này giúp tránh nảy sinh các lỗi mới khi debug. – • Test & debug không nên được thực hiện bởi cùng 1 Copyright © Showeet.com người. 4
Khái niệm Testing • Beizer: Việc thực hiện test là để chứng minh tính đúng đắn giữa 1 phần tử và các đặc tả của nó. • Myers: Là quá trình thực hiện 1 chương trình với mục đích tìm ra lỗi. • IEEE: Là quá trình kiểm tra hay đánh giá 1 hệ thống hay 1 thành phần hệ thống một cách thủ công hay tự động để kiểm chứng rằng nó thỏa • mãn những yêu cầu đặc thù hoặc để xác định sự Copyright © Showeet.com khác biệt giữa kết quả mong đợi và kết quả thực tế 5
Program Verification • Lý tưởng: Chứng minh được rằng chương trình của ta là chính xác, đúng đắn – Có thể chứng minh các thuộc tính của chương trình? – Có thể chứng minh điều đó kể cả khi chương trình kết thúc? Specification Program Right/Wrong • © Copyright Copyright © Showeet.com program.c Checker ? 6
Program Testing • Hiện thực: Thuyết phục bản thân rằng chương trình có thể làm việc Specification Testing Probably Right/Wrong program.c Strategy • © Copyright Copyright © Showeet.com 7
External vs. Internal Testing • Các loại testing – External testing • Thiết kế dữ liệu để test chương trình – Internal testing • Thiết kế program để chương trình tự test • © Copyright Copyright © Showeet.com 9
External Testing • External testing: TK dữ liệu để test chương trình • Phân loại : External testing (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) Kiểm chứng tải: Stress testing • © Copyright Copyright © Showeet.com 10
Boundary Testing (1) Boundary testing – “Là kỹ thuật kiểm chứng sử dụng các giá trị nhập vào ở trên hoặc dưới một miền giới hạn của 1 đầu vào và với các giá trị đầu vào tạo ra các đầu ra ở biên của 1 đầu ra.” • Hầu hết các lỗi đều xảy ra ở các điều kiện biên - • boundary conditions Copyright © Showeet.com • Nếu chương trình làm việc tốt ở đk biên, nó có thể sẽ làm việc đúng với các đk khác 11
Boundary Testing Example • VD: đọc 1 dòng từ stdin và đưa vào mảng ký tự int i; char s[MAXLINE]; for (i=0; (s[i]=getchar()) != '\n' && i in ra “||” , ok • – Nếu gặp EOF trước '\n‘ Copyright © Showeet.com • Tiếp tục gọi getchar() và lưu ӱ vào s[i], not ok – Nếu gặp ngay EOF (empty file) • Tiếp tục gọi getchar() và lưu ӱ vào s[i], not ok 12
Boundary Testing Example (cont.) int i; char s[MAXLINE]; for (i=0; (s[i]=getchar()) != '\n' && i < MAXLINE-1; i++); s[i] = '\0'; printf("String: |%s|\n", s); • Tiếp tục xét các ĐK biên (tt) – Dòng chứa đúng MAXLINE-1 ký tự • In ra đúng, với ‘\0’ tại s[MAXLINE-1] – Dòng chứa đúng MAXLINE ký tự • • Ký tự cuối cùng bị ghi đè, và dòng mới không bao giờ được Copyright © Showeet.com đọc – Dòng dài hơn MAXLINE ký tự • 1 số ký tự, kể cả newline, không được đọc và sót lại trong stdin 13
Boundary Testing Example (cont.) int i; • Viết lại code char s[MAXLINE]; for (i=0; i< MAXLINE-1; i++) if ((s[i] = getchar()) == '\n') break; s[i] = '\0'; • Trường hợp gặp EOF for (i=0; i<MAXLINE-1; i++) if ((s[i] = getchar()) == '\n' || s[i] == EOF) break; s[i] = '\0'; • Các trường hợp khác? • © Copyright Copyright © Showeet.com – Nearly full SAI! – Exactly full Vì sao? – Over full 14
Boundary Testing Example (cont.) • Rewrite yet again for (i=0; ; i++) { int c = getchar(); if (c==EOF || c=='\n' || i==MAXLINE-1) { s[i] = '\0'; break; } else s[i] = c; } • Vấn đề ( với MAXLINE=9) Output: • Input: Copyright © Showeet.com Four FourØ score and seven score anØ Where’s years sevenØ the ‘d’? yearsØ 15
Ambiguity in Specification • Nếu dòng quá dài, xử lý thế nào? – Giữ MAXLINE ký tự đầu, bỏ qua phần còn lại? – Giữ MAXLINE ký tự đầu + ‘\0’, bỏ qua phần còn lại? – Giữ MAXLINE ký tự đầu+’\0’, lưu phần còn lại cho lần gọi sau của input function? • Có thể phần đặc tả - specification không hề đề cập khi MAXLINE bị quá – Có thể người ta không muốn dòng dài quá giới hạn trong mọi trường hợp – Đạo đức: 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 ! Copyright © Showeet.com • 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? 16
Kiểm tra đk trước và đk sau • Xác định những thuộc tính cần đi trước ( đk trước) và sau (đk sau) mã nguồn đc thi hành • Ví dụ: các giá trị đầu vào phải thuộc 1 phạm vi cho trước double avg( double a[], int n) { int i; double sum=0.0; for ( i = 0; i<n; i++) sum+=a[i]; return sum/n; } Nếu n=0 ?, nếu n<0 ? • Có thể thay : return n <=0 ? 0.0: sum/n; Copyright © Showeet.com Tháng 11/1998, chiến hạm Yorktown bị chìm : nhập vào giá trị 0, chương trình không kiểm tra dl nhập dẫn đến chia cho 0, và lỗi làm tầu rối loạn, hệ thống đẩy ngưng hoạt động, tàu chìm !!! 17
Statement Testing (2) Statement testing – “Testing để thỏa mãn điều kiện rằng mỗi lệnh trong 1 chương trình phải thực hiện ít nhất 1 lần khi testing.” ‒ Glossary of Computerized System and Software Development Terminology • © Copyright Copyright © Showeet.com 18
Statement Testing Example • Example pseudocode: if (condition1) statement1; else statement2; Statement testing: if (condition2) statement3; Phải chắc chắn các lệnh “if” else và 4 lệnh trong cac nhánh statement4; phải đc thực hiện • Đòi hỏi 2 tập dữ liệu;vd: – • condition1 là đúng và condition2 là đúng Copyright © Showeet.com • Thực hiện statement1 và statement3 – condition1 là sai và condition2 là sai • Thực hiện statement2 và statement4 19
Path Testing (3) Path testing – “Kiểm tra để đáp ứng các tiêu chuẩn đảm bảo rằng mỗi đường dẫn logic xuyên suốt chương trình được kiểm tra. Thường thì đường dẫn xuyên suốt chương trình này được nhóm thành một tập hữu hạn các lớp . Một đường 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 các chương trình đơn giản, có thể liệt kê các Copyright © Showeet.com nhánh đường dẫn 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 chương trình 20
Path Testing Example • Example pseudocode: if (condition1) statement1; else statement2; Path testing: if (condition2) Cần đảm bảo tất cả các statement3; đường dẫn được thực hiện else statement4; • Đòi hỏi 4 tập dữ liệu: • –condition1 là true và condition2 là true Copyright © Showeet.com –condition1 là true và condition2 là false –condition1 là false và condition2 là true –condition1 là false và condition2 la false • Chương trình thực tế => bùng nổ các tổ hợp!!! 21
Consider an example (1) input(A,B) 1 if (A>0) A>0 (2) Z = A; F T else 3 2 (3) Z = 0; B>0 if (B>0) T F (4) Z = Z+B; 4 (5) output(Z) 5 • What is the path condition for path ? Copyright © Showeet.com (A>0) && (B 0) •22
Consider ANOTHER example (1) input(A,B) 1 if (A>B) (2) B = B*B; A>B T F if (B ? Copyright © Showeet.com 2 (A>B) Л (B<0) (B <0) = FALSE •24
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 Copyright © Showeet.com vs. ASCII) • Nên dùng máy tính để tạo đầu vào 25
Stress Testing Example 1 • Example program: #include int main(void) { char c; Stress testing: Phải cung cấp while ((c = getchar()) != EOF) random (binary and ASCII) putchar(c); inputs return 0; } • Mục tiêu: Copy tất cả các ký tự từ stdin vào stdout; nhưng lưu ý bug!!! • Làm việc với tập dữ liệu ASCII chuẩn ( tự tạo) • • Máy tính tự tạo ngẫu nhiên tập dữ liệu dạng 255 Copyright © Showeet.com (decimal), hay 11111111 (binary), và EOF để dừng vòng lặp 26
Stress Testing Example 2 • Example program: #include int main(void) { short charCount = 0; Stress testing: Phải cung cấp while (getchar() != EOF) very large inputs charCount++; printf("%hd\n", charCount); return 0; } • Mục tiêu: Đếm và in số các kỹ tự trong stdin • • Làm việc với tập dữ lieu có kích thước phù hợp Copyright © Showeet.com • Sẽ có lỗi với tập dữ liệu do máy tạo chứa hơn 32767 characters 27
Uses of assert • Typical uses of assert – Validate formal parameters size_t Str_getLength(const char *str) { assert(str != NULL); } – Check for “impossible” logical flow switch (state) { case START: break; case COMMENT: break; default: assert(0); /* Never should get here */ • © Copyright Copyright © Showeet.com } – Make sure dynamic memory allocation requests worked assert(ptr != NULL); 28
Internal Testing • Internal testing: Thiết kế chương trình để chương trình tự kiểm thử • 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 Copyright © Showeet.com (5) Giữ nguyên mã thử nghiệm -Leaving testing code intact 29
Testing Invariants (1) Testing invariants – Thử nghiệm các đk trước và sau – Vài khía cạnh của cấu trức dữ liệu không đc thay đổi – 1 hàm tác động đến cấu trúc dữ liệu phải kiểm tra các bất biến ở đầu và cuối nó – Ví dụ: Hàm “doubly-linked list insertion” • Kiểm tra ở đầu và cuối – Xoay doubly-linked list – Khi node x trỏ ngược lại node y, thì liệu node y có trỏ ngược lại node x? • Copyright © Showeet.com – Example: “binary search tree insertion” function • Kiểm tra ở đầu và cuối – Xoay tree – Các nodes có còn đc sắp xếp không ? 30
Testing Invariants (cont.) • Tiện cho việc dùng assert để test invariants #ifndef NDEBUG int isValid(MyType object) { Test invariants here. Return 1 (TRUE) if object passes all tests, and 0 (FALSE) otherwise. Có thể dùng NDEBUG } #endif trong code, giống như assert void myFunction(MyType object) { assert(isValid(object)); • Copyright © Showeet.com Manipulate object here. assert(isValid(object)); } 31
Kiểm tra các thuộc tính lưu trữ – Khái quát hóa của testing invariants – 1 hàm cần kiểm tra các cấu trúc dữ liệu bị tác động tại các điểm đầu và cuối – VD: hàm Str_concat() • Tại điểm đầu, tìm độ dài của 2 xâu đã cho; tính tổng • Tại điểm cuối, tìm độ dài của xâu kết quả • 2 độ dài có bằng nhau không ? – VD: Hàm chèn thêm PT vào danh sách -List • insertion function Copyright © Showeet.com • Tại điểm khởi đầu, tính độ dài ds • Tại điểm cuối, Tính độ dài mới • Độ dài mới = độ dài cũ + 1? 32
Kiểm tra GT trả về Checking Return Values – Trong Java và C++: • Phương thức bị phát hiện có lỗi có thể tung ra một “checked exception” • Phương thưc triệu gọi phải xử lý ngoại lệ – Trong C: • Không có cơ chế xử lý exception • • Hàm phát hiện có lỗi chủ yếu thông qua giá trị trả Copyright © Showeet.com về • Người LT thường dễ dàng quên kiểm tra GT trả về • Nói chung là chúng ta nên kiểm tra GT trả về 33
Checking Return Values (cont.) – VD: scanf() trả về số của các giá trị đc đọc Bad code Good code int i; int i; scanf("%d", &i); if (scanf("%d", &i) != 1) /* Error */ Bad code??? Good code, or overkill??? int i = 100; int i = 100; printf("%d", i); if (printf("%d", i) != 3) /* Error */ • © Copyright Copyright © Showeet.com – VD: printf() có thể bị lỗi nếu ghi ra file và đĩa bị đầy; Hàm này trả về số ký tự được ghi (không phải giá trị) 34
Tạm thay đổi code – Tạm thay đổi code để tạo ranh giới nhân tạo hoặc stress tests – VD: chương trình sắp xếp trên mảng • Tạm đặt kích thước mảng nhỏ • chương trình có xử lý tràn số hay không ? – Viết 1 phiên bản hàm cấp phát bộ nhớ và phát hiện ra lỗi sớm, để kiểm chứng đoạn mã nguồn bị lỗi thiếu bộ nhớ : void *testmalloc( size_t n) { static int count =0; if (++count > 10) • return NULL; Copyright © Showeet.com else return malloc(n); } 35
Để nguyên đoạn code kiểm tra – Hãy để nguyên trạng các đoạn kiểm tra trên code – Có thể khoanh lại = #ifndef NDEBUG #endif – Kiểm tra với tùy chọn –DNDEBUG gcc • Bặt/Tắt assert macro • Cũng có thể Bật/tắt debugging code • Cẩn trọng với mâu thuẫn - conflict: – Mở rộng thử nghiệm nội bộ có thể giảm chi phí bảo trì • – Code rõ ràng có thể giảm chi phí bảo trì Copyright © Showeet.com – Nhưng Mở rộng thử nghiệm nội bộ có thể làm giảm độ rõ ràng của Code ! 36
Các chiến lược testing • General testing strategies (1) Kiểm chứng tăng dần -Testing incrementally (2) So sánh 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 • © Copyright Copyright © Showeet.com 38
Testing Incrementally (1) Testing incrementally – Test khi viết code • Thêm test khi tạo 1 lựa chọn mới - new cases • Test phần đơn giản trước phần phức tạp • Test units (tức là từng module riêng lẻ) trước khi testing toàn hệ thống – Thực hiện regression testing – kiểm thử hồi quy • Xử lý đc 1 lỗi thường tạo ra những lỗi mới trong 1 hệ thống lớn, vì vậy • Phải đảm bảo chắc chắn hệ thống không “thoái lui” kiểu như chức năng trước kia đang làm việc giờ bị • broken, nên Copyright © Showeet.com • Test mọi khả năng để so sanh phiên bản mới với phiên bản cũ 39
Testing Incrementally (cont.) (1) Testing incrementally (cont.) – Tạo “giàn giáo” - scaffolds và “mẫu” -stubs để test đoạn code mà ta quan tâm Scaffold: Đoạn code •Hàm gọi đến code tạm thời gọi đến code mà ta quan tâm Mà ta quan tâm • Đoạn code cần quan tâm Copyright © Showeet.com Stub: Đoạn code Hàm được gọi Hàm được gọi Tạm thời được gọi bởi đoạn code cần •bởi đoạn code cần Bởi đoạn code cần quan tâm •quan tâm Quan tâm 40
So sánh các cài đặt • (2) Compare implementations – Hãy chắc chắn rằng các triển khai độc lập hoạt động như nhau – Example: So sánh hành vi của chương trình mà bạn dịch ( TB C++3.0 ) với GCC – Example: So sánh hành vi của các hàm bạn tạo trong str.h với các hàm trong thư viện string.h – Đôi khi 1 kết quả có thể đc tính bằng 2 cách khác nhau, 1 bài toán có thể giải bằng 2 phương pháp, thuật toán khác nhau. Ta có thể xây dựng cả 2 • chương trình, nếu chúng có cùng kết quả thì có Copyright © Showeet.com thể khẳng định cả 2 cùng đúng, còn kết quả khác nhau thì ít nhất 1 trong 2 chương trình bị sai. 41
Kiểm chứng tự động - Automation (3) Automation – Là quá trình xử lý 1 cách tự động các bước thực hiện test case = 1 công cụ nhằm rut ngắn thời gian kiểm thử. – Ba quá trình kiểm chúng bao gồm : • Thực hiện kiểm chứng nhiều lần • Dùng nhiều bộ dữ liệu nhập • Nhiều lần so sánh dữ liệu xuất – vì vậy cần kiểm chứng = chương trình để : tránh mệt mỏi, giảm sự bất cẩn – Tạo testing code • Viết 1 bộ kiểm chứng để kiểm tra toàn bộ chương trình mỗi khi có sự thay đổi, sau khi biên dịch thành công • – Cần biết cái gì được chờ đợi Copyright © Showeet.com • Tạo ra các đầu ra, sao cho dễ dàng nhận biết là đúng hay sai • Tự động kiểm chứng có thể cung cấp: – Tốt hơn nhiều so với kiểm chứng thủ công 42
• Tự động hóa kiểm chứng lùi – Tuần tự kiểm chứng so sánh các phiên bản mới với những phiên bản cũ tương ứng. – Mục đích : đảm bảo việc sửa lỗi sẽ không làm ảnh hưởng những phần khác trừ khi chúng ta muốn – 1 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 các đoạn script để test tuần tự • Unix : có các thao tác trên tệp tin như cmp và diff để so sanh dữ liệu xuất, sort sắp xếp các phần tử, grep để kiểm chứng dữ liệu xuất, wc, sum va freq để tổng kết dữ liệu xuất – Khi kiểm chứng lùi, cần đảm bảo phiên bản cũ là đúng, nếu sai thì rất khó xác định và kết quả sẽ không chính xác • – Cần phải kiểm tra chính việc kiểm chứng lùi 1 cách định kỳ Copyright © Showeet.com để đảm bảo nó vẫn hợp lệ •43
• Dùng các công cụ test - QuickTest professional - TestMaker - Rational Robot - Jtest - Nunit - Selenium • © Copyright Copyright © Showeet.com - . 44
Bug-Driven Testing (4) Kiểm chứng hướng lỗi : Bug-driven testing – Tìm thấy 1 bug => Ngay lập tức tạo 1 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 các bugs!!! • Copyright © Showeet.com – Rồi quyết định nếu tìm thấy chúng – Kiểm chứng bản thân kiểm chứng!!! 45
Ai test cái gì - Who Tests What • Programmers – White-box testing – Ưu điểm: Người triển khai nắm rõ mọi luồng dữ liệu – Nhược: Bị ảnh hưởng bởi 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 về implementation – Con: Không muốn test mọi logical paths • Customers – Field testing • – Pros: Có các cách sử dụng chương trình bất ngờ;dễ gây lỗi Copyright © Showeet.com – Cons: Không đủ trường hợp; khách hàng không thích tham gia vào quá trình test ; 47
Testing Techniques • Black-Box: Testing chỉ dựa trên việc phân tích các yêu cầu - requirements (unit/component specification, user documentation, v.v.). Còn được gọi là functional testing. • White-Box: Testing dựa trên việc phân tích các logic bên trong - internal logic (design, code, v.v.). (Nhưng kết quả mong đợi vẫn đến từ • requirements.) Còn đc gọi là structural testing. Copyright © Showeet.com 48
WBT • Còn được gọi là clear box testing, glass box testing, transparent box testing, or structural testing, thường thiết kế các trường hợp kiểm thử dựa vào cấu trúc bên trong của phần mềm. • WBT đòi hỏi kĩ thuật lập trình am hiểu cấu trúc bên trong của phần mềm ( các đường, luồng dữ liệu, chức năng, kết quả ). • © Copyright Copyright © Showeet.com • Phương thức : – Chọn các đầu vào và xem các đầu ra 49
White Box Testing Đặc điểm • Phụ thuộc vào các cài đặt hiện tại của hệ thống và của phần mềm, nếu có sự thay đổi thì các bài test cũng cần thay đổi theo. • Được ứng dụng trong các kiểm tra ở cấp độ mô đun (điển hình) , tích hợp (có khả năng) và hệ thống của quá trình test phần mềm. • © Copyright Copyright © Showeet.com 50
Black Box Testing • Black-box testing sử dụng mô tả bên ngoài của phần mềm để kiểm thử, ,bao gồm các đặc tả (specifications), yêu cầu (requirements) và thiết kế ( design). • Không có sự hiểu biết cấu trúc bên trong của phần mềm • Các dạng đầu vào có dạng hàm hoặc không , hợp lệ và không không hợp lệ và biết trước đầu hợp lệ và không không hợp lệ và biết trước đầu ra • Được sử dụng để kiểm thử phần mềmtại mức : mô đun, tích hợp, hàm, hệ thống và chấp nhận. • Lợi điểm của kiểm thử hộp đen là khả năng đơn giản hoá • kiểm thử tại các mức độ được đánh giá là khó kiểm thử Copyright © Showeet.com • Yếu điểm là khó đánh giá còn bộ giá trị nào chưa được kiểm thử hay không 51
• Các kí thuật chính của kiểm thử hộp đen : • Decision Table testing • Pairwise testing • State transition tables • Tests of Customer Requirement • Equivalence partitioning • • Boundary value analysis Copyright © Showeet.com • Failure Test Cases 52
Grey Box Testing • Là sự kết hợp của kiểm thử hộp đen và kiểm thử hộp trắng khi mà người kiểm thử biết được một phần cấu trúc bên trong của phần mềm • Như vậy không phải là KT hộp đen • Là dạng kiểm thử tốt và có sự kết hợp các kĩ thuật của cả kiểm thử hộp đen và các kĩ thuật của cả kiểm thử hộp đen và hộp trắng • © Copyright Copyright © Showeet.com 53
Other Test • Sanity testing • Smoke testing • Software testing • Stress testing • Test automation • Web Application Security Scanner • • Fuzzing Copyright © Showeet.com • Acceptance testing • Sanwich Testing 54
Sanity testing • Kiểm thử đúng đắn là kiểm thử lướt qua; được thực hiện khi có đủ điều kiện nâng cao ứng dụng nhờ việc hàm hoá đặc tả. • Kiểm thử các thành phần thoái hoá của phần mềm. – Bao gồm các kiểm thử vào vùng lõi của các – Bao gồm các kiểm thử vào vùng lõi của các hàm GUI cơ sở để xem kết nối dữ liệu, máy chủ ứng dụng, máy in , vv . Smoke testing • Smoke Testing xảy ra khi thành phần mới được thêm vào • và được tích hợp vào phần code đã có của phần mềm. Nó Copyright © Showeet.com đảm bảo việc làm việc ăn khớp của khối code mới • Là bước đầu kiểm tra sau đó cần kiểm thử thêm các bằng các kĩ thuật khác . 55
WBT – Cac ky thuat • Kiểm thử luồng, lộ trình (Deriving Test Cases ) – Lộ trình cơ sở (Basis pmath Testing ) • Luồng điều khiển / Phạm vi •( Control-flow / Coverag e Testing) ) – Phương thức -Method Coverage – Câu lệnh –StatementCoverge – Nhánh -Branch Coverge – Điều kiện –Condition Converage • Kiểm thử luồng dữ liệu (Data Flow Test ) • © Copyright Copyright © Showeet.com • Trường hợp hỏng ‘rác’– Failure ‘Dirty’ Case Test • Flow Groaps Revisited 56
Levels or Phases of Testing • Unit: testing các mẫu công việc nhỏ nhất của lập trình viên để có thể lập kế hoạch và theo dõi hợp lý (vd : function, procedure, module, object class, .) • Component: testing 1 tập hợp các units tạo thành 1 thành phần (vd : program, package, task, interacting object classes, ) • Product: testing các thành phần tạo thành 1 sản phẩm ( subsystem, application, ) • System: testing toàn bộ hệ thống • Testing thường: • – Bắt đầu = functional (black-box) tests, Copyright © Showeet.com – Rồi thêm = structural (white-box) tests, và – Tiến hành từ unit level đến system level với 1 hoặc một vài bước tích hợp 57
Tại sao không "test everything"? •Chi phí cho 'exhaustive' testing: • 20 x 4 x 3 x 10 x 2 x 100 = 480,000 tests Copyright © Showeet.com •Nếu 1 giây cho 1 test, 8000 phút, 133 giờ, 17.7 ngày (chưa kể nhầm lẫn hoặc test đi test lại) nếu 10 secs = 34 wks, 1 min = 4 yrs, 10 min = 40 yrs 58
Bao nhiêu testing là đủ? • Không bao giờ đủ ! • Khi bạn thực hiện những 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 / tin tưởng rằng hệ thống hoạt động đúng, chính xác • Phụ thuộc vào risks for your system • Càng ít thời gian, càng nhiều để thời gian để test luôn có giới hạn • • Dùng RISK để xác định: Copyright © Showeet.com – Cái gì phải test trước – Cái gì phải test nhiều – Mỗi phần tử cần test kỹ như thế nào ? Tức là đâu là trọng tâm – Cái gì không cần test (tại thời điểm này ) 59
The testing paradox • Mục đích của testing: để tìm ra lỗi • Tìm thấy lỗi làm mất (hủy hoại) sự tự tin - confidence • => Mục đích của testing: hủy hoại sự tự tin • Nhưng mục đích của testing: Xây dựng niềm tin, tự tin • • => Cách tốt nhất để xây dựng niềm tin là: Cố Copyright © Showeet.com gắng hủy hoại nó 61
Summary • External testing taxonomy – Boundary testing – Statement testing – Path testing – Stress testing • Internal testing techniques – Checking invariants – Verifying conservation properties • – Checking function return values Copyright © Showeet.com – Changing code temporarily – Leaving testing code intact 62
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! Copyright © Showeet.com • Kiểm chứng code, kiểm chứng việc kiểm chứng – và kiểm chứng cả đặc tả ! 63