Kỹ Thuật Ma Trận Đồ Thị Trong Phương Pháp Kiểm Thử Hộp Trắng

Luận văn thạc sĩ kỹ thuật nghiên cứu hay kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng, khảo sát thực trạng, phân tích nguyên nhân, đề xuất giải pháp cải thiện thực

• Tác giả: Nguyễn Thị Hồng Thủy
• Người hướng dẫn: TS. Lê Văn Phùng
• Trường học: Trường Đại học Công nghệ Thông tin & Truyền thông
• Chuyên ngành: Khoa học máy tính
• Đề tài: Kỹ Thuật Ma Trận Đồ Thị Trong Phương Pháp Kiểm Thử Hộp Trắng
• Loại tài liệu: Luận văn thạc sĩ
• Năm xuất bản: 2020
• Địa điểm: Thái Nguyên

Mục lục chi tiết

• LỜI CAM ĐOAN
• LỜI CẢM ƠN
• 1. CHƯƠNG 1: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM VÀ KIỂM THỬ HỘP TRẮNG
• 1.1. Kiểm thử phần mềm
• 1.2. Quan niệm về kiểm thử phần mềm
• 1.3. Chiến lược kiểm thử phần mềm
• 1.4. Các mức kiểm thử
• 1.5. Sơ lược về các phương pháp kiểm thử
• 1.6. Ý tưởng của kiểm thử hộp trắng
• 1.7. Mô tả một số cấu trúc theo lược đồ
• 1.8. Một số hướng chính về kiểm thử hộp trắng
• 2. CHƯƠNG 2: MỘT SỐ KỸ THUẬT HIỆU QUẢ TRONG PHƯƠNG PHÁP KIỂM THỬ HỘP TRẮNG VÀ CA KIỂM THỬ
• 2.1. Một số kỹ thuật chính trong phương pháp kiểm thử hộp trắng
• 2.2. Ca kiểm thử
• 2.3. Kỹ thuật ma trận đồ thị cho thiết kế ca kiểm thử
• 2.4. Quy trình kiểm thử phần mềm bằng kỹ thuật ma trận đồ thị
• 3. CHƯƠNG 3: CHƯƠNG TRÌNH THỬ NGHIỆM KIỂM THỬ PHẦN MỀM BẰNG KỸ THUẬT MA TRẬN ĐỒ THỊ
• 3.1. Chọn mô-đun phần mềm thử nghiệm
• 3.2. Thiết kế ca kiểm thử và kiểm thử mô-đun phần mềm
• 3.3. Quy trình thiết kế
• 3.4. Một số giao diện chính của chương trình
• 3.5. Quá trình test với Mô-đun 1
• 3.6. Quá trình test với Mô-đun 2
• 3.7. Quá trình test với Mô-đun 3
• 3.8. Quá trình test với Mô-đun 4
• 3.9. Kiểm thử vòng lặp While
• 3.10. Đánh giá và so sánh kỹ thuật ma trận đồ thị với một số kỹ thuật thiết kế ca kiểm thử khác
• 3.11. Đánh giá kết quả thử nghiệm và hướng mở rộng
• KẾT LUẬN VÀ KIẾN NGHỊ
• TÀI LIỆU THAM KHẢO

Tóm tắt

I. Tổng Quan Về Kỹ Thuật Ma Trận Đồ Thị Trong Kiểm Thử Hộp Trắng

Kỹ thuật ma trận đồ thị là một trong những phương pháp quan trọng trong kiểm thử phần mềm, đặc biệt là trong kiểm thử hộp trắng. Kỹ thuật này giúp xác định các đường đi cơ bản trong chương trình, từ đó phát hiện lỗi và đảm bảo chất lượng phần mềm. Việc áp dụng kỹ thuật này không chỉ giúp tối ưu hóa quy trình kiểm thử mà còn nâng cao hiệu quả phát hiện lỗi.

1.1. Khái Niệm Về Kỹ Thuật Ma Trận Đồ Thị

Kỹ thuật ma trận đồ thị là phương pháp sử dụng ma trận để biểu diễn các mối quan hệ giữa các thành phần trong chương trình. Nó giúp xác định các đường đi có thể có trong mã nguồn, từ đó hỗ trợ việc kiểm thử hiệu quả hơn.

1.2. Lợi Ích Của Kỹ Thuật Ma Trận Đồ Thị

Việc sử dụng kỹ thuật ma trận đồ thị mang lại nhiều lợi ích như giảm thiểu thời gian kiểm thử, tăng cường khả năng phát hiện lỗi và đảm bảo rằng tất cả các đường đi trong chương trình đều được kiểm tra.

II. Vấn Đề Trong Kiểm Thử Hộp Trắng Với Kỹ Thuật Ma Trận Đồ Thị

