Phân tích giá trị biên (BVA - Boundary Value Analysis)

Một phần của tài liệu (LUẬN VĂN THẠC SĨ) Kiểm định phần mềm theo tiếp cận hệ thống (Trang 29 - 74)

CHƯƠNG 2. CÁC KỸ THUẬT KIỂM ĐỊNH PHẦN MỀM

2.3 Kiểm định hộp đen

2.3.1 Các kỹ thuật kiểm định hộp đen

2.3.1.2. Phân tích giá trị biên (BVA - Boundary Value Analysis)

Khi thực hiện việc kiểm thử phần mềm theo dữ liệu, chúng ta kiểm tra xem đầu vào của người dùng, kết quả nhận được và kết quả tạm thời bên trong có được xử lý chính xác hay không.

Các điều kiện biên là tình trạng trực tiếp ở phía trên và dưới của các lớp tương đầu vào và lớp tương đương đầu ra. Việc phân tích các giá trị biên khác với phân hoạch tương đương theo hai điểm:

Từ mỗi lớp tương đương, phân hoạch tương đương sẽ chọn phần tử bất kỳ làm phần tử đại diện, trong khi việc phân tích giá trị biên sử dụng một hoặc một số phần tử. Như vây, mỗi biên của lớp tương đương chính là đích kiểm thử.

Không chỉ chú ý tập trung vào những điều kiện đầu vào, các trường hợp kiểm thử cũng được suy ra từ việc xem xét các kết quả ra (tức các lớp tương đương đầu ra).

Các trường hợp kiểm thử tốt là tại các biên của lớp. Những giá trị biên này là các phần tử cực tiểu/cực đại, ngắn nhất/dài nhất, chậm nhất/nhanh nhất, xấu nhất/đẹp nhất, đầu/cuối, bắt đầu/kết thúc, rỗng/đầy, sớm nhất/muộn nhất,… tức là những giá trị cận nhất. Như vậy, BVA mở rộng phân hoạch tương đương trên cơ sở tập trung vào các biên của miền đầu vào hơn là các giá trị tiêu biểu của nó.

Rất khó có thể có thể liệt kê hết các hướng dẫn cụ thể cho các trường hợp. Tuy nhiên, cũng có một số nguyên tắc phân tích giá trị biên nhƣ sau:

1. Nếu điều kiện đầu vào xác định một khoảng giá trị giữa a và b, các trường hợp kiểm thử sẽ đƣợc thiết kế với giá trị a và b, và các giá trị sát trên và sát dưới a và b.

2. Nếu một điều kiện đầu vào xác định một số các giá trị, các trường hợp kiểm thử sẽ đƣợc phát triển để thực hiện tại các giá trị cực đại, cực tiểu. Các giá trị sát trên và dưới giá trị cực đại, cực tiểu cũng được kiểm thử.

3. Nguyên tắc 1 và 2 đƣợc áp dụng cho các điều kiện đầu ra.

4. Nếu cấu trúc dữ liệu chương trình bên trong được qui định các biên (chẳng hạn, mảng được định nghĩa giới hạn 100 mục), tập trung thiết kế trường hợp kiểm thử để thực thi cấu trúc dữ liệu tại biên của nó.

Ngoài ra, người kiểm thử có thể sử dụng sự xét đoán và sáng tạo của mình để tìm các điều kiện biên.

Tóm lại, chúng ta phải kiểm thử mỗi biên của một lớp tương đương về tất cả các phía. Một chương trình nếu vượt qua những trường hợp kiểm thử đó có thể vượt qua các kiểm thử khác từ lớp đó.

Ví dụ: Nếu phần mềm cần điều khiển một số bản ghi bất kỳ trong khoảng từ 1 đến 16383 bản ghi, sẽ có ba lớp tương đương:

Lớp tương đương hợp lệ 1: trong khoảng 1 đến 16383 Lớp tương đương không hợp lệ 2 : nhỏ hơn 1

