(LUẬN văn THẠC sĩ) kiểm thử đơn vị cho hệ thống

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 ngày càng trở nên quan trọng Hầu hết các dự án phát triển phần mềm hiện nay áp dụng mô hình phát triển chữ V, trong đó kiểm thử đóng vai trò thiết yếu 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 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 Mặc dù vậy, nhiều lập trình viên hiện nay vẫn chưa áp dụng công cụ sinh ca kiểm thử tự động, mà vẫn thực hiện kiểm thử thủ công và chạy ca kiểm thử trong môi trường lập trình.

Có nhiều kỹ thuật kiểm thử hiệu quả cho đơn vị/chương trình, bao gồm các phương pháp kiểm thử dựa trên đặc tả bài toán như phân lớp tương đương, phân tích giá trị biên, kiểm thử cặp và bảng quyết định Đối với kiểm thử cấu trúc, 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 quan trọng Lập trình viên cần xây dựng một chiến lược kiểm thử hợp lý nhằm tối ưu hóa hiệu quả kiểm thử, giảm thiểu số lượng ca kiểm thử và hạn chế 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 tập trung vào 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ử được áp dụng cho mức độ kiểm thử đơn vị, đồng thời 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ể sẽ áp dụng cho từng phương pháp kiểm thử.

Bài viết này tập trung vào việc áp dụng các kỹ thuật kiểm thử để tạo ra ca kiểm thử cho 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à xây dựng chiến lược kiểm thử nhằm đảm bảo rằng số ca kiểm thử là tối thiểu nhưng độ bao phủ đạt mức 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 thành công cho 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 việc lặp lại kiểm thử, tìm lỗi và sửa lỗi trong suốt giai đoạn phát triển Mỗi giai đoạn phát triển cần có đánh giá hệ thống để đảm bảo hoạt động đúng trước khi bàn giao sản phẩm Theo Friedman và Voas, kiểm thử phần mềm là quá trình thẩm định nhằm nâng cao chất lượng sản phẩm Các hoạt động đánh giá phần mềm thường được phân chia thành 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 việc xem xét các tài liệu như đặc tả, thiết kế, 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 các lỗi được phát hiện sẽ được sửa chữa trong các giai đoạn đầu 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 quá 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 các 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 khả năng đáp ứng yêu cầu của người sử dụng, tập trung vào sản phẩm cuối cùng khi bàn giao cho khách hàng Mục tiêu chính của thẩm định là phát hiện các lỗi liên quan đến thiết kế và đặc tả Dù một hệ thống có thể được xây dựng đúng theo đặc tả, nhưng vẫn có thể không đáp ứng yêu cầu của khách hàng do đặc tả 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 như lập trình viên, kiểm thử viên, quản trị dự án và khách hàng đều có những quan điểm khác nhau về mục tiêu của kiểm thử Theo tài liệu [6], sự đa dạng trong cái nhìn này giúp đảm bảo rằng các yêu cầu và tiêu chuẩn chất lượng được đáp ứng một cách toàn diện.

Các lập trình viên thường tập trung vào việc làm cho chương trình hoạt động hiệu quả trong các điều kiện thông thường.

Chương trình không hoạt động thường xảy ra, nhưng lập trình viên thường ít chú ý đến vấn đề này Họ cần quan tâm đến thời điểm chương trình gặp lỗi và cách khắc phục những sự cố đó để đảm bảo hiệu suất và độ tin cậy của ứng dụng.

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 tiềm ẩn nhiều lỗi, dẫn đến nguy cơ thất bại Do đó, việc phát hiện và sửa lỗi trong quá trình kiểm thử là rất quan trọng, giúp giảm thiểu tỷ lệ rủi ro cho hệ thống.

Giảm chi phí kiểm thử là một yêu cầu quan trọng của khách hàng, bao gồm các khoản chi phí như thiết kế, bảo trì, thực thi ca kiểm thử, phân tích kết quả, tài liệu hóa và duy trì hệ thống kiểm thử Khách hàng mong muốn giảm thiểu chi phí mà vẫn đảm bảo chất lượng sản phẩm.

Mục tiêu chính của kiểm thử là tối ưu hóa chi phí thông qua việc thiết kế các bộ ca kiểm thử hiệu quả, đảm bảo vùng kiểm thử được bao phủ tốt Điều này cho phép giảm số lượng ca kiểm thử mà vẫn đảm bảo 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ế ca kiểm thử hiệu quả, trước tiên cần xác định đối tượng kiểm thử, nhằm đảm bảo chương trình đáp ứng đúng yêu cầu Một đối tượng rõ ràng sẽ giúp kết nối trực tiếp với các ca kiểm thử tương ứng.

 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 bên ngoài đều được thỏa mãn Đ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ư các máy tương tác cần thiết.

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 khác nhau 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 vào những thời điểm khác nhau.