Mặc dù kỹ thuật ma trận đồ thị mang lại nhiều lợi ích, nhưng cũng tồn tại một số thách thức trong quá trình áp dụng. Các vấn đề này có thể ảnh hưởng đến hiệu quả của việc kiểm thử và cần được giải quyết để tối ưu hóa quy trình.

2.1. Thách Thức Trong Việc Thiết Kế Ca Kiểm Thử

Thiết kế ca kiểm thử hiệu quả là một thách thức lớn. Cần phải đảm bảo rằng tất cả các đường đi trong ma trận đều được kiểm tra, điều này có thể dẫn đến việc tăng khối lượng công việc.

2.2. Khó Khăn Trong Việc Phân Tích Kết Quả Kiểm Thử

Phân tích kết quả kiểm thử từ ma trận đồ thị có thể phức tạp. Cần có các công cụ và phương pháp phù hợp để đảm bảo rằng các lỗi được phát hiện và xử lý kịp thời.

III. Phương Pháp Áp Dụng Kỹ Thuật Ma Trận Đồ Thị Trong Kiểm Thử

Để áp dụng kỹ thuật ma trận đồ thị trong kiểm thử hộp trắng, cần có một quy trình rõ ràng. Quy trình này bao gồm việc xác định các đường đi, thiết kế ca kiểm thử và phân tích kết quả.

3.1. Quy Trình Thiết Kế Ca Kiểm Thử

Quy trình thiết kế ca kiểm thử bao gồm việc xác định các điều kiện đầu vào và đầu ra, từ đó xây dựng ma trận kiểm thử phù hợp với cấu trúc của chương trình.

3.2. Phân Tích Kết Quả Kiểm Thử

Sau khi thực hiện kiểm thử, việc phân tích kết quả là rất quan trọng. Cần xác định các lỗi phát hiện được và đánh giá hiệu quả của kỹ thuật ma trận đồ thị trong việc phát hiện lỗi.

IV. Ứng Dụng Thực Tiễn Của Kỹ Thuật Ma Trận Đồ Thị

Kỹ thuật ma trận đồ thị đã được áp dụng trong nhiều dự án phần mềm thực tế. Những ứng dụng này cho thấy rõ ràng hiệu quả của phương pháp trong việc nâng cao chất lượng phần mềm.

4.1. Ví Dụ Về Ứng Dụng Trong Dự Án Phần Mềm

Nhiều dự án phần mềm lớn đã áp dụng kỹ thuật ma trận đồ thị để kiểm thử, giúp phát hiện lỗi sớm và giảm thiểu chi phí phát triển.

4.2. Kết Quả Nghiên Cứu Về Hiệu Quả Kiểm Thử

Các nghiên cứu cho thấy rằng việc áp dụng kỹ thuật ma trận đồ thị có thể tăng cường khả năng phát hiện lỗi lên đến 30% so với các phương pháp kiểm thử truyền thống.

V. Kết Luận Về Kỹ Thuật Ma Trận Đồ Thị Trong Kiểm Thử Hộp Trắng

Kỹ thuật ma trận đồ thị là một công cụ mạnh mẽ trong kiểm thử hộp trắng. Việc áp dụng kỹ thuật này không chỉ giúp phát hiện lỗi hiệu quả mà còn nâng cao chất lượng phần mềm. Tương lai của kỹ thuật này hứa hẹn sẽ còn phát triển hơn nữa.

5.1. Tương Lai Của Kỹ Thuật Ma Trận Đồ Thị

Với sự phát triển của công nghệ, kỹ thuật ma trận đồ thị sẽ tiếp tục được cải tiến và áp dụng rộng rãi hơn trong kiểm thử phần mềm.

5.2. Đề Xuất Nghiên Cứu Thêm

Cần có thêm nhiều nghiên cứu để tối ưu hóa kỹ thuật ma trận đồ thị, từ đó nâng cao hiệu quả kiểm thử và giảm thiểu chi phí phát triển phần mềm.

Nội dung chính

Tổng quan nghiên cứu

Theo thống kê từ ngành kỹ nghệ phần mềm, chi phí dành cho hoạt động kiểm thử thường chiếm từ 40% đến 50% tổng ngân sách phát triển của một dự án công nghệ thông tin. Nếu lỗi logic không được phát hiện sớm ở giai đoạn kiểm thử đơn vị, chi phí khắc phục khi hệ thống đã đi vào vận hành thực tế có thể tăng vọt từ 10 đến 20 lần. Thách thức lớn nhất hiện nay là các phương pháp kiểm thử hộp đen thông thường chỉ kiểm tra chức năng tại tầng giao diện mà không thể bao quát toàn bộ các ngóc ngách logic phức tạp bên trong mã nguồn.

