Công nghệ phần mềm - Chương 4 kiểm thử PM

Chia sẻ: Nguyen Van Dai | Ngày: | Loại File: PDF | Số trang:10

Thêm vào BST

Báo xấu

225
lượt xem 31
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Chương 4. Kiểm thử PM Khái niệm kiểm thử PM (Software Testing) Các nguyên lý kiểm thử PM Các chiến lược kiểm thử PM Nghệ thuật gỡ rối Thế nào là kiểm thử PM Kiểm thử PM là Thực hiện (chạy) phần mềm Thự hiệ (chạ phầ mề trong một môi trường mô phỏng hay thực tế, mộ trườ phỏ thự tế bằng cách sử dụng các yếu tố đầu vào được lựa chọn cá sử cá yế tố đầ và đượ lự chọ theo cách nào đó cá nà đó Tại sao phải kiểm thử PM Trong tiến trình PM : Mặc dù được tự...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Công nghệ phần mềm - Chương 4 kiểm thử PM

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