Lớp tương đương không hợp lệ 3: lớn hơn 16383 Các trường hợp kiểm thử có thể là:

Trường hợp kiểm thử 1: 0 bản ghi, là thành viên của lớp tương đương 2 và kề sát giá trị biên.

Trường hợp kiểm thử 2: 1 bản ghi, là giá trị biên.

Trường hợp kiểm thử 3: 2 bản ghi, kề sát giá trị biên.

Trường hợp kiểm thử 4: 723 bản ghi, là thành phần của lớp tương đương 1.

Trường hợp kiểm thử 5: 16382 bản ghi, kề sát giá trị biên.

Trường hợp kiểm thử 6: 16383 bản ghi, chính là giá trị biên.

Trường hợp kiểm thử 7: 16384 bản ghi, thành phần của lớp tương đương 3, kề sát giá trị biên.

2.3.1.3. Kỹ thuật đồ thị nhân-quả (Cause-Effect Graph)

Trong nhiều trường hợp, việc cố gắng chuyển một chính sách hoặc một thủ tục trong ngôn ngữ tự nhiên vào phần mềm dẫn đến sự thất bại và các vấn đề khó hiểu. Đồ thị nhân - quả là một phương pháp thiết kế trường hợp kiểm thử trên cơ sở đưa ra một sự mô tả súc tích các điều kiện logic và các hành vi kèm theo.

Đồ thị nhân - quả sử dụng mô hình các quan hệ logic giữa nguyên nhân và kết quả cho thành phần phần mềm. Mỗi nguyên nhân đƣợc biểu diễn nhƣ một điều kiện (đúng hoặc sai) của một đầu vào, hoặc kết hợp các đầu vào. Mỗi kết quả đƣợc biểu diễn như là một biểu thức Bool biểu diễn một kết quả tương ứng cho những thành phần vừa thực hiện.

Đồ thị nhân - quả đƣợc tạo nhƣ sau:

Tất cả các nguyên nhân (đầu vào) và các kết quả (đầu ra) đƣợc liệt kê dựa trên đặc tả và đƣợc định danh cho mỗi nhân - quả.

Các quan hệ giữa các nguyên nhân (các đầu vào) và các kết quả (các đầu ra) đƣợc biểu diễn trong đồ thị làm rõ ràng các quan hệ logic.

Từ đồ thị tạo ra bảng quyết định biểu diễn các quan hệ giữa nguyên nhân và kết quả. Dữ liệu kiểm thử đƣợc sinh ra dựa trên các qui tắc trong các bảng này.

Các ký hiệu đƣợc đơn giản hoá sử dụng trong đồ thị nhân quả, gồm các phần tử mô tả nhƣ bảng 2.3.

Bảng 2.3 - Các ký hiệu trong đồ thị nhân quả

STT Ký hiệu Ý nghĩa Giải thích

1 Tương đương Nếu đúng thì đúng.

2 AND (và) Nếu đúng và đúng, thì đúng 3 OR (hoặc) Nếu đúng hoặc đúng, thì

đúng

4 NOT (phủ định) Nếu sai, thì đúng

5 Loại trừ Nếu đúng, thì sai, hoặc nếu sai thì đúng.

6 Bao hàm

bao hàm

7 Yêu cầu yêu cầu

Các qui tắc trong bảng quyết định đƣợc mô tả nhƣ sau:

V

í dụ: Để tính thuế thu nhập, người ta có mô tả sau:

Tên bảng Qui tắc Tên bảng: cho biết tên logic

Qui tắc: đánh số để phân biệt các qui tắc quyết định logic.

Các dòng điều kiện: Mỗi dòng bao gồm các điều kiện để tạo quyết định cho chương trình.

Y: “true”

N: “false”

-- : Không có quyết định đƣợc tạo ra.

Các hành động: Mỗi dòng chỉ định có các xử lý đƣợc thực hiện hoặc không.

X: Xử lý đƣợc thực hiện.

-- : Không có xử lý đƣợc thực hiện.