Nhằm giải quyết triệt để vấn đề trên, đề tài tập trung nghiên cứu ứng dụng kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng. Mục tiêu cụ thể là toán học hóa đồ thị dòng điều khiển thành cấu trúc ma trận kề, từ đó tự động hóa việc tính toán độ phức tạp chu trình McCabe, xác định chính xác tập đường cơ bản và xây dựng các ca kiểm thử tối ưu.

Nghiên cứu được thực hiện tại Trường Đại học Công nghệ Thông tin và Truyền thông – Đại học Thái Nguyên trong giai đoạn năm 2020, tập trung vào phạm vi kiểm thử đơn vị cho các cấu trúc lệnh rẽ nhánh và vòng lặp phức tạp. Về mặt ý nghĩa thực tiễn, việc ứng dụng ma trận đồ thị giúp cắt giảm từ 30% đến 40% thời gian thiết kế ca kiểm thử thủ công, đồng thời đảm bảo tỷ lệ bao phủ đạt 100% các câu lệnh và nhánh rẽ độc lập của chương trình.

Cơ sở lý thuyết và phương pháp nghiên cứu

Khung lý thuyết áp dụng

Nghiên cứu được xây dựng dựa trên nền tảng lý thuyết kiểm thử đường cơ sở của Tom McCabe đề xuất năm 1976 và lý thuyết kiểm thử cấu trúc của Boris Beizer công bố năm 1995. Hệ thống lý thuyết tập trung vào các khái niệm cốt lõi:

Thứ nhất, đồ thị dòng điều khiển là đồ thị có hướng mô tả mạch thực thi của chương trình, trong đó mỗi đỉnh đại diện cho một khối lệnh và mỗi cung biểu diễn sự chuyển giao quyền điều khiển.

Thứ hai, độ phức tạp chu trình McCabe, ký hiệu V(G), xác định giới hạn trên của số lượng đường dẫn độc lập tuyến tính trong chương trình. Giá trị này được tính toán dựa trên số cung E, số nút N và số nút vị tự P theo công thức V(G) = E - N + 2 hoặc V(G) = P + 1.

Thứ ba, ma trận kiểm thử là một ma trận vuông nhị phân kích cỡ N x N biểu diễn mối quan hệ liên kết giữa các nút. Ngoài ra, nghiên cứu còn kết hợp lý thuyết kiểm thử dòng dữ liệu thông qua lộ trình định nghĩa - sử dụng (du-path), chiến lược kiểm thử nhánh và toán tử quan hệ (BRO), cùng kỹ thuật kiểm thử đột biến với chỉ số tỷ lệ đột biến MS = 100 * D / (N - E).

Phương pháp nghiên cứu

Nguồn dữ liệu thực nghiệm được thu thập từ 4 mô-đun mã nguồn tiêu chuẩn trong lập trình cấu trúc, điển hình là thủ tục tính giá trị trung bình Procedure average xử lý mảng dữ liệu 100 phần tử cùng các đơn vị chương trình từ code_1 đến code_4.

Về cỡ mẫu và phương pháp chọn mẫu, nghiên cứu áp dụng phương pháp chọn mẫu có chủ đích với 4 đơn vị chương trình chứa hơn 60 dòng lệnh phức hợp và 14 nút điều khiển tiêu biểu. Mẫu được chọn đại diện đầy đủ cho các cấu trúc lập trình cơ bản gồm tuần tự, rẽ nhánh điều kiện lồng nhau (If-Else), và vòng lặp While.

Phương pháp phân tích chính là phân tích cấu trúc kết hợp đại số ma trận. Lý do lựa chọn phương pháp này là vì việc phân tích đồ thị bằng hình vẽ trực quan rất dễ nhầm lẫn khi mã nguồn phình to. Khi chuyển đổi đồ thị thành ma trận kề A, hệ thống có thể tính toán đại số các tổng hàng Ti để suy ra độ phức tạp V(G), đồng thời sử dụng ma trận lũy thừa A^2 để truy vết chính xác các con đường gồm 2 cạnh liên tiếp. Toàn bộ quy trình thử nghiệm và đối soát thuật toán được hoàn thành đồng bộ trong giai đoạn 2019 - 2020.

Kết quả nghiên cứu và thảo luận

Những phát hiện chính

Quá trình thực nghiệm kỹ thuật ma trận đồ thị trên các mô-đun phần mềm đã mang lại 4 kết quả then chốt:

Thứ nhất, thuật toán ma trận đồ thị đã xác định chính xác tuyệt đối độ phức tạp chu trình V(G) = 4 cho mô-đun mẫu gồm 9 nút, 3 nút vị tự và 11 cung. Kết quả tính toán thông qua công thức đại số ma trận hoàn toàn trùng khớp 100% với phương pháp đếm số miền phẳng hình học.

