Các Kỹ Thuật Kiểm Thử Dòng Dữ Liệu Tĩnh Trong Phát Triển Phần Mềm

Khám phá các kỹ thuật kiểm thử dòng dữ liệu tĩnh, giúp nâng cao chất lượng phần mềm và phát hiện lỗi hiệu quả trong quá trình phát triển.

• Tác giả: Nguyễn Thị Yên
• Người hướng dẫn: TS. Đặng Văn Hưng
• Trường học: Đại học Quốc gia Hà Nội
• Chuyên ngành: Công nghệ thông tin
• Đề tài: Các Kỹ Thuật Trong Kiểm Thử Dòng Dữ Liệu Tĩnh
• Loại tài liệu: luận văn thạc sĩ
• Năm xuất bản: 2016
• Địa điểm: Hà Nội

Tóm tắt

I. Tổng Quan Về Kỹ Thuật Kiểm Thử Dòng Dữ Liệu Tĩnh

Trong bối cảnh ngành công nghiệp phần mềm phát triển mạnh mẽ, việc đảm bảo chất lượng phần mềm trở nên vô cùng quan trọng. Kiểm thử phần mềm là một hoạt động không thể thiếu, tiêu tốn đến 50% thời gian và chi phí của dự án. Trong đó, kiểm thử dòng dữ liệu tĩnh đóng vai trò quan trọng. Luận văn này tập trung nghiên cứu về các kỹ thuật kiểm thử dòng dữ liệu tĩnh, từ đó đưa ra những giải pháp giúp nâng cao hiệu quả kiểm thử, giảm thiểu rủi ro và chi phí phát triển phần mềm. Mục tiêu là nghiên cứu tổng quan về kiểm thử phần mềm, các phương pháp kiểm thử, và ứng dụng Logic Hoare. Cấu trúc luận văn chia thành 3 chương chính, đi từ tổng quan đến ứng dụng cụ thể.

1.1. Định Nghĩa và Mục Tiêu của Kiểm Thử Dòng Dữ Liệu

Kiểm thử phần mềm là quy trình đảm bảo chất lượng, chứng minh phần mềm không có lỗi và phát hiện lỗi càng sớm càng tốt. Lỗi được hiểu là phần mềm không hoạt động đúng như đặc tả. Kiểm thử phần mềm hướng tới việc phát hiện càng nhiều lỗi càng tốt trong thời gian xác định, chứng minh sản phẩm phù hợp đặc tả, xác thực chất lượng kiểm thử với chi phí tối thiểu, và tạo các ca kiểm thử chất lượng cao. "Có hai mục đích chính của một phép thử: tìm thất bại hoặc chứng tỏ việc tiến hành của phần mềm là đúng đắn" (Nguyễn Thị Yên, 2016). Đây là nền tảng cho mọi hoạt động kiểm thử.

1.2. Vai Trò Quan Trọng Của Kiểm Thử Tĩnh Trong SDLC

Kiểm thử tĩnh đóng vai trò quan trọng trong việc đánh giá chất lượng phần mềm trong quá trình phát triển. Thông qua chu trình “kiểm thử - tìm lỗi - sửa lỗi”, chất lượng của sản phẩm phần mềm được cải thiện. Nhiều tác giả mô tả kiểm thử phần mềm là một quy trình kiểm chứng để đánh giá và tăng cường chất lượng của sản phẩm phần mềm. Quy trình này gồm hai công việc chính là phân tích tĩnh và phân tích động. Phân tích tĩnh và động là hai kỹ thuật bổ sung cho nhau.

II. Vấn Đề và Thách Thức Trong Kiểm Thử Dòng Dữ Liệu Tĩnh

Mặc dù kiểm thử dòng dữ liệu tĩnh mang lại nhiều lợi ích, nhưng cũng tồn tại không ít thách thức. Việc xác định và xử lý các vấn đề bất thường trong dòng dữ liệu (ví dụ: biến được định nghĩa nhưng không được sử dụng) đòi hỏi sự hiểu biết sâu sắc về mã nguồn và logic của chương trình. Bên cạnh đó, các công cụ hỗ trợ kiểm thử dòng dữ liệu tĩnh thường có giới hạn về khả năng phân tích và báo cáo, gây khó khăn cho việc đánh giá và sửa lỗi. Ngoài ra, việc tích hợp kiểm thử dòng dữ liệu tĩnh vào quy trình phát triển phần mềm hiện tại cũng là một thách thức không nhỏ.

2.1. Các Loại Lỗi Thường Gặp Trong Dòng Dữ Liệu Phần Mềm