Phân tích kết quả kiểm thử là quá trình so sánh giữa kết quả đầu ra thực tế và kết quả đầu ra mong muốn Độ phức tạp của việc so sánh này phụ thuộc vào tính chất của dữ liệu quan sát Cuối cùng, cần đưa ra quyết định về việc chương trình có đáp ứng yêu cầu của người dùng hay không, với các kết quả là thỏa mãn (pass), không thỏa mãn (fail) hoặc không thể đưa ra quyết định.

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 diễn ra song song với quá trình phát triển, bao gồm lập kế hoạch, 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 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 hay phương thức Các thành phần này đượ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 Quy trình này thường được thực hiện bởi lập trình viên trước khi chuyển giao sang giai đoạn tích hợp với các module khác Để đảm bảo chất lượng, kiểm thử đơn vị cần được thực hiện ngay từ giai đoạn viết mã nguồn và duy trì xuyên suốt chu kỳ phát triển phần mềm.

Trước khi tiến hành kiểm thử đơn vị (UT), kiểm thử viên cần xác định rõ ràng các tiêu chí và đối tượng sẽ được kiểm thử Thực tế, UT nên tập trung vào việc kiểm tra các đối tượng cụ thể để đảm bảo hiệu quả và chất lượng 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

Việc kiểm thử đơn vị thường diễn ra trên các đơn vị nhỏ với chức năng đơn giản, giúp cho quá trình tổ chức, ghi nhận và phân tích kết quả trở nên dễ dàng Khi phát hiện lỗi, việc xác định nguyên nhân và khắc phục cũng đơn giản hơn vì chỉ cần tập trung vào đơn thể đang được kiểm tra Thực tế cho thấy, thời gian đầu tư cho kiểm thử đơn vị sẽ mang lại lợi ích lớn, tiết kiệm đáng kể 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ó kiến thức về thiết kế và mã nguồn của chương trình, nhằm đảm bảo thông tin xử lý và xuất ra từ đơn vị là chính xác với dữ liệu đầu vào và chức năng của nó Để phát hiện lỗi, cần kiểm tra tất cả các nhánh bên trong thành phần đơn vị, vì mỗi nhánh là một 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à có thể cần sử dụng thuật toán để đạt hiệu quả tối ưu.

Kiểm thử đơn vị yêu cầu chuẩn bị kỹ lưỡng các ca kiểm thử và kịch bản kiểm thử, bao gồm 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 trữ các ca kiểm thử và kịch bản này là cần thiết để 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, với hơn 25% tổng số lỗi của dự án thường được phát hiện trong giai đoạn này Kiểm thử tích hợp, do các kỹ sư lập trình và kiểm thử thực hiện, đảm bảo rằng chương trình hoạt động chính xác khi các đơn vị được kết hợp, đồng thời kiểm tra xem chương trình có đáp ứng các yêu cầu thiết kế chi tiết 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 ứng dụng thành một hệ thống hoàn chỉnh và tiến hành kiểm tra sự giao tiếp cũng như tương tác giữa chúng Khác với kiểm thử đơn vị, chỉ kiểm tra các thành phần riêng lẻ, kiểm thử tích hợp tập trung vào việc xác minh sự hoạt động của các thành phần khi làm việc cùng nhau Đây là giai đoạn tiếp theo sau kiểm thử đơn vị, do nhóm kiểm thử viên thực hiện, nhằm đảm bảo rằng các thành phần đã vượt qua kiểm thử đơn vị trước khi tiến hành kiểm thử tích hợp.

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ị và tích hợp các thành phần đơn lẻ thành hệ thống nhỏ, cuối cùng tạo 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 việc kiểm tra đầy đủ chỉ diễn ra khi các đơn vị được tích hợp trong quá trình kiểm thử tích hợp.

Kiểm thử tích hợp nên được thực hiện trên những đơn vị đã qua kiểm thử đơn vị cẩn thận và đã sửa chữa lỗi Việc tích hợp các đơn vị có thể tạo ra những tình huống mới, do đó chỉ kiểm thử đơn vị là không đủ Một chiến lược hiệu quả là tích hợp từng đơn vị một, cho phép kiểm tra giao tiếp giữa đơn vị mới và các đơn vị đã tích hợp trước đó, 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.