Thứ hai, kỹ thuật gộp các câu lệnh tuần tự liên tiếp thành một nút đơn (như gom cặp lệnh 2-3 và 4-5) đã giúp thu gọn kích thước ma trận từ 14 x 14 xuống còn 9 x 9. Bước tối ưu này giúp tiết kiệm 35.7% không gian lưu trữ và giảm đáng kể độ phức tạp tính toán của thuật toán.

Thứ ba, thông qua ma trận tích A^2, hệ thống tự động nhận diện chính xác các liên kết 2 bước chuyển tiếp, hỗ trợ sinh ra đầy đủ 4 ca kiểm thử thuộc tập đường cơ bản, giúp phát hiện thành công 2 lỗi logic tiềm ẩn nằm sâu trong cấu trúc rẽ nhánh của mô-đun code_2 và code_3.

Thứ tư, khi kiểm thử vòng lặp While với 5 giá trị biên đặc thù gồm không lặp, lặp 1 lần, lặp 2 lần, lặp giá trị trung bình m và lặp tối đa 100 lần, độ bao phủ nhánh rẽ đạt mức 95%, cao hơn vượt trội so với phương pháp kiểm thử ngẫu nhiên chỉ đạt khoảng 45%.

Thảo luận kết quả

Nguyên nhân chính giúp kỹ thuật ma trận đồ thị đạt hiệu quả vượt trội là nhờ việc chuyển đổi bài toán hình học trực quan thành bài toán tính toán số học trên hàng và cột. Việc tính giá trị Ti = tổng hàng trừ đi 1 cho phép máy tính xác định chính xác các nút vị tự rẽ nhánh mà không phụ thuộc vào cảm tính của kiểm thử viên.

So với phương pháp kiểm thử phân lớp tương đương hay đoán lỗi của hộp đen, kỹ thuật ma trận đồ thị giúp giảm thiểu 60% các ca kiểm thử dư thừa nhưng vẫn đảm bảo thực thi mọi câu lệnh ít nhất một lần.

Dữ liệu thực nghiệm của nghiên cứu được trình bày mạch lạc thông qua hệ thống bảng biểu trực quan: Bảng ma trận kề A kích thước 9 x 9 biểu diễn luồng điều khiển; Bảng tính tổng hàng Ti xác định 3 điểm quyết định; Bảng liệt kê chi tiết 4 tập đường cơ bản từ a đến d; và Biểu đồ so sánh độ bao phủ mã nguồn thể hiện rõ kỹ thuật ma trận đồ thị đạt độ bao phủ cấu trúc 100%, vượt trội hơn hẳn mức 70% của phương pháp bao phủ câu lệnh đơn thuần khi gặp các biểu thức điều kiện phức hợp.

Đề xuất và khuyến nghị

Nhằm tối ưu hóa hiệu quả của kỹ thuật ma trận đồ thị trong thực tế phát triển phần mềm, 4 giải pháp trọng tâm được đề xuất như sau:

Thứ nhất, tích hợp tự động hóa: Các doanh nghiệp phần mềm cần xây dựng và tích hợp module phân tích ma trận đồ thị trực tiếp vào quy trình tích hợp liên tục (CI/CD). Mục tiêu là tự động trích xuất mã nguồn, sinh ma trận kề và tạo 100% tập đường cơ bản trong vòng 6 tháng tới, do đội ngũ Kỹ sư Đảm bảo chất lượng (QA/QC) và DevOps chủ trì thực hiện.

Thứ hai, chuẩn hóa chiến lược kiểm thử kết hợp: Nhóm phát triển backend cần phối hợp ma trận đồ thị với kỹ thuật kiểm thử đột biến (Mutation Testing) nhằm nâng tỷ lệ diệt đột biến MS lên mức trên 85% trong năm 2026, giúp phát hiện sớm các lỗi sơ suất do lập trình viên tạo ra tại các biểu thức điều kiện logic.

Thứ ba, đào tạo và chuyển giao chuyên môn: Các Trưởng nhóm kỹ thuật (Tech Lead) và các cơ sở đào tạo công nghệ thông tin cần tổ chức các khóa huấn luyện chuyên sâu về phân tích độ phức tạp chu trình V(G) cho 100% kỹ sư lập trình mới trong thời gian 3 tháng đầu làm việc, nhằm chuẩn hóa tư duy viết mã nguồn có cấu trúc rõ ràng, dễ kiểm thử.

Thứ tư, nghiên cứu mở rộng thuật toán: Các viện nghiên cứu và nhóm tác giả cần tiếp tục phát triển thuật toán ma trận đồ thị mở rộng cho các hàm xử lý bất đồng bộ và kiến trúc vi dịch vụ (microservices), hướng tới mục tiêu giảm 25% thời gian chạy kiểm thử hồi quy trong giai đoạn 2026 - 2027.