Có nhiều loại lỗi có thể xảy ra trong dòng dữ liệu. Ví dụ: tính toán sai, hiệu chỉnh sai dữ liệu, trộn dữ liệu không đúng, tìm kiếm dữ liệu sai yêu cầu, xử lý sai mối quan hệ giữa các dữ liệu, coding/hiện thực sai các qui luật nghiệp vụ. Những lỗi này có thể dẫn đến kết quả không chính xác, hiệu suất kém, hoặc thậm chí là gây ra sự cố hệ thống. Việc phát hiện sớm và sửa chữa các lỗi này là rất quan trọng để đảm bảo chất lượng phần mềm.

2.2. Hạn Chế Của Các Công Cụ Phân Tích Dòng Dữ Liệu Tĩnh

Các công cụ phân tích dòng dữ liệu tĩnh có thể giúp tự động hóa quá trình kiểm thử, nhưng chúng không phải là hoàn hảo. Chúng có thể gặp khó khăn trong việc phân tích các đoạn mã phức tạp, hoặc bỏ sót các lỗi tinh vi. Ngoài ra, các công cụ này thường đưa ra nhiều cảnh báo sai (false positives), gây mất thời gian cho việc đánh giá và loại bỏ chúng.

III. Phương Pháp Kiểm Thử Dòng Dữ Liệu Tĩnh Hiệu Quả Nhất

Để khắc phục những hạn chế trên, cần áp dụng phương pháp kiểm thử dòng dữ liệu tĩnh một cách hiệu quả. Điều này bao gồm việc lựa chọn công cụ phù hợp, tùy chỉnh cấu hình phân tích, và kết hợp kiểm thử tự động với kiểm thử thủ công. Bên cạnh đó, cần chú trọng đến việc xây dựng các quy tắc kiểm thử rõ ràng và tuân thủ chúng một cách nghiêm ngặt. Các kỹ thuật kiểm thử tĩnh có thể được chia thành hai nhóm kỹ thuật: nhóm kỹ thuật kiểm thử kiểm tra (verification tests); nhóm kỹ thuật kiểm thử phân tích (analysis tests).

3.1. Lựa Chọn Công Cụ Phân Tích Phù Hợp Cho Dự Án

Việc lựa chọn công cụ phân tích dòng dữ liệu tĩnh phù hợp là rất quan trọng. Các yếu tố cần xem xét bao gồm: khả năng phân tích của công cụ, khả năng tích hợp với IDE và các công cụ khác, khả năng tùy chỉnh cấu hình, và chi phí. Cần đánh giá kỹ lưỡng các công cụ khác nhau trước khi đưa ra quyết định cuối cùng.

3.2. Kết Hợp Kiểm Thử Tự Động Và Thủ Công Để Tối Ưu

Kiểm thử tự động và kiểm thử thủ công nên được kết hợp để đạt hiệu quả tối ưu. Kiểm thử tự động có thể giúp phát hiện các lỗi cơ bản một cách nhanh chóng, trong khi kiểm thử thủ công có thể giúp phát hiện các lỗi tinh vi hơn. Việc kết hợp cả hai phương pháp sẽ giúp đảm bảo chất lượng phần mềm một cách toàn diện.

IV. Ứng Dụng Logic Hoare Trong Kiểm Thử Dòng Dữ Liệu Tĩnh

Logic Hoare là một công cụ mạnh mẽ có thể được sử dụng để chứng minh tính đúng đắn của chương trình. Bằng cách kết hợp Logic Hoare với kiểm thử dòng dữ liệu tĩnh, có thể nâng cao hiệu quả kiểm thử và giảm thiểu rủi ro. Logic Hoare cung cấp một phương pháp hình thức để mô tả và chứng minh các tính chất của chương trình, giúp phát hiện các lỗi tiềm ẩn mà các phương pháp kiểm thử thông thường có thể bỏ sót. Chương 3 của luận văn trình bày chi tiết về ứng dụng Logic Hoare trong kiểm thử phần mềm.

4.1. Tổng Quan Về Logic Hoare Và Các Ký Hiệu Sử Dụng

Logic Hoare là một hệ thống logic được sử dụng để chứng minh tính đúng đắn của chương trình. Hệ thống này dựa trên việc sử dụng các bộ ba Hoare, có dạng {P} C {Q}, trong đó P là tiền điều kiện, C là đoạn mã, và Q là hậu điều kiện. Bộ ba Hoare có nghĩa là nếu P đúng trước khi thực thi C, thì Q sẽ đúng sau khi thực thi C.

4.2. Kỹ Thuật Kết Hợp Logic Hoare Với Kiểm Thử Dòng Dữ Liệu