Hai phương pháp kiểm thử tích hợp phổ biến là kiểm thử hộp trắng (kiểm thử cấu trúc) và kiểm thử hộp đen (kiểm thử chức năng) Trong quá trình tích hợp, cần áp dụng kỹ thuật bộ cuống và bộ lái để 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 thức hoạt động 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ụ thể Một số 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ả hệ thống, chia miền dữ liệu thành các lớp con có giá trị tương tác giống nhau Kỹ thuật này giúp xác định ca kiểm thử để phát hiện lỗi trong từng 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 việc đá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ệ liên quan đến điều kiện đầu vào 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 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ì có một lớp tương đương hợp lệ với các giá trị a < X < b, cùng với hai lớp tương đương không hợp lệ, bao gồm 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 {M1}, {M2}, {M3}, {M4}, …, {Mn}, thì sẽ có một lớp tương đương hợp lệ chứa các giá trị {M1, M2, M3, M4, …, Mn} và một lớp tương đương không hợp lệ chứa các giá trị ngoài {M1, M2, M3, M4, …, Mn}.

 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ệ

Khi điều kiện đầu vào xác định số lượng giá trị hợp lệ (ví dụ n), 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 một điều kiện đầu vào yêu cầu phải là một giá trị, thì sẽ có một lớp tương đương hợp lệ tương ứng với giá trị đó và một lớp tương đương không hợp lệ cho giá trị không phù hợp.

(2) Xác định các ca kiểm thử

Sau khi xác định các lớp tương đương, bước tiếp theo là sử dụng chúng để xác định các ca kiểm thử Quá trình này diễn ra theo các bước cụ thể.

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 loại 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 Mỗi loại kỹ thuật này mang lại những cách tiếp cận khác nhau trong việc kiểm tra và đánh giá chất lượng phần mềm.

Phân lớp tương đương yếu là một kỹ thuật kiểm thử quan trọng, 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 Trong quá trình sinh ca kiểm thử, mỗi lớp con cần được kiểm tra ít nhất một lần, đảm bảo tính toàn diện của quá trình kiểm thử Số lượng trường hợp kiểm thử trong kỹ thuật này được xác định 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 được thực hiện bằng cách chia 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 sẽ 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ử là một phần tử của tích đề các 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 đơn giản nhất trong kiểm thử phân lớp tương đương Kỹ thuật này chỉ cần tập trung vào hai lớp cho các biến giá trị đầu vào.

 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ử, lớp tương đương không hợp lệ chứa dữ liệu của biến đầu vào nằm trong miền không hợp lệ Đối với ca kiểm thử hợp lệ, chúng ta chỉ cần sử dụng các giá trị của biến đầu vào nằm trong miền hợp lệ Ngược lại, khi tạo ca kiểm thử cho trường hợp không hợp lệ, một trong các biến đầu vào sẽ 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 đã được lập trình Phương pháp này tập trung vào việc kiểm tra mã lệnh và mã nguồn, 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 yêu cầu 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, thay vì ở các mức độ kiểm thử 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 bằng cách mô hình hóa các 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 các dòng lệnh từ mã nguồn thành đồ thị dòng điều khiển Mỗi rẽ nhánh trong luồng xử lý sẽ tạo ra một đường đi, và từ những đường đi này, chúng ta sẽ 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 tạo ra từ kỹ thuật này có khả năng kiểm tra tính chính xác 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à đ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:

Để xác định mức độ bao phủ của chương trình từ một tập ca kiểm thử, ta áp dụng khái niệm độ đo kiểm thử Mức độ bao phủ được tính bằng tỷ lệ giữa số thành phần thực sự được kiểm thử và tổng số thành phần sau khi thực hiện ca kiểm thử Độ bao phủ càng cao thì độ tin cậy của bộ kiểm thử cà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 các ca kiểm thử Độ đo kiểm thử cấp 2 (C2) yêu cầu các điểm quyết định trong đồ thị được thực hiện ít nhất một lần cho cả hai nhánh đúng và sai Cuối cùng, độ đo kiểm thử cấp 3 (C3) đề cập đến việc kiểm tra các điều kiện phức tạp, trong đó không chỉ cần quan tâm đến giá trị đúng sai mà còn đảm bảo rằng tất cả các điều kiện con thuộc các điều kiện phức tạp đều được thực hiện ít nhất một lần cho cả hai nhánh đúng và sai.

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 các ca này bao phủ một độ đo cụ thể Theo [1], số đường đi tương ứng với đồ thị dòng điều khiển có thể được tính 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