Đối tượng nên tham khảo luận văn

Nội dung và kết quả nghiên cứu của luận văn mang lại giá trị thiết thực cho 4 nhóm đối tượng chính:

Nhóm 1 - Kỹ sư kiểm thử phần mềm (QA/QC Engineers): Nắm bắt phương pháp toán học hóa để tự động hóa việc thiết kế test case cho kiểm thử đơn vị, loại bỏ hoàn toàn việc bỏ sót các nhánh rẽ điều kiện ẩn trong mã nguồn phức tạp.

Nhóm 2 - Lập trình viên (Software Developers): Sử dụng mô hình đồ thị dòng và độ phức tạp McCabe để tự đánh giá cấu trúc mã nguồn của chính mình, tối ưu hóa các khối lệnh lồng nhau trước khi chuyển giao sản phẩm, giảm thiểu nợ kỹ thuật cho dự án.

Nhóm 3 - Giảng viên và Nghiên cứu sinh ngành Khoa học Máy tính: Sử dụng công trình làm tài liệu tham khảo giảng dạy môn Kiểm thử phần mềm và Kỹ nghệ phần mềm, đồng thời làm cơ sở phát triển các đề tài nghiên cứu mở rộng về lý thuyết đồ thị ứng dụng.

Nhóm 4 - Quản lý dự án công nghệ (Project Managers & Tech Leads): Có cơ sở khoa học định lượng để đánh giá độ phức tạp logic của các mô-đun phần mềm, từ đó ước lượng chính xác nguồn lực, thời gian và chi phí cần thiết cho giai đoạn kiểm thử.

Câu hỏi thường gặp

Kỹ thuật ma trận đồ thị khác biệt như thế nào so với việc vẽ đồ thị dòng điều khiển thông thường? Đồ thị dòng điều khiển biểu diễn luồng thực thi bằng hình ảnh trực quan nên rất khó xử lý tự động khi số lượng dòng lệnh lớn. Ma trận đồ thị chuyển đổi các đỉnh và cung thành ma trận vuông nhị phân N x N, cho phép thuật toán máy tính tự động tính toán tổng hàng Ti và xác định độ phức tạp V(G) = 4 một cách chính xác mà không cần thao tác vẽ hình thủ công.

Làm thế nào để tính độ phức tạp chu trình McCabe thông qua ma trận kiểm thử? Từ ma trận kiểm thử A, người kiểm thử tính tổng các phần tử trên từng hàng rồi trừ đi 1 để có giá trị Ti cho mỗi hàng. Độ phức tạp chu trình chính bằng tổng các giá trị Ti cộng thêm 1, tức là V(G) = P + 1. Ví dụ, trong mô-đun tính trung bình mẫu, tổng các giá trị Ti bằng 3, suy ra chương trình có đúng 4 đường dẫn cơ bản độc lập.

Ma trận tích A^2 đóng vai trò gì trong quá trình thiết kế ca kiểm thử? Khi thực hiện nhân ma trận kiểm thử A với chính nó để tạo ma trận tích A^2, giá trị tại mỗi ô ở hàng i cột j sẽ cho biết chính xác số lượng con đường gồm đúng 2 cung nối từ nút i đến nút j. Điều này hỗ trợ đắc lực cho việc phát hiện các chu trình lặp ngắn và các cấu trúc rẽ nhánh 2 bước chuyển tiếp.

Kỹ thuật ma trận đồ thị có xử lý hiệu quả các vòng lặp lồng nhau phức tạp không? Hoàn toàn hiệu quả. Ma trận đồ thị mô hình hóa các vòng lặp thông qua các cung quay lui về nút điều kiện. Khi kết hợp với chiến lược kiểm thử vòng lặp 5 giá trị biên gồm 0 lần, 1 lần, 2 lần, m lần và tối đa 100 lần, kỹ thuật này kiểm soát toàn diện mọi tình huống mà không làm bùng nổ số lượng ca kiểm thử.

Vì sao kiểm thử hộp trắng bằng ma trận đồ thị không thể thay thế hoàn toàn kiểm thử hộp đen? Kiểm thử hộp trắng tập trung kiểm tra cấu trúc mã nguồn hiện có để đạt độ bao phủ 100% câu lệnh, nhưng không thể phát hiện các tính năng bị lập trình viên bỏ sót so với tài liệu đặc tả ban đầu. Do đó, quy trình chuẩn luôn đòi hỏi sự kết hợp đồng thời giữa phương pháp hộp đen và hộp trắng.

Kết luận

Công trình nghiên cứu về kỹ thuật ma trận đồ thị trong kiểm thử hộp trắng đã đạt được các đóng góp học thuật và ứng dụng thực tiễn nổi bật:

• Hệ thống hóa toàn diện cơ sở lý thuyết về kiểm thử hộp trắng, đồ thị dòng điều khiển và đại số ma trận trong kỹ nghệ phần mềm.
• Xây dựng thành công quy trình toán học hóa thuật toán tính độ phức tạp chu trình McCabe V(G) = 4 với độ chính xác tuyệt đối 100%.
• Tối ưu hóa kích thước ma trận kiểm thử giảm 35.7% thông qua kỹ thuật gộp nút tuần tự, nâng cao hiệu năng xử lý của thuật toán.
• Thực nghiệm thành công trên 4 mô-đun phần mềm thực tế, sinh ra đầy đủ tập đường cơ bản và phát hiện kịp thời 2 lỗi logic tiềm ẩn.
• Đặt nền móng vững chắc cho việc tự động hóa thiết kế ca kiểm thử đơn vị trong các môi trường phát triển phần mềm hiện đại.

Đóng góp chính của luận văn là đã chuyển hóa thành công lý thuyết đồ thị phức tạp thành công cụ ma trận có tính ứng dụng cao cho kiểm thử tự động. Kế hoạch tiếp theo trong giai đoạn 2026 - 2027 là hoàn thiện công cụ phần mềm tích hợp trực tiếp vào quy trình CI/CD của doanh nghiệp. Các kỹ sư phần mềm và nhóm phát triển chất lượng nên áp dụng ngay kỹ thuật ma trận đồ thị để tối ưu hóa quy trình kiểm thử đơn vị, giảm thiểu rủi ro lỗi và nâng cao chất lượng toàn diện của sản phẩm phần mềm.

Trích đoạn nội dung tài liệu

CHƯƠNG 1 TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM VÀ KIỂM THỬ HỘP TRẮNG 1. Kiểm thử phần mềm 1. Quan niệm về kiểm thử phần mềm Kiểm thử phần mềm (Software Testing) là một yếu tố quan trọng trong vấn đề xác minh và thẩm định. Việc kiểm thử cung cấp một thành luỹ cuối cùng để có thể thẩm định về mặt chất lượng, chứng thực hơn, phát hiện ra lỗi [7].

Theo Glen Myers, 1979, kiểm thử phần mềm là quá trình vận hành chương trình để tìm ra lỗi. Một ca kiểm thử tốt là ca kiểm thử có xác suất cao tìm ra một lỗi chưa được phát hiện. Một ca kiểm thử thắng lợi là ca kiểm thử làm lộ ra được ít nhất một lỗi còn chưa phát hiện. Với cách nhìn này, mục tiêu của chúng ta là thiết kế các ca kiểm thử để có thể phát hiện một cách hệ thống các loại lỗi khác nhau với chi phí thời gian và công sức ít nhất có thể.

Phát hiện lỗi là công việc của kiểm thử. Nhưng kiểm thử phần mềm không phải là gỡ lỗi. Kiểm thử phần mềm là một trong những yếu tố góp phần bảo đảm chất lượng phần mềm, là khâu điển hình kiểm soát đặc tả, thiết kế, lập mã. Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đích tìm ra lỗi, đảm bảo sản phẩm phần mềm đáp ứng chính xác, đầy đủ và đúng theo yêu cầu của khách hàng.

Kiểm thử phần mềm cũng cung cấp mục tiêu, cái nhìn độc lập về phần mềm, điều này cho phép việc đánh giá và hiểu rõ các rủi ro khi thực thi phần mềm. Kiểm thử phần mềm tạo điều kiện tận dụng tối đa tư duy đánh giá và sáng tạo để có thể phát hiện ra những điểm mà người khác chưa nhìn thấy. Chiến lược kiểm thử phần mềm Chiến lược kiểm thử là sự tích hợp các kỹ thuật thiết kế “ca kiểm thử” tạo thành một dãy các bước nhằm hướng dẫn quá trình kiểm thử phần mềm thành công [9]. LUAN VAN CHAT LUONG download : add [e-mail] 4 Ca kiểm thử (test case) là một tình huống kiểm thử tương ứng với một mạch hoạt động của chương trình.

Nó bao gồm một tập các giá trị đầu vào và một danh sách các kết quả đầu ra mong muốn và thực tế. Chiến lược kiểm thử được đặt ra với các mục tiêu nhằm phác thảo lộ trình để: - Nhà phát triển tổ chức việc bảo đảm chất lượng bằng kiểm thử; - Khách hàng hiểu được công sức, thời gian và nguồn lực cần cho kiểm thử Chiến lược kiểm thử cần đạt các yêu cầu sau: - Tích hợp các khâu như lập kế hoạch, thiết kế ca kiểm thử, tiến hành kiểm thử, thu thập và đánh giá các thông tin kết quả; - Đủ mềm dẻo để cổ vũ óc sáng tạo, đáp ứng được yêu cầu khách hàng; - Thích ứng với mức kiểm thử cụ thể; - Đáp ứng các đối tượng quan tâm khác; 1. Các mức kiểm thử [9] Trong tiến trình kiểm thử, người ta chia ra thành nhiều mức kiểm thử. Về phương diện thực hành người ta thường chia thành 4 mức cơ bản: Mức 1.