Việc kết hợp Logic Hoare với kiểm thử dòng dữ liệu có thể giúp phát hiện các lỗi tiềm ẩn mà các phương pháp kiểm thử thông thường có thể bỏ sót. Kỹ thuật này dựa trên việc sử dụng Logic Hoare để mô tả các tính chất của dòng dữ liệu, và sau đó sử dụng kiểm thử dòng dữ liệu để kiểm tra xem các tính chất này có được thỏa mãn hay không.

V. Kết Luận và Hướng Phát Triển Kỹ Thuật Kiểm Thử Tĩnh

Kiểm thử dòng dữ liệu tĩnh là một kỹ thuật quan trọng trong quá trình phát triển phần mềm, giúp phát hiện các lỗi tiềm ẩn và nâng cao chất lượng sản phẩm. Luận văn này đã trình bày tổng quan về kiểm thử dòng dữ liệu tĩnh, các vấn đề và thách thức liên quan, các phương pháp kiểm thử hiệu quả, và ứng dụng Logic Hoare. Trong tương lai, kỹ thuật kiểm thử dòng dữ liệu tĩnh sẽ tiếp tục phát triển và đóng vai trò ngày càng quan trọng trong việc đảm bảo chất lượng phần mềm.

5.1. Tóm Tắt Các Kết Quả Nghiên Cứu Chính Về Kiểm Thử Tĩnh

Luận văn đã trình bày các khái niệm cơ bản về kiểm thử tĩnh, phân loại các kỹ thuật kiểm thử tĩnh thành verification và phân tích tĩnh. Đồng thời, luận văn cũng đề cập đến các kỹ thuật phân tích style, phân tích dòng điều khiển và phân tích dòng dữ liệu.

5.2. Hướng Nghiên Cứu Phát Triển Trong Tương Lai Của Kiểm Thử

Trong tương lai, có nhiều hướng nghiên cứu phát triển cho kiểm thử dòng dữ liệu tĩnh. Một trong số đó là phát triển các công cụ phân tích mạnh mẽ hơn, có khả năng phân tích các đoạn mã phức tạp và phát hiện các lỗi tinh vi hơn. Một hướng khác là phát triển các phương pháp kiểm thử dựa trên trí tuệ nhân tạo, có khả năng tự động hóa quá trình kiểm thử và cải thiện hiệu quả phát hiện lỗi.

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

Chương 1, trong chương này tác giả luận văn sẽ tập trung vào nghiên cứu và trình bày các phương pháp kiểm thử dòng dữ liệu tĩnh. Phương pháp kiểm thử dòng dữ liệu tĩnh Chúng ta đã biết, kiểm thử dòng điều khiển và kiểm thử dòng dữ liệu được xem là hai phương pháp chủ yếu trong chiến lược kiểm thử hộp trắng nhằm phát hiện các lỗi tiềm tàng bên trong các chương trình/đơn vị chương trình. Phương pháp kiểm thử dòng điều khiển cho phép sinh ra các ca kiểm thử (tương ứng với các đường đi dòng điều khiển) của chương trình. Tuy nhiên, chỉ áp dụng phương pháp này là chưa đủ để phát hiện tất cả các lỗi tiềm ẩn bên trong chương trình.

Trong thực tế, các lỗi thường hay xuất hiện tại các biến được sử dụng trong chương trình/đơn vị chương trình. Kiểm thử dòng dữ liệu cho phép chúng ta phát hiện những lỗi này. Bằng cách áp dụng cả hai phương pháp này, chúng ta khá tự tin về chất lượng của sản phẩm phần mềm [1]. Với phạm vi nghiên cứu của đề tài, trong chương này sẽ trình bày phương pháp kiểm thử dòng dữ liệu tĩnh.

Ý tưởng của phương pháp Mỗi chương trình/đơn vị chương trình là chuỗi các hoạt động gồm nhận các giá trị đầu vào, thực hiện các tính toán, gán giá trị mới cho các biến (các biến cục bộ và toàn cục) và cuối cùng là trả lại kết quả đầu ra như mong muốn. Khi một biến được khai báo và gán giá trị, nó phải được sử dụng ở đâu đó trong chương trình. Ví dụ, khi khai báo một biến int tem = 0, chúng ta hy vọng biến tem sẽ được sử dụng ở các câu lệnh tiếp theo trong đơn vị chương trình. Việc sử dụng biến này có thể trong các câu lệnh tính toán hoặc trong các biểu thức điều kiện.

