0

Data Flow Testing

Kiểm thử tích hợp bao gồm việc xây dựng hệ thống từ những thành phần của nó và kiểm tra xem có vấn đề gì xảy ra từ các tương tác giữa các thành phần. Có hai cách tích hợp hệ thống:

  • Tích hợp từ trên xuống: xây dựng khung của hệ thống và đưa các thành phần vào trong nó.

  • Tích hợp từ dưới lên: tích hợp các thành phần cơ sở, sau đó bổ sung thêm các thành phần chức năng.

Trong bài viết lần này tôi sẽ trình bày cụ thể về kiểm thử tích hợp từ trên xuống dưới.

  • Tích hợp từ trên xuống là tích hợp từ hàm chính (main) - gốc của cây.

  • Các hàm được gọi trong hàm main trước khi tích hợp là các hàm giả (stub). Các hàm giả này là các hàm mô phỏng hàm được gọi và sẽ được bỏ đi khi tích hợp với hàm thật.

    => Ví dụ: hàm main gọi hàm f(x) và g(y) thì khi kiểm thử đơn vị hàm main chúng ta sử dụng hàm f() và g() là các hàm giả. Hàm giả sẽ nhận tham số và trả về kết quả như hàm thật nhưng nó không được cài đặt như hàm thật mà trả về luôn giá trị kết quả ứng với các một số tham số biết trước - tương ứng với ca kiểm thử sẽ được truyền cho f(x) và g(y). Khi có các hàm giả này thì chúng ta có thể kiểm thử hàm main một cách độc lập, không phụ thuộc vào hàm thật. Lúc này chúng ta có thể áp dụng các kỹ thuật đã học về kiểm thử đơn vị để kiểm thử hàm main.

  • Khi chúng ta đã kiểm thử xong hàm main, chúng ta sẽ thay dần các hàm giả bằng các hàm thật.

  • Trên thực tế người lập trình sẽ phải bỏ ra khá nhiều công sức để viết các hàm giả. Do đó phần việc viết các hàm giả này cũng cần coi như mã nguồn thông thường, và chúng ta cũng cần quản lý chúng tốt để có thể chuyển giữa mã giả và mã thật - do mã giả và mã thật không cùng tồn tại đồng thời được.

Ý tưởng của kiểm thử luồng dữ liệu:

  • kiểm thử luồng dữ liệu liên quan đến việc chọn đường đi với mục tiêu bao phủ các cặp gán (definition) và dùng (use) dữ liệu, được gọi là các tiêu chuẩn luồng dữ liệu.

Quy trình tổng quát của kiểm thử luồng dữ liệu:

  • vẽ đồ thị luồng dữ liệu cho chương trình.
  • chọn tiêu chuẩn kiểm thử luồng dữ liệu.
  • xác định các đường đi trong đồ thị để thỏa mãn tiêu chuẩn lựa chọn (all-defs, all-uses, all-P-user/some-c-uses....).
  • Tạo các ca kiểm thử cho các đường đi đã xác định.

Một số định nghĩa:

  • Đỉnh gán - definition: dỉnh n trong đồ thị luồng của chương trình P là đỉnh gán của biến v, viết def(v,b) nếu và chỉ nếu giá trị của v được xác định không mơ hồ tại lệnh ở đỉnh n.

  • Đỉnh Use: Đỉnh n trong đồ thị luồng dữ liệu của chương trình P là đỉnh dùng của biến v, viết use(v,n) nếu và chỉ nếu giá trị của biến v được dùng ở lệnh tại đỉnh n

  • PATHS(P) là tập tất cả các đường đi có thể trong CFG của chương trình P.

  • một đường đi du-path(def-use) cho biến v là đường đi trong paths(p) thỏa mãn: tồn tại def(v,m) và use(n,n) sao cho m và n tương ứng là đỉnh đầu và cuối của đường đi.

Tiêu chuẩn bao phủ kiểm thử DU-Path

  • ý tưởng: sử dụng thông tin def-use và tiêu chuẩn cụ thể để nhận được các đường đi cụ thể trong đồ thị CFG, từ đó xác định các ca kiểm thử.

  • Giả sử T là tập tất cả các đường đi đầy đủ và khả thi trong CFG của chương trình P và V là tập tất cả các biến trong P.

  • T thỏa mãn tiêu chuẩn All-Defs nếu và chỉ nếu với mọi v,T chứa các đường đi dc-path từ mọi đỉnh gán của v đến một đỉnh dùng của v.

  • T thỏa mã tiêu chuẩn All-Uses nếu và chỉ nếu với mọi v, T chứa các đường đi dc-path từ mọi đỉnh gán của v đến mọi đỉnh dùng của v và đến đỉnh tiếp theo của mỗi USE(v,n).

  • Chúng ta có thể làm min hơn bằng All-C-Uses và All-P_Uses

  • All-P-Uses/Some-C-Uses: với mọi v, T gồm các đường đi dc-path từ mọi đỉnh gán của v đến mọi đỉnh p-use của v và nếu một định nghĩa của v không có p-use thì tồn tại một đường đi dc-path đến ít nhất một c-use.

  • All-c-uses / some-p-uses: với mọi v, T gồm các đường đi dc-path từ mọi đỉnh gán của v đến mọi đỉnh gán c-use của v và nếu một định nghĩa của v không có c-use thì tồn tại một đường đi dc-path đến ít nhất một p-use.

  • All-DU-Path: với mọi v, T gồm các đường đi dc-Path từ mọi đỉnh gán của v đến mọi đỉnh dùng của v và đến đỉnh tiếp theo của mối use(v,n) và các đường đi này hoặc là lặp một lần hoặc không lặp.

😦 Phần lý thuyết hơi dài, mọi người đọc có khi cũng oải, dưới đây tôi sẽ lấy ví dụ cụ thể để mọi người dễ hình dung hơn về phần kiểm thử data flow testing.

Ta có source code sau:

1.PNG

  • Bước 1: sinh đồ thị

2.PNG

  • Bước 2: du-pair cho từng biến

3.PNG

9.PNG

  • Bước 3: Sinh test path cho mỗi biến

4.PNG

  • Bước 4: SInh test case và kiểm thử

Đối với biến Price

5.PNG

đối với biến Use

6.PNG


All rights reserved

Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí