Giáo trình Kiểm thử phần mềm (Nghề Ứng dụng phần mềm Trình độ Cao đẳng)

TUYÊN BỐ BẢN QUYỀN Tài liệu thuộc loại sách giáo trình nên nguồn thơng tin phép dùng nguyên trích dùng cho mục đích đào tạo tham khảo Mọi mục đích khác mang tính lệch lạc sử dụng với mục đích kinh doanh thiếu lành mạnh bị nghiêm cấm LỜI GIỚI THIỆU Chúng ta chứng kiến tăng trưởng đáng kinh ngạc ngành công nghiệp phần mềm vài thập kỷ qua Nếu trước phần mềm máy tính sử dụng để tính tốn khoa học kỹ thuật xử lý liệu ngày ứng dụng vào mặt của đời sống hàng ngày người, từ ứng dụng nhỏ để điều khiển thiết bị dùng gia đình thiết bị nghe nhìn, điện thoại, máy giặt, lị vi sóng, nồi cơm điện, đến ứng dụng lớn trợ giúp điều khiển phương tiện hệ thống giao thơng, trả tiền cho hố đơn, quản lý tốn tài chính, vân vân Vì người ngày phụ thuộc chặt chẽ vào sản phẩm phần mềm đòi hỏi chất lượng sản phẩm phần mềm ngày cao, tức phần mềm phải sản xuất với giá thành hạ, dễ dùng, an toàn tin cậy Kiểm thử có phương pháp hoạt động khơng thể thiếu quy trình sản xuất phần mềm để đảm bảo yếu tố chất lượng nêu sản phẩm phần mềm Kiểm thử phần mềm mô đun sở nghề Ứng dụng phần mềm biên soạn dựa theo chương trình đào tạo xây dựng ban hành năm 2021 trường Cao đẳng nghề Cần Thơ dành cho nghề Ứng dụng phần mềm hệ Cao đẳng Khi biên soạn, nhóm biên soạn dựa kinh nghiệm thực tế giảng dạy, tham khảo đồng nghiệp, tham khảo giáo trình có cập nhật kiến thức có liên quan để phù hợp với nội dung chương trình đào tạo phù hợp với mục tiêu đào tạo, nội dung biên soạn gắn với nhu cầu thực tế Nội dung giáo trình biên soạn với lượng thời gian đào tạo 45 gồm có: Bài MĐ 01: Tổng Quan Về Kiểm Thử Bài MĐ 02: Một số ví dụ Bài MĐ 03: Kiểm thử hàm Bài MĐ 04: Kiểm thử dòng diều khiển Bài MĐ 05: Kiểm thử dòng liệu Mặc dù cố gắng tổ chức biên soạn để đáp ứng mục tiêu đào tạo khơng tránh thiếu sót Rất mong nhận đóng góp ý kiến thầy, bạn đọc để nhóm biên soạn điều chỉnh hoàn thiện Cần Thơ, ngày tháng năm 2021 Tham gia biên soạn Chủ biên Nguyễn Hoàng Vũ MỤC LỤC LỜI GIỚI THIỆU MỤC LỤC GIÁO TRÌNH MÔN HỌC/MÔ ĐUN BÀI 1: TỔNG QUAN VỀ KIỂM THỬ Mã BÀI: MĐ31-01 Các thuật ngữ định nghĩa kiểm thử Ca kiểm thử 11 Mô tả toán kiểm thử qua biểu đồ venn 12 Việc xác định ca kiểm thử 13 4.1 Kiểm thử hàm 13 4.2 Kiểm thử cấu trúc 14 4.3 Tranh luận kiểm thử hàm so với kiểm thử cấu trúc 15 Phân loại lỗi sai 16 Các mức kiểm thử 17 Bài tập học viên 19 Hướng dẫn thực 19 Những trọng tâm cần ý 20 Bài mở rộng nâng cao 20 Yêu cầu đánh giá kết học tập 20 BÀI MỘT SỐ VÍ DỤ 21 Mã BÀI: MĐ31-02 21 Bài toán tam giác 21 1.1 Phát biểu toán 21 1.2 Nhận xét 21 1.3 Cài đặt truyền thống 21 1.4 Cài đặt có cấu trúc 23 Hàm NextDate (ngày kế tiếp) 25 2.1 Phát biểu toán 25 2.2 Nhận xét 25 2.3 Cài đặt 25 Hệ thống rút tiền tự động đơn giản 26 3.1 Phát biểu toán 26 3.2 Nhận xét 28 Bộ điều khiển gạt nước ô tô 28 Bài tập học viên 28 Hướng dẫn thực 29 Những trọng tâm cần ý: 29 Bài mở rộng nâng cao 29 Yêu cầu đánh giá kết học tập 30 BÀI KIỂM THỬ HÀM 31 Mã BÀI: MĐ31-03 31 Tổng quan 31 1.1 Sự phức tạp kiểm thử hàm 32 1.2 Phương pháp hệ thống 34 Kiểm thử giá trị biên 36 2.1 Giá trị biên 36 2.2 Một số dạng kiểm thử giá trị biên 39 2.2.1 Kiểm thử giá trị biên mạnh 39 2.2.2 Kiểm thử giá trị biên tổ hợp 39 2.2.3 Kiểm thử giá trị đặc biệt 40 2.3 Ví dụ minh họa 40 2.3.1 Kiểm thử giá trị biên cho Triangle 40 2.3.2 Kiểm thử giá trị biên cho NextDate 41 2.4 Kinh nghiệm áp dụng 41 Kiểm thử lớp tương đương .42 3.1 Blind FTP / Giấu tên 42 3.2 Phân loại kiểm thử lớp tương đương 42 3.2.1 Kiểm thử lớp tương đương yếu 42 3.2.2 Kiểm thử lớp tương đương mạnh 43 3.2.3 Kiểm thử lớp tương đương đơn giản 43 3.3 Ví dụ minh họa 44 3.3.1 Kiểm thử lớp tương đương cho Triangle 44 3.3.2 Kiểm thử lớp tương đương cho NextDate 45 3.3.3 Kiểm thử tương đương yếu cho NextDate 45 3.3.4 Kiểm thử tương đương mạnh cho NextDate 46 3.4 Kinh nghiệm áp dụng 46 Kiểm thử bảng định 47 4.1 Bảng định 47 4.2 Ví dụ minh họa 48 4.3 Kinh nghiệm áp dụng 49 Kiểm thử tổ hợp 50 5.1 Kiểm thử đôi 50 5.2 Ma trận trực giao 5.3 Kinh nghiệm áp dụng Bài tập học viên 10 Hướng dẫn thực 10 Những trọng tâm cần ý: 10 Bài mở rộng nâng cao 10 Yêu cầu đánh giá kết học tập 10 BÀI KIỂM THỬ DÒNG DIỀU KHIỂN 12 Mã BÀI: MĐ31-04 .12 Kiểm thử hộp trắng 12 Đồ thị dòng điều khiển 12 Các độ đo kiểm thử .13 Kiểm thử dựa độ đo 15 4.1 Kiểm thử cho độ đo C1 16 4.2 Kiểm thử cho độ đo C2 16 4.3 Kiểm thử cho độ đo C3: 17 4.4 Kiểm thử vòng lặp 18 Tổng kết 20 Bài tập học viên 21 Hướng dẫn thực 21 Những trọng tâm cần ý: 24 Bài mở rộng nâng cao 24 Yêu cầu đánh giá kết học tập 24 BÀI 5: KIỂM THỬ DÒNG DỮ LIỆU 25 Kiểm thử dựa gán sử dụng giá trị biến 25 1.1 Ý tưởng 25 1.2 Các vấn đề phổ biến dòng liệu 25 1.3 Tổng quan kiểm thử dòng liệu động 29 1.4 Đồ thị dòng liệu 30 1.5 Các khái niệm dòng liệu 33 1.6 Các độ đo cho kiểm thử dòng liệu 35 1.7 Sinh ca kiểm thử 37 Kiểm thử dựa lát cắt 38 2.1 Ý tưởng kiểm thử dựa lát cắt 39 2.2 Ví dụ áp dụng 40 2.3 Một số lưu ý với kiểm thử dựa lát cắt 44 Tổng kết 46 Câu hỏi tập thực hành 47 Hướng dẫn thực 47 Những trọng tâm cần ý: 49 Bài mở rộng nâng cao 49 Yêu cầu đánh giá kết học tập 49 TÀI LIỆU THAM KHẢO 51 GIÁO TRÌNH MƠN HỌC/MƠ ĐUN Tên mơn học/mơ đun: KIỂM THỬ PHẦN MỀM Mã môn học/mô đun: MĐ 13 Vị trí, tính chất, ý nghĩa vai trị mơ đun  Vị trí: mơ đun bố trí giảng dạy dạy từ đầu khóa học, trước học môn chuyên môn nghề như: Quản trị mạng, Quản trị sở liệu, Thiết kế Web với ASP.NET, Lập trình Python, Xây dựng phần mềm quản lý liệu (Bán hàng/ Nhân sự/ Khách sạn),  Tính chất mơ đun: mơ đun bắt buộc thuộc chun mơn nghề chương trình đào tạo Cao đẳng Ứng dụng phần mềm  Ý nghĩa vai trị: Đây mơn học sở ngành ngành ứng dụng phần mềm, cung cấp cho sinh viên kiến thức bảo mật hệ thống mạng để làm tản cho việc bảo mật giải vấn đề cần thiết  Vai trò: Giáo trình “kiểm thử phần mềm” nhằm cung cấp cho sinh viên kiến thức phương pháp kỹ thuật đo lường đại lượng vật lý Mục tiêu môn học: Sau học xong mô đun học viên có lực - Kiến thức:  Hiểu khái niệm an toàn thông tin mật mã  Nắm nguyên tắc quy trình kiểm thử phần mềm  Hiểu phân biệt mức độ kiểm thử phần mềm  Nắm kỹ thuật kiểm thử chiến lược kiểm thử  Tìm bug phát sinh dev tạo code  Đạt tự tin cung cấp thông tin mức độ chất lượng  Để ngăn ngừa lỗi  Đảm bảo kết cuối đáp ứng yêu cầu kinh doanh người sử dụng  Để đạt tín nhiệm khách hàng cách cung cấp cho họ sản phẩm chất lượng  Kiểm thử trình thực thi chương trình với mục đích tìm lỗi/các yếu điểm chương trình  Một trường hợp kiểm thử không tốt (không thành cơng) trường hợp mà khả tìm thấy lỗi chưa biết đến - Kỹ năng:  xây dựng testplan viết tài liệu testplan cho dự án thực tế;  Thiết kế test cases cho toán cụ thể;  Thực thi chương trình với mục đích tìm lỗi/các yếu điểm chương trình  Thực thi test cases  Nghiêm túc, tỉ mỉ, sáng tạo trình tiếp thu kiến thức vận dụng vào việc xây dựng thực testplan cụ thể Chủ động, tích cực tìm hiểu tài liệu nguồn tập liên quan - Năng lực tự chủ trách nhiệm:  Nghiêm túc, tỉ mỉ việc tiếp nhận kiến thức  Chủ động, tích cực thực hành tìm kiếm nguồn tập liên quan  Rèn luyện tính tổ chức, khoa học, hệ thống, xác, cẩn thận Nội dung mơ đun: Thời gian (giờ) Thực Số hành, thí Tên mô đun Tổng Lý Kiểm TT nghiệm, số thuyết tra thảo luận, tập Bài 1: Tổng Quan Về Kiểm Thử 2 Bài số ví dụ Bài 3: Kiểm thử hàm 12 Bài Kiểm thử dòng diều khiển 5 Bài 5: Kiểm thử dòng liệu 13 45 15 28 Tổng BÀI 1: TỔNG QUAN VỀ KIỂM THỬ Mã BÀI: MĐ31-01 Giới thiệu Kiểm thử nhằm đánh giá chất lượng tính chấp nhận sản phẩm Kiểm thử nhằm phát lỗi vấn đề sản phẩm Chúng ta cần kiểm thử biết người ln mắc sai lầm Điều đặc biệt lĩnh vực phát triển phần mềm hệ thống điều khiển phần mềm Bài nhằm phác họa tranh tổng thể kiểm thử phần mềm Các cịn lại nằm khn khổ tranh mức chi tiết Mục tiêu - Trình bày nội dung tổng quan kiểm thử phần mềm - Xác định mức bảo vệ hệ thống - Thực thao tác an toàn với máy tính mật mã - Hiểu khái niệm an tồn thơng tin, vai trị chúng; - Biết số dịch vụ phương thức hay sử dụng hệ thống thông tin; - Hiểu phương thức truy cập hệ thống; - Xác định rủi ro mối đe dọa hệ thống; - Có tính chủ động, khoa học, cẩn thận, tỉ mỉ, xác Nội dung chính: Các thuật ngữ định nghĩa kiểm thử Mục tiêu: Trình bày tổng quan kiểm thử phần mềm Kỹ nghệ kiểm thử phát triển tiến hoá hàng chục năm nên thuật ngữ tài liệu khác thường không thống thiếu tương thích Các thuật ngữ trình bày sách dựa vào thuật ngữ chuẩn phát triển IEEE (Viện Kỹ nghệ điện điện tử) với việc chọn lọc cẩn thận thuật ngữ tiếng Việt tương ứng Lỗi (Error): Lỗi vấn đề mà người mắc phải trình phát triển sản phẩm phần mềm Trong thực tế, người ln phạm lỗi Khi lập trình viên phạm lỗi lập trình, ta gọi lỗi bug (con bọ) Lỗi phát tán Chẳng hạn, lỗi xác định yêu cầu dẫn đến sai lầm thiết kế sai lập trình theo thiết kế Lỗi nguyên nhân dẫn đến sai Sai (Fault): Sai kết lỗi, hay nói khác đi, lỗi dẫn đến sai Cũng nói sai biểu diễn lỗi dạng biểu thức, chẳng hạn chương trình, văn bản, sơ đồ dịng liệu, biểu đồ lớp, Sai lầm khó bị phát Khi nhà thiết kế mắc lỗi bỏ sót q trình thiết kế, sai kết từ lỗi thiếu mà lẽ cần phải có Sai nhiệm vụ xuất vào sai thơng tin, cịn sai bỏ qn xuất không vào đủ thông tin Loại sai thứ hai khó phát khó sửa loại sai thứ Thất bại (Failure): Thất bại xuất lỗi thực thi Có hai điều cần lưu ý Một thất bại xuất dạng chạy mà thơng thường mã nguồn Hai thất bại liên kết với lỗi nhiệm vụ Còn thất bại tương ứng với lỗi bỏ quên xử lý nào? Những lỗi không tiến hành, không tiến hành khoảng thời gian dài cần xử lý nào? Virus Michaelangelo ví dụ lỗi loại Nó tiến hành vào ngày sinh Michaelangelo, tức ngày 6/3 mà thơi Việc khảo sát ngăn chặn nhiều thất bại cách tìm lỗi thuộc hai loại Sự cố (Incident): Khi thất bại xuất hiện, hiển thị khơng, tức rõ ràng không rõ ràng người dùng người kiểm thử Sự cố triệu chứng liên kết với thất bại thể cho người dùng người kiểm thử xuất thất bại Yêu cầu khách hàng đặc tả phần mềm: Phần mềm viết để thực nhu cầu khách hàng Các nhu cầu khách hàng thu thập, phân tích khảo cứu sở để định xác đặc trưng cần thiết mà sản phẩm phần mềm cần phải có Dựa yêu cầu khách hàng yêu cầu bắt buộc khác, đặc tả xây dựng để mơ tả xác u cầu mà sản phẩm phần mềm cần đáp ứng, có giao diện Tài liệu đặc tả sở để đội ngũ phát triển phần mềm xây dựng sản phẩm phần mềm Khi nói đến thất bại nói đến việc sản phẩm phần mềm khơng hoạt động đặc tả Lỗi tiến hành dẫn đến thất bại Do đó, lỗi bỏ quên coi tương ứng với lỗi xây dựng đặc tả Kiểm chứng thẩm định: Kiểm chứng (verification) thẩm định (validation) hay dùng lẫn lộn, thực chúng có ý nghĩa khác Kiểm chứng trình để đảm bảo sản phẩm phần mềm thỏa mãn đặc tả Cịn thẩm định q trình để đảm bảo sản phẩm đáp ứng yêu cầu người dùng (khách hàng) Trong thực tế, cần thực kiểm chứng trước thực việc thẩm định sản phẩm phần mềm Vì vậy, có thuật ngữ V&V (Verification & Validation) Lý việc cần đảm bảo sản phẩm với đặc tả trước Nếu thực việc thẩm định trước, phát lỗi, xác định lỗi đặc tả sai hay lập trình sai so với đặc tả Chất lượng độ tin cậy phần mềm: Theo từ điển, chất lượng sản phẩm thể đặc trưng phù hợp với đặc tả Theo cách hiểu này, chất lượng sản phẩm phần mềm đáp ứng yêu cầu chức (tức hàm cần tính tốn), hồn thiện chuẩn đặc tả, đặc trưng mong chờ từ sản phẩm phần mềm chuyên nghiệp Chất lượng phần mềm đặc trưng cho “độ tốt, độ tuyệt hảo” phần mềm, gồm có yếu tố chất lượng như: tính đắn (hành vi đặc tả), tính hiệu (tiết kiệm thời gian tiền bạc), độ tin cậy, tính khả kiểm thử (kiểm thử dễ), dễ học, dễ sử dụng, dễ bảo trì Như vậy, độ tin cậy yếu tố để đánh giá chất lượng phầm mềm Người kiểm thử hay nhầm lẫn độ tin cậy với chất lượng Khi kiểm thử đạt tới mức phần mềm chạy ổn định, phụ thuộc vào nó, người kiểm thử thường cho phần mềm đạt chất lượng cao Các yếu tố mặt chất lượng mà liên quan trực tiếp đến việc phát triển phần mềm gọi tiêu chuẩn chất lượng tính có cấu trúc, tính đơn thể, tính khả kiểm thử, Độ tin cậy phần mềm xác suất để phần mềm chạy khơng có thất bại khoảng thời gian định Nó xem yếu tố quan trọng chất lượng phần mềm Ngoài ra, thời gian trung bình cho việc khắc phục cố thông số quan trọng việc đánh giá độ tin cậy sản phẩm phần mềm Kiểm thử: Rõ ràng việc kiểm thử liên quan đến khái niệm trên: lỗi, sai, thất bại cố Có hai mục đích phép thử: tìm thất bại chứng tỏ việc tiến hành phần mềm đắn Vai trò kiểm thử phần mềm: Kiểm thử phần mềm đóng vai trị quan trọng việc đánh giá thu chất lượng cao sản phẩm phần mềm trình phát triển Thơng qua chu trình “kiểm thử - tìm lỗi - sửa lỗi”, ta hy vọng chất lượng sản phẩm phần mềm cải tiến Mặt khác, thông qua việc tiến hành kiểm thử mức hệ thống trước cho lưu hành sản phẩm, ta biết sản phẩm ta tốt mức Vì thế, nhiều tác giả mô tả việc kiểm thử phần mềm quy trình kiểm chứng để đánh giá tăng cường chất lượng sản phẩm phần mềm Quy trình gồm hai cơng việc phân tích tĩnh phân tích động • Phân tích tĩnh: Việc phân tích tĩnh tiến hành dựa việc khảo sát tài liệu xây dựng trình phát triển sản phẩm tài liệu đặc tả nhu cầu người dùng, mơ hình phần mềm, hồ sơ thiết kế mã nguồn phần mềm Các phương pháp phân tích tĩnh truyền thống bao gồm việc khảo sát đặc tả mã nguồn tài liệu thiết kế Các kỹ thuật khảo sát giới thiệu Người ta dùng kỹ thuật phân tích hình thức kiểm chứng mơ hình (model checking) chứng minh định lý (theorem proving) để chứng minh tính đắn thiết kế mã nguồn Các kỹ thuật tương đối phức tạp nằm ngồi khn khổ giáo trình Công việc không động đến việc thực thi chương trình mà duyệt, lý giải tất hành vi chương trình thực thi Tối ưu hóa chương trình dịch ví dụ phân tích tĩnh • Phân tích động: Phân tích động liên quan đến việc thực thi chương trình để phát thất bại có chương trình, quan sát tính chất hành vi hiệu (performance) Vì gần khơng thể thực thi chương trình tất liệu đầu vào có thể, ta chọn tập liệu đầu vào để thực thi, gọi “ca kiểm thử” Chọn để liệu đầu vào hiệu (tức liệu có xác suất phát thất bại (nếu có) cao công việc cần suy nghĩ nội dung giáo trình Bằng việc phân tích tĩnh động, người kiểm thử muốn phát nhiều lỗi để chúng sửa giai đoạn sớm trình phát triển phần mềm Phân tích tĩnh động hai kỹ thuật bổ sung cho cần làm lặp lặp lại nhiều trình kiểm thử Ca kiểm thử: Mỗi ca kiểm thử có tên liên kết với hành vi chương trình Ca kiểm thử gồm tập liệu đầu vào xâu giá trị đầu mong đợi phần mềm Hình 1.1: Một vịng đời việc kiểm thử Hình 1.1 mơ tả vịng đời việc kiểm thử ứng với mơ hình thác nước Lưu ý giai đoạn phát triển phần mềm, lỗi đưa vào gia đoạn đặc tả yêu cầu, thiết kế lập trình Các lỗi tạo sai lan truyền sang phần cịn lại q trình phát triển Một nhà kiểm thử lỗi lạc tóm tắt vòng đời 10 p-use) biến có đường từ định nghĩa (def) biến tới sử dụng All-du-paths: Với biến x đỉnh i cho i Global def với biến x, chọn Complete-path chứa tất Du-path từ đỉnh i tới: • tất đỉnh j cho có Global c-use biến x j, • tất cạnh (j,k) cho có p-use biến x (j,k) So sánh độ đo kiểm thử dịng liệu: Sau tìm hiểu độ đo kiểm thử dòng liệu, cần so sánh mối quan hệ chúng để trả lời câu hỏi “chúng ta nên chọn độ đo cho kiểm thử dòng liệu?” Với cặp độ đo trên, chúng so sánh với không Rapps Weyuker [SJ85] định nghĩa mối quan hệ “bao gồm” hai độ đo sau Định nghĩa 7.25 (Mối quan hệ bao gồm.) Cho hai độ đo c1 c2, ta nói c1 bao gồm c2 đường đầy đủ (Complete-paths) sinh từ đồ thị dịng liệu thỏa mãn c1 thỏa mãn c2 Định nghĩa 7.26 (Mối quan hệ bao gồm chặt.) Cho hai độ đo c1 c2, ta nói c1 bao gồm chặt c2, ký hiệu c1 −→ c2, c1 bao gồm c2 tồn số đường đầy đủ sinh từ đồ thị dịng liệu thỏa mãn c2 khơng thỏa mãn c1 Dễ thấy mối quan hệ bao gồm chặt (−→) có tính bắc cầu Hơn nữa, với hai độ đo c1 c2, c1 khơng bao gồm chặt c2 c2 không bao gồm chặt c1 Trong trường hợp ta nói hai độ đo không so sánh Frankl Weyuker [GJ88] tổng kết mối quan hệ độ đo cho kiểm thử dịng liệu Hình 7.7 Với độ đo trình bày trên, All-du-paths độ đo tốt Độ đo bao gồm chặt độ đo All-uses Tương tự, độ đo All-uses bao gồm chặt hai độ đo All-p-uses/Some-c-uses All-c-uses/Some-p-uses chúng bao gồm chặt độ đo All-defs Hơn nữa, độ đo All-p-uses/Some-c-uses bao gồm chặt độ đo All-p-uses độ đo All-cuses/Some-p-uses bao gồm chặt độ đo All-c-uses Tuy nhiên, khơng thể tìm thấy mối quan hệ bao gồm chặt hai độ đo All-c-uses All-p-uses 1.7 Sinh ca kiểm thử Để tiến hành phương pháp kiểm thử dòng liệu, trước hết phải sinh đồ thị dòng liệu đơn vị chương trình Với độ đo kiểm thử C, Hình 7.7: Mối quan hệ độ đo cho kiểm thử dòng liệu 37 xác định tất đường đầy đủ (Complete-paths) thỏa mãn độ đo Tuy nhiên, đường tìm liệu đầu vào để thực thi chạy đơn vị chương trình Nếu tồn liệu đầu vào đường tương ứng gọi đường thực thi Như vậy, toán lại làm để sinh đầu vào cho đường đầy đủ Bộ đầu vào với giá trị đầu mong đợi ca kiểm thử cho đường Để trả lời câu hỏi này, ta xét ví dụ sau Ví dụ 7.27 Xét đường đầy đủ (1 - - - - - - - - 9) từ đồ thị dịng liệu Hình 7.6 Từ đường này, ta xác định biểu thức thuộc p-uses nằm cạnh Cụ thể, ta có biểu thức sau: ((ti= MIN) && (value[i] 0){ } • C-use: Biến sử dụng câu lệnh tính tốn Ví dụ, x = x + y; • O-use: Biến sử dụng cho câu lệnh hiển thị trả kết Ví dụ, return x; printf("%d",x); • L-use: Biến sử dụng trỏ trỏ đến địa số mảng Ví dụ, int x =100, *ptr; ptr = &x; • I-use: Biến sử dụng biến đếm (trong vịng lặp) Ví dụ, i++; Chúng ta có hai dạng xác định giá trị cho biến sau: • I-def: xác định từ đầu vào (từ bàn phím, truyền tham số, ) • A-def: xác định từ phép gán Giả sử lát cắt S(V,n) lát cắt biến, tập V chứa biến v Nếu nút n chứa định nghĩa v ta thêm n vào lát cắt S(V,n) Ngược lại, nút n chứa sử dụng biến v ∈ V n khơng thêm vào lát cắt S(V,n) Những nút chứa P-use C-use biến khác (không phải biến v tập V ) mà ảnh hưởng trực tiếp gián tiếp tới giá trị biến v thêm vào tập V Đối với lát cắt S(V,n), định nghĩa sử dụng biến sau thêm vào lát cắt S(V,n) • Tất I-def A-def biến v • Tất C-use P-use biến v cho loại bỏ làm thay đổi giá trị v • Tất P-use C-use biến khác (không phải biến v) cho loại bỏ làm thay đổi giá trị biến v • Loại bỏ khỏi lát cắt I-use, L-use O-use biến v • Loại bỏ tồn câu lệnh khơng thực thi câu lệnh khai báo biến • Kiểm tra số, số ảnh hưởng đến biến v ta thêm số vào lát cắt 2.2 Ví dụ áp dụng Quay trở lại với ví dụ hàm ReturnAverage 7.5 mục 7.1.4, để áp dụng kỹ thuật kiểm thử dựa lát cắt, phân mảnh hàm hình 40 7.10 Tiếp đến, xây dựng đồ thị hàm sau phân mảnh hình 7.11 Sau đó, định nghĩa lại định nghĩa (Def) sử dụng (Use) biến bảng 7.3 7.4 Và cuối cùng, lát cắt biến hàm tính tốn Chú ý, ta nhận thấy biến i,ti tv biến sử dụng vòng lặp Tuy nhiên, chúng biến cục nên xếp sử dụng biến I-use Tiếp theo, xét lát cắt hàm ReturnAverage biến tập V = {value,AS,MIN,MAX,i,ti,tv,sum,av} Ta nhận thấy rằng, value,AS,MIN MAX biến có I-def giá trị chúng không bị ảnh hưởng thực chương trình Cụ thể, biến value có I-def đỉnh 0, có hai P-use đỉnh và có C-use đỉnh 10 Vì vậy, lát cắt biến sau: • S1 : S(value,0) = {0} (do có I-def biến value đỉnh nên thêm vào S1) • S2 : S(value,6) = {0} (từ đỉnh đến đỉnh có I-def biến value đỉnh ảnh hưởng đến giá trị biến value đỉnh nên thêm vào S2) • S3 : S(value,8) = {0} (từ đỉnh đến đỉnh có I-def biến value đỉnh nên thêm vào S3 Với P-use biến value đỉnh không ảnh hương đến giá trị biến đỉnh nên khơng thêm vào S3) Hình 7.10: Mã nguồn hàm ReturnAverage • S4 : S(value,10) = {0} (từ đỉnh đến đỉnh 10, biến value có I-def đỉnh hai P-use đỉnh Do hai P-use không làm ảnh hưởng đến giá trị biến nên chúng không thêm vào S4.) Tương tự, biến AS có I-def đỉnh có P-use đỉnh Vì vậy, lát cắt biến sau: • S5 : S(AS,0) = {0} (do có I-def biến AS đỉnh nên thêm vào S5) • S6 : S(AS,6) = {0} (từ đỉnh đến đỉnh có I-def biến AS đỉnh nên ta thêm vào S6) 41 Có I-def biến MIN đỉnh có P-use đỉnh Vì vậy, lát cắt biến sau: Hình 7.11: Hàm ReturnAverage sau phân mảnh đồ thị • S7 : S(MIN,0) = {0} • S8 : S(MIN,8) = {0} Tương tự với biến MIN, biến MAX có I-def đỉnh có P-use đỉnh Các lát cắt biến sau: • S9 : S(MAX,0) = {0} • S10 : S(MAX,8) = {0} Chú ý, với lát cắt S2,S3,S4,S6,S8 S10, lát cắt tồn Def-clear-path Thường lát cắt tồn Def-clear-path lỗi tiềm ẩn xuất Đối với biến i, có hai A-def biến đỉnh 11, ba L-use đỉnh 6, 8, 10 C-use đỉnh 11 Vì vậy, lát cắt biến sau: Bảng 7.3: I-def, A-def Const đỉnh Hình 7.11 Đỉnh i I-def(i) A-def(i) Const(i) {value, AS, MIN, {} {} MAX} {} {i} {} {} {ti} {} {} {tv} {} {} {sum} {} {} {} {} {} {} {} {} {ti} {} {} {} {} {} {tv} {} 10 {} {sum} {} 11 {} {i} {} 12 {} {} {} 42 13 {} {av} {} 14 {} {av} {} 15 {} {} {} • S11 : S(i,1) = {1} (biến i có A-def đỉnh nên thêm vào S11) • S12 : S(i,6) = {1,6,7,11} (biến i có hai A-def đỉnh 11 nên chúng thêm vào S12 Xét P-use C-use biến khác ảnh hưởng đến giá trị biến i đỉnh 6, theo bảng 7.4 ta có P-use biến ti,value,AS đỉnh có ảnh hưởng đến giá trị biến i nên thêm vào S12 Ngồi ra, có Cuse biến ti đỉnh ảnh hưởng đến giá trị i đỉnh nên thêm vào lát cắt này.) • S13 : S(i,8) = {1,6,7,11} (tương tự S12) • S14 : S(i,10) = {1,6,7,11} (tương tự S12) • S15 : S(i,11) = {1,6,7,11} (tương tự S12) Bảng 7.4: C-def, L-def, I-def, O-def P-def đỉnh Hình 7.11 Đỉnh i C-def(i) L-def(i) I-def(i) O-def(i) P-def(i) {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {ti,AS,value} {ti} {} {} {} {} {} {} {} {} {value,MIN,MAX} {tv} {} {} {} {} 10 {sum,value} {} {} {} {} 11 {i} {} {} {} {} 12 {} {} {} {} {tv} 13 {sum,tv} {} {} {} {} 14 {} {} {} {} {} 15 {} {} {} {av} {} Đối với biến ti, có hai A-def đỉnh 7, P-use đỉnh C-use đỉnh Các lát cắt biến sau: • S16 : S(ti,2) = {2} • S17 : S(ti,6) = {2,6,7,11} (có hai A-def đỉnh ảnh hưởng đến giá trị biến đỉnh nên chúng thêm vào lát cắt Thêm nữa, P-use biến value,AS đỉnh C-use biến i đỉnh 11 ảnh hưởng đến giá trị biến ti đỉnh nên đỉnh 11 thêm vào lát cắt.) • S18 : S(ti,7) = {2,6,7,11} (tương tự S17) Tương tự với biến tv, có hai A-def đỉnh 9, hai C-use đỉnh 9, 13 có P-use đỉnh 12 Vì vậy, lát cắt biến sau: • S19 : S(tv,3) = {3} • S20 : S(tv,9) = {3,6,7,8,9,11} (có hai A-def đỉnh nên chúng thêm vào lát cắt Xét P-use C-use biến khác có ảnh hưởng đến giá trị biến tv đỉnh Tại đỉnh có P-use biến value,ti,AS ảnh hưởng 43 đến giá trị biến tv đỉnh nên đỉnh thêm vào lát cắt Tương tự, đỉnh có C-use tv ảnh hưởng đến giá trị nên đỉnh thêm vào S20 Tiếp theo, đỉnh 8, P-use biến value,MIN,MAX ảnh hưởng đến giá trị biến nên đỉnh thêm vào lát cắt Cuối cùng, đỉnh 11 có C-use biến i ảnh hưởng đến giá trị biến tv đỉnh nên đỉnh 11 thêm vào S20.) • S21 : S(tv,12) = {3,6,7,8,9,11} (tương tự S20) • S22 : S(tv,13) = {3,6,7,8,9,11} (tương tự S20) Biến sum có hai A-def đỉnh 10 có hai C-use đỉnh 10 13 Do đó, lát cắt biến sau: • S23 : S(sum,4) = {4} • S24 : S(sum,10) = {4,6,8,9,10,11} • S25 : S(sum,13) = {4,6,7,8,9,10,11} Tương tự, biến av khai báo đỉnh 5, có hai A-def đỉnh 13, 14 O-use đỉnh 15 Các lát cắt biến sau: • S26 : S(av,5) = {} • S27 : S(av,13) = {6,8,9,10,11,12} • S28 : S(av,14) = {14} • S29 : S(av,15) = {6,8,9,10,11,12,13,14} Ta nhận thấy lát cắt S29 biến av bị ảnh hưởng hai A-def biến đỉnh 14 15 tương đương với lát cắt S28 S27 Do vậy, ta viết S29 = S28 ∪S27 Ta làm tương tự biến lại để có cách viết khác lát cắt Hơn nữa, ta rút nhận xét quan trọng sau liên quan đến lát cắt • Các lỗi tiềm ẩn xuất lát cắt chứa nhiều A-def • Các lát cắt hợp lát cắt khác • Các lát cắt biến đỉnh khác trùng Để tránh trùng lặp loại bỏ lát cắt không cần thiết, cần xây dựng mối quan hệ lát cắt cho tồn chương trình Các mối quan hệ tạo nên mạng gọi là mạng tinh thể lát cắt với định nghĩa sau Định nghĩa 7.31 Mạng tinh thể lát cắt ứng với chương trình/đơn vị chương trình đồ thị khơng tuần hồn có hướng, đỉnh chứa lát cắt cho đỉnh tương ứng với vị trí mã nguồn Mối quan hệ lát cắt xác định Def-clear-path biến Ví dụ, ta nhận thấy có hai Def-clear-path biến av tương ứng với cạnh Các cạnh lát cắt S27 S28 tập lát cắt S29 Hình 7.12 cho thấy phần mạng tinh thể lát cắt hàm ReturnAverage mơ tả hình 7.11 Sau có mạng tinh thể, cơng việc cuối tạo chương trình biên dịch tương ứng với lát cắt cần thiết kiểm thử chúng 2.3 Một số lưu ý với kiểm thử dựa lát cắt Để áp dụng cách hiệu phương pháp kiểm thử dựa lát cắt, cần ý đến vấn đề sau: 44 Hình 7.12: Mạng tinh thể hàm ReturnAverage • Khơng tạo lát cắt S(V, n) biến v ∈ V nơi mà biến không xuất câu lệnh/đoạn câu lệnh thứ n • Ln tạo lát cắt biến một, tập V lát cắt S(V, n) chứa nhiều biến Ví dụ, S(V,10) với V = sume, value, i Do vậy, ta phải xây dựng lát cắt biến bao gồm lát cắt: S(sum,10), S(value,10) S(10,i) • Tạo cắt lát cắt cho toàn đỉnh chứa A-def Khi biến tính tốn câu lệnh gán, lát cắt biến bao gồm tất Du-paths biến sử dụng việc tính tốn Lát cắt S(10, sum) ví dụ mục 7.2.2 ví dụ rõ ràng cho trường hợp • Tạo lát cắt cho đỉnh chứa P-use Khi biến sử dụng câu lệnh điều khiển, lát cắt cho biết làm biến điều khiển nhận giá trị Điều thật hữu ích cho việc kiểm tra điểm định chương trình • Các lát cắt đỉnh chứa điều kiện khơng sử dụng đến biến (ví dụ: while(1){ }) khơng cần quan tâm • Chúng ta tạo chương trình biên dịch từ lát cắt Chưa có định nghĩa lát cắt yêu cầu tập câu lệnh phải biên dịch làm điều Cụ thể, tạo chương trình từ câu lệnh lát cắt Ví dụ, Hình 7.13: Chương trình ứng với lát cắt S12 từ hàm ReturnAverage 45 Hình 7.14: Chương trình (có thể biên dịch được) ứng với chương trình lát cắt S12 chương trình ứng với lát cắt S12 = {1,6,7,11} chứa câu lệnh hình 7.13 Tuy nhiên, chương trình khơng thể biên dịch lỗi cú pháp (biến ti chưa khai báo chưa trả kết kiểu double) Vì vậy, sửa chương trình để có chương trình biên dịch hình 7.14 Khi đó, kiểm thử chương trình ứng với lát cắt Tương tự, kiểm thử lát cắt khác, kết hợp chúng thành khối chương trình hồn chỉnh Tổng kết Phương pháp kiểm thử dòng liệu cho phép phát lỗi tiềm ẩn bên chương trình liên quan đến việc sử dụng biến Các lỗi thường khó phát phương pháp khác Để áp dụng phương pháp này, cần xây dựng đồ thị dịng liệu cho chương trình cần kiểm thử Ứng với độ đo kiểm thử, xây dựng tập đường đầy đủ (Complete-paths) để sinh ca kiểm thử tương ứng Chúng ta nên sử dụng kiểm thử dịng liệu chương trình có nhiều tính tốn Khi chương trình có nhiều lệnh rẽ nhánh biến biểu thức điều kiện tính tốn (p-use) nên sử dụng kiểm thử dịng liệu Có nhiều cơng cụ nhóm nghiên cứu hỗ trợ xác định khái niệm kiểm thử dịng liệu số cơng cụ thương mại hóa Khi bạn gặp số mơ-đun khó kiểm thử, nên sử dụng số gợi ý sau: • Các lát cắt khơng tương ứng với ca kiểm thử, nhiều lệnh khơng nằm lát cắt nằm đường chương trình Khi cách kết hợp lát cắt, tức dựa lát cắt để cấu trúc lại mơ-đun để thuận tiện cho việc kiểm thử • Phần bù tương đối lát cắt giúp việc chuẩn đốn chương trình Phần bù tương đối tập B so với tập A tập phần tử thuộc A mà không nằm B, ký hiệu A − B • Tồn quan hệ nhiều-nhiều lát cắt dd-paths: lệnh lát cắt nằm số dd-paths lệnh dd-paths nằm số lát cắt Tuy nhiên, so với phương pháp kiểm thử dòng điều khiển, phương pháp kiểm thử dịng liệu khó áp dụng có độ khó Hơn nữa, phương pháp thường phức tạp áp dụng với đơn vị chương trình có kích thước lớn Phương pháp kiểm thử dựa lát cắt xem giải pháp hứa hẹn nhằm giải vấn đề Trong phương pháp kiểm thử dựa lát cắt, không cần phân tích tất câu lệnh thuộc đơn vị chương trình Với biến, quan tâm đến tập câu lệnh có liên quan (khai báo, gán giá trị sử dụng) đến biến 46 Hình 7.15: Mã nguồn C hàm calFactorial Câu hỏi tập thực hành So sánh phương pháp kiểm thử dòng điều khiển phương pháp kiểm thử dịng liệu Liệu chúng có thay lẫn không Thế kiểm thử dòng liệu tĩnh? Thế kiểm thử dòng dữliệu động? Trình bày mối quan hệ chúng, tham khảo mục 1.3 giáo trình Mô tả ba loại vấn đề phổ biến dòng liệu Với loại vấn đề lấy ví dụ minh họa Trình bày phương pháp xác định vấn đề dòng liệu sử dụng sơđồ chuyển trạng thái Hãy áp dụng phương pháp cho chương trình/đơn vị chương trình cụ thể Tại kiểm thử dịng liệu tĩnh khơng đảm bảo rằngchương trình khơng cịn lỗi liên quan đến dịng liệu chương trình? Trình bày bước quy trình kiểm thử dịng liệu động tham khảo mục 1.3 giáo trình Thực việc backup, restore file folder Windows Hướng dẫn thực So sánh phương pháp kiểm thử dòng điều khiển phương pháp kiểmthử dịng liệu Liệu chúng có thay lẫn không, , tham khảo mục giáo trình Thế kiểm thử dòng liệu tĩnh? Thế kiểm thử dịng dữliệu động? Trình bày mối quan hệ chúng Mô tả ba loại vấn đề phổ biến dòng liệu Với loại vấn đề lấy ví dụ minh họa Trình bày phương pháp xác định vấn đề dòng liệu sử dụng sơđồ chuyển trạng thái Hãy áp dụng phương pháp cho chương trình/đơn vị chương trình cụ thể Tại kiểm thử dòng liệu tĩnh khơng đảm bảo rằngchương trình khơng cịn lỗi liên quan đến dịng liệu chương trình? Trình bày bước quy trình kiểm thử dịng liệu động Cho hàm calFactorial viết ngôn ngữ C Hình 7.15 • Hãy liệt kê câu lệnh ứng với khái niệm def, c−use, p−use ứng với biến sử dụng hàm • Hãy vẽ đồ thị dịng liệu hàm 47 Hình 7.16: Một ví dụ đồ thị dịng liệu Hình 7.17: Đồ thị dịng liệu việc sử dụng biến Hãy chứng minh khơng thể tìm thấy mối quan hệ bao gồm chặt hai độ đo All-c-uses All-p-uses (hay nói cách khác, hai độ đo khơng so sánh được) Cho đồ thị dòng liệu hình 7.16 • Hãy xác định tất Complete-path từ đồ thị • Các đường (0 - - 3), (1 - - - - 4), (3 - - 4), (2 - 2) (0 - - 4) có phải simplepaths khơng? Giải thích • Các đường (2 - - 2), (2 - 3) (3 - - 4) có phải loop-free-paths khơng? Giải thích 10 Cho đồ thị dịng liệu hình 7.17 • Hãy xác định tất Def-clear-path biến x y • Hãy xác định tất du-paths biến x y Hình 7.18: Đoạn lệnh ngơn ngữ C++ • Dựa vào chuẩn kiểm thử dòng liệu xác định tất All-puses/Some-c-uses All-c-uses/Some-p-uses • Biểu thức p-use(x,y) cạnh (1,3) (4,5) x + y = x2 + y2 > 17 Đường (0 - - - - - 6) có thực thi khơng? Giải thích • Tại đỉnh biến x định nghĩa sử dụng không tồn mối quan hệ def-use? 11 Tại xây dựng xong lát cắt người ta lại phải xây dựng mạng tinh thể cho lát cắt Mối quan hệ lát cắt thể thông qua mối quan hệ nào? 48 12 Cho đoạn lệnh hình 7.18 • Biến i vịng lặp for có ảnh hưởng đến giá trị biến intV alue khơng? Tại sao? • Hãy xác định các câu lệnh ảnh hưởng đến giá trị biến intV alue câu lệnh Những trọng tâm cần ý:  Trình bày vấn đề phổ biến dịng liệu  Trình bày dịng liệu  Trình bày xác định Sinh ca kiểm thử  Trình bày Kiểm thử dựa lát cắt  Trình bày Chính sách phản ứng trước cố (Incident Response Policy)  Thực thao tác lập trình để xác định kiểm thử Bài mở rộng nâng cao Viết hàm returnSumArray • Hãy xây dựng hàm phân mảnh hàm • Xây dựng đồ thị dòng liệu xác định định nghĩa (def) sử dụng (use) tất biến chương trình • Áp dụng quy tắc xây dựng lát cắt để tạo tất lát cắt tất biến chương trình Yêu cầu đánh giá kết học tập Nội dung  Về kiến thức:  Trình bày kiểm thử dòng điều khiển phương pháp kiểm thử dòng liệu  Trình bày dịng liệu  Trình bày Sinh ca kiểm thử, Kiểm thử dựa lát cắt  Trình bày bước lập trình để kiểm thử dịng liệu  Về kỹ năng: + Thao tác thành thạo bước lập trình để kiểm thử dịng liệu + Thực thao tác lập trình để kiểm thử dịng liệu t  Năng lực tự chủ trách nhiệm: Tỉ mỉ, cẩn thận, xác, linh hoạt ngăn nắp công việc Phương pháp  Về kiến thức: Đánh giá hình thức kiểm tra viết, trắc nghiệm, vấn đáp  Về kỹ năng: Đánh giá kỹ thực hành lập trình để kiểm thử dịng liệu  Năng lực tự chủ trách nhiệm: Tỉ mỉ, cẩn thận, xác, linh hoạt ngăn nắp cơng việc 49 Điều kiện để hồn thành mơ đun để dự thi kết thúc mô đun: + Người học tham dự 70% thời gian học lý thuyết đầy đủ học tích hợp, học thực hành, thực tập + Điểm trung bình chung điểm kiểm tra đạt từ 5,0 điểm trở lên theo thang điểm 10; + Người học có giấy xác nhận khuyết tật theo quy định hiệu trưởng xem xét, định ưu tiên điều kiện dự thi sở sinh viên phải bảo đảm điều kiện điểm trung bình điểm kiểm tra + Số lần dự thi kết thúc mô đun theo quy định khoản Điều 13 Thông tư 09/2017/TT-BLĐTBXH, ngày 13 tháng năm 2017 Điều kiện để công nhận, cấp chứng nhận đạt mô đun đào tạo: Người học công nhận cấp chứng nhận đạt mơ đun có điểm trung bình mơ đun theo thang điểm 10 đạt từ 4,0 trở lên 50 TÀI LIỆU THAM KHẢO [1] TS N Phạm Ngọc Hùng, Trương Anh Hồng Đặng Văn Hưng, Giáo trình kiểm thử phần mềm, Trường Đại học Công nghệ, ĐHQGHN, năm 2014 [2] Trần Tường Thụy – Phạm Quang Hiển, Kiểm Thử Phần Mềm (Testing), NXB Thông tin truyền thông,2013 [3] Phạm Quang Huy, Phạm Quang Hiển, Giáo Trình Thực Hành Kiểm Thử Phần Mềm, NXB Thanh Niên, 2020 [4] Nguyễn Văn Tảo, hà Thị Thanh, Kiểm thử phần mềm, Đại học Thái Nguyên, năm 20209 [5] Trần Tường Thụy – Phạm Quang Hiển, Kiểm Thử Phần Mềm (Testing), NXB Thông tin truyền thông, 2013; 51