Nếu biến này không được sử dụng ở các câu lệnh tiếp theo thì việc khai báo biến này là không cần thiết. Hơn nữa, cho dù biến này có được sử dụng thì tính đúng đắn của chương trình chưa chắc đã đảm bảo vì lỗi có thể xảy ra trong quá trình tính toán hoặc trong các biểu thức điều kiện. Để giải quyết vấn đề này, phương pháp kiểm thử dòng dữ liệu xem đơn vị chương trình gồm các đường đi tương ứng với các dòng dữ liệu nơi mà các biến được khai báo, được gán giá trị, được sử dụng để tính toán và trả lại kết quả mong muốn của đơn vị chương trình ứng với đường đi này. 19 Với mỗi đường đi, chúng ta sẽ sinh một ca kiểm thử để kiểm tra tính đúng đắn của nó.

Quá trình kiểm thử dòng dữ liệu được chia thành hai pha riêng biệt: kiểm thử dòng dữ liệu tĩnh (static data flow testing) và kiểm thử dòng dữ liệu động (dynamic data flow testing). Với kiểm thử dòng dữ liệu tĩnh, chúng ta áp dụng các phương pháp phân tích mã nguồn mà không cần chạy chương trình/đơn vị chương trình nhằm phát hiện các vấn đề về khai báo, khởi tạo giá trị cho các biến và sử dụng chúng. Chi tiết về vấn đề này sẽ được trình bày trong phần tiếp theo. Với kiểm thử dòng dữ liệu động, chúng ta sẽ chạy các ca kiểm thử nhằm phát hiện các lỗi tiềm ẩn mà kiểm thử tĩnh không phát hiện được.

Các vấn đề bất thường trong dòng dữ liệu Trong quá trình lập trình, các lập trình viên có thể viết các câu lệnh “bất thường” hoặc không tuân theo chuẩn lập trình. Chúng ta gọi những bất thường liên quan đến việc khai báo, khởi tạo giá trị cho các biến và sử dụng chúng là các vấn đề về dòng dữ liệu của đơn vị chương trình. Ví dụ, một lập trình viên có thể sử dụng một biến mà không khởi tạo giá trị sau khi khai báo nó (int x; if (x==100) {…}). Các vấn đề bất thường về dòng dữ liệu có thể được phát hiện bằng phương pháp kiểm thử dòng dữ liệu tĩnh.

Theo Fosdick và Osterweil [4], các vấn đề này được chia thành ba loại như sau:  Gán giá trị rồi gán tiếp giá trị (Loại 1) [4]: Ví dụ hình dưới đây chứa hai câu lệnh tuần tự x = f1(y); x = f2(z); với f1 và f2 là các hàm đã định nghĩa trước và y, z lần lượt là các tham số đầu vào của các hàm này.1: Tuần tự các câu lệnh có vấn đề thuộc loại 1 Chúng ta có thể xem xét hai câu lệnh tuần tự này với các tình huống sau: - Khi câu lệnh thứ hai được thực hiện, giá trị của biến x được gán và câu lệnh đầu không có ý nghĩa; - Lập trình viên có thể có nhầm lẫn ở câu lệnh đầu. Câu lệnh này có thể là gán giá trị cho một biến khác như là w = f1(y); 20 - Có thể có nhầm lẫn ở câu lệnh thứ hai. Lập trình viên định gán giá trị cho một biến khác như là w = f2(z). - Một hoặc một số câu lệnh giữa hai câu lệnh này bị thiếu.

Ví dụ như câu lệnh w = f3(x). Chỉ có lập trình viên và một số thành viên khác trong dự án mới có thể trả lời một cách chính xác vấn đề trên thuộc trường hợp nào trong bốn tình huống trên. Mặc dù vậy, những vấn đề tương tự như ví dụ này là khá phổ biến và chúng ta cần phân tích mã nguồn để phát hiện ra chúng.  Chưa gán giá trị nhưng được sử dụng (Loại 2) [4]: Ví dụ hình dưới đây chứa ba câu lệnh tuần tự với y là một biến đã được khai báo và gán giá trị (y = f(x1)).

Trong trường hợp này, biến z chưa được gán giá trị khởi tạo nhưng đã được sử dụng trong câu lệnh để tính giá trị của biến x (x=y+z).2: Tuần tự các câu lệnh có vấn đề thuộc loại 2 Chúng ta cũng có thể lý giải vấn đề này theo các tình huống sau: - Lập trình viên có thể bỏ quên lệnh gán giá trị cho biến z trước câu lệnh tính toán giá trị cho biến x. Ví dụ, z = f2(x2), với f2 là một hàm đã được xác định và x2 là một biến đã được khai báo và gán giá trị. - Có thể có sự nhầm lẫn giữa biến z với một biến đã được khai báo và gán giá trị.  Đã được khai báo và gán giá trị nhưng không được sử dụng (Loại 3) [4]: Nếu một biến đã được khai báo và gán giá trị nhưng không hề được sử dụng (trong các câu lệnh tính toán hoặc trong các biểu thức điều kiện), chúng ta cần xem xét cẩn thận vấn đề này.

