Giới thiệu
Đặt vấn đề
Hiện nay, với sự gia tăng lợi ích của sản phẩm phần mềm trong cuộc sống, việc đánh giá và kiểm thử để chứng minh giá trị của chúng trở nên thiết yếu Hầu hết các dự án phát triển phần mềm hiện tại áp dụng mô hình phát triển chữ V, trong đó kiểm thử đóng vai trò quan trọng Mô hình này cho phép xác định các chiến lược kiểm thử phù hợp với từng giai đoạn phát triển của dự án, từ đó nâng cao hiệu quả và chất lượng sản phẩm.
Trong ngành phần mềm, kiểm thử đơn vị là phương pháp quan trọng để xác định tính đúng đắn của mã nguồn Tuy nhiên, nhiều lập trình viên vẫn chưa sử dụng công cụ sinh ca kiểm thử tự động, mà chủ yếu viết ca kiểm thử thủ công và chạy chúng trong môi trường lập trình.
Có nhiều kỹ thuật và phương pháp kiểm thử có thể áp dụng cho đơn vị/chương trình, bao gồm chiến lược kiểm thử dựa trên đặc tả bài toán (black box) với các kỹ thuật như phân lớp tương đương, phân tích giá trị biên, kiểm thử cặp và sử dụng bảng quyết định Ngoài ra, đối với chiến lược kiểm thử cấu trúc (white box), các kỹ thuật như kiểm thử dòng điều khiển và kiểm thử dòng dữ liệu cũng rất hữu ích Điều quan trọng là lập trình viên cần xây dựng một chiến lược kiểm thử hiệu quả, nhằm giảm thiểu số lượng ca kiểm thử trong khi vẫn đảm bảo hạn chế tối đa lỗi phát sinh.
Luận văn đã tiến hành thử nghiệm nhiều kỹ thuật kiểm thử khác nhau nhằm áp dụng cho bài toán thực tế trong dự án phần mềm, từ đó tạo ra các ca kiểm thử hiệu quả.
Từ đó, phân tích và đưa ra kết luận về chiến lược kiểm thử phù hợp sẽ áp dụng cho bài toán/ hàm thuộc chương trình.
Nội dung nghiên cứu
Bài viết này nghiên cứu và khảo sát tổng quan về kiểm thử phần mềm cùng các kỹ thuật kiểm thử liên quan Nó phân tích các kỹ thuật kiểm thử áp dụng cho mức độ kiểm thử đơn vị, nêu rõ ưu và nhược điểm của từng kỹ thuật, cũng như các bài toán cụ thể mà mỗi kỹ thuật sẽ được áp dụng.
Thông qua việc nghiên cứu các kỹ thuật kiểm thử, chúng tôi đã áp dụng các phương pháp này để tạo ra các ca kiểm thử cho các bài toán thực tế Dựa trên kết quả thu được, chúng tôi tiến hành phân tích và tổng hợp để phát triển chiến lược kiểm thử cho các hàm hoặc đơn vị cần kiểm thử, nhằm đảm bảo số lượng ca kiểm thử tối thiểu nhưng vẫn đạt được độ bao phủ cao nhất Cuối cùng, chúng tôi đưa ra kết luận về các chiến lược kiểm thử sẽ được áp dụng khi lập trình viên thực hiện kiểm thử ở mức độ đơn vị.
Cấu trúc luận văn
Luận văn có cấu trúc gồm năm phần như sau:
Chương 1: Đưa ra vấn đế nghiên cứu của luận văn Từ đó, mô tả khái quát nội dụng nghiên cứu của luận văn
Chương 2: Trình bày kiến thức tổng quan về kiểm thử phần mềm
Chương 3: Trình bày các kỹ thuật kiểm thử phần mềm áp dụng cho mức độ kiểm thử đơn vị
Chương 4: Đưa bài toán thực tế, tiến hành phân tích, đánh giá, nhận xét và đưa ra chiến lược kiểm thử áp dụng cho bài toán
Chương 5: Kết luận đưa ra kết quả đạt được của luận văn và hướng nghiên cứu tiếp theo của luận văn
quan về kiểm thử phần mềm
Kiểm thử và vai trò của kiểm thử
Kiểm thử phần mềm là yếu tố then chốt để đảm bảo sự thành công của sản phẩm phần mềm Quá trình này bao gồm việc cải tiến phần mềm thông qua kiểm thử, phát hiện và sửa lỗi liên tục trong suốt vòng đời phát triển Ở mỗi giai đoạn phát triển, cần thực hiện đánh giá để đảm bảo hệ thống hoạt động đúng trước khi sản phẩm được bàn giao Theo Friedman và Voas, kiểm thử phần mềm không chỉ là một quy trình mà còn là một phương pháp thẩm định nhằm nâng cao chất lượng sản phẩm.
Thông thường, các hoạt động đánh giá phần mềm được chia làm hai loại:
Phân tích tĩnh (static analysis) là quá trình đánh giá chương trình mà không cần thực thi mã lệnh, bao gồm các hoạt động như xem xét tài liệu đặc tả, tài liệu thiết kế, tài liệu ca kiểm thử và thanh tra mã nguồn.
Phân tích động (dynamic analysis) là quá trình đánh giá chương trình thông qua việc thực thi mã lệnh, bao gồm các kỹ thuật kiểm thử hộp đen và hộp trắng.
Người kiểm thử viên thực hiện phân tích tĩnh và động nhằm phát hiện nhiều lỗi nhất có thể, đồng thời đảm bảo rằng những lỗi này sẽ được khắc phục trong giai đoạn sớm của quy trình phát triển phần mềm.
Xác minh và thẩm định là hai bước quan trọng trong quy trình phát triển phần mềm, bắt đầu từ giai đoạn phân tích thiết kế Xác minh kiểm tra xem phần mềm có đáp ứng yêu cầu của tài liệu đặc tả hay không, nhằm trả lời câu hỏi "Hệ thống đã được xây dựng đúng theo tài liệu đặc tả hay chưa?" Mục tiêu chính của xác minh là phát hiện các lỗi lập trình.
Thẩm định phần mềm là quá trình kiểm tra xem sản phẩm có đáp ứng yêu cầu của người sử dụng hay không Mục tiêu chính của thẩm định là phát hiện các lỗi trong thiết kế và đặc tả trước khi bàn giao cho khách hàng Dù hệ thống có thể được xây dựng đúng theo đặc tả, nhưng vẫn có khả năng không thỏa mãn nhu cầu của khách hàng do đặc tả có thể sai, thiết kế thiếu chi tiết hoặc quá trình sử dụng không thuận tiện.
Các mục tiêu của kiểm thử
Trong quy trình phát triển phần mềm, các bên liên quan bao gồm lập trình viên, kiểm thử viên, quản trị dự án và khách hàng, mỗi đối tượng này có những quan điểm riêng về mục tiêu của kiểm thử.
Các lập trình viên thường tập trung vào việc đảm bảo chương trình hoạt động hiệu quả trong các điều kiện bình thường.
Chương trình không hoạt động có thể xảy ra khi lập trình viên không chú ý đến các vấn đề liên quan, đặc biệt là cách xử lý khi gặp lỗi Việc hiểu rõ nguyên nhân và biện pháp khắc phục khi chương trình gặp sự cố là rất quan trọng để đảm bảo hiệu suất và tính ổn định của phần mềm.
Giảm thiểu rủi ro do lỗi là một trong những ưu tiên hàng đầu của nhà quản trị phần mềm Các hệ thống phần mềm phức tạp thường ẩn chứa lỗi, và những lỗi này có thể dẫn đến thất bại của hệ thống Do đó, việc phát hiện và sửa chữa lỗi trong quá trình kiểm thử sẽ giúp giảm đáng kể tỷ lệ rủi ro mà hệ thống phải đối mặt.
Giảm chi phí kiểm thử là một yêu cầu phổ biến từ khách hàng, bao gồm các khoản chi cho thiết kế, bảo trì và thực thi các ca kiểm thử Điều này cũng bao gồm chi phí phân tích kết quả và tài liệu hóa các ca kiểm thử, cùng với chi phí cho hệ thống hoạt động và tài liệu hóa các hoạt động liên quan Khách hàng mong muốn giảm chi phí mà vẫn đảm bảo chất lượng kiểm thử.
Mục tiêu chính của kiểm thử là tối ưu hóa chi phí bằng cách thiết kế các bộ ca kiểm thử hiệu quả, đảm bảo bao phủ vùng kiểm thử tốt với số lượng ca kiểm thử ít hơn nhưng vẫn duy trì chất lượng cao.
Các hoạt động kiểm thử
Theo [2], để kiểm thử một chương trình phần mềm kỹ sư kiểm thử phải thực hiện một chuỗi các hoạt động như sau:
Để thiết kế các ca kiểm thử hiệu quả, trước tiên cần xác định rõ đối tượng cần kiểm thử Việc xác định đối tượng giúp đảm bảo rằng chương trình sẽ đáp ứng đầy đủ các yêu cầu của đối tượng đó, và mỗi đối tượng sẽ liên kết trực tiếp với một hoặc nhiều ca kiểm thử cụ thể.
Lựa chọn các giá trị đầu vào: Việc lựa chọn này dựa vào đặc tả yêu cầu, mã nguồn hoặc mong muốn của chúng ta
Tính toán giá trị đầu ra mong muốn: Tức là ứng với các giái trị đầu vào, cần tính toán giá trị đầu ra mong muốn của chương trình
Để thiết lập môi trường kiểm thử cho chương trình, cần đảm bảo rằng tất cả các giả định ngoài của chương trình được đáp ứng Điều này bao gồm việc thiết lập đúng đắn các hệ thống mạng và cơ sở dữ liệu, cũng như đảm bảo máy tương tác hoạt động hiệu quả.
Kỹ sư kiểm thử tiến hành kiểm tra chương trình bằng cách sử dụng các tập giá trị đầu vào và theo dõi giá trị đầu ra thực tế Để thực hiện một ca kiểm thử hiệu quả, các giá trị đầu vào cần được cung cấp cho chương trình tại các thời điểm khác nhau.
Phân tích kết quả kiểm thử là quá trình so sánh kết quả đầu ra thực tế với kết quả đầu ra mong muốn, với độ phức tạp của phép so sánh phụ thuộc vào dữ liệu quan sát Cuối cùng, từ việc phân tích này, cần đưa ra quyết định về việc chương trình có thỏa mãn (pass) hay không thỏa mãn (fail) yêu cầu của người dùng.
Các mức độ kiểm thử
Theo mô hình phát triển phần mềm chữ V, kiểm thử phần mềm là một chuỗi các hoạt động diễn ra song song với quá trình phát triển, bao gồm lập kế hoạch và kiểm soát, phân tích yêu cầu, thiết kế ca kiểm thử, viết ca kiểm thử, thực hiện kiểm thử, đánh giá kết quả và báo cáo tổng hợp Mối liên hệ giữa hoạt động phát triển phần mềm và kiểm thử phần mềm được thể hiện rõ ràng trong mô hình này.
Hình 2.1 Mô hình phát triền phầm mềm chữ V
Theo mô hình này, các hoạt động kiểm thử phần mềm bao gồm:
Mỗi hoạt động này tương ứng với các pha trong phát triển phần mềm từ đặc tả yêu cầu của khách hàng đến hoạt động lập trình
Theo [2], đơn vị (unit) là thành phần phần mềm nhỏ nhất có thể kiểm thử, bao gồm hàm, thủ tục, lớp hoặc phương thức Các thành phần này sẽ được kiểm thử ở cấp độ kiểm thử đơn vị trong quy trình kiểm thử phần mềm.
Kiểm thử đơn vị (unit testing - UT) là một cấp độ kiểm thử quan trọng, cho phép phát hiện lỗi trong các chức năng của phần mềm như module, đối tượng hay lớp Thông thường, lập trình viên sẽ thực hiện kiểm thử module ở mức đơn vị trước khi chuyển giao cho giai đoạn tích hợp với các module khác Việc này cần được thực hiện sớm trong quá trình viết mã nguồn và duy trì xuyên suốt chu kỳ phát triển phần mềm để đảm bảo chất lượng sản phẩm.
Trước khi tiến hành kiểm thử đơn vị (UT), các kiểm thử viên cần xác định rõ các tiêu chí và đối tượng sẽ được kiểm thử Thực tế cho thấy, UT nên tập trung vào việc kiểm tra các đối tượng cụ thể để đảm bảo chất lượng và tính chính xác của phần mềm.
Kiểm tra, xác minh hoạt động của các tham số với giá trị bình thường (norm)
Kiểm tra, xác minh hoạt động của các tham số với giá trị biên
Kiểm tra, xác minh hoạt động của các tham số với giá trị không nằm trong miền giới hạn (abnormal)
Kiểm tra sự hoạt động của các vòng lặp
Kiểm tra sự hoạt động của các hàm đệ quy
Kiểm tra sự truy cập cấu trúc dữ liệu/truy cập file
Đảm bảo rằng tất các các câu lệnh, các nhánh lệnh được thực thi đúng
Kiểm thử đơn vị, với kích thước nhỏ và chức năng đơn giản, dễ dàng tổ chức và phân tích kết quả Khi phát hiện lỗi, việc xác định nguyên nhân và khắc phục cũng trở nên thuận lợi hơn do chỉ cần tập trung vào một đơn thể cụ thể Thực tế cho thấy, thời gian đầu tư cho kiểm thử đơn vị sẽ được bù đắp bởi việc tiết kiệm thời gian và chi phí cho các giai đoạn kiểm thử và sửa lỗi sau này.
Kiểm thử đơn vị (UT) yêu cầu kiểm thử viên có hiểu biết về thiết kế và mã nguồn của chương trình, nhằm đảm bảo rằng thông tin được xử lý và xuất ra từ đơn vị là chính xác so với dữ liệu đầu vào và chức năng của nó Để phát hiện lỗi, tất cả các nhánh bên trong thành phần đơn vị cần được kiểm tra, vì một nhánh thường là chuỗi lệnh được thực thi Việc lựa chọn các nhánh để đơn giản hóa quá trình kiểm thử đòi hỏi kỹ thuật và đôi khi cần sử dụng thuật toán để lựa chọn hiệu quả.
Kiểm thử đơn vị, như các mức độ kiểm thử khác, cần phải chuẩn bị trước các ca kiểm thử và kịch bản kiểm thử, trong đó xác định rõ dữ liệu đầu vào, các bước thực hiện và dữ liệu đầu ra mong muốn Việc lưu giữ các ca kiểm thử và kịch bản này là cần thiết để có thể tái sử dụng trong tương lai.
Kiểm thử mức đơn vị cho phép phát hiện lỗi hiệu quả với sự hỗ trợ của các công cụ phát triển như framework và công cụ gỡ lỗi, giúp tìm ra hơn 25% tổng số lỗi trong dự án Kiểm thử tích hợp, do kỹ sư lập trình và kỹ sư kiểm thử thực hiện, đảm bảo chương trình hoạt động chính xác khi các đơn vị được kết hợp Nó cũng tương đương với việc kiểm tra thiết kế chi tiết để xác định xem chương trình có đáp ứng yêu cầu thiết kế hay không.
Kiểm thử tích hợp (integration test) là quá trình kết hợp các thành phần của một ứng dụng thành một hệ thống hoàn chỉnh và tiến hành kiểm tra chúng Trong khi kiểm thử đơn vị tập trung vào việc kiểm tra các thành phần riêng lẻ, kiểm thử tích hợp chú trọng vào việc kiểm tra sự giao tiếp và tương tác giữa các thành phần này Đây là giai đoạn tiếp theo sau kiểm thử đơn vị, được thực hiện bởi đội ngũ kiểm thử viên, nhằm đảm bảo rằng các thành phần đã được tích hợp một cách hiệu quả Trước khi bắt đầu kiểm thử tích hợp, cần xác nhận rằng các thành phần đơn vị đã vượt qua kiểm thử đơn vị (UT) thành công.
Mục tiêu chính của kiểm thử tích hợp là phát hiện lỗi giao tiếp giữa các đơn vị, từ việc tích hợp các thành phần đơn lẻ thành hệ thống nhỏ đến việc hình thành một hệ thống hoàn chỉnh để chuẩn bị cho kiểm thử ở mức hệ thống Mặc dù có một số phép kiểm thử đơn giản cho giao tiếp giữa đơn vị và các thành phần liên quan, nhưng chỉ khi các đơn vị được tích hợp với nhau trong quá trình kiểm thử tích hợp, thì giao tiếp giữa chúng mới được kiểm tra đầy đủ.
Kiểm thử tích hợp nên được thực hiện trên các đơn vị đã qua kiểm thử cẩn thận và sửa chữa lỗi Việc tích hợp từng đơn vị một cách dần dần là cần thiết, bởi vì sự kết hợp giữa các đơn vị có thể tạo ra tình huống mới Khi tích hợp một thành phần đơn vị vào nhóm đã được kiểm thử, chỉ cần kiểm thử giao tiếp của đơn vị mới với hệ thống đã tích hợp, giúp giảm số lượng ca kiểm thử và sai sót Trong kiểm thử tích hợp, có hai chiến lược chính là kiểm thử từ dưới lên và kiểm thử từ trên xuống.
1 Kiểm thử từ dưới lên (bottom up testing ) là quá trình tích hợp và kiểm thử các module ở mức thấp trước Thông thường người ta không thuần túy kiểm thử tất cả các module ở tầng dưới cùng mà nhóm các module này thành các nhóm chức năng, tích hợp và kiểm thử chúng theo từng nhóm Ưu điểm: Chiến lược kiểm thử từ dưới lên sẽ giúp cho kiểm thử viên tránh được việc phải tạo ra các bộ giả lập đầu vào phức tạp hay tạo các kết quả nhân tạo để thực hiện kiểm thử và thuận tiện cho việc phát triển các module thứ cấp dùng lại được Nhược điểm: Phát hiện chậm các lỗi thiết kế và chậm trễ trong việc có được phiên bản thực thi của hệ thống
2 Kiểm thử từ trên xuống (top down testing) là quá trình tiến hành kiểm thử các module ở mức cao trước, các module ở mức thấp được tạm thời phát triển với các chức năng hạn chế Thông thường để sớm có một phiên bản phần mềm để thực hiện người ta thường tiến hành tích hợp theo một nhánh cho đến các module cấp thấp nhất Ưu điểm: Giúp cho người phát triển phát hiện sớm các lỗi thiết kế và có phiên bản thực thi hoạt động sớm
Phương pháp này có nhược điểm là khó mô phỏng các chức năng phức tạp của module cấp thấp, dẫn đến việc không thể kiểm thử đầy đủ các chức năng của hệ thống.
Trong kiểm thử tích hợp, hai phương pháp chính được áp dụng là kiểm thử hộp trắng (để kiểm tra cấu trúc) và kiểm thử hộp đen (để kiểm tra chức năng) Bên cạnh đó, trong quá trình tích hợp, việc sử dụng kỹ thuật bộ cuống và bộ lái là cần thiết để thay thế các mô-đun còn thiếu, đảm bảo tính toàn vẹn của hệ thống được kiểm thử.
Hình 2.2 Kỹ thuật bộ cuống và bộ lái trong chiến lươc tích hợp dần
kỹ thuật kiểm thử phần mềm
Kiểm thử hộp đen
Kiểm thử hộp đen là một phương pháp quan trọng trong kiểm thử phần mềm, trong đó kiểm thử viên không cần biết cách cài đặt bên trong của chương trình, mà chỉ tập trung vào việc xác định chức năng và yêu cầu của nó thông qua các ca kiểm thử đã được định nghĩa Các kỹ thuật phổ biến trong kiểm thử hộp đen bao gồm phân lớp tương đương, phân tích giá trị biên, bảng quyết định, bảng chuyển trạng thái và kiểm thử ca sử dụng.
3.1.1 Kỹ thuật phân lớp tương đương(Equivalence Class Testing)
Phân lớp tương đương là kỹ thuật kiểm thử hộp đen dựa trên tài liệu đặc tả của hệ thống, giúp chia miền dữ liệu thành các lớp con mà các giá trị trong mỗi lớp sẽ có sự tương tác giống nhau Kỹ thuật này cho phép xác định một ca kiểm thử để phát hiện lỗi trong một lớp, từ đó giảm số lượng ca kiểm thử cần thiết.
Hình 3.1 Trực quan mô tả phân lớp tương đương
Thiết kế ca kiểm thử cho phân lớp tương đương dựa trên đánh giá các lớp tương đương của điều kiện đầu vào Lớp tương đương đại diện cho tập hợp các trạng thái hợp lệ và không hợp lệ Dữ liệu trong phân lớp tương đương được chia thành hai loại: lớp tương đương hợp lệ, chứa dữ liệu trong miền giá trị hợp lệ, và lớp tương đương không hợp lệ, chứa dữ liệu nằm trong miền giá trị không hợp lệ.
Thiết kế Test-case bằng phân lớp tương đương tiến hành theo hai bước:
(1) Xác định các lớp tương đương và
(2) Xác định các ca kiểm thử
(1)Xác định các lớp tương đương
Theo [9], lớp tương đương có thể được xác định dựa theo các yếu tố sau:
Nếu điều kiện đầu vào xác định một miền giới hạn [a,b], thì sẽ có một lớp tương đương hợp lệ bao gồm các giá trị trong khoảng a < X < b, cùng với hai lớp tương đương không hợp lệ: một lớp chứa các giá trị X < a và một lớp chứa các giá trị X > b.
Nếu điều kiện đầu vào yêu cầu các giá trị xác định như {M1}, {M2}, {M3}, {M4}, …{Mn}, thì sẽ có một lớp tương đương hợp lệ chứa các giá trị này và một lớp tương đương không hợp lệ bao gồm các giá trị nằm ngoài tập hợp trên.
Nếu điều kiện đầu vào xác định cho từng giá trị riêng lẻ thì xác định một lớp cho từng giá trị đầu vào hợp lệ
Nếu điều kiện đầu vào xác định số lượng giá trị hợp lệ (ví dụ là n), thì cần xác định một lớp tương đương cho số lượng giá trị hợp lệ và hai lớp tương đương cho giá trị không hợp lệ: một lớp cho trường hợp không có giá trị (0) và một lớp cho trường hợp có nhiều hơn n giá trị.
Nếu điều kiện đầu vào yêu cầu một giá trị, thì sẽ có một lớp tương đương hợp lệ (là giá trị đó) và một lớp tương đương không hợp lệ (không phải là giá trị đó) được xác định.
(2) Xác định các ca kiểm thử
Sau khi xác định các lớp tương đương ở bước trước, bước tiếp theo là sử dụng những lớp này để xây dựng các ca kiểm thử Quá trình này diễn ra như sau [2]:
1 Gán một số duy nhất cho mỗi lớp tương đương
2 Với mỗi lớp tương đương bao gồm các giá trị hợp lệ chưa được bao phủ bởi các ca kiểm thử trên thì viết một ca kiểm thử mới bao phủ được nhiều nhất có thể các lớp tương đương
3 Với mỗi lớp tương đương bao gồm các giá trị không hợp được bao phủ hết bởi các ca kiểm thử trên thì ta viết một ca kiểm thử mà bao phủ một và chỉ một trong các lớp tương đương chưa được bao phủ
Kỹ thuật kiểm thử phân lớp tương đương bao gồm ba phương pháp chính: phân lớp tương đương yếu, phân lớp tương đương mạnh và phân lớp tương đương truyền thống Những kỹ thuật này giúp xác định các nhóm đầu vào tương tự để tối ưu hóa quy trình kiểm thử phần mềm.
Phân lớp tương đương yếu là một kỹ thuật kiểm thử dựa trên nguyên tắc chia miền dữ liệu đầu vào thành các lớp con tương đương Kỹ thuật này yêu cầu mỗi lớp con phải được kiểm tra ít nhất một lần, do đó số trường hợp kiểm thử tối thiểu bằng giá trị lớn nhất của số phân hoạch biến đầu vào, tức là lực lượng lớn nhất của phân hoạch.
Phân lớp tương đương mạnh là quá trình phân hoạch miền giá trị của các biến đầu vào thành các lớp tương đương Từ đó, chúng ta tạo ra các trường hợp kiểm thử dựa trên nguyên tắc rằng mỗi ca kiểm thử sẽ là một phần tử trong tích đề các của các phân hoạch con Do đó, số lượng ca kiểm thử được sinh ra tương ứng với số phần tử của tích đề các này.
Phân lớp tương đương truyền thống là kỹ thuật cơ bản nhất trong kiểm thử phân lớp tương đương Kỹ thuật này yêu cầu phân lớp các biến giá trị đầu vào thành hai lớp chính để thực hiện kiểm thử hiệu quả.
Lớp tương đương hợp lệ: Chứa dữ liệu của biến đầu vào nằm trong miền hợp lệ
Khi xây dựng ca kiểm thử cho trường hợp đúng, chúng ta cần sử dụng các giá trị biến đầu vào nằm trong miền hợp lệ Ngược lại, để tạo ca kiểm thử cho trường hợp sai, chỉ cần chọn một biến đầu vào có giá trị không hợp lệ Mỗi ca kiểm thử với biến đầu vào không hợp lệ sẽ bao gồm một biến có giá trị không nằm trong miền hợp lệ, trong khi các biến còn lại vẫn phải nằm trong miền hợp lệ.
Kiểm thử hộp trắng
Kỹ thuật kiểm thử hộp trắng, hay còn gọi là kiểm thử hướng cấu trúc, được sử dụng để xác minh tính chính xác của mã nguồn đã lập trình Phương pháp này tập trung vào việc kiểm tra các mã nguồn và mã lệnh, thay vì các chương trình đã được thực thi.
Do đó, kỹ thuật này được áp dụng để kiểm thử cấu trúc chương trình, dòng điều khiển và dòng xử lý dữ liệu của chương trình
Kỹ thuật này thường đòi hỏi nhiều thời gian và công sức, vì vậy nó thường chỉ được áp dụng ở mức độ kiểm thử đơn vị, như hàm hoặc lớp thành phần, mà không thực hiện ở các mức độ cao hơn.
Các kỹ thuật kiểm thử hộp trắng là: Kiểm thử dòng điều khiển, kiểm thử dòng dữ liệu và kiểm thử miền
3.2.1 Kỹ thuật dòng điều khiển (Control Flow Testing)
Kỹ thuật dòng điều khiển là phương pháp tạo ra các testcase dựa trên việc mô hình hóa luồng xử lý của hệ thống thông qua đồ thị dòng điều khiển Để xác định kiểm thử, chúng ta sẽ chuyển đổi mã nguồn thành đồ thị dòng điều khiển Mỗi nhánh trong luồng xử lý sẽ tạo ra một đường đi, từ đó sinh ra các testcase tương ứng.
Kỹ thuật này là kỹ thuật kiểm thử căn bản và được áp dụng hiệu quả cho nhiều hệ thống, nhiều giai đoạn test khác nhau
Các bộ giá trị kiềm thử được sinh ra từ kỹ thuật này có khả năng kiểm tra tính đúng đắn của các thành phần trong chương trình, bao gồm các phương thức, câu lệnh, nhánh và các điều kiện như if và switch.
Hình 3.6 Sơ đồ dòng điều khiển
Các ký hiệu sử dụng trong đồ thị CFG:
Để đánh giá mức độ bao phủ của chương trình từ một tập ca kiểm thử, ta sử dụng khái niệm độ đo kiểm thử Mức độ bao phủ được tính bằng tỷ lệ các thành phần đã được kiểm thử so với tổng thể sau khi thực hiện ca kiểm thử Độ bao phủ cao hơn đồng nghĩa với độ tin cậy của bộ kiểm thử cũng tăng lên.
Trong kiểm thử phần mềm, có ba độ đo kiểm thử phổ biến Độ đo kiểm thử cấp 1 (C1) yêu cầu mỗi câu lệnh được thực hiện ít nhất một lần sau khi chạy toàn bộ ca kiểm thử Độ đo kiểm thử cấp 2 (C2) đảm bảo rằng các điểm quyết định trong đồ thị đều được thực hiện ít nhất một lần cho cả hai nhánh đúng và sai Độ đo kiểm thử cấp 3 (C3) tập trung vào các điều kiện phức tạp, yêu cầu rằng các điều kiện con của các điều kiện phức tạp cần phải được thực hiện ít nhất một lần cho cả hai nhánh đúng và sai để đảm bảo tính chính xác của chương trình.
Dựa trên các định nghĩa về độ đo, kiểm thử độ đo có thể được áp dụng để xác định số lượng ca kiểm thử cần thiết nhằm đảm bảo rằng các ca kiểm thử bao phủ một độ đo cụ thể Theo tài liệu [1], số đường đi tương ứng với đồ thị dòng điều khiển có thể được tính toán bằng hai phương pháp khác nhau.
2 Số đỉnh quyết định + 1 Ứng với mỗi đường đi ta sẽ sinh ra được một ca kiểm thử tương ứng
Mặc dù việc xây dựng kiểm thử dựa trên độ đo đã được thực hiện, nhưng vẫn chưa thể kiểm tra các lỗi phát sinh từ vòng lặp trong chương trình Trong quá trình viết mã nguồn cho các đơn vị hoặc hàm, lỗi do sử dụng vòng lặp thường xảy ra và có ảnh hưởng lớn đến toàn bộ chương trình Theo [1], khi làm việc với chương trình có vòng lặp, cần chú ý đến loại vòng lặp được sử dụng.
Lệnh lặp đơn giản: Tức là đơn vị chương trình chỉ có chứa một lệnh lặp
Lệnh lặp liền kề: Tức là đơn vị chương trình chứa lệnh lặp liền kề nhau
Lệnh lặp lồng nhau là khi một chương trình chứa lệnh lặp bên trong lệnh lặp khác Để kiểm thử các vòng lặp này, chúng ta cần xây dựng các ca kiểm thử dựa trên số lần thực hiện của từng vòng lặp trong chương trình.
1 Vòng lặp thực hiện 0 lần
2 Vòng lặp thực hiện 1 lần
3 Vòng lặp thực hiện 2 lần
4 Vòng lặp thực hiện k lần, 2 < k < n - 1, với n là số lần lặp tối đa của vòng lặp
5 Vòng lặp thực hiện n - 1 lần
6 Vòng lặp thực hiện n lần
7 Vòng lặp thực hiện n + 1 lần
Trong một số tình huống, việc xác định số vòng lặp tối đa có thể gặp khó khăn Do đó, chúng ta chỉ cần áp dụng phương pháp sinh ca kiểm thử với bốn trường hợp đầu tiên Đối với những trường hợp không xác định được lệnh lặp thực hiện n+1 lần, chỉ cần áp dụng sinh kiểm thử với sáu trường hợp trước đó.
Kỹ thuật kiểm thử dòng điều khiển giúp phát hiện lỗi tiềm ẩn trong chương trình bằng cách xác định các đường đi tương ứng với dòng điều khiển từ đồ thị dòng điều khiển Mỗi đường đi sẽ được xây dựng thành một ca kiểm thử, đảm bảo rằng đường đi đó có thể thực thi được.
Mặc dù không nhiều công ty phần mềm áp dụng kỹ thuật kiểm thử này do tính khó khăn và chi phí cao hơn so với các kỹ thuật kiểm thử hộp đen, nhưng một số công cụ đã được phát triển để hỗ trợ thực hiện kỹ thuật này Các công cụ này cho phép thực thi các ca kiểm thử trên một đơn vị hàm nhằm xác định tính đúng đắn của hàm dựa trên kết quả của các ca kiểm thử.
3.2.2 Kỹ thuật dòng dữ liệu (Data Flow Testing)
Kỹ thuật kiểm thử dòng dữ liệu là phương pháp sinh ca kiểm thử dựa trên các đường đi từ đồ thị dòng dữ liệu Trong kỹ thuật này, các đường dẫn kiểm thử của chương trình được xác định dựa vào vị trí khai báo và cách sử dụng các biến trong mã nguồn.
Trong quá trình lập trình, lập trình viên có thể tạo ra các câu lệnh không tuân theo chuẩn, bao gồm việc khai báo biến và dữ liệu không chính xác, khởi tạo giá trị biến sai hoặc sử dụng và gán giá trị không đúng Những vấn đề này liên quan đến dòng dữ liệu trong chương trình và được phân loại thành ba loại khác nhau theo [1].
Gán giá trị rồi gán tiếp giá trị (loại 1)
Chưa gán giá trị nhưng được sử dụng (loại 2)
Đã được khai báo và gán giá trị nhưng không được sử dụng (loại 3)
Huang đã phát triển một phương pháp để phát hiện bất thường trong việc sử dụng các biến dữ liệu thông qua sơ đồ chuyển trạng thái tương ứng với từng biến trong chương trình Để áp dụng kỹ thuật kiểm thử dòng dữ liệu động, cần xác định các đường dẫn chương trình có điểm đầu vào và điểm đầu ra, nhằm đảm bảo việc gán giá trị và sử dụng mỗi biến trong chương trình hoặc đơn vị chương trình cần kiểm thử được bao phủ đầy đủ Các bước thực hiện được mô tả chi tiết trong tài liệu.
Xây dựng đồ thị dòng dữ liệu của chương trình/đơn vị chương trình
Chọn một hoặc một số tiêu chí kiểm thử dòng dữ liệu
Xác định các đường dẫn chương trình phù hợp với tiêu chí kiểm thử đã chọn