Trong quá trình xây dựng kiểm thử dựa trên độ đo, chúng ta cần chú ý đến việc kiểm tra các lỗi phát sinh từ vòng lặp trong chương trình, vì đây là nguồn gốc của nhiều vấn đề nghiêm trọng Các lỗi do sử dụng vòng lặp thường gặp trong mã nguồn của các đơn vị/hàm và có thể ảnh hưởng lớn đến hiệu suất và độ tin cậy của chương trình Theo [1], khi làm việc với chương trình có vòng lặp, việc xác định loại vòng lặp là rất quan trọng để đảm bảo chất lượng mã nguồn.

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à một cấu trúc trong chương trình, trong đó có lệnh lặp chứa bên trong một 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

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ố trường hợp, việc xác định số vòng lặp tối đa là khó, ta chỉ cần pá dụng việc sinh ca kiểm thử với bốn trường hợp đầu tiên 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, ta chỉ áp dụng sinh kiểm thử với 6 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 trong đồ thị sẽ được xây dựng thành một ca kiểm thử, đảm bảo rằng đường đi đó có thể được thực thi.

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 độ khó 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 Những công cụ này cho phép thực thi các ca kiểm thử trên đơn vị hàm, nhằm xác định tính đúng đắn của hàm dựa trên kết quả chạy 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 tạo ca kiểm thử dựa trên các đường đi từ đồ thị dòng dữ liệu Các đường dẫn kiểm thử của chương trình được xác định dựa trên vị trí khai báo và cách sử dụng các biến trong chương trình.

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 sai, dữ liệu không đúng, khởi tạo giá trị biến không chính xác và việc sử dụng, gán giá trị không hợp lệ Những vấn đề này liên quan đến dòng dữ liệu của chương trình và được phân loại thành ba loại khác nhau.

 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 [7] đã 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 của 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 với một điểm đầu vào và một đ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 kiểm thử Các bước thực hiện được trình bày như sau [1]:

 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

toán áp dụng

Bài toán 1

Phát biểu bài toán: Xác định ngày thực hiện giao dịch theo ngày đăng ký cuối cùng của từng hình thức thực hiện quyền

Bài toán được mô tả như sau:

Ngày thực hiện giao dịch của chỉ số được xác định dựa trên giá trị của ngày đăng ký cuối cùng, và điều này phụ thuộc vào từng hình thức thực hiện quyền đã được quy định.

Nếu cổ tức được trả bằng tiền mặt, ngày thực hiện giao dịch sẽ là ngày đăng ký cuối cùng trừ đi 2 ngày.

Nếu hình thức thực hiện quyền là hình thức niêm yết bổ sung thì ngày thực hiện giao dịch sẽ bằng ngày đăng ký cuối cùng lùi lại 1 ngày

Nếu hình thức thực hiện quyền là hình thức thay đổi tỷ lệ Free float thì ngày thực hiện giao dịch sẽ chính là ngày đăng ký cuối cùng

Ngoài ra, ngày thực hiện giao dịch phải là ngày làm việc trong tuần, không tính ngày thứ bảy, chủ nhật và ngày nghỉ lễ tết trong năm

Xác định dữ liệu nhƣ sau:

 Ngày đăng ký cuối cùng kiểu Datetime

 Hình thức thực hiện quyền kiểu Int được quy định như sau:

 Hình thức trả cổ tức bằng tiền mặt là 1

 Hình thức niêm yết bổ sung là 2

 Hình thức thay đổi tỷ lệ Free float là 3

Dữ liệu đầu ra: Ngày thực hiện giao dịch kiểu Datetime

Từ phân tích bài toán theo đặc tả yêu cầu ta áp dụng các kỹ thuật kiểm thử để xây dựng ca kiểm thử như sau:

4.1.1 Áp dụng kỹ thuật phân lớp tương đương Đối với biến thứ nhất là ngày đăng ký cuối cùng ta sẽ phân hoạch tương đương dựa vào sự kết quả trả ra khi truyển dữ liệu đầu vào khác nhau như sau:

Miền 1 là các dữ liệu đầu vào là ngày thường mà khi áp dụng theo từng hình thức thì ngày thực hiện quyền vẫn là ngày thường

Miền 2 là các dữ liệu đầu vào là ngày nghỉ, ngày lễ tết Trong miền 2 ta lại chia thành hai miền con như sau: o Miền con 1: các ngày nghỉ, ngày lễ tết mà ngày thực hiện quyền chỉ tính lại 1 ngày là thỏa mãn điều kiện không phải là ngày nghỉ o Miền con 2: các ngày nghỉ, ngày lễ tết mà ngày thực hiện quyền chỉ tính lại nhiều hơn 1 ngày là thỏa mãn điều kiện không phải là ngày nghỉ

Số miền tương đương được sinh ra là 3 miền, với hai giá trị biên tương ứng là ngày thứ 7 và ngày chủ nhật Đối với biến thứ hai, hình thức thực hiện quyền được biểu diễn dưới dạng kiểu int, dẫn đến các miền dữ liệu bao gồm các giá trị không phải là hình thức thực hiện quyền (giá trị < 1 hoặc > 3), cùng với các giá trị cụ thể là 1, 2 và 3 Như vậy, tổng cộng sẽ có 3 miền tương đương được xác định.