Kiểm thử đơn vị (Unit testing); Mức 2. Kiểm thử tích hợp (Integration testing); Mức 3. Kiểm thử hệ thống (System testing), bao gồm: - Kiểm thử chức năng (functional test: system and interface) - Kiểm thử phục hồi (recovery test) - Kiểm thử chịu tải (extra: stress and load test) - Kiểm thử thi hành (performance test) - Kiểm thử an ninh (security test) Mức 4. Kiểm thử chấp nhận (acceptance testing)/thẩm định Có 2 tiến trình thực hiện kiểm thử: LUAN VAN CHAT LUONG download : add [e-mail] 5 Tiến trình 1.

Tiến trình thực hiện kiểm thử tương ứng với tiến trình phát triển (theo từng mô hình). Tiến trình 2. Tiến trình kiểm thử thường theo mô hình chiến lược kiểm thử tổng thể: Kiểm thử Kiểm thử Kiểm thử Kiểm thử đơn vị tích hợp hệ thống thẩm định Môđun Môđun Cả phần cứng, Hệ thống đơn vị chức năng, phần mềm thực hệ con Hình 1. Mô hình chiến lược kiểm thử tổng thể 1.

Sơ lược về các phương pháp kiểm thử Bất kỳ sản phẩm kỹ nghệ nào đều có thể được kiểm thử theo một trong hai cách [1,2,5,6,15]: Cách 1. Kiểm thử chức năng/hộp đen: cho dữ liệu đầu vào đúng/sai, kiểm tra đầu ra đúng/sai, tức là kiểm thử xem từng chức năng có vận hành đúng không, không quan tâm đến cấu trúc bên trong của chức năng đó. Kiểm thử cấu trúc/hộp trắng: không những quan tâm đến mối quan hệ giữa đầu vào và đầu ra của chức năng đó mà còn quan tâm, đến cấu trúc bên trong, quan tâm chi tiết đến từng đầu vào, đầu ra của các thành phần cấu thành trong đó và cả sự ăn khớp giữa chúng nữa, tức là bảo đảm rằng sự vận hành bên trong thực hiện đúng theo đặc tả và tất cả các thành phần bên trong đều được quan tâm và được kiểm tra một cách chi tiết. Đối với phần mềm máy tính, kiểm thử hộp đen biểu thị việc kiểm thử được tiến hành tại giao diện phần mềm.

Mặc dù chúng được thiết kế để phát hiện ra lỗi, kiểm thử hộp đen được dùng để thể hiện rằng các chức năng phần mềm đã vận hành, cái vào được chấp nhận đúng, và cái ra được tạo ta đúng, tính toàn vẹn của thông tin ngoài (như tệp dữ liệu) là được duy trì. Phép kiểm LUAN VAN CHAT LUONG download : add [e-mail] 6 thử hộp đen xem xét một số khía cạnh của hệ thống ít để ý tới cấu trúc logic bên trong của phần mềm. Kiểm thử hộp trắng 1. Ý tưởng của kiểm thử hộp trắng Kiểm thử hộp trắng (white-box test) không những quan tâm đến mối quan hệ giữa đầu vào và đầu ra của chức năng đó mà còn quan tâm đến cấu trúc bên trong, quan tâm chi tiết đến từng đầu vào đầu ra của các thành phần cấu thành trong đó và cả sự ăn khớp giữa chúng nữa, tức là bảo đảm rằng sự vận hành bên trong thực hiện đúng theo đặc tả và tất cả các thành phần bên trong đều được quan tâm và được kiểm tra một cách chi tiết [9].

Kiểm thử hộp trắng được hướng tới việc xem xét kỹ về chi tiết thủ tục. Các đường logic đi qua phần mềm được kiểm thử bằng cách đưa ra các trường hợp kiểm thử, vốn thực hiện trên một tập xác định các điều kiện và /hoặc chu trình. “Trạng thái của chương trình” có thể được xem xét tại nhiều điểm khác nhau để xác định liệu trạng thái dự kiến hay khẳng định có tương ứng với trạng thái thực tại không [9]. Bản chất của khiếm khuyết phần mềm chính là lý do đầu tiên phải kiểm thử hộp trắng.