Tương tự như các trường hợp trên, các tình huống sau có thể được sử dụng để lý giải cho vấn đề này: - Có sự nhầm lẫn giữa biến này và một số biến khác được sử dụng trong chương trình. Trong thiết kế, biến này được sử dụng nhưng nó đã bị thay thế (do nhầm lẫn) bởi một biến khác. - Biến này thực sự không được sử dụng trong chương trình. Lúc đầu lập trình viên định sử dụng nó như là một biến tạm thời hoặc biến trung gian nhưng 21 sau đó lại không cần dùng.

Lập trình viên này đã quên xóa các câu lệnh khai báo và gán giá trị cho biến này. Huang [5] đã giới thiệu một phương pháp để xác định những bất thường trong việc sử dụng các biến dữ liệu bằng cách sử dụng sơ đồ chuyển trạng thái ứng với mỗi biến dữ liệu của chương trình. Các thành phần của sơ đồ chuyển trạng thái của một chương trình ứng với mỗi biến gồm: • Các trạng thái, gồm: - U: biến chưa được gán giá trị - D: biến đã được gán giá trị nhưng chưa được sử dụng - R: biến đã được sử dụng - A: trạng thái lỗi • Các hành động, gồm: - d: biến được gán giá trị - r: biến được sử dụng - u: biến chưa được gán giá trị hoặc được khai báo lại và chưa được gán giá trị.3: Sơ đồ chuyển trạng thái của một biến Hình 2.3 mô tả sơ đồ chuyển trạng thái của một biến trong một chương trình/đơn vị chương trình. Ban đầu, biến này đã được khai báo và chưa được gán giá trị nên trạng thái của chương trình là U.

Tại trạng thái này, nếu biến này được sử dụng (hành động r) thì chương trình có vấn đề và trạng thái của chương trình là A. Ngược lại, trạng thái U vẫn được giữ nguyên nếu các câu lệnh tiếp theo vẫn chưa chứa lệnh gán giá trị cho biến này (hành động u). Cho đến khi gặp câu lệnh gán giá trị cho biến này (hành động d), trạng thái của chương trình được chuyển thành D. Nếu biến này được sử dụng ở các câu lệnh tiếp theo (hành 22 động r) thì trạng thái của chương trình chuyển thành R.

Ngược lại, nếu các câu lệnh tiếp theo lại gán lại giá trị cho biến (hành động d) hoặc khai báo lại biến này và không gán giá trị cho nó (hành động u) thì xảy ra vấn đề và trạng thái của chương trình là A. Tại trạng thái này, mọi hành động (d, u và r) xảy ra đều không thay đổi trạng thái của chương trình. Tại trạng thái R, nếu biến này vẫn tiếp tục được sử dụng ở các lệnh tiếp theo (hành động r) thì trạng thái của chương trình vẫn không thay đổi. Ngược lại, nếu xuất hiện câu lệnh gán lại giá trị cho biến (hành động d) thì trạng thái của chương trình quay về D.

Trong trường hợp xuất hiện câu lệnh khai báo lại biến này và không gán giá trị cho nó (hành động u) thì chương trình được chuyển từ trạng thái R sang trạng thái U. Như vậy, các vấn đề với dòng dữ liệu thuộc loại 1 ứng với trường hợp dd xảy ra trong sơ đồ chuyển trạng thái. Các vấn đề thuộc loại 2 ứng với trường hợp ur và loại 3 ứng với trường hợp du. Để phát hiện các vấn đề này, chúng ta sẽ tiến hành xây dựng sơ đồ chuyển trạng thái ứng với mỗi biến như Hình 2.

Nếu trạng thái A xuất hiện thì chương trình có vấn đề về dòng dữ liệu. Trong trường hợp này, chúng ta cần kiểm tra lại mã nguồn, tìm nguyên nhân của tình huống này và sửa lỗi. Tuy nhiên, cho dù trạng thái lỗi (trạng thái A) không xuất hiện trong quá trình phân tích chương trình, chúng ta vẫn không đảm bảo được rằng chương trình không còn lỗi. Các lỗi có thể xảy ra trong quá trình gán/gán lại giá trị cho các biến và trong quá trình sử dụng chúng (trong các câu lệnh tính toán, trong các biểu thức điều kiện…).

Để phát hiện những lỗi này, chúng ta cần phương pháp kiểm thử dòng dữ liệu động.