Ta có các ca kiểm thử được sinh ra gồm 7 testcase như sau:

Bảng 4.2 Các ca kiểm thử sinh ra theo kỹ thuật phân lớp tương đương

Dữ liệu đầu vào Ngày thực EO hiện

Hình thức thực hiện quyền

TC1 27/11/2014 Không là hình thức nào

Không có giá trị trả ra do không thuộc hình thức nào TC2 27/11/2014 Trả cổ tức bằng tiền mặt 25/11/2014

TC3 27/11/2014 Niêm yết bổ sung 26/11/2014

TC4 27/11/2014 Thay đổi tỷ lệ FreeFloat 27/11/2014 TC5 24/11/2014 Trả cổ tức bằng tiền mặt 21/11/2014 TC6 25/11/2014 Trả cổ tức bằng tiền mặt 21/11/2014

4.1.2 Áp dụng kỹ thuật Bảng quyết định

Ta sẽ xây dựng ca kiểm thử dựa trên các mô tả về yêu cầu như sau:

Mô tả 1:(C1) Nếu hình thức thực hiện quyền trả cổ tức bằng tiền thì (E1) ngày thực hiện là ngày đăng ký cuối cùng -2

Mô tả 2: (C2) Nếu hình thức thực hiện quyền niêm yết bổ sung thì (E2) ngày thực hiện là ngày đăng ký cuối cùng -1

Mô tả 3: (C3) Nếu hình thức thực hiện quyền thay đổi tỷ lệ free float thì (E3) ngày thực hiện là ngày đăng ký cuối cùng

Nếu ngày thực hiện quyền trùng với ngày nghỉ lễ, thì ngày thực hiện sẽ được lùi lại 1 ngày cho đến khi không còn rơi vào ngày nghỉ lễ.

Từ bốn mô tả trên ta sẽ có bảng quyết định như sau:

Bảng 4.3 Bảng quyết định cho bài toán 1

Bảng quyết định cho thấy các điều kiện C1, C2, C3 chỉ có thể nhận giá trị Y hoặc N duy nhất Theo mô tả bài toán, với mỗi cặp giá trị đầu vào, chỉ có một trong các điều kiện C1, C2, hoặc C3 có thể là true, không thể xảy ra đồng thời Mặc dù bảng quyết định tạo ra 16 trường hợp, sau khi loại trừ các trường hợp không khả thi, chỉ còn lại 6 trường hợp cần kiểm thử Đặc biệt, khi ngày thực hiện trùng với ngày đăng ký cuối cùng, không có trường hợp nào thỏa mãn cả điều kiện Thay đổi tỷ lệ FreeFloat và ngày đăng ký cuối cùng là ngày nghỉ lễ Do đó, trong số 16 trường hợp, chỉ có 5 trường hợp là thực thi được.

Từ bảng quyết định trên, ta có số testcase được sinh ra gồm:

Bảng 4.4 Các ca kiểm thử sinh ra theo kỹ thuật bảng quyết định Testcase

TC1 24/11/2014 Trả cổ tức bằng tiền mặt 21/11/2014 TC2 27/11/2014 Trả cổ tức bằng tiền mặt 25/11/2014

TC5 27/11/2014 Thay đổi tỷ lệ FreeFloat 27/11/2014

4.1.3 Áp dụng kỹ thuật kiểm thử dòng điều khiển Áp dụng kỹ thuật kiểm thử dòng điều khiển ta sẽ phân tích bài toán theo mã nguồn và theo tiêu chí phủ rẽ nhánh để kiểm thử dựa vào độ đo kiểm thử cấp 2 tức là tất cả các điểm quyết định của đồ thị đều được thực hiện ít nhất 1 lần Bên cạnh đó, ta còn thấy xuất hiện vòng lặp trong mã nguồn, nên việc tiến hành xây dựng kiểm thử dựa trên độ đo là chưa đủ mà ta cần phải xây dựng ca kiểm thử liên quan đến vòng lặp của chương trình Ở mã nguồn 1, nhận thấy việc xác định vòng lặp tối đa là khó nên ta sẽ chỉ áp dụng sinh kiểm thử cho vòng lặp với bốn trường hợp đầu tiên (theo mục 3.2.1, tr34)

Mã nguồn của bài toán:

Mã nguồn 1: public datetime dtActionDate (datetime dtLastDateMoneyDiv, int c_intCorporateType)

Int32 _paramActionDate = -1;//Ngay TH if(c_intCorporateType==(Int32)Common.CorporateActionType.Money Dividend)