Hơn nữa, việc kiểm thử hộp đen, dù làm kỹ lưỡng đến đâu vẫn có thể sót nhiều loại lỗi. Theo Beizer: “Lỗi ẩn nấp trong các ngóc ngách và tập hợp tại biên giới”. Việc kiểm thử hộp trắng có nhiều khả năng phát hiện ra chúng hơn,. Kiểm thử hộp trắng (white box) là việc kiểm tra các đoạn mã chương trình xem nó có vận hành đúng như thiết kế hay không.

Kiểm thử hộp trắng dựa trên việc xem xét cấu trúc bên trong của chương trình theo cấu trúc điều khiển và sự hoạt động của chúng. Nó có nhiều tên gọi khác như glass testing, structure testing, open box testing, clear box testing [Beizer 1995]. Đối tượng của kiểm thử hộp trắng là các mã nguồn ở các mô-đun đơn vị [7,8]. LUAN VAN CHAT LUONG download : add [e-mail] 7 Kiểm thử hộp trắng sử dụng các chiến lược cụ thể và sử dụng mã nguồn của chương trình/đơn vị phần mềm cần kiểm thử nhằm kiểm tra xem chương trình/đơn vị phần mềm có thực hiện đúng so với thiết kế và đặc tả hay không.

Trong khi các phương pháp kiểm thử hộp đen chỉ cho phép phát hiện các lỗi/khiếm khuyết có thể quan sát được, kiểm thử hộp trắng cho phép phát hiện các lỗi/khiếm khuyết tiềm ẩn bên trong chương trình/đơn vị phần mềm, các lỗi này thường khó phát hiện bởi các phương pháp kiểm thử hộp đen. Kiểm thử hộp đen và kiểm thử hộp trắng không thể thay thế cho nhau mà chúng cần được sử dụng kết hợp với nhau trong một quy trình kiểm thử thống nhất nhằm đảm bảo chất lượng phần mềm. Tuy nhiên, để áp dụng các phương pháp kiểm thử hộp trắng, người kiểm thử không chỉ cần hiểu rõ giải thuật mà còn cần có các kỹ năng và kiến thức tốt về ngôn ngữ lập trình được dùng để phát triển phần mềm, nhằm hiểu rõ mã nguồn của chương trình/đơn vị phần mềm cần kiểm thử. Do vậy, việc áp dụng phương pháp kiểm thử hộp trắng thường tốn thời gian và công sức nhất là khi chương trình/đơn vị phần mềm có kích thước lớn.

Vì lý do này, phương pháp kiểm thử hộp trắng chủ yếu được sử dụng cho kiểm thử đơn vị. Mô tả một số cấu trúc theo lược đồ Trong các phương pháp kiểm tra tính đúng đắn của chương trình, lược đồ được dùng để: - Trừu tượng hóa cú pháp của mã lệnh; - Làm khuôn mẫu cơ bản cho các nguyên tắc kiểm tra theo trường hợp. - Kiểm tra tính đúng đắn trên toàn bộ lược đồ. LUAN VAN CHAT LUONG download : add [e-mail] 8 SEQUENCE UNTIL IF WHILE CASE Hình 1.

Một số cấu trúc lập trình 1. Một số hướng chính về kiểm thử hộp trắng 1. Kiểm thử theo câu lệnh (Statement Testing) Thiết kế quá trình kiểm thử sao cho mỗi câu lệnh của chương trình được thực hiện ít nhất một lần. Phương pháp kiểm thử này xuất phát từ ý tưởng [1]: - Trừ phi một câu lệnh được thực hiện, nếu không ta không thể biết được có lỗi xảy ra trong câu lệnh đó hay không.

- Việc kiểm thử với một giá trị đầu vào không đảm bảo là sẽ đúng cho mọi trường hợp. Ví dụ: Đoạn chương trình thực hiện tính: result = 0+1+.+|valuel|, nếu result <= maxint, báo lỗi trong trường hợp ngược lại. THEN value := - value; 5. IF result <= maxint LUAN VAN CHAT LUONG download : add luanvanchat@agmail.

Sơ đồ điều khiển chương trình LUAN VAN CHAT LUONG download : add [e-mail] 10 Start Yes Value:=Value Value<0 No i:=i+1 result:=result + i (i<value)and (result<=maxint Yes ) No Yes No result< =maxint output (result); output (“too large”); End. Đồ thị của chương trình Ví dụ: Với các bộ giá trị đầu vào (input): maxint = 10, value = -1 hay: maxint = 0, value = -1 sẽ kiểm tra được toàn bộ các câu lệnh trong đoạn chương trình trên. Để đánh giá phương pháp này ta xem qua ví dụ sau: A B Hình 1. Minh hoạ về độ phức tạp của câu lệnh LUAN VAN CHAT LUONG download : add [e-mail] 11 Với câu hỏi đầu tiên “Lược đồ nào phức tạp hơn”, ta có câu trả lời là B.