1 2 … n Điều kiện 1 Y Y Y Điều kiện 2 Y -- Y Điều kiện 3 Y -- N

… … … …

Điều kiện n -- -- Y Hành động 1 X X X Hành động 2 -- X X Hành động 3 X -- X

… … … …

Hành động n -- -- X

a b

 a

c b

AND

 a

c b

OR

a b

a E

b a I

b a R

b

a b

a b c

a b c

a b

a b a

b

b

b a

a

Người vô gia cư nộp 4% thuế thu nhập Người có nhà ở nộp thuế theo bảng sau:

Tổng thu nhập Thuế

<= 5.000.000 đồng 4%

> 5.000.000 đồng 6%

Quan hệ giữa nguyên nhân (đầu vào) và kết quả (đầu ra) nhƣ sau:

Nguyên nhân Kết quả

1. Người có nhà ở

2. Tổng thu nhập <= 5.000.000 đồng 3. Tổng thu nhập > 5.000.000 đồng

4. Nộp 4 % thuế 5. Nộp 6% thuế Đồ thị biểu diễn quan hệ logic rõ ràng giữa nguyên nhân-kết quả

Hình 0.11 - Ví dụ đồ thị nhân-quả

Xây dựng bảng quyết định dựa trên đồ thị. Từ đây xây dựng được bốn trường hợp kiểm thử (một trường hợp cho việc nộp thuế 6% và ba trường hợp kiểm thử cần cho việc nộp thuế 4%).

Bảng 0.4 – Ví dụ bảng quyết định

Để đảm bảo phủ nhân quả 100%, các trường hợp kiểm thử phải được phát sinh tương ứng với các qui tắc trong bảng quyết định bảng 2.4.

Ví dụ 2: Xem xét một chương trình thực hiện giao dịch A/C như sau Trường hợp kiểm thử

Nguyên nhân và kết quả 1 2 3 4

Nguyên nhân 1. Người có nhà ở Y Y N --

2. Có tổng thu nhập <= 5.000.000 N Y -- Y 3. Có tổng thu nhập > 5.000.000 Y N -- --

Kết quả

4. Nộp thuế 4% -- X X X

5. Nộp thuế 6% X -- -- --

2

1

3

4

5 Tổng thu nhập ≤

5000000

người có nhà ở

Tổng thu nhập

>5000000

4% thuế

6% thuế

OR

AND NOT

Điều kiện đầu vào Điều kiện đầu ra

C1: Lệnh là tiền gửi E1: In lệnh không hợp lệ C2: Lệnh ghi nợ E2: In A/C không hợp lệ C3: A/C hợp lệ E3: In số ghi nợ không hợp lệ C4: Giá trị giao dịch hợp lệ E4: ghi nợ A/C hợp lệ

E5: gửi tiền A/C

Trường hợp

kiểm thử 1 2 3 4 5

C1 N Y -- -- Y

C2 N -- Y Y --

C3 -- N Y Y Y

C4 -- -- N Y Y

E1 X -- -- -- --

E2 -- X -- -- --

E3 -- -- X -- --

E4 -- -- -- X --

E5 -- -- -- -- X

2.3.1.4. Kiểm thử so sánh

Có một số trường hợp (như điện tử máy bay, điều khiển thiết bị năng lượng hạt nhân) trong đó độ tin cậy của phần mềm là tuyệt đối quan trọng, người ta thường gọi là phần mềm tuyệt đối đúng. Trong các ứng dụng nhƣ vậy phần cứng và phần mềm không cần thiết thường được sử dụng để tối thiểu khả năng lỗi. Khi phần mềm không cần thiết đƣợc phát triển, các nhóm công nghệ phần mềm riêng biệt phát triển các phiên bản độc lập của ứng dụng sử dụng cùng một đặc tả. Trong các trường hợp như vậy, mỗi phiên bản có thể đƣợc kiểm thử với cùng dữ liệu kiểm thử để đảm bảo rằng tất cả cung cấp đầu ra y nhƣ nhau. Sau đó tất cả các phiên bản đƣợc thực thi song song

