Kỹ thuật kiểm thử phần mềm

Kỹ thuật kiểm thử phần mềmGV: Th.s Nguyễn Quang VũKỸ THUẬT KIỂM THỬ PHẦN MỀMPHẦN MỀM VÀ LỖI PHẦN MỀM1KỸ THUẬT KIỂM THỬ PHẦN MỀM 2CHIẾN LƯỢC KIỂM THỬ PHẦN MỀM3QUY TRÌNH KIỂM THỬ PHẦN MỀM4KỸ THUẬT KIỂM THỬ ĐỘT BIẾN 5THỰC HÀNH: THIẾT KẾ TESTCASE6Chương 1. Phần mềm và lỗi phần mềmCông nghệ phần mềm (CNPM) ?Các tác vụ chủ yếu của CNPM:Thiết kếXây dựngKiểm thửBảo trìMục tiêu của CNPM:Tạo ra phần mềm tốtGiảm thiểu sai sót trong quá trình vận hànhThuận lợi trong bảo trì và nâng cấpChương 1. Phần mềm và lỗi phần mềmPhần mềm ?là một tập các đoạn mã hoặc câu lệnh viết ra để cài đặt trên máy tính nhằm thực hiện một hoặc một nhóm chức năng nào đó.Các công việc để tạo ra một phần mềm:Phân tích – Đặc tả yêu cầuThiết kếLập trìnhKiểm thửViết tài liệuBảo trìChương 1. Phần mềm và lỗi phần mềmCó nhiều quy trình phần mềm khác nhau (Software Development Process – SEP)Đóng vai trò quyết định chất lượng PM.Các nhóm công việc được triển khai theo những cách khác nhau.Có 4 nhóm công việc nền tảng: Đặc tả yêu cầu – Phát triển – Kiểm thử - Cài đặt và bảo trìMột PM có thể dùng nhiều mô hình khác nhau.Không phải tất cả các mô hình đều thích hợp cho mọi phần mềm ứng dụngChương 1. Phần mềm và lỗi phần mềmVì các yếu tố (đặc điểm) sau: Đặc tính (Characteristics ).Tính đáp ứng (responsiveness )Loại (Type)Chương 1. Phần mềm và lỗi phần mềmCác đặc tính của phần mềm: Dữ liệuXử lýRàng buộc: Thứ tự trước – Thứ tự sau – Thời gian – Cấu trúc – Điều khiển – Suy diễnGiao diện: Người sử dụng – Thủ công – Giao diện chuẩn hóa (Giao diện mạng LAN; Chuẩn OSI;)Chương 1. Phần mềm và lỗi phần mềmChương 1. Phần mềm và lỗi phần mềmChương 1. Phần mềm và lỗi phần mềmPhân loại phần mềm: Chương 1. Phần mềm và lỗi phần mềmCó thể phân loại PM theo sự định hướng công việc: Ứng dụng hướng giao dịchỨng dụng CSDLỨng dụng hỗ trợ quyết địnhHệ chuyên giaHệ thống nhúngChương 1. Phần mềm và lỗi phần mềmChất lượng phần mềm: Các nhân tố ảnh hưởng đến chất lượng PM có thể làNhân tố đo trực tiếpNhân tố đo gián tiếpChương 1. Phần mềm và lỗi phần mềmCác tiêu chuẩn chất lượng phần mềm có thể thay đổi tùy theo:Công dụngNhu cầu thực tếChuẩn quốc gia, quốc tếNền văn minh cộng đồngThời điểmChương 1. Phần mềm và lỗi phần mềmCác tiêu chuẩn phải đảm bảo những thuộc tính TỐI QUAN TRỌNG:Khả năng bảo trìKhả năng tin cậyĐộ hữu hiệuKhả năng sử dụngLỗi phần mềmThế nào là phần mềm được gọi là đúng ?Để đánh giá CẤP ĐỘ ĐÚNG của phần mềm, phải kiểm tra CHẤT LƯỢNG PHẦN MỀMLỗi phần mềmLỗi phần mềm xảy ra ở tất cả các công đoạnLỗi phần mềmĐịnh nghĩa LỖI PHẦN MỀM?Lỗi phần mềm là sự không khớp giữa chương trình và đặc tả của nó Lỗi phần mềm xuất hiện nhiều nhất ở công đoạn nào ?Đặc tả: ~ 70%Đặc tảNguyên nhân khácLập trìnhThiết kếLỗi phần mềmNguyên nhân làm đặc tả nhiều lỗi ?Đặc tả không được viết raĐặc tả không đủ cẩn thậnĐặc tả thay đổiChưa phối hợp tốt trong nhómLỗi phần mềmVí dụ: Bài toán phân sốĐặc tả phi hình thức: phân số là một cặp t/m, trong đó t là một số nguyên, m là một số tự nhiên lớn hơn 0; t được gọi là tử số, m được gọi là mẫu số của phân số Đặc tả hình thức: là đặc tả trong đó sử dụng các ký hiệu toán học để mô tả. Phân số = {(t,m) | t  Z, m  N+} (*)Trong đó: N = {0, 1, 2, 3, } N+ = {1, 2, 3, } Z = {0, 1, 2, 3, }Lỗi phần mềmVí dụ (tt): Xét đặc tả phép chia hai phân số(t1,m1):(t2,m2) = Reduce(t1 m2, t2  m1), trong đó Reduce(t, m) = (t/d, m/d) với d = gcd(t, m) Hàm gcd là hàm tìm ước số chung lớn nhất của hai số tự nhiên.Bây giờ, hãy thực hiện chia hai phân số: (1,3):(-2,5)? Lỗi phần mềmVí dụ: Chia nhóm và mỗi nhóm tìm một bài toán (đặc tả phi hình thức, đặc tả hình thức, và một trường hợp có thể không đúng với đặc tả) Các lỗi phần mềm thường gặpSản phẩm phần mềm được được xây dựng thiếu, sai, thừa so với đặc tả được xem là có lỗi.Thậm chí, một phần mềm khó hiểu, khó sử dụng, thực thi chậm, cũng được xem là lỗi.Các lỗi phần mềm thường gặpLỗi chiến lượcPhân tích không đủ yêu cầu hoặc lệch lạcHiểu sau về chức năngVi phạm nguyên lý đối tượngNguyên lý đóng – mởNguyên lý nghịch đảo phụ thuộcNguyên lý thay thế LiskovNguyên lý phân tách InterfaceCác lỗi phần mềm thường gặp (tt)Lỗi các thủ tục chịu tảiLỗi lây lanLỗi cú phápLỗi hiệu ứng phụCác lỗi phần mềm thường gặp (tt)Ví dụ: chương trình tính tiền lương được đặc tả cho từng nhân viên theo qui định làm tròn đến hàng đơn vị, với công thức (1.1) Lươngi = round(hsli*lcb(1- 0.06),0 ) (1.1)Nhưng khi lập trình:Lươngi = round(hsli *lcb(1- 0.06),-2 ) (1.2)Các lỗi phần mềm thường gặp (tt)Ví dụ: Như vậy dẫn đến sai số như sauSttHọc và tênhslCT(1.1)CT(1.2)Chênh lệnhtiền lương1Lê Ngọc Anh3,991.312.7101.312.700-102Trần ThịBình2,34 769.860 769.900+403Nguyễn VănNam4,321.421.2801.421.300+204Bùi AnhVũ2,67 878.430 878.400-30Tổng cộng4.382.2804.382.300+20Các lỗi phần mềm thường gặp (tt)Đặc tả thiếu: Một yêu cầu đã được đặc tả nhưng lại không có trong sản phẩm được xây dựng. Ví dụ: Chương trình quản lý tính vốn vay, khi ngân hàng cho vay vốn thì việc tính lãi được qui định theo hai phương thức là tính lãi đơn và tính lãi kép. Nhưng khi thiết kế thì chương trình chỉ tính lãi đơn không tính lãi kép. Do vậy, chương trình không đưa vào ứng dụng ngay được mà phải sửa chữa cập nhật lại. Các lỗi phần mềm thường gặp (tt)Đặc tả thừa: Một yêu cầu được đưa vào sản phẩm mà không có trong đặc tả. Cũng có trường hợp yêu cầu này có thể là một thuộc tính sẽ được người dùng chấp nhận nhưng khác với đặc tả nên vẫn coi là có lỗi.Ví dụ: ????Chi phí cho việc sửa lỗi phần mềmKiểm thử và sửa lỗi có thể được thực hiện tại bất kỳ giai đoạn nào của vòng đời phần mềm Chi phí cho việc tìm và sửa lỗi tăng một cách đáng kể theo quá trình phát triển:Không đáng kể khi thay đổi yêu cầu ở lần duyệt yêu cầu đầu tiênTăng lên gấp bội khi thay đổi yêu cầu lúc đã lập trìnhKhông đáng kể nếu lập trình viên tự phát hiện lỗi của mìnhChi phí cho việc sửa lỗi phần mềm“Sửa một lỗi trước khi phát hành một phần mềm sẽ tốn chi phí ít hơn rất nhiều so với việc khắc phục nó sau khi đã phát hành. ”Lỗi được phát hiện càng muộn thì chi phí cho việc sữa lỗi càng lớn Chi phí cho việc sửa lỗi phần mềmChi phí để sữa lỗi Đặc tả Thiết kế lập trình Kiểm thử Phát hànhChi phí cho việc sửa lỗi phần mềm Ví dụ: Sự cố Y2K.Đảm bảo chất lượng phần mềmMục đích của nhóm phát triển PM là có PM chất lượng cao Hạn chế thấp nhất việc phát sinh lỗiĐảm bảo chất lượng phần mềm là một hoạt động có hệ thống và kế hoạchĐảm bảo chất lượng phần mềmĐảm bảo chất lượng phần mềm gồm nhiều nhiệm vụ liên kết và các hoạt động chính sau:Áp dụng các phương pháp kỹ thuật,Tiến hành các cuộc xét duyệt kỹ thuật chính thức,Kiểm thử phần mềm,Buộc tôn trọng các chuẩn,Kiểm soát thay đổi,Đo chất lượng,Báo cáo, lưu giữ kết quả.Đảm bảo chất lượng phần mềmĐảm bảo chất lượng phần mềm là một hoạt động BẢN CHẤT cho bất kỳ nhóm phát triển PM nào.Có hai kỹ thuật để tăng độ tin cậy của phần mềm:Tránh lỗiThứ lỗiĐảm bảo chất lượng phần mềmTránh lỗiĐặc tả hệ thống chính xácTăng cường duyệt và thẩm địnhChấp nhận triết lý chất lượng tổ chức: chất lượng là bánh lái của quá trình phát triển phần mềm. Lập kế hoạch cẩn thẩn cho việc thử nghiệm hệ thốngĐảm bảo chất lượng phần mềmThứ lỗiMột hệ vô lỗi thì vẫn cần một tiện ích thứ lỗi: đó là vì có thể có các lỗi đặc tả Một tiện ích thứ lỗi là cần thiết cho một hệ thống đáng tin cậyĐảm bảo chất lượng phần mềm4 hoạt động cần tiến hành để THỨ LỖIPhát hiện lỗiĐịnh ra mức độ thiệt hạiHồi phục sau khi gặp lỗi: Hồi phục tiến hoặc Hồi phục lùiChữa lỗi. (Lưu ý các lỗi “tàng hình”)Xác minh và Thẩm địnhV&V – Verification and Validation Là một quá trình liên tục xuyên suốt mọi giai đoạn của tiến trình phát triển phần mềmlà từ chung cho các quá trình kiểm thử Có hai mục tiêu:Phát hiện các khuyết tật trong hệ thống.Đánh giá xem hệ thống liệu có dùng được hay không?Xác minh và Thẩm địnhSự khác nhau giữa xác minh và thẩm định:Xác minh: Are we building the product right?Thẩm định: Are we buiding the right product ?Mô hình phát triển phần mềmPhân tích yêu cầuThiết kếMã hoá và kiểm thử đơn vịTích hợp và kiểm thử hệ thốngHình 1.1–Mô hình WaterFallCài đặt vàbảo trìMô hình phát triển phần mềmƯu điểm của mô hình này: - chuỗi các hoạt động xây dựng phần mềm theo trình tự, rõ ràng.Nhược điểm của mô hình này: - Đòi hỏi tất cả yêu cầu phần mềm phải được xác định rõ ràng ngay từ đầu dự án. - Sự quay lui là nhu cầu tự nhiên. - Ẩn chứa nhiều rủi ro mà chỉ có thể phát hiện ở giai đoạn cuối cùng - Chi phí để sửa chữa có thể rất cao. Mô hình phát triển phần mềmCác hoạt động đồng thờiĐặc tả(Specification)Phát triển(Development, design, coding)Kiểm thử(Testing)Phiên bản đầu tiênPhiên bản trung gianPhiên bản Cuối cùngYêu lược ban đầuHình 1.2–Mô hình tiến hóaMô hình phát triển phần mềmƯu điểm của mô hình này: - Chú trọng việc tái sử dụng mẫu - Một phần của hệ thống có thể được phát triển ngay trong các giai đoạn phân tích phát triển yêu cầu và thiết kế - Cho phép thay đổi yêu cầu và khuyến khích người sử dụng tham gia trong suốt chu kỳ của dự án Nhược điểm của mô hình này: - chậm quá trình phát triển yêu cầu - tính chặt chẽ, minh bạch của qui trình phát triển phần mềm kém Mô hình phát triển phần mềmMô hình phát triển phần mềmTrong mô hình này: - Một khi sai sót được phát hiện trong một giai đoạn kiểm thử thì giai đoạn phân tích hay thiết kế tương ứng được xem xét lại và chu trình bắt đầu lại từ đó Mô hình phát triển phần mềmMô hình phát triển phần mềmƯu điểm của mô hình này: - Phân tích đánh giá rủi ro để tăng thêm mức độ tin cậy của dự án - Kết hợp được những ưu điểm của mô hình thác nước và mô hình tiến hóa - cho phép thay đổi tùy theo điều kiện thực tế dự án Nhược điểm của mô hình này: - Phức tạp và không phù hợp cho dự án nhỏ với ít rủi ro - Cần có kỹ năng tốt về phân tích rủi ro Chương 2. Kiểm thử phần mềmChương 2. Kiểm thử phần mềmĐóng vai trò tối quan trọng, quyết định đến việc đánh giá chất lượng phần mềmLà quá trình tìm lỗiMục đích của kiểm thử là đảm bảo rằng tất cả các thành phần của phần mềm ăn khớp, vận hành như mong đợi và phù hợp các tiêu chuẩn thiết kế. Chương 2. Kiểm thử phần mềmHình 2.2 - Kiểm thử phần mềm trong một số ngữ cảnh (a) Ngữ cảnh quy trình (b) Ngữ cảnh chất lượngCông nghệ hệ thốngQuản lý và đảm bảo chất lượngCông nghệ phần mềmXác minh và thẩm định phần mềmKiểm thử phần mềmĐảm bảo chất lượng phần mềmXác minh và thẩm định phần mềmKiểm thử phần mềmChương 2. Kiểm thử phần mềmKiểm thử phát triển ?Kiểm thử chấp nhận ?Chương 2. Kiểm thử phần mềmKiểm thử là gì ?KTPM bao gồm việc "chạy thử" phần mềm (PM) hay một chức năng của PM, xem nó "chạy" đúng như mong muốn hay không Kiểm thử phần mềm là cho thực thi chương trình để tìm lỗi Chương 2. Kiểm thử phần mềmĐầu vào của kiểm thử ?Sản phẩm của kiểm thử ?Chương 2. Kiểm thử phần mềmQuy trình kiểm thử ?Lập kế hoạchBố trí nhân viênThiết kế test caseKiểm thửĐánh giá phần mềmChương 2. Kiểm thử phần mềmNguyên tắc kiểm thử ?Khách quanNgẫu nhiên“Người sử dụng kém”“Kẻ phá hoại”Chương 2. Kiểm thử phần mềmNguyên lý thiết kế và kiểm thử phần mềm?Phải theo yêu cầu khách hàngPhải được lập kế hoạch trướcPhải từ phạm vi nhỏ đến phạm vi rộngKhông thể có kiểm thử toàn diệnĐộc lậpPhải thiết kế cho “đầu vào” hợp lệ và không hợp lệPhải xác định “đầu ra” mong muốnChương 2. Kiểm thử phần mềmNguyên lý thiết kế và kiểm thử phần mềm (tt)?Phải kiểm tra kỹ kết quả kiểm thửĐủ và đúngTránh “bỏ qua”Không nên cho rằng “không có lỗi”Chú trọng tư duy và sáng tạoKỹ thuật kiểm thử phần mềm“Phá vỡ thay vì xây dựng”Có hai kỹ thuật cơ bảnKỹ thuật kiểm thử chức năng (Kỹ thuật kiểm thử hộp đen)Kỹ thuật kiểm thử cấu trúc (Kỹ thuật kiểm thử hộp trắng)Kỹ thuật kiểm thử chức năngDữ liệu kiểm thử xuất phát từ đặc tả:Kiểm thử hệ thống: Đặc tả yêu cầuKiểm thử tích hợp: Đặc tả thiết kếKiểm thử đơn vị: Đặc tả chi tiết mô-đunKỹ thuật kiểm thử chức năngKTV xem phần mềm như là một hộp đen:Không quan tâm đến cấu trúc và hành vi bên trong phần mềmChỉ quan tâm đến các “hoạt động bề ngoài” của phần mềmKỹ thuật kiểm thử chức năngKTCN cố gắng tìm ra các LỖI sau:Chức năng THIẾU hoặc KHÔNG ĐÚNGLỗi giao diệnLỗi cấu trúc dữ liệuLỗi truy cập CSDL bên ngoàiLỗi thi hànhLỗi khởi tạo/kết thúcKỹ thuật kiểm thử chức năngPhân hoạch tương đươngKiểm thử giá trị biênKỹ thuật đồ thị nhân quảPhân hoạch tương đươngViệc kiểm thử tất các đầu vào của PM là KHÔNG THỂNên giới hạn một tập con tất cả các trường hợp đầu vào có thể có Mục đích: lựa chọn một tập con đúng Có xác suất cao nhất phát hiện hầu hết các lỗi Phân hoạch tương đươngTập con được chọn bao gồm 2 tính chất:Mỗi trường hợp kiểm thử nên gồm nhiều điều kiện đầu vào khác nhau có thể để giảm thiểu tổng số các trường hợp cần thiết.Nên cố gắng phân hoạch các miền đầu vào của một chương trình thành một số xác định các lớp tương đương, sao cho có thể giả định hợp lý rằng việc kiểm thử một giá trị đại diện của mỗi lớp là tương đương với việc kiểm thử một giá trị bất kỳ trong cùng lớp đó Phân hoạch tương đươngThiết kế DL thử bằng phân hoạch tương đương theo 2 bước như sau:Phân hoạch các miền đầu vào/ra thành các lớp tương đương Thiết kế các trường hợp kiểm thử đại diện cho mỗi lớp.Phân hoạch tương đươngVí dụ: Xét chương trình đọc số nguyên có giá trị hợp lệ trong đoạn 0..1000Trong trường hợp này chúng ta có 3 phân hoạch đầu vào:Phân hoạch hợp lệ Phân hoạch không hợp lệ DƯỚC PHHLPhân hoạch không hợp lệ TRÊN PHHLPhân hoạch tương đươngVí dụ: Xét chương trình đọc số nguyên có giá trị hợp lệ trong đoạn 0..1000 (tt)Như vậy dữ liệu thử nào sau đây có khả năng phát hiện lỗi cao hơn:-7, 396, 1800 140, 1680, 360Kiểm thử giá trị biênCác điều kiện biên là tình trạng trực tiếp ở phía trên và dưới của các lớp tương đương đầu vào và lớp tương đương đầu ra.Kiểm thử giá trị biênViệc phân tích các giá trị biên khác với phân hoạch tương đương theo hai điểm: Từ mỗi lớp tương đương, phân hoạch tương đương sẽ chọn phần tử bất kỳ làm phần tử đại diện, trong khi việc phân tích giá trị biên sử dụng một hoặc một số phần tử Không chỉ chú ý tập trung vào những điều kiện đầu vào, các trường hợp kiểm thử cũng được suy ra từ việc xem xét các kết quả ra Kiểm thử giá trị biênCác THKT tốt nhất là tại các biên của các lớpKiểm thử giá trị biên mở rộng phân hoạch tương đương trên cơ sở tập trung vào các biên của miền đầu vào hơn là các giá trị tiêu biểu của nó Kiểm thử giá trị biênVí dụ: Nếu phần mềm cần điều khiển một số bản ghi bất kỳ trong khoảng từ 1 đến 16383 bản ghi, sẽ có ba lớp tương đương: Lớp hợp lệLớp không hợp lệ DƯỚILớp không hợp lệ TRÊNKiểm thử giá trị biênVí dụ(tt): Khi đó, các THKT có thể là:Trường hợp kiểm thử 1: 0 bản ghi, là thành viên của lớp tương đương 2 và kề sát giá trị biên.Trường hợp kiểm thử 2: 1 bản ghi, là giá trị biên.Trường hợp kiểm thử 3: 2 bản ghi, kề sát giá trị biên.Trường hợp kiểm thử 4: 723 bản ghi, là thành phần của lớp tương đương 1.Trường hợp kiểm thử 5: 16382 bản ghi, kề sát giá trị biên.Trường hợp kiểm thử 6: 16383 bản ghi, chính là giá trị biên.Trường hợp kiểm thử 7: 16384 bản ghi, thành phần của lớp tương đương 3, kề sát giá trị biên.Đồ thị nhân – quảLà một phương pháp thiết kế trường hợp kiểm thử trên cơ sở đưa ra một sự mô tả súc tích các điều kiện logic và các hành vi kèm theo Sử dụng mô hình quan hệ logic giữa nguyên nhân và kết quả:Nguyên nhân: điều kiện (đúng hoặc sai) của một đầu vào, hoặc kết hợp các đầu vào Kết quả: một biểu thức Bool biểu diễn một kết quả tương ứng cho những thành phần vừa thực hiện Đồ thị nhân – quảCác bước tạo đồ thị nhân – quảTất cả các nguyên nhân (các đầu vào) và các kết quả (các đầu ra) được liệt kê dựa trên đặc tả và được định danh cho mỗi nhân - quả.Các quan hệ giữa các nguyên nhân (các đầu vào) và các kết quả (các đầu ra) được biểu diễn trong đồ thị làm rõ ràng các quan hệ logic.Từ đồ thị tạo ra bảng quyết định biểu diễn các quan hệ giữa nguyên nhân và kết quả. Dữ liệu kiểm thử được sinh ra dựa trên các qui tắc trong các bảng này.Đồ thị nhân – quảCác ký hiệu quy ước:Đồ thị nhân – quảCác ký hiệu quy ước:Đồ thị nhân – quảVí dụ: để tính thuế thu nhập, người ta có mô tả sau: - Người vô gia cư nộp 4% thuế thu nhập - Người có nhà ở nộp thuế theo bảng sau: Tổng thu nhập Thuế 5.000.000 đồng 6%Đồ thị nhân – quảVí dụ(tt): Quan hệ giữa nguyên nhân (đầu vào) và kết quả (đầu ra) như sau:Đồ thị nhân – quảVí dụ(tt): Đồ thị biểu diễn quan hệ logic rõ ràng giữa nguyên nhân-kết quả :Đồ thị nhân – quảVí dụ(tt): Bảng quyết định: Từ đây xây dựng được bốn trường hợp kiểm thử (một trường hợp cho việc nộp thuế 6% và ba trường hợp kiểm thử cần cho việc nộp thuế 4%):Kỹ thuật kiểm thử cấu trúc Kỹ thuật kiểm thử hộp trắngKỹ thuật này dựa trên sự phân tích mã chương trình hoặc một mô hình của mã chương trình để xây dựng các phép thử theo các tiêu chuẩn bao phủ.Kiểm thử cấu trúc bên trong của phần mềm, với mục đích kiểm tra tất cả các câu lệnh và điều kiện tồn tại trong phần mềm đó Kỹ thuật kiểm thử cấu trúc Kỹ thuật kiểm thử hộp trắng (tt)Trong kỹ thuật này kiểm thử viên lấy dữ liệu thử xuất phát từ việc kiểm tra logic của chương trình (không quan tâm đến đặc tả). Đồ thị luồng điều khiển là một đồ thị có hướng biểu diễn một chương trình, trong đó:Mỗi nút (đỉnh): biểu diễn một lệnh tuần tự hoặc khối lệnh tuần tự.Các cung: tương ứng với các quyết định luồng điều khiển đi ra từ một nút cấu trúc lựa chọn hay lệnh rẽ nhánh. Một cung cần phải kết thúc tại một đỉnh, cho dù đỉnh đó không biểu diễn cho một lệnh thủ tục nào. Một đỉnh vào và một đỉnh ra được thêm vào đồ thị để biểu diễn cho điểm vào ra tương ứng của chương trình Đồ thị luồng điều khiển Ví dụ 1: Đồ thị luồng điều kiểm của đoạn chương trình giải phương trình bậc nhất if(a == 0) if(b == 0) cout>x; if(x==0) x++; g=1/x; Hãy vẽ đồ thị luồng điều khiển ?Phủ tất cả các lệnh (đỉnh)Ví dụ 2: Vậy lộ trình nào phủ tất cả các đỉnh ?acbnex=0x!=0x++g=1/xn0Phủ tất cả các lệnh (đỉnh)Như vậy: Tiêu chuẩn phủ tất cả các đỉnh thì không phủ các cung.Phủ tất cả các cung Là phép thử cho phép phủ tất cả các cung của đồ thị luồng điều khiển ít nhất một lần. Việc phủ tất cả các cung tương đương với việc phủ tất các giá trị logic của mỗi đỉnh quyết định. Phủ tất cả các cung sẽ kéo theo phủ tất cả các đỉnh.Phủ tất cả các cung Ví dụ 3: Cho đoạn chương trình sau if(a >n;cout>m; i=n; s=0;whlie(nm 1/si=n; s=0Phủ tất cả các điều kiện Ví dụ 5: Lúc này, Tập dữ liệu thử bao phủ các cung của đồ thị luồng điều khiểnlà: a[0]= 1, a[1]=2, a[2]=3, n =1, m=2. Tuy nhiên lỗi sẽ không được phát hiện trong trường hợp n>m nghĩa là s= 0, => 1/s (1/0) => lỗi.Phủ tất cả các lộ trình Tiêu chuẩn phủ tất cả các lộ trình có thể gặp những khó khăn khi số lộ trình là vô hạn hoặc các lộ trình không thực thi Trong trường hợp, chương trình có số lần lặp quá lớn thì chúng ta qui định rằng chỉ thực hiện i lần lặp hữu hạn nào đó mà thôi. Phủ tất cả các lộ trình Nhìn chung chúng ta thường quan tâm đến hai lộ trình đó là:Lộ trình qua vòng lặp một lần.Lộ trình không qua vòng lặp.abcdLộ trình không qua vòng lặp: abdLộ trình qua vòng lặp một lập: abcbdPhủ tất cả các lộ trình Như vậy, phủ tất cả lộ trình kéo theo phủ tất cả các cung và phủ tất cả các đỉnh.Bài tập tổng kết Cho đoạn chương trình sau: if(n giới hạn ít nhất số lộ trình kiểm thử bắt buộc.Lộ trình cơ sở (Lộ trình độc lập) Là một lộ trình bất kỳ đưa ra ít nhất một tập lệnh xử lý hoặc điều kiện mới ( tức là phải đi qua một cung mới chưa từng được một lộ trình nào trước đó đi qua). Ví dụCho lưu đồ thuật toán sau, hãy vẽ đồ thị luồng điều khiển.1091236458711Ví dụ (tt): Có bao nhiêu lộ trình cơ sở ?Sẽ có 4 lộ trình cơ sở:- Lộ trình 1: 1-11- Lộ trình 2: 1-2-3-4-5-10-1-11- Lộ trình 3: 1-2-3-6-8-9-10-1-11- Lộ trình 4: 1-2-3-6-7-9-10-1-11Lộ trình 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11 thì sao ?R312,34,567891011R2R1R4Các công thức tính độ phức tạp Cyclomat Công thức 1: V(G) = R, trong đó R là số vùng của đồ thị luồng điều khiển G.Công thức 2: V(G) = P + 1, trong đó P là số đỉnh điều kiện có trong đồ thị luồng điều khiển G.Công thức 3: V(G) = E – N + 2, trong đó E là số cạnh, N là số đỉnh của đồ thị luồng điều khiển G.Các công thức tính độ phức tạp Cyclomat Như vậy ở ví dụ trên, độ phức tạp Cyclomat được tính như sau:- Công thức 1: V(G) = R = 4- Công thức 2: V(G) = P +1 = 3 + 1 = 4- Công thức 3: V(G) = E – N + 2 = 11 – 9 + 2 = 4Phát sinh các trường hợp kiểm thử theo LTCS Theo 4 bước:- Bước 1: Vẽ đồ thị luồng điều khiển từ mã nguồn hoặc mô hình của mã nguồn.- Bước 2: Xác định độ phức tạp Cyclomat của đồ thị luồng điều khiển- Bước 3: Xác định các lộ trình cơ sở- Bước 4: Phát sinh các trường hợp kiểm thử có khả năng thực hiện trên mỗi lộ trình cơ sở.Phát sinh các trường hợp kiểm thử theo LTCS Chú ý:Dữ liệu kiểm thử được chọn sao cho các điều kiện tại các nút điều kiện phải được kiểm thử Mỗi trường hợp kiểm thử được thực thi và được đối chiếu với kết quả mong đợi Phát sinh các trường hợp kiểm thử theo LTCS Ví dụ: Thiết kế các trường hợp kiểm thử cho hàm tính trung bình cộng n số nguyên (hàm có tên là average, được viết bằng ngôn ngữ C), với n = min && Arr[i] 0) avg = (double) sum/count;else avg = -999;return avg;}HÃY XÁC ĐỊNHCÁC ĐIỂM NÚT ???Xác định các điểm nútDouble average (int [] Arr, int min, int max){ /*1*/ int sum =0, count = 0, i=0; double avg = 0.0; while (/*2*/Arr[i] != -999 && /*3*/i = min && /*5*/Arr[i] 0) /*9*/avg = (double) sum/count;else /*10*/avg = -999;/*11*/return avg;}Bước 1: Vẽ đồ thị luồng điều khiểnR4R3R2R11234567810911R5R6Bước 2: Tính độ phức tạp CyclomatCông thức 1: V(G) = R = 6Công thức 2: V(G) = P + 1 = 5 + 1 = 6Công thức 3: V(G) = E – N + 2 = 17 – 13 + 2 = 6Bước 3: Tìm tập các lộ trình cơ sởLộ trình 1: 1-2-8-9-11Lộ trình 2: 1-2-8-10-11Lộ trình 3: 1-2-3-8-9-11Lộ trình 4: 1-2-3-4-7-2- Lộ trình 5: 1-2-3-4-5-7-2- Lộ trình 6: 1-2-3-4-5-6-7-2- Lưu ýCác dấu () phía sau các lộ trình 4,5,6 có nghĩa là một lộ trình (hợp lệ) bất kỳ đi qua các phần còn lại của cấu trúc điều khiển đều có thể chấp nhận. Quan trọng là việc chỉ ra các đỉnh điều kiệnTrong ví dụ này, các đỉnh điều kiện là 2,3,4,5,8.Bước 4: Thiết kế các trường hợp kiểm thửLộ trình 1:Đầu vào: Arr = {3,5,11,-999}, min = 0, max = 100Đầu ra mong muốn: average = (3+5+11)/3 = 6.0Mục đích: Kiểm thử việc tính trung bình chính xácBước 4: Thiết kế các trường hợp kiểm thửLộ trình 2:Đầu vào: Arr = {-999}, min = 0, max = 0Đầu ra mong muốn: average = -999Mục đích: Kiểm thử việc tạo đầu ra average = -999Bước 4: Thiết kế các trường hợp kiểm thửLộ trình 3:Đầu vào: Arr = {3,5,7,8,10,.,80} (nhập đủ 101 số hợp lệ), min = 0, max = 100Đầu ra mong muốn: Trung bình của 100 số đầu tiên trong mảng ArrMục đích: Chỉ tính trung bình cho 100 số hợp lệ đầu tiên.Bước 4: Thiết kế các trường hợp kiểm thửLộ trình 5:Đầu vào: Arr = {7,23,104,4,34,6,-999}, min = 0, max =100Đầu ra mong muốn: average = (7+23+4+34+6)/5Mục đích: Kiểm thử biên trên (Arr[i]>max, i0) và một mảng gồm K phần tử là các số nguyên, với 0 < K <= N- Chương trình P sắp xếp mảng theo thứ tự tăng dần và xuất ra mảng đã sắp xếp.- P được xem là đúng với đặc tả nếu và chỉ nếu: với mỗi đầu vào hợp lệ, đầu ra của P tương ứng như đặc tả (xuất ra mảng đúng được sắp xếp theo thứ tự tăng dần). Xây dựng ứng dụng KTPM Phát biểu bài toán (tt):Một lập trình viên đã áp dụng thuật toán MergeSort để viết chương trình giải bài toán trên. Đặc tả chi tiết thuật toán MergeSort gồm các module như sau:- Module Merge: Module này làm nhiệm vụ nối hai mảng thành một mảng được sắp xếp.- Module Split: Module này làm nhiệm vụ nhận vào một mảng và chia thành 2 nữa, sau đó được gọi đệ quy cho mỗi nữa nếu nó còn chứa hơn 1 phần tử. Sau đó, gọi module Merge nối hai nữa kề sát.- Module MergeSort: là module nhận các tham số khởi tạo từ giao diện người dùng cuối cho chức năng sắp xếp, sau đó gọi module Split với các tham số khởi tạo đó. Xây dựng ứng dụng KTPM Hãy thực hiện kiểm thử cho thuật toán MergeSort trên:Chiến lược kiểm thửPhát sinh trường hợp kiểm thửThiết kế bộ điều khiển kiểm thửThực hiện