{ //tra co tuc = tien ngay thuc hien = ngay DKCC-2

_dtTemp=_dtLastDateMoneyDiv.SelectedDate.Value.Date; _dtTemp = _dtTemp.AddDay(_paramActionDate);//

} //truong hop niem yet bo sung = ngay DKCC-1 elseif(c_intCorporateType==(Int32)Common.CorporateActionType.A ddListing)

{ _dtTemp = dtNYDate.SelectedDate.Value.Date;

} //truong hop ChangeFreeFloat elseif(c_intCorporateType==(Int32)Common.CorporateActionType.C hangeFreeFloat)

{ _dtTemp =dtLastDateChangeFF.SelectedDate.Value.Date;

Mã nguồn 2: public datetime dtActionDate (datetime dtLastDateMoneyDiv, int c_intCorporateType)

Int32 _paramActionDate = -1;//Ngay TH if(c_intCorporateType==(Int32)Common.CorporateActionType.Money Dividend)

{ //tra co tuc = tien ngay thuc hien = ngay DKCC-2

_dtTemp=_dtLastDateMoneyDiv.SelectedDate.Value.Date; _dtTemp = _dtTemp.AddDay(_paramActionDate);

} //truong hop niem yet bo sung elseif(c_intCorporateType==(Int32)Common.CorporateActionType.A ddListing)

{ _dtTemp = dtNYDate.SelectedDate.Value.Date;

} //truong hop ChangeFreeFloat elseif(c_intCorporateType==(Int32)Common.CorporateActionType.C hangeFreeFloat)

{ _dtTemp =dtLastDateChangeFF.SelectedDate.Value.Date;

Bảng 4.5 Quy ƣớc các điều kiện, hành động trong sơ đồ CFG của bài toán 1

STT Điều kiện Quy ƣớc

1 c_intCorporateType ==(Int32)Common.CorporateActionType.MoneyDividend C1

2 c_intCorporateType ==(Int32)Common.CorporateActionType AddListing C2

5 _dtTemp = dtLastDateMoneyDiv.SelectedDate.Value.Date;

_dtTemp = _dtTemp.AddDay(_paramActionDate);//-2 _dtTemp = _dtTemp.AddDay(_paramActionDate);//-1

6 _dtTemp = dtNYDate.SelectedDate.Value.Date;

7 _dtTemp = dtLastDateChangeFF.SelectedDate.Value.Date; A7

8 _dtTemp = _dtTemp.AddDay(-1); A8 Áp dụng kỹ thuật dòng điều khiển ta có sơ đồ CFG như sau:

Hình 4.1Sơ đồ dòng điều khiền cho bài toán 1 – mã nguồn 1

Để đảm bảo tất cả các câu lệnh và điều kiện T-F được thực hiện ít nhất một lần, chúng ta cần xây dựng các đường đi khác nhau Đường đi 1 là 1-2-3(T)-4-9(T)-10-11, trong khi Đường đi 2 là 1-2-3(T)-4-9(F)-11 Đường đi 3 có dạng 1-2-3(F)-5(T)-6-9(T)-10-9(F)-11, và Đường đi 4 là 1-2-3(F)-5(T)-6-9(F)-11 Đường đi 5 được xác định bởi 1-2-3(F)-5(F)-7(T)-8-9(F)-11, trong khi Đường đi 6 là 1-2-3(F)-5(F)-7(T)-8-9(T)-10-9(F)-11 Đường đi 7 là 1-2-3(F)-5(F)-7(F)-9(T)-10-9(F)-11, và cuối cùng, Đường đi 8 là 1-2-3(F)-5(F)-7(F)-9(F)-11.

Do đó ta có 8 đường đi từ sơ đồ CF

Trong hàm trên có xuất hiện vòng lặp while do đó cần sinh ra ca kiểm thử cho vòng lặp với trường hợp như sau:

Vòng lặp không thực hiện lần nào Nhận thấy đường đi thứ 2 thỏa mãn điều kiền này

Vòng lặp thực hiện 1 lần ứng với đường đi thứ 1

Vòng lặp thực hiện 2 lần Đường đi 9: 1-2-3(T)-4-9(T)-10-9(T)-10-9(F)-11 Vòng lặp thực hiện k lần (ta chọn k =5) Đường đi 10:

Do đó số đường đi cần thiết là 10

Ta có tescace được sinh ra từ đường đi như sau:

Bảng 4.6 Các ca kiểm thử sinh ra theo kỹ thuật dòng điều khiển với mã nguồn 1 Testcase Đường đi

Vào ngày 21/11/2014, TC1 đã thực hiện trả cổ tức bằng tiền mặt, với thời gian đi là 24/11/2014 Tiếp theo, TC2 cũng trả cổ tức bằng tiền mặt vào ngày 25/11/2014, và thời gian đi là 27/11/2014 Về niêm yết bổ sung, TC3 đã thực hiện vào ngày 01/09/2014, với thời gian đi là 03/09/2014 TC4 thực hiện niêm yết bổ sung vào ngày 26/11/2014, với thời gian đi là 27/11/2014 Cuối cùng, TC5 thông báo thay đổi tỷ lệ FreeFloat vào ngày 27/11/2014.

Ngày thực hiện không thể thực thi do trùng với ngày đăng ký cuối cùng, trong khi ngày thực hiện luôn phải là ngày làm việc, không bao gồm ngày nghỉ hay lễ tết Do đó, ngày đăng ký cuối cùng cũng phải là một ngày làm việc.

Nếu ngày thực hiện không thuộc một hình thức nào, ngày đăng ký cuối cùng sẽ nhận giá trị mặc định là 01/01/1900, tức là ngày thứ hai Do đó, điều này không thể đáp ứng điều kiện là ngày nghỉ lễ.

27/11/2014 Không thuộc hình thức nào

“Không thuộc hình thức thực hiện quyền nào”

TC7 Đường đi 9 25/11/2014 Trả cổ tức bằng tiền mặt 21/11/2014

Trả cổ tức bằng tiền mặt 16/02/2015

Hình 4.2 Sơ đồ dòng điều khiền cho bài toán 1 – mã nguồn 2

Để đảm bảo mọi câu lệnh và điều kiện T-F đều được thực hiện ít nhất một lần, chúng ta sẽ xây dựng các đường đi dựa trên lược đồ (Hình 3.9) Các đường đi bao gồm: Đường đi 1: 1-2-3(T)-4-9(T)-10-11; Đường đi 2: 1-2-3(T)-4-9(F)-11; Đường đi 3: 1-2-3(F)-5(T)-6-9(T)-10-11; Đường đi 4: 1-2-3(F)-5(T)-6-9(F)-11; Đường đi 5: 1-2-3(F)-5(F)-7(T)-8-9(F)-11; Đường đi 6: 1-2-3(F)-5(F)-7(T)-8-9(T)-10-11; Đường đi 7: 1-2-3(F)-5(F)-7(F)-9(T)-10-11; và Đường đi 8: 1-2-3(F)-5(F)-7(F)-9(F)-11.

Do đó ta có 8 đường đi từ sơ đồ CF

Ta có tescace được sinh ra từ đường đi như sau:

Bảng 4.7 Các ca kiểm thử sinh ra theo kỹ thuật dòng điều khiển với mã nguồn 2 Testcase Đường đi

Vào ngày 21/11/2014, TC1 đã thực hiện trả cổ tức bằng tiền mặt, tiếp theo là TC2 vào ngày 25/11/2014 cũng với hình thức trả cổ tức bằng tiền mặt TC3 đã niêm yết bổ sung vào ngày 01/09/2014, trong khi TC4 thực hiện niêm yết bổ sung vào ngày 26/11/2014 Cuối cùng, vào ngày 27/11/2014, TC5 đã thông báo thay đổi tỷ lệ FreeFloat.

Ngày thực hiện không thể được thực thi vì trùng với ngày đăng ký cuối cùng, trong khi ngày thực hiện luôn phải là ngày làm việc, không bao gồm ngày nghỉ và lễ tết Do đó, ngày đăng ký cuối cùng cũng sẽ rơi vào một ngày làm việc.

Bài toán 2

Phát biểu bài toán: Xác định tỷ lệ FreeFloat của chí số theo Bảng áp dụng dải tỷ lệ tính chỉ số

Mô tả bài toán: Hệ số Free float của chỉ số sẽ được xác định như sau:

Nếu tỷ lệ thực của chỉ số có giá trị =5 và 15 và 20 và 30 và 40 và 50 và 75 và 100% đều không thỏa mãn điều kiện tính chỉ số

Miền 2 là các dữ liệu đầu vào là tỷ số thực của chỉ số nằm trong khoảng từ 5 đến

15 Với miền này, ta sẽ có 2 giá trị biên là 5 và 15

20 Với miền này, ta sẽ có 1 giá trị biên là 20

Do đó ta sẽ có 8 miền tương đương và 8 giá trị tại biên với kỹ thuật phân lớp tương đương

Bảng 4.15 Các ca kiểm thử sinh ra theo kỹ thuật phân lớp tương đương

Test case Dữ liệu đầu vào (Tỷ lệ thực) EO

TC1 1% Không đủ điều kiện đưa vào chỉ số

TC17 190% Không đủ điều kiện đưa vào chỉ số

4.2.2 Áp dụng kỹ thuật bảng quyết định

Ta sẽ xây dựng ca kiểm thử dựa trên các mô tả về yêu cầu như sau:

Nếu tỷ lệ thực của chỉ số có giá trị < 5 thì kết quả là không đủ điều kiện đưa vào các chỉ số HNX

Nếu tỷ lệ thực của chỉ số có giá trị >= 5 và 15 và 20 và 30 và 40 và 50 và 75 và 5 && rate 5 && rate < 15) {

Bảng 4.17 Quy ƣớc các điều kiện, hành động trong sơ đồ CFG của bài toán 2 – mã nguồn 1

STT Điều kiện/ Hành động Quy ƣớc Hành động Quy ƣớc

2 rate >= 5 && rate 15 && rate 20 && rate 30 && rate 40 && rate 50 && rate 5 && rate 15 && rate < 20 C3 _FREE_FLOAT_RATE = 20 ; A 3

4 rate > 20 && rate < 30 C4 _ FREE_FLOAT_RATE= 30 ; A 4

5 rate > 30 && rate 40 && rate 50 && rate 75 && rate 10

Từ mô tả bài toán ta xác định dữ liệu nhƣ sau:

Dữ liệu đầu vào là: Mảng chỉ số có 10 chỉ số

Dữ liệu đầu ra là: Tổng Marketcap của 10 chỉ số tính theo phương pháp chặt 10

Từ phân tích bài toán theo đặc tả yêu cầu ta áp dụng các kỹ thuật kiểm thử để xây dựng ca kiểm thử như sau:

4.3.1 Áp dụng kỹ thuật Domain testing

Chúng ta có một mảng chỉ số gồm 10 phần tử, mỗi phần tử tương ứng với các giá trị thuộc hai miền tương đương.

 Miền thứ nhất: chỉ số có giá trị tỷ trọng weight >10

 Miền thứ hai: chỉ số có giá trị tỷ trọng weight < 10

Có hai miền tương đương và một giá trị biên là 10 cho mỗi phần tử trong mảng chỉ số Số trường hợp sinh ra tương ứng là 3 mũ 10, dẫn đến số lượng test case tối đa không xác định do sự lớn lao của các trường hợp này.

4.3.2 Áp dụng kỹ thuật Bảng quyết định

Ta có mảng dữ liệu đầu vào là 10 chỉ số, do đó với mỗi phần tử của mảng sẽ xảy ra giả thiết như sau:

Nếu tỷ trọng weght của chỉ số nhỏ hơn hoặc bằng 10, ta sẽ cộng giá trị marketcap của chỉ số vào tổng giá trị marketcap của mảng chỉ số

Mỗi phần tử trong bảng có hai khả năng, đó là nhận giá trị True hoặc False Do đó, với một mảng gồm 10 phần tử, sẽ có tổng cộng 10 trường hợp có thể xảy ra.

Ta sẽ có 10 test case như sau:

Test case 1 (TC1): Mảng chỉ số gồm 10 chỉ số, trong đó phần tử đầu tiên có tỷ trọng nhỏ hơn 10%

Dữ liệu đầu vào EO

STT Chỉ số MarketCap Tỷ trọng Tổng giá trị

Test case 2 (TC2): Mảng chỉ số gồm 10 chỉ số, trong đó phần tử thứ 2 có tỷ trọng nhỏ hơn 10%

4.3.3 Áp dụng kỹ thuật dòng điều khiển Áp dụng kỹ thuật kiểm thử dòng điều khiển ta sẽ phân tích bài toán theo mã nguồn và theo tiêu chí phủ rẽ nhánh dựa vào độ đo kiểm thử cấp 3 tức là tất cả các điểm quyết định của đồ thị đều được thực hiện ít nhất 1 lần và các điều kiện con đều được thực hiện tại hai nhánh true và false Bên cạnh đó, ta còn thấy xuất hiện vòng lặp trong mã nguồn, nên việc tiến hành xây dựng kiểm thử dựa trên độ đo là chưa đủ mà ta cần phải xây dựng ca kiểm thử liên quan đến vòng lặp của chương trình (theo mục 3.2.1, tr34)

Mã nguồn 1: private decimal getTotalbyMaxPercent(ArrayList arCell) { try { Cons int maxPercent; decimal _total_MC= 0; decimal _dem = 0; int i =0;

//Tinh tong cac chi so co ty trong

Tiêu đề	Kiểm Thử Đơn Vị Cho Hệ Thống
Tác giả	Luyện Thị Lan Hương
Người hướng dẫn	TS. Trần Thị Minh Châu
Trường học	Đại Học Quốc Gia Hà Nội
Chuyên ngành	Công Nghệ Thông Tin
Thể loại	luận văn
Năm xuất bản	2014
Thành phố	Hà Nội

Định dạng
Số trang	85
Dung lượng	1,78 MB