C1 

C2

C3

C4

 

E2

E3

E5

E4 E1

với so sánh thời gian thực các kết quả để đảm bảo tính chắc chắn. Các phiên bản độc lập là cơ sở của kỹ thuật kiểm thử hộp đen đƣợc gọi là kiểm thử so sánh hay kiểm thử back-to-back.

Khi nhiều cài đặt của cùng một đặc tả được đưa ra, các trường hợp kiểm thử đƣợc thiết kế sử dụng các kỹ thụât hộp đen khác (ví dụ phân hoạch cân bằng) đƣợc cung cấp nhƣ đầu vào cho mỗi phiên bản của phần mềm. Nếu đầu ra của mỗi phiên bản là nhƣ nhau, sẽ cho rằng tất cả các cài đặt là đúng. Nếu đầu ra là khác nhau, mỗi ứng dụng đƣợc nghiên cứu để xác định có sai sót nào trong một hoặc nhiều phiên bản là nguyên nhân gây ra lỗi. Trong nhiều trường hợp, so sánh các đầu ra có thể được thực hiện bởi các công cụ tự động.

Kiểm thử so sánh là không rõ ràng. Nếu đặc tả mà tất cả các phiên bản đƣợc phát triển trên đó là có lỗi, thì tất cả các phiên bản sẽ có khả năng dẫn đến lỗi. Hơn nữa, nếu mỗi phiên bản độc lập tạo ra giống nhau, nhƣng không đúng, các kết qủa, kiểm thử điều kiện sẽ thất bại trong việc phát hiện lỗi.

2.3.1.5. Đoán lỗi

Không cần một phương pháp đặc biệt nào, một số chuyên gia có thể kiểm tra các điều kiện lỗi bằng cách đoán lỗi dễ xảy ra. Trên cơ sở trực giác và kinh nghiệm, với các chương trình cụ thể, các chuyên gia đoán trước các loại lỗi có thể, rồi viết các trường hợp kiểm thử để phơi ra các lỗi này.

Khó có thể đƣa ra đƣợc một thủ tục cho việc đoán lỗi vì đó là một quá trình của trực giác và tự học. Ý tưởng cơ bản là liệt kê một danh sách các lỗi có thể hoặc những tình huống dễ mắc lỗi, rồi viết các trường hợp kiểm thử dựa trên danh sách. Chẳng hạn như sự xuất hiện giá trị 0 trong đầu vào hoặc đầu ra của một chương trình là tình huống dễ có lỗi. Vì vậy, người ta viết những trường hợp kiểm thử cho các giá trị đầu vào có giá trị là 0 và các giá trị ra là 0. Và cũng như vậy đối với trường hợp số biến vào và ra có thể biểu diễn (chẳng hạn đầu vào là một danh sách tìm kiếm), các trường hợp danh sách rỗng hoặc chỉ chứa một phần tử là những tình huống dễ gây lỗi.

Một ý tưởng khác là chỉ ra các trường hợp kiểm thử liên quan đến giả định rằng lập trình viên đã mắc phải khi đọc đặc tả (tức là những thứ bị bỏ sót từ đặc tả có thể do tình cờ).

2.3.2 Quy trình kỹ thật kiểm định hộp đen

Quy trình kỹ thuật kiểm định hộp đen là quy trình sử dụng các kỹ thuật kiểm định hộp đen một cách hợp lý để kiểm định phần mềm trên các chức năng của chúng có thực hiện theo đúng đặc tả hay không. Để thực hiện kiểm định phần mềm sử dụng các kỹ thuật hộp đen nhằm phát hiện lỗi của chương trình trên các chức năng của chúng một cách hiệu quả nhất, với chi phí và thời gian tiêu tốn ít nhất chúng ta cần có một quy trình kiểm định hợp lý. Sau đây là các bước của một quy trình:

Bước 1: Xác định yêu cầu kiểm định hộp đen

Trong bước này dựa vào đặc tả của chương trình để xác định các chức năng cần kiểm định, xác định các miền giá trị dữ liệu vào và giá trị dữ liệu ra.

Bước 2: Phân tích dữ liệu vào ra

Để thiết kế các trường hợp kiểm định cho mỗi chức năng ta phải tiến hành phân tích các miền giá trị dữ liệu vào và dữ liệu ra bằng cách:

- Phân hoạch miền đầu vào thành các lớp tương đương, hợp lệ hay không hợp lệ, các giá trị đặc trƣng.

- Xác định các giá trị biên và các giá trị kề cận trong và ngoài biên cho các lớp tương đương.

Bước 3: Thiết kế các trường hợp kiểm định

- Dựa vào sự phân tích miền giá trị, thiết kế các trường hợp kiểm định đại diện cho các lớp tương đương, giá trị biên và kề cận trong và ngoài biên cũng như lỗi dự đoán theo tri thức và kinh nghiệm.

- Dự kiến kết quả dữ liệu ra bằng việc xây dựng một bộ oracle kiểm định ở bước tiếp theo là bước thiết kế và lập trình kiểm định.

Bước 4: Thiết kế & lập trình kiểm định hộp đen

- Thiết kế và lập trình giao diện kiểm định: Dựa vào đặc tả yêu cầu để thiết kế giao diện kiểm định, về cơ bản giao diện có thể biểu diễn được cho từng trường hợp kiểm định: dữ liệu vào, dữ liệu ra và kết quả đánh giá dữ liệu ra của chương trình cần kiểm định thực tế có đúng nhƣ đặc tả của hệ thống hay không.

- Thiết kế và lập trình cấu trúc bên trong của chương trình, nhằm đáp ứng các chức năng được thiết kế trên giao diện của chương trình kiểm định.

Trong việc thiết kế & lập trình kiểm định này một bộ oracle kiểm định sẽ đƣợc xây dựng.

Bước 5: Thực thi kiểm định hộp đen

Tiến hành thực hiện chương trình cần kiểm định lần lượt với tất cả các trường hợp kiểm định đã đƣợc thiết kế, bao gồm đƣa vào các giá trị dữ liệu vào và cho ra các kết quả dữ liệu ra của từng trường hợp. Sau đó thực thi chương trình kiểm định để tiến hành kiểm tra so sánh các kết quả của chương trình cần kiểm định với đặc tả của oracle kiểm định.

Bước 6: Đánh giá kết quả

- Khảo sát các kết quả của các trường hợp kiểm định, so sánh kết quả thực thi với đặc tả của oracle kiểm định đúng hay sai.

- Đánh giá chung kết quả kiểm định theo hộp đen.

Hình 2.12. Các bước của quy trình kiểm định hộp đen.

Ví dụ minh hoạ

Kiểm định chương trình giải phương trình bậc hai ax2+bx+c, bằng phương pháp hộp đen. Chúng ta không sử dụng mã nguồn để xác định bộ kiểm định, để giải quyết vấn đề này chúng ta đƣa ra bốn loại của dữ liệu kiểm định:

- Dữ liệu dễ tính toán. (theo kinh nghiệm) - Dữ liệu đặc trƣng.

- Dữ liệu biên.

- Dữ liệu không hợp lệ.

Áp dụng quy trình kỹ thuật kiểm định hộp đen ta thực hiện nhƣ sau:

Bước 1: Xác định yêu cầu kiểm định

Xác định yêu cầu kiểm định

Phân tích dữ liệu vào, ra

Thiết kế các trường hợp kiểm định

Thiết kế & lập trình kiểm định hộp đen

Thực thi kiểm định hộp đen

Đánh giá kết quả Bước 1

Bước 2

Bước 3

Bước 4

Bước 5

Bước 6

