Nhap môn CNPM Ch.4 Kiểm thử 1 Công nghệ Phần mềm Software Engineering Công ngh Công ngh ệ ệ Ph Ph ầ ầ n m n m ề ề m m Software Engineering Software Engineering Chương 4. Kiểm thử PM Chương Chương 4 4 . . Ki Ki ể ể m th m th ử ử PM PM PGS.TS. Phan Huy Khánh khanhph29@gmail.com, phkhanh@dut.udu.vn 2/ 2/ 57 57 Chương Chương 4 4 . . Ki Ki ể ể m th m th ử ử PM PM a Khái niệm kiểm thử PM (Software Testing) a Các nguyên lý kiểm thử PM a Các chiến lược kiểm thử PM a Nghệ thuật gỡ rối 3/ 3/ 57 57 Thế nào là kiểm thử PM a Kiểm thử PM là V V Th Th ự ự c hi c hi ệ ệ n (ch n (ch ạ ạ y) ph y) ph ầ ầ n m n m ề ề m m trong m trong m ộ ộ t môi trư t môi trư ờ ờ ng mô ph ng mô ph ỏ ỏ ng hay th ng hay th ự ự c t c t ế ế , , V V b b ằ ằ ng c ng c á á ch s ch s ử ử d d ụ ụ ng c ng c á á c y c y ế ế u t u t ố ố đ đ ầ ầ u v u v à à o đư o đư ợ ợ c l c l ự ự a ch a ch ọ ọ n n theo c theo c á á ch n ch n à à o đ o đ ó ó a a What is Software Testing? What is Software Testing? V V Executing software in a simulated or real environment, Executing software in a simulated or real environment, V V using inputs selected somehow using inputs selected somehow 4/ 4/ 57 57 Tại sao phải kiểm thử PM a Trong tiến trình PM : V Mặc dù được tự động hoá một phần bởi các công cụ CASE, rất nhiều công đoạn vẫn được thực hiện thủ công V Sản phẩm PM vẫn có khả năng xảy ra sai sót, phạm lỗi V Lỗi có thể xảy ra trong tất cả các giai đoạn, từ phân tích yêu cầu, thiết kế, mã hoá đến đóng gói sản phẩm a Do đóphải kiểm thử PM trước khi chính thức sử dụng 5/ 5/ 57 57 Giá phải trả cho việc tìm và sửa lỗi 6/ 6/ 57 57 Mục tiêu của kiểm thử PM a Kiểm thử PM là : V Hoạt động thực thi chương trình với mục đích tìm ra lỗi và phê phán V Không mang tính xây dựng, phát triển hay thay đổi PM V Có chi phí hợp lý (do thường có chi phí cao) a Kiểm thử PM giúp V Phát hiện được lỗi, thiếu sót trong chương trình (nếu có) V Chứng minh PM được viết đúng V Chứng minh được PM hoạt động đúng như đã thiết kế V Chứng minh được PM đáp ứng những yêu cầu của NSD a Kiểm thử PM góp phần chứng minh chất lượng của PM Nhap môn CNPM Ch.4 Kiểm thử 2 7/ 7/ 57 57 Who Tests the Software? Who Tests the Software? Developer Developer Independent Tester Independent Tester Understands the system Understands the system but, will test "gently"and, but, will test "gently"and, is driven by " is driven by " delivery delivery " " Must learn about the system, Must learn about the system, but, will attempt to break it but, will attempt to break it and, is driven by and, is driven by quality quality 8/ 8/ 57 57 M M ộ ộ t s t s ố ố kh kh á á i ni i ni ệ ệ m m a a M M ộ ộ t t ki ki ể ể m th m th ử ử : : V V L L à à cho ch cho ch ạ ạ y (Run), hay th y (Run), hay th ự ự c hi c hi ệ ệ n (Execution) m n (Execution) m ộ ộ t chương tr t chương tr ì ì nh nh t t ừ ừ nh nh ũ ũ ng d ng d ữ ữ li li ệ ệ u đư u đư ợ ợ c l c l ự ự a ch a ch ọ ọ n đ n đ ặ ặ c bi c bi ệ ệ t t a a M M ộ ộ t t t t ậ ậ p d p d ữ ữ li li ệ ệ u th u th ử ử : : V V L L à à t t ậ ậ p h p h ợ ợ p h p h ữ ữ u h u h ạ ạ n d n d ữ ữ li li ệ ệ u ph u ph ụ ụ c v c v ụ ụ cho m cho m ộ ộ t ki t ki ể ể m th m th ử ử a a M M ỗ ỗ i i ph ph é é p ki p ki ể ể m th m th ử ử : : V V L L à à ho ho ạ ạ t đ t đ ộ ộ ng g ng g ồ ồ m xây d m xây d ự ự ng t ng t ậ ậ p d p d ữ ữ li li ệ ệ u th u th ử ử , , ti ti ế ế n h n h à à nh ph nh ph é é p p ki ki ể ể m th m th ử ử v v à à đ đ á á nh gi nh gi á á k k ế ế t qu t qu ả ả a a Ngư Ngư ờ ờ i ki i ki ể ể m th m th ử ử (hay (hay nh nh ó ó m ki m ki ể ể m th m th ử ử ) : ) : V V L L à à nh nh ữ ữ ng chuyên gia c ng chuyên gia c ó ó nhi nhi ệ ệ m v m v ụ ụ ti ti ế ế n h n h à à nh ph nh ph é é p ki p ki ể ể m th m th ử ử a a M M ộ ộ t t khi khi ế ế m khuy m khuy ế ế t t (Failure) : (Failure) : V V X X ả ả y ra khi th y ra khi th ự ự c hi c hi ệ ệ n chương tr n chương tr ì ì nh cho k nh cho k ế ế t qu t qu ả ả không tương h không tương h ợ ợ p v p v ớ ớ i đ i đ ặ ặ c t c t ả ả c c ủ ủ a chương tr a chương tr ì ì nh nh a a M M ộ ộ t t l l ỗ ỗ i sai i sai (Error) : (Error) : V V L L à à m m ộ ộ t ph t ph ầ ầ n chương tr n chương tr ì ì nh (l nh (l ệ ệ nh) nh) đã gây ra khi đã gây ra khi ế ế m khuy m khuy ế ế t t 9/ 9/ 57 57 Kiểm thử PM = Xác minh + Thẩm định Software Testing = Verification and Validation (V&V) a Xác minh (Verification: Are we building the Product Right?) : V Quá trình xem xét PM có thực hiện đúng đặc tả không, có đúng thiết kế không ? a Thẩm định, hay hợp thức hóa (Validation: Are we building the Right Product?) : V Quá trình xem xét PM có được xây dựng theo đúng yêu cầu của khách hàng hay không ? V Phát hiện lỗi phân tích, lỗi thiết kế (lỗi ở mức cao) 10/ 10/ 57 57 Hoạt động xác minh và thẩm định a Xác minh và thẩm định cho mọi sản phẩm khác nhau : V Thực hiện ở mọi giai đoạn phát triển PM, do các đối tượng khác nhau thực hiện Phân tích nhu cầu phần mềm Phân tích nhu cầu phần mềm Đặc tả phân tích nhu cầu Đặc tả phân tích nhu cầu Thiết kế phần mềm Thiết kế phần mềm Phần mềm và các đặc trưng chất lượng Phần mềm và các đặc trưng chất lượng Đặc tả tốt Đặc tả chưa tốt Chưa đặc tả Thẩm định Thẩm định Xác minh Xác minh Xác minh Xác minh Thẩm định Thẩm định * * * * * * Xác minh Xác minh 11/ 11/ 57 57 B B ả ả n ch n ch ấ ấ t c t c ủ ủ a a xác minh và thẩm định Có hai dạng tĩnh và động a Xác minh/thẩm định tĩnh, còn đgl thanh tra hay kiểm tra (Software Inspection) V Không thực hiện chương trình V Chỉ xem xét yêu cầu, thiết kế, mã nguồn V Tiến hành ở mọi công đoạn phát triển V Hạn chế : khó đánh giá tính hiệu quả của sản phẩm a Xác minh/thẩm định động, là giai đoạn kiểm thử (Software Testing) V Thực hiện (chạy) chương trình để tìm lỗi lập trình V Cần có mã nguồn V Để đánh giá tính hiệu quả, hay chất lượng phần mềm 12/ 12/ 57 57 Đặc điểm của kiểm thử PM a Trong hầu hết tiến trình PM : V Kiểm thử PM không khẳng định được PM không còn khiếm khuyết V Chỉ khẳng định được PM có lỗi và giúp giảm thiểu lỗi a Quá trình kiểm thử PM là tốt khi : V Có khả năng tìm ra lỗi cao V Không dư thừa các hoạt động vô ích, hay có tác dụng ngược V Biết cách chọn lọc : Chỉ kiểm thử những phần nào có khả năng tìm ra lỗi đặc trưng V Không quá phức tạp, cũng không quá đơn giản Nhap môn CNPM Ch.4 Kiểm thử 3 13/ 13/ 57 57 M M ộ ộ t s t s ố ố công c công c ụ ụ tr tr ợ ợ gi gi ú ú p p kiểm thử a a Hi Hi ệ ệ n nay c n nay c ó ó nhi nhi ề ề u công c u công c ụ ụ tr tr ợ ợ gi gi ú ú p p kiểm thử PM, thường gặp là : V V TestTrack Pro TestTrack Pro V V DMS for Defect Management DMS for Defect Management V V Rational Robot Functional Test Tool Rational Robot Functional Test Tool V V Rational Performance Test Tool Rational Performance Test Tool V V Virtual Ruler and Eye Dropper for Graphic Test Virtual Ruler and Eye Dropper for Graphic Test 14/ 14/ 57 57 Các nguyên lý kiểm thử PM a Không thể kiểm thử triệt để một PM a Việc kiểm thử nên : V Do những người không tham gia phát triển PM thực hiện V Được lập kế hoạch trước khi phát triển PM một thời gian dài V Hướng về yêu cầu của khách hàng V Nên tiến hành từ nhỏ đến lớn : Bắt đầu từ những đơn thể riêng biệt rồi sau đótích hợp các đơn thể lại a Áp dụng nguyên lý Pareto (80-20) : V 80% lỗi có nguyên nhân từ 20% các đơn thể cô lập V Chỉ kiểm tra những đơn thể khả nghi nhất 15/ 15/ 57 57 Cài đặt và chuẩn bị Test Cài đặt và chuẩn bị Test Bắt đầu Bắt đầu Lập kế hoạch Test Lập kế hoạch Test Thiết kế Test Thiết kế Test Test tích hợp Test tích hợp Kết thúc Kết thúc Test hệ thống Test hệ thống Tổng hợp, báo cáo Tổng hợp, báo cáo Xem xét và đánh giá kết quả test Xem xét và đánh giá kết quả test Phân tích kết quả Chuẩn bị Test Lập kế hoạch C C á á c ho c ho ạ ạ t đ t đ ộ ộ ng ki ng ki ể ể m th m th ử ử a Các bước chính 16/ 16/ 57 57 Sản phẩm chính Kế hoạch test Test case Test procedure Test scrip Test data Môi trường Lỗi Biên bản test Bcáo KQ test Đề xuất Bcáo tổng hợp test Hồ sơ e e c c c e e c Cài đặt và chuẩn bị Test Cài đặt và chuẩn bị Test Bắt đầu Bắt đầu Lập kế hoạch Test Lập kế hoạch Test Thiết kế Test Thiết kế Test Test tích hợp Test tích hợp Kết thúc Kết thúc Test hệ thống Test hệ thống Tổng hợp, báo cáo Tổng hợp, báo cáo Xem xét và đánh giá kết quả test Xem xét và đánh giá kết quả test 17/ 17/ 57 57 Chiến thuật kiểm thử PM a Chiến thuật kiểm thử PM : V Tích hợp các phương pháp tạo ra các ca kiểm thử (Test Case) V Xây dựng chuỗi các công việc có thứ tự để có thể kiểm thử PM thành công với chi phí thấp a Bao gồm các công việc V Lập kế hoạch kiểm thử V Xây dựng các ca (trường hợp) kiểm thử a Một số chiến thuật kiểm thử (Testing) : V Kiểm thử đơn thể/đơn vị (Unit Testing) V Kiểm thử (Integration Testing) V kiểm thử hướng đối tượng (OO Testing) V Kỹ thuật gỡ rối (Debugging) 18/ 18/ 57 57 Chiến thuật kiểm thử hình chữ V Phát triển Phát triển kiểm thử kiểm thử Phân tích toàn bộ hệ thống kiểm thử toàn bộ hệ thống Phân tích yêu cầukiểm thử tính năng Thiết kế kiểm thử tích hợp Mã hóa kiểm thử đơn thể Nhap môn CNPM Ch.4 Kiểm thử 4 19/ 19/ 57 57 Một số kinh nghiệm a Sau giai đoạn thiết kế, mã hoávàbiên dịch hoàn tất : V Người phát triển PM có thể tự kiểm thử PM của mình V Nhưng với các dự án lớn, cần phải do một nhóm chuyên gia độc lập tiến hành a Dưới đây là một số kinh nghiệm trong kiểm thử V Kiểm thử bắt đầu tại từng đơn thể rồi tích hợp lớn dần đến toàn bộ hệ thống V Mỗi giai đoạn sử dụng một kỹ thuật kKiểm thử thích hợp V kiểm thử hoạt động độc lập với sửa lỗi, nhưng sửa lỗi phải phù hợp với chiến thuật kiểm thử 20/ 20/ 57 57 Kiểm thử từng đơn thể a Trong kiểm thử đơn thể, người kiểm thử tiến hành : V Kiểm thử từng đơn vị nhỏ nhất của mã nguồn, là các đơn thể V Có thể tiến hành kiểm thử cùng lúc nhiều đơn thể V Thường được sử dụng trong lập trình cấu trúc (Top-Down Programing) a Gọi M là đơn thể cần kiểm thử, có hai khả năng hay gặp : V Sử dụng “cuống” (Stubs) khi những đơn thể do M gọi tới không có mặt lúc kiểm thử V Sử dụng “trình gọi” (Driver) khi những đơn thể gọi tới M không có mặt lúc kiểm thử a Tùy trường hợp có thể sử dụng một hoặc cả hai khả năng 21/ 21/ 57 57 Trường hợpsử dụng Stubs a Những đơn thể do M gọi tới không có mặt lúc kiểm thử V V Khi đ Khi đ ó ó , nh , nh ữ ữ ng đơn th ng đơn th ể ể v v ắ ắ ng m ng m ặ ặ t ph t ph ả ả i đư i đư ợ ợ c thay th c thay th ế ế b b ở ở i i c c á á c tr c tr ì ì nh đgl nh đgl “ “ cu cu ố ố ng ng “ “ (Stubs) c (Stubs) c ó ó c c ù ù ng giao di ng giao di ệ ệ n v n v ớ ớ i M i M V V C C á á c tr c tr ì ì nh nh “ “ cu cu ố ố ng ng “ “ th th ự ự c hi c hi ệ ệ n đ n đ ú ú ng ch ng ch ứ ứ c năng c năng m m à à ch ch ú ú ng đ ng đ ạ ạ i di i di ệ ệ n cho đơn th n cho đơn th ể ể v v ắ ắ ng m ng m ặ ặ t t Đơn thể M Đơn thể M Các trình Stubs C C á á c tr c tr ì ì nh Stubs nh Stubs Các đơn thể vắng mặt C C á á c đơn th c đơn th ể ể v v ắ ắ ng m ng m ặ ặ t t 22/ 22/ 57 57 V V í í d d ụ ụ sử dụng Stubs a a Gi Gi ả ả s s ử ử đơn th đơn th ể ể ki ki ể ể m th m th ử ử M g M g ọ ọ i th i th ủ ủ t t ụ ụ c s c s ắ ắ p x p x ế ế p : p : Procedure Procedure Sort Sort (T: (T: Array Array ; ; n: n: Integer Integer ) ) ; ; tuy nhiên th tuy nhiên th ủ ủ t t ụ ụ c c Sort Sort v v ắ ắ ng m ng m ặ ặ t t a a Ngư Ngư ờ ờ i ta c i ta c ó ó th th ể ể s s ử ử d d ụ ụ ng tr ng tr ì ì nh Stub thay th nh Stub thay th ế ế : : Procedure Procedure Sort Sort (T: (T: Array Array ; ; n: n: Integer Integer ) ) ; ; Writeln Writeln ( ( ‘ ‘ Dãy c Dãy c ầ ầ n s n s ắ ắ p x p x ế ế p l p l à à : : ‘ ‘ ) ) ; ; For For i:= 1 i:= 1 To To n n Do Do writeln writeln (T[i]) (T[i]) ; ; For For i:= 1 i:= 1 To To n n Do Do readln readln (T[i]) (T[i]) ; ; a a Ti Ti ế ế p theo, p theo, ngư ngư ờ ờ i ki i ki ể ể m th m th ử ử s s ẽ ẽ s s ắ ắ p x p x ế ế p dãy đã nh p dãy đã nh ậ ậ p p b b ằ ằ ng tay đ ng tay đ ể ể thay th thay th ế ế cho th cho th ủ ủ t t ụ ụ c s c s ắ ắ p x p x ế ế p v p v ắ ắ ng m ng m ặ ặ t t 23/ 23/ 57 57 Trường hợpsử dụng Drive a Những đơn thể gọi tới M không có mặt lúc kiểm thử V Khi đó, đơn thể gọi tới M nhưng vắng mặt phải được thay thế bởi một “trình gọi” (Driver) V Trình Driver gọi M để M thực hiện trên tập dữ liệu thử, sau đó so sánh kết quả tính được với các kết quả chờ đợi Đơn thể M Đơn thể M Trình gọi Tr Tr ì ì nh g nh g ọ ọ i i Các đơn thể vắng mặt C C á á c đơn th c đơn th ể ể v v ắ ắ ng m ng m ặ ặ t t 24/ 24/ 57 57 Kiểm thử t t í í ch h ch h ợ ợ p p a Mục đích kiểm thử t t í í ch h ch h ợ ợ p : p : V V Đ Đ ể ể t t ạ ạ o m o m ố ố i liên k i liên k ế ế t gi t gi ữ ữ a c a c á á c đơn th c đơn th ể ể V V V V ừ ừ a a kiểm thử nh nh ữ ữ ng đơn th ng đơn th ể ể l l ớ ớ n n h h ì ì nh th nh th à à nh h nh h ệ ệ th th ố ố ng chương tr ng chương tr ì ì nh ho nh ho à à n ch n ch ỉ ỉ nh nh a a C C ó ó nhi nhi ề ề u phương ph u phương ph á á p ki p ki ể ể m th m th ử ử t t í í ch h ch h ợ ợ p : p : V V Phương ph Phương ph á á p p “ “ big bang big bang ” ” V V Phương ph Phương ph á á p ki p ki ể ể m th m th ử ử t t ừ ừ trên xu trên xu ố ố ng ng (Descendant, (Descendant, hay hay Top Top - - down Testing Method) down Testing Method) V V Phương ph Phương ph á á p ki p ki ể ể m th m th ử ử t t ừ ừ dư dư ớ ớ i lên i lên (Ascendant, (Ascendant, hay hay Bottom Bottom - - Up Testing Method) Up Testing Method) V V ki ki ể ể m th m th ử ử h h ệ ệ th th ố ố ng ng V V ki ki ể ể m th m th ử ử h h ồ ồ i quy i quy Nhap môn CNPM Ch.4 Kiểm thử 5 25/ 25/ 57 57 Phương ph Phương ph á á p p “ “ big bang big bang ” ” a a N N ộ ộ i dung phương ph i dung phương ph á á p : p : V V Xây d Xây d ự ự ng m ng m ộ ộ t phiên b t phiên b ả ả n h n h ệ ệ th th ố ố ng ho ng ho à à n ch n ch ỉ ỉ nh nh g g ồ ồ m t m t ấ ấ t c t c ả ả đơn th đơn th ể ể đ đ ể ể ti ti ế ế n h n h à à nh ki nh ki ể ể m th m th ử ử V V M M ỗ ỗ i đơn th i đơn th ể ể c c ủ ủ a h a h ệ ệ th th ố ố ng đ ng đ ề ề u s u s ử ử d d ụ ụ ng m ng m ộ ộ t tr t tr ì ì nh Drivers nh Drivers v v à à m m ộ ộ t tr t tr ì ì nh Stubs, tr nh Stubs, tr ừ ừ đơn th đơn th ể ể ch ch í í nh ph nh ph ả ả i đư i đư ợ ợ c ki c ki ể ể m th m th ử ử b b ằ ằ ng phương ph ng phương ph á á p ki p ki ể ể m th m th ử ử đơn v đơn v ị ị a a Phương ph Phương ph á á p p “ “ big bang big bang ” ” nguy hi nguy hi ể ể m : m : V V M M ọ ọ i sai s i sai s ó ó t c t c ó ó th th ể ể đ đ ồ ồ ng th ng th ờ ờ i xu i xu ấ ấ t hi t hi ệ ệ n, n, nhưng kh nhưng kh ó ó x x á á c đ c đ ị ị nh nh V V Đòi h Đòi h ỏ ỏ i m i m ộ ộ t lư t lư ợ ợ ng t ng t ố ố i đa c i đa c á á c tr c tr ì ì nh Drivers v nh Drivers v à à c c á á c tr c tr ì ì nh Stubs nh Stubs a a Th Th ự ự c t c t ế ế , n , n gư gư ờ ờ i ta i ta í í t s t s ử ử d d ụ ụ ng phương ph ng phương ph á á p p “ “ big bang big bang ” ” m m à à s s ử ử d d ụ ụ ng t ng t í í ch h ch h ợ ợ p t p t ừ ừ trên xu trên xu ố ố ng, hay t ng, hay t ừ ừ dư dư ớ ớ i lên i lên 26/ 26/ 57 57 Kiểm t h h ử ử t t ừ ừ trên xu trên xu ố ố ng ng a a Hay còn đgl Hay còn đgl phương ph phương ph á á p l p l ù ù i i . N . N ộ ộ i dung phương ph i dung phương ph á á p : p : V V B B ắ ắ t đ t đ ầ ầ u ki u ki ể ể m th m th ử ử đơn th đơn th ể ể ch ch í í nh nh V V Sau đ Sau đ ó ó ki ki ể ể m th m th ử ử c c á á c đơn th c đơn th ể ể do đơn th do đơn th ể ể ch ch í í nh g nh g ọ ọ i đ i đ ế ế n, v.v n, v.v V V Ch Ch ỉ ỉ d d ù ù ng m ng m ộ ộ t tr t tr ì ì nh Driver duy nh nh Driver duy nh ấ ấ t cho đơn th t cho đơn th ể ể ch ch í í nh, nh, nhưng m nhưng m ỗ ỗ i đơn th i đơn th ể ể còn l còn l ạ ạ i đ i đ ề ề u c u c ầ ầ n m n m ộ ộ t tr t tr ì ì nh Stubs nh Stubs Level 2 stubs Level 2 stubs Level 1 Level 1 Level 1 Level 1 Dãy các kiểm thử Dãy các kiểm thử Level 3 stubs Level 3 stubs Level 2 Level 2 Level 2 Level 2 Level 2 Level 2 Level 2 Level 2 27/ 27/ 57 57 Ví dụ kiểm t h h ử ử t t ừ ừ trên xu trên xu ố ố ng ng a a Gi Gi ả ả s s ử ử A l A l à à đơn th đơn th ể ể ch ch í í nh ki nh ki ể ể m th m th ử ử đ đ ầ ầ u tiên v u tiên v ớ ớ i 1 Drive i 1 Drive 1. 1. A, stub(B), stub(C) A, stub(B), stub(C) 2. 2. A, B, stub(C), stub(D), stub(E), stub(F) A, B, stub(C), stub(D), stub(E), stub(F) 3. 3. A, B, C, stub(G), stub(D), stub(E), stub(F) A, B, C, stub(G), stub(D), stub(E), stub(F) 4. 4. A, B, C, D, stub(G), stub(E), stub(F) A, B, C, D, stub(G), stub(E), stub(F) 5. 5. A, B, C, D, E, stub(G), stub(F) A, B, C, D, E, stub(G), stub(F) 6. 6. A, B, C, D, E, F, stub(G), stub(H) A, B, C, D, E, F, stub(G), stub(H) 7. 7. A, B, C, D, E, F, G, stub(H) A, B, C, D, E, F, G, stub(H) 8. 8. A, B, C, D, E, F, G, H A, B, C, D, E, F, G, H 28/ 28/ 57 57 Kiểm t h h ử ử t t ừ ừ dư dư ớ ớ i lên i lên a a Hay còn đgl Hay còn đgl phương ph phương ph á á p ti p ti ế ế n n . N . N ộ ộ i dung phương ph i dung phương ph á á p p : : V V ki ki ể ể m th m th ử ử c c á á c đơn th c đơn th ể ể không g không g ọ ọ i đ i đ ế ế n c n c á á c đơn th c đơn th ể ể kh kh á á c c V V Ti Ti ế ế p t p t ụ ụ c c c c á á c đơn th c đơn th ể ể g g ọ ọ i đ i đ ế ế n c n c á á c đơn th c đơn th ể ể đã ki đã ki ể ể m th m th ử ử V V Đòi h Đòi h ỏ ỏ i m i m ỗ ỗ i đơn th i đơn th ể ể m m ộ ộ t Driver, không c t Driver, không c ầ ầ n Stub n Stub Mức N Mức N Mức N Mức N Mức N Mức N Mức N Mức N Mức N Mức N Mức N-1 Mức N-1 Mức N-1 Mức N-1 Mức N-1 Mức N-1 29/ 29/ 57 57 Ví dụ kiểm t h h ử ử t t ừ ừ dư dư ớ ớ i lên i lên a a B B ắ ắ t đ t đ ầ ầ u ki u ki ể ể m th m th ử ử t t ừ ừ đơn th đơn th ể ể D D ở ở m m ứ ứ c th c th ấ ấ p nh p nh ấ ấ t t 1. 1. D, driver(D) D, driver(D) 2. 2. E, driver(E) E, driver(E) 3. 3. H, driver(H) H, driver(H) 4. 4. G, driver(G) G, driver(G) 5. 5. H, F, driver(F) H, F, driver(F) 6. 6. D, E, F,B, driver(B), driver(F) D, E, F,B, driver(B), driver(F) 7. 7. H, F, G, C, driver(C), driver(F) H, F, G, C, driver(C), driver(F) 8. 8. D, E, H, G, F, B, C, A D, E, H, G, F, B, C, A 30/ 30/ 57 57 Đánh giá PP kiểm t h h ử ử t t ừ ừ dư dư ớ ớ i lên i lên a a Phương ph Phương ph á á p ti p ti ế ế n t n t ỏ ỏ ra ưu đi ra ưu đi ể ể m hơn phương ph m hơn phương ph á á p l p l ù ù i : i : V V Do c Do c á á c tr c tr ì ì nh Driver s nh Driver s ử ử d d ụ ụ ng đ ng đ ế ế n d n d ễ ễ vi vi ế ế t hơn c t hơn c á á c tr c tr ì ì nh Stubs nh Stubs V V Thư Thư ờ ờ ng c ng c ó ó công c công c ụ ụ đ đ ể ể t t ạ ạ o sinh t o sinh t ự ự đ đ ộ ộ ng c ng c á á c tr c tr ì ì nh Drivers nh Drivers V V Th Th ứ ứ t t ự ự t t í í ch h ch h ợ ợ p thư p thư ờ ờ ng b ng b ị ị r r à à ng bu ng bu ộ ộ c b c b ở ở i th i th ứ ứ t t ự ự c c ó ó m m ặ ặ t t c c ủ ủ a c a c á á c đơn th c đơn th ể ể Nhap môn CNPM Ch.4 Kiểm thử 6 31/ 31/ 57 57 M M ộ ộ t t PP ki ki ể ể m th m th ử ử kh kh á á c (1) c (1) a a Sandwich testing: Sandwich testing: V V A, stub(B), stub(C) A, stub(B), stub(C) V V A, B, stub(C), stub(D), stub(E), stub(F) A, B, stub(C), stub(D), stub(E), stub(F) V V A, B, C, stub(G), stub(D), stub(E), stub(F) A, B, C, stub(G), stub(D), stub(E), stub(F) V V D, driver(D) D, driver(D) V V E, driver(E) E, driver(E) V V H, driver(H) H, driver(H) V V G, driver(G) G, driver(G) V V H, F, driver(F) H, F, driver(F) V V A, B, C, D, E, F, G, H A, B, C, D, E, F, G, H 32/ 32/ 57 57 M M ộ ộ t t PP ki ki ể ể m th m th ử ử kh kh á á c (2) c (2) a a Build testing: Build testing: V V A, stub(B), stub(C) A, stub(B), stub(C) V V A, B, stub(C), stub(D), stub(E), stub(F) A, B, stub(C), stub(D), stub(E), stub(F) V V A, B, F, stub(H), stub(D), stub(E), stub(C) A, B, F, stub(H), stub(D), stub(E), stub(C) V V A, B, F, H, stub(D), stub(E), stub(C) A, B, F, H, stub(D), stub(E), stub(C) V V A, B, F, H, D, stub(E), stub(C) A, B, F, H, D, stub(E), stub(C) V V A, B, F, H, D, E, stub(C) A, B, F, H, D, E, stub(C) V V A, B, F, H, D, E, C, stub(G) A, B, F, H, D, E, C, stub(G) V V A, B, F, H, D, E, C, G A, B, F, H, D, E, C, G 33/ 33/ 57 57 Ki Ki ể ể m th m th ử ử h h ệ ệ th th ố ố ng ng a a N N ộ ộ i dung phương ph i dung phương ph á á p : p : V V Ti Ti ế ế n h n h à à nh ki nh ki ể ể m th m th ử ử ho ho à à n ch n ch ỉ ỉ nh to nh to à à n b n b ộ ộ ph ph ầ ầ n m n m ề ề m m v v à à s s ự ự tương h tương h ợ ợ p v p v ớ ớ i ph i ph ầ ầ n c n c ứ ứ ng ng V V Đ Đ á á nh gi nh gi á á hi hi ệ ệ u năng u năng , , đ đ ộ ộ an to an to à à n, n, t t í í nh tương h nh tương h ợ ợ p v p v ớ ớ i c i c á á c đ c đ ặ ặ c t c t ả ả yêu c yêu c ầ ầ u, v.v . . . u, v.v . . . a a Đ Đ ặ ặ c đi c đi ể ể m ki m ki ể ể m th m th ử ử h h ệ ệ th th ố ố ng : ng : V V Đòi h Đòi h ỏ ỏ i nhi i nhi ề ề u th u th ờ ờ i gian, công s i gian, công s ứ ứ c c V V Trong nhi Trong nhi ề ề u trư u trư ờ ờ ng h ng h ợ ợ p, PP n p, PP n à à y còn đgl y còn đgl ki ki ể ể m th m th ử ử ch ch ấ ấ p nh p nh ậ ậ n n (Acceptance Testing), (Acceptance Testing), 34/ 34/ 57 57 M M ộ ộ t s t s ố ố dạng ki ki ể ể m th m th ử ử h h ệ ệ th th ố ố ng kh ng kh á á c c a a Ki Ki ể ể m th m th ử ử c c à à i đ i đ ặ ặ t (Setup Testing) : t (Setup Testing) : V V ki ki ể ể m th m th ử ử s s ả ả n ph n ph ẩ ẩ m cu m cu ố ố i c i c ù ù ng ng V V Ti Ti ế ế n h n h à à nh t nh t ạ ạ i v i v ị ị tr tr í í c c ủ ủ a kh a kh á á ch h ch h à à ng ng (v (v ớ ớ i c i c á á c m c m á á y t y t í í nh v nh v à à h h ệ ệ đi đi ề ề u h u h à à nh h nh h ọ ọ đang s đang s ử ử d d ụ ụ ng) ng) a a Do t Do t í í nh ph nh ph ứ ứ c t c t ạ ạ p c p c ủ ủ a ph a ph ầ ầ n m n m ề ề m, m, ngư ngư ờ ờ i ta thư i ta thư ờ ờ ng ki ng ki ể ể m th m th ử ử h h ệ ệ th th ố ố ng dư ng dư ớ ớ i d i d ạ ạ ng : ng : V V ki ki ể ể m th m th ử ử Alpha Alpha V V ki ki ể ể m th m th ử ử Beta Beta 35/ 35/ 57 57 Ki Ki ể ể m th m th ử ử Alpha Alpha a Được tiến hành ngay tại nơi sản xuất PM a a C C ó ó th th ể ể do kh do kh á á ch h ch h à à ng, ng, NSD ti ti ế ế n h n h à à nh ki nh ki ể ể m th m th ử ử trên trên sản phẩm a a N N ộ ộ i dung : i dung : V V Ki Ki ể ể m tra s m tra s ả ả n ph n ph ẩ ẩ m c m c ó ó ph ph ù ù h h ợ ợ p v p v ớ ớ i h i h ợ ợ p đ p đ ồ ồ ng ng đã ký v đã ký v ớ ớ i kh i kh á á ch h ch h à à ng hay chưa ng hay chưa V Người phát triển PM quan sát NSD dùng sản phẩm và ghi nhận lại những lỗi phát sinh để sửa chữa 36/ 36/ 57 57 Kiểm thử Beta aPM được kiểm tra bên ngoài phạm vi của đơn vị sản xuất aNội dung V V ki ki ể ể m th m th ử ử cho phiên b cho phiên b ả ả n ( n ( Version/Release) Version/Release) đ đ ầ ầ u tiên c u tiên c ủ ủ a PM a PM V V L L ự ự a ch a ch ọ ọ n kh n kh á á ch h ch h à à ng n ng n à à o đư o đư ợ ợ c tham gia ki c tham gia ki ể ể m th m th ử ử , , v v í í d d ụ ụ c c á á c trư c trư ờ ờ ng đ ng đ ạ ạ i h i h ọ ọ c, vi c, vi ệ ệ n nghiên c n nghiên c ứ ứ u u V Khách hành trực tiếp sử dụng và ghi nhận lỗi để báo lại cho nhà phát triển sửa chữa Nhap môn CNPM Ch.4 Kiểm thử 7 37/ 37/ 57 57 Kiểm thử hồi quy a Còn đgl kiểm thử thoái lui (Regresgion Testing) : V Tiến hành sau khi sửa lỗi, thường ở giai đoạn bảo trì PM V Xác định các sai sót chưa được xử lý sau giai đoạn kiểm thử V Lưu giữ những kết quả kiểm thử đã tiến hành trong quá trình sản xuất PM a Khó khăn của phương pháp : V Chọn những kiểm thử nào cho kiểm thử thoái lui ? V Số lượng các kiểm thử đã triển khai thường rất lớn, dễ thay đổi 38/ 38/ 57 57 Kiểm thử hộp đen (BlackBox) a Thường áp dụng cho những PM lớn a Nội dung phương pháp : V Kiểm tra các chức năng cụ thể của PM V Không quan tâm cấu trúc bên trong 39/ 39/ 57 57 Kiểm thử hộp trắng (WhiteBox) a Thường dùng cho những những PM nhỏ a Nội dung phương pháp là kiểm tra cấu trúc điều khiển bên trong chương trình với tiêu chí : V Kiểm thử các đường độc lập trong dòng chảy của thuật giải V Bảo đảm số phép thử là ít nhất đủ để phát hiện các lỗi V Thử các điều kiện rẽ nhánh True và False V Thử vòng lặp tại biên cũng như bên trong V Thử cấu trúc dữ liệu để đảm bảo tính toàn vẹn của nó a Kiểm thử hộp đen và kiểm thử hộp trắng đều có khả năng tìm ra những nhóm lỗi khác nhau, trong thực tế nên kết hợp cả hai 40/ 40/ 57 57 V V í í d d ụ ụđồthị dòng chảy a Cách xây dựng : V Mỗi node hình tròn biểu diễn một hoặc một vài tác vụ (hơi khác so với lưu đồ thuật toán) V Cạnh có hướng miêu tả đường thực thi a Đồ thị dòng chảy được xây dựng từ lưu đồ thuật toán Sequence If Until While Case 41/ 41/ 57 57 Ví dụ xây dựng đồ thị dòng chảy a a T T ừ ừ sơ đ sơ đ ồ ồ kh kh ố ố i : i : 42/ 42/ 57 57 a a T T ừ ừ chương tr chương tr ì ì nh : nh : Procedure: DoSomething 1: do while x=0 2: if y=0 then 3: z=0; 4: elseif k=0 then 5: z=1; 6: else x=1; 7: endif ; endif ; 8: enddo 9: end Nhap môn CNPM Ch.4 Kiểm thử 8 43/ 43/ 57 57 Kỹ thuật gỡ rối (Debugging) a Gỡ rối : V Là công việc khó khăn và dễ gây tâm lý chán nản V Nhiều nguyên nhân gây ra lỗi, nhưng nhiều khi lại mơ hồ :  Do timeout  Do độ chính xác  Do chủ quan khi lập trình a Mỗi lập trình viên, hay kiểm thử viên đều có khả năng gỡ rối a Có nhiều phương pháp gỡ rối : V Brute Force V Loại trừ nguyên nhân V Theo vết 44/ 44/ 57 57 Phương pháp Brute Force a Là phương pháp phổ biến nhất nhưng lại ít hiệu quả nhất cho việc phát hiện nguyên nhân gây lỗi phần mềm a Triết lý của phương pháp này là để máy tính tự tìm ra lỗi a Áp dụng phương pháp này khi tất cả các phương pháp khác đều thất bại a Có 3 cách thực hiện : V Lấy dữ liệu trong bộ nhớ để xem xét V Dùng Run-Time Trace để tìm lỗi V Dùng lệnh Write để in ra màn hình dữ liệu cần kiểm tra 45/ 45/ 57 57 Loại trừ nguyên nhân a Phương pháp này dựa trên nguyên tắc phân chia nhị phân a Cách thực hiện: V Khi một lỗi được phát hiện, cố gắng đưa ra một danh sách các nguyên nhân có thể gây ra lỗi V Danh sách này được kiểm nghiệm lại để loại bỏ dần các nguyên nhân không đúng cho đến khi tìm thấy một nguyên nhân khả nghi nhất V Khi đódữ liệu kiểm nghiệm sẽ được tinh chế lại để tiếp tục tìm lỗi 46/ 46/ 57 57 Theo vết a Là phương pháp gỡ lỗi khá phổ biến V Có thể dùng thành công trong các chương trình nhỏ V Khó áp dụng cho các chương trình rất lớn a Cách thực hiện : V Bắt đầu tại dòng mã nguồn có triệu chứng lỗi thực hiện lần ngược trở lại từng dòng mã nguồn cho đến khi tìm thấy dòng gây ra lỗi 47/ 47/ 57 57 Summary Summary aTesting is still a black art , but many rules and heuristics are available aTesting consists of component-testing (unit testing, integration testing) and system testing, and … aOOT and architectural testing, still challenging aUser-oriented reliability modeling and evaluation not adequate aTesting has its own lifecycle a a Testing is still a Testing is still a black art black art , , but many rules and heuristics are available but many rules and heuristics are available a a Testing consists of Testing consists of component component - - testing testing ( ( unit testing, integration testing) unit testing, integration testing) and system testing and system testing , and , and … … a a OOT and architectural testing, still challenging OOT and architectural testing, still challenging a a User User - - oriented reliability modeling oriented reliability modeling and evaluation not adequate and evaluation not adequate a a Testing has its own lifecycle Testing has its own lifecycle 48/ 48/ 57 57 What is this? What is this? A failure? An error? A fault? Need to specify the desired behavior first! Nhap môn CNPM Ch.4 Kiểm thử 9 49/ 49/ 57 57 Erroneous State ( Erroneous State ( “ “ Error Error ” ” ) ) 50/ 50/ 57 57 Algorithmic Fault Algorithmic Fault 51/ 51/ 57 57 Mechanical Fault Mechanical Fault 52/ 52/ 57 57 How do we deal How do we deal with Errors and Faults? with Errors and Faults? 53/ 53/ 57 57 Verification? Verification? 54/ 54/ 57 57 Modular Redundancy? Modular Redundancy? Nhap môn CNPM Ch.4 Kiểm thử 10 55/ 55/ 57 57 Declaring the Bug Declaring the Bug as a Feature? as a Feature? 56/ 56/ 57 57 Patching? Patching? 57/ 57/ 57 57 Testing? Testing? . Chương 4 4 . . Ki Ki ể ể m th m th ử ử PM PM a Khái niệm kiểm thử PM (Software Testing) a Các nguyên lý kiểm thử PM a Các chiến lược kiểm thử PM a Nghệ. Engineering Chương 4. Kiểm thử PM Chương Chương 4 4 . . Ki Ki ể ể m th m th ử ử PM PM PGS.TS. Phan Huy Khánh khanhph29@gmail.com, phkhanh@dut.udu.vn 2/ 2/ 57 57 Chương