Để tiến hành kiểm định chương trình giải phương trình bậc hai ta xác định yêu cầu cần phải tiến hành khảo sát phương trình bậc hai để xác định hai nghiệm của phương trình bậc hai ax2+bx+c.

Dễ dàng nhận thấy rằng chúng ta sẽ thực hiện với các số thực và đƣa ra một thông báo lỗi nếu kết quả là hai nghiệm là số phức (các số này là căn bậc hai của số âm).

Chúng ta có thể đưa ra dữ liệu kiểm định đối với mỗi trường hợp dựa trên các giá trị của biểu thức delta (b2-4ac), bởi vì giá trị dữ liệu ra phụ thuộc vào kết quả của biểu thức này, nhƣ vậy:

- Dữ liệu vào: gồm ba phần tử (a, b,c) là số thực.

- Dữ liệu ra: gồm hai phần tử (x1, x2) hợp lệ nếu là số thực, và ngƣợc lại là không hợp lệ.

Bước 2: Phân tích dữ liệu vào, ra

- Lớp dữ liệu dễ tính toán, dựa theo kinh nghiệm:

Các hệ số a, b, c lần lƣợt theo thứ tự là: 1, 2, 1. Nghiệm hợp lệ.

hoặc: 1, 3, 2. Nghiệm hợp lệ.

- Lớp dữ liệu đặc trưng (biểu thức delta dương):

Các hệ số a, b, c lần lƣợt theo thứ tự là: 1, 4, 1. Hai nghiệm hợp lệ.

hoặc : 2, 4, 1. Hai nghiệm hợp lệ.

- Lớp dữ liệu biên (biểu thức delta bằng 0):

Các hệ số a, b, c lần lƣợt theo thứ tự là: 2, -4, 2. Nghiệm kép hợp lệ.

hoặc : 2, -8, 8. Nghiệm kép hợp lệ.

- Lớp dữ liệu không hợp lệ: phép chia cho 0 (nghiệm không xác định).

Các hệ số a, b, c lần lƣợt theo thứ tự là: 0, 1, 1.

- Lớp dữ liệu không hợp lệ: nghiệm phương trình là số phức.

Căn bậc hai của một số âm (biểu thức delta có kết quả âm).

Các hệ số a, b, c lần lƣợt theo thứ tự là: 1, 1, 1.

Bước 3: Thiết kế các trường hợp kiểm định

Dựa trên sự phân tích ta có các trường hợp kiểm định sau:

- Dữ liệu dễ tính toán, dựa theo kinh nghiệm.

Trường

hợp a b c Các nghiệm

1 1 2 1 -1, -1

2 1 3 2 -1, -2

- Dữ liệu đặc trưng (biểu thức delta dương):

a b c Các nghiệm

3 1 4 1 -3.73205, -0.267949

4 2 4 1 -1.70711, -0.292893

- Dữ liệu biên (biểu thức delta bằng 0):

a b c Các nghiệm

5 2 -4 2 1, 1

6 2 -8 8 2, 2

- Dữ liệu không hợp lệ:

a b c Các nghiệm

7 0 1 1 Phép chia cho 0 (không xác định cho phương trình bậc 2).

8 1 1 1 Căn bậc hai của một số âm (số phức), delta

<0.

Bước 4: Thiết kế & lập trình kiểm định hộp đen

* Thiết kế và lập trình giao diện kiểm định: Dựa vào đặc tả, yêu cầu bài toán để thiết kế giao diện kiểm định, về cơ bản giao diện có thể thể hiện:

- Tên chương trình kiểm định.

- Các trường hợp kiểm định đã thiết kế: Dữ liệu vào a, b, c, dữ liệu ra nghiệm x1, x2 (hoặc thông báo) và kết quả kiểm định của từng trường hợp (đúng /sai).

Một phần của tài liệu (LUẬN VĂN THẠC SĨ) Kiểm định phần mềm theo tiếp cận hệ thống (Trang 29 - 74)

Tải bản đầy đủ (PDF)

(74 trang)