Phân tích giá trị biên – Boundary Values Analysis

a. Định nghĩa.
Phân tích giá trị biên (BVA) là kỹ thuật thiết kế test case và hoàn thành phân vùng tương đương.
Mục tiêu là lựa chọn các test case để thực thi giá trị biên.
Kiểm thử các dữ liệu vào bao gồm:
Giá trị nhỏ nhất.
Giá trị gần kề lớn hơn giá trị nhỏ nhất.
Giá trị bình thường.
Giá trị gần kề bé hơn giá trị lớn nhất.
Giá trị lớn nhất.


Hình 3: Ví dụ về biểu thị phân tích giá trị biên
b. Nguyên tắc chọn dữ liệu.
- Nếu giá trị đầu vào xác định là một mảng có biên là a và b(a < b) thì có thể thiết kế được các test case như sau:
§ Biên a
§ Biên b
§ Giá trị nhỏ hơn biên a
§ Giá trị lớn hơn biên b
§ Một giá trị nằm giữa a và b.
Ø Kiểm thử theo giá trị biên với một biến


Hình 4: Đồ thị kiểm thử giá trị biên với một biến
Ví dụ: Cho một mảng [ -3 , 10] ta có thể thiết kế được các test case là:
§ Giá trị nhỏ nhất: -3
§ Giá trị lớn nhất: 10
§ Giá trị nhỏ hơn giá trị nhỏ nhất: -4
§ Giá trị lớn hơn giá trị lớn nhất: 11
§ Giá trị nằm trong -3 và 10: 0

Ø Kiểm thử theo giá trị biên theo hai biến x1 và x2.

Hình 5: Đồ thị kiểm thử giá trị biên với hai biến
Ø Kiểm thử theo giá trị biên đầy đủ với một biến x1.

Hình 6: Đồ thị kiểm thử giá trị biên đầy đủ với một biến
Ø Kiểm thử theo giá trị biên đầy đủ với hai biến x1 và x2.

Hình 7: Đồ thị kiểm thử giá trị biên đầy đủ với hai biến.
Ø Kiểm thử theo giá trị biên xấu nhất với hai biến x1 và x2.


Hình 8: Đồ thị kiểm thử giá trị biên xấu nhất với hai biến.
Kết luận: Số lượng trường hợp kiểm thử phải có: (với n là các biến)
§ Kiểm thử theo giá trị biên: 4n +1
§ Kiểm thử theo giá trị biên đầy đủ: 6n +1
§ Kiểm thử theo giá trị biên xấu nhất: 5^n
- Nếu miền giá trị đầu vào là một danh sách các giá trị thì có thể thiết kế các test case như sau:
§ Giá trị nhỏ nhất.
§ Giá trị lớn hơn giá trị nhỏ nhất.
§ Giá trị lớn nhất.
§ Giá trị nhỏ hơn giá trị lớn nhất.
Ví dụ: Cho một danh sách như sau { 3,5,90,100,102} nên có thể thiết kế như sau:
§ Giá trị nhỏ nhất: 3
§ Giá trị lớn hơn giá trị nhỏ nhất: 5
§ Giá trị lớn nhất: 102
§ Giá trị nhỏ hơn giá trị lớn nhất: 100
- Nếu dữ liệu vào là điều kiện ràng buộc số giá trị thì có thể thiết kế được các test case như sau:
§ Số giá trị tối thiểu.
§ Số giá trị tối đa.
§ Và một số giá trị không hợp lệ.
c. Phân loại miền biên.
- Điểm trên biên (Boundary point).
- Điểm cực biên (Extreme point).
- Điểm ngoài biên (Off point).
- Điểm trong biên (Interior point.)


Hình 9: Phân loại miền biên
d. Ví dụ cho phân tích giá trị biên
Kiểm tra tính hợp lệ của tháng trong năm thì ta có thể thiết kế như sau:
§ Giá trị biên: 1 và 12
§ Giá trị cận biên ở bên trong: 2 và 11
§ Giá trị cận biên ở bên ngoài: 0 và 13
1.1.1.3. Đồ thị nguyên nhân – hệ quả.

a. Định nghĩa.
Một điểm yếu của hai phương pháp trên là chúng không khảo sát sự kết hợp của các trường hợp đầu vào. Việc kiểm tra sự kết hợp đầu vào không phải là một nhiệm vụ đơn giản bởi vì nếu bạn phân lớp tương đương các trạng thái đầu vào, thì số lượng sự kết hợp thường là rất lớn. Nếu bạn không có cách lựa chọn có hệ thống một tập con các trạng thái đầu vào, có lẽ bạn sẽ chọn ra một tập tùy hứng các điều kiện, điều này có thể dẫn tới việc kiểm thử không có hiệu quả.
Đồ thị nguyên nhân – kết quả hỗ trợ trong việc lựa chọn một cách có hệ thống tập các ca kiểm thử có hiệu quả cao. Nó có tác động có lợi ảnh hưởng tới việc chỉ ra tình trạng chưa đầy đủ và nhập nhằng trong đặc tả. Nó cung cấp cả cách biểu diễn chính xác cho các điều kiện logic và hành động tương ứng.
Kỹ thuật gồm có 4 bước:
§ Xác định điều kiện vào và hành động cho mỗi module cần kiểm định.
§ Xác định đồ thị nguyên nhân – kết quả.
§ Đồ thị được chuyển thành bảng quyết định.
§ Những phần trong bảng quyết định được chuyển thành test case.

b. Các ký hiệu cơ bản.
- Mỗi nút có giá trị là 0 hoặc 1.
- 0 mô tả trạng thái vắng mặt và 1 mô tả trạng thái có mặt.

Hình 10: Các ký hiệu của đồ thị nguyên nhân – kết quả.
- Hàm đồng nhất (Identity) nói:
§ Nếu a là 1 thì b là 1
§ Nếu a là 0 thì b là 0
- Hàm NOT nói:
§ Nếu a là 1 thì b là 0
§ Nếu a là 0 thì b là 1
- Hàm OR nói: (Cho phép số lượng đầu vào là bất kỳ)
§ Nếu a hoặc b hoặc c là 1 thì d là 1
§ Nếu a hoặc b hoặc c là 0 thì d là 0.
- Hàm AND nói: (Số lượng đầu vào là bất kỳ)
§ Nếu cả a và b là 1 thì c là 1
§ Nếu cả a và b là 0 thì c là 0.
c. Các ký hiệu ràng buộc.

Hình 11: Các ký hiệu ràng buộc trong đồ thị nguyên nhân – kết quả.
- Ràng buộc E (Exclude – loại trừ):
§ Khẳng định tối đa rằng, chỉ có thể a hoặc b là 1(a,b không đồng thời = 1)
- Ràng buộc I (Include – bao hàm):
§ Khẳng định ít nhất một trong a,b hoặc c phải luôn là 1(a,b,c không đồng thời bằng 0)
- Ràng buộc O (Only – chỉ một):
§ Một và chỉ một a hoặc b là 1
- Ràng buộc R (Request – yêu cầu):
§ Khi a là 1 thì b phải là 1
- Ràng buộc M (Mask – mặt lạ):
§ Nếu kết quả a là 1 thì kết quả b bắt buộc phải là 0.
Bước tiếp theo là tạo bảng quyết định mục vào giới hạn – limited-entry decision table. Tương tự với các bảng quyết định, thì nguyên nhân chính là các điều kiện và kết quả chính là các hành động.
Quy trình được sử dụng là như sau:
§ Chọn một kết quả để là trạng thái có mặt (1).
§ Lần ngược trở lại đồ thị, tìm tất cả những sự kết hợp của các nguyên nhân (đối tượng cho các rằng buộc) mà sẽ thiết lập kết quả này thành 1.
§ Tạo một cột trong bảng quyết định cho mỗi sự kết hợp nguyên nhân.
§ Với mỗi sự kết hợp, hãy quy định trạng thái của tất cả các kết quả khác và đặt chúng vào mỗi cột.
Trong khi biểu diễn bước 2, cần quan tâm các vấn đề sau:
§ Khi lần ngược trở lại qua một nút or mà đầu ra của nó là 1, không bao giờ thiết lập nhiều hơn 1 đầu vào cho nút or là 1 một cách đồng thời. Điều này được gọi là path sensitizing – làm nhạy đường đi. Mục tiêu của nó là để ngăn chặn dò lỗi thất bại vì một nguyên nhân che đi một nguyên nhân khác.
§ Khi lần ngược trở lại qua một nút and mà đầu ra của nó là 0, dĩ nhiên, phải liệt kê tất cả các sự kết hợp đầu vào dẫn tới đầu ra 0. Tuy nhiên, nếu bạn đang khảo sát trạng thái mà 1 đầu ra là 0 và một hay nhiều đầu ra khác là 1, thì không nhất thiết phải liệt kê tất cả các điều kiện mà dưới điều kiện đó các đầu vào khác có thể là 1.
Khi lần ngược trở lại qua một nút and mà đầu ra của nó là là 0, chỉ cần liệt kê 1 điều kiện trong đó tất cả đầu vào bằng 0. (Nếu nút and ở chính giữa của đồ thị như vậy thì tất cả các đầu vào của nó xuất phát từ các nút trung gian khác, có thể có quá nhiều trạng thái mà trong trạng thái đó tất cả các đầu vào của nó bằng 0.)
Những xem xét được dò theo đồ thị:

Hình 12: Các hình biểu diễn dò theo đồ thị
- Ví dụ cho bài toán nhập tháng trong một chương trình. Sử dụng phương pháp đồ thị nguyên nhân – kết quả để thiết kế:
§ Bước 1: Xác định điều kiện nhập vào.
Cause ( Điều kiện vào)
Effect (Hành động)
1. Số nguyên ≥ 1
2. Số nguyên ≤ 12
3. Số < 1
4. Số > 12
5. Chuỗi
6. Không phải số nguyên
A: Đúng
B: Sai
C: Nghi ngờ

§ Xây dựng đồ thị. (có sử dụng các ký hiệu cơ bản và cá ký hiệu ràng buộc)

Hình 13: Đồ thị của ví dụ nhập tháng.
Nhận xét:
Vẽ đồ thị nguyên nhân – kết quả là phương pháp tạo các ca kiểm thử có hệ thống mô tả sự kết hợp của các điều kiện. Sự thay đổi sẽ là 1 sự lựa chọn kết hợp không thể dự tính trước, nhưng khi thực hiện như vậy, có vẻ như bạn sẽ bỏ sót nhiều ca kiểm thử “thú vị” được xác định bằng đồ thị nguyên nhân – kết quả .
Vì vẽ đồ thị nguyên nhân – kết quả yêu cầu chuyển một đặc tả thành một mạng logic Boolean, nó cung cấp một triển vọng khác và sự hiểu biết sâu sắc hơn nữa về đặc tả. Trên thực tế, sự phát triển của 1 đồ thị nguyên nhân – kết quả là cách hay để khám phá sự mơ hồ và chưa đầy đủ trong các đặc tả.
Mặc dù việc vẽ đồ thị nguyên nhân – kết quả tạo ra tập các ca kiểm thử hữu dụng, nhưng thông thường nó không tạo ra tất cả các ca kiểm thử hữu dụng mà có thể được nhận biết. Ngoài ra, đồ thị nguyên nhân – kết quả không khảo sát thỏa đáng các điều kiện giới hạn. Dĩ nhiên, bạn có thể cố gắng bao phủ các điều kiện giới hạn trong suốt quá trình.
Tuy nhiên, vấn đề trong việc thực hiện điều này là nó làm cho đồ thị rất phức tạp và dẫn tới số lượng rất lớn các ca kiểm thử. Vì thế, tốt nhất là xét 1 sự phân tích giá trị giới hạn tách rời nhau.
Vì đồ thị nguyên nhân – kết quả làm chúng ta mất thời gian trong việc chọn các giá trị cụ thể cho các toán hạng, nên các điều kiện giới hạn có thể bị pha trộn thành các ca kiểm thử xuất phát từ đồ thị nguyên nhân – kết quả. Vì vậy, chúng ta đạt được một tập các ca kiểm thử nhỏ nhưng hiệu quả mà thỏa mãn cả 2 mục tiêu.
1.1.1.4. Đoán lỗi – Error Guessing

Một kỹ thuật thiết kế test-case khác là error guessing – đoán lỗi. Tester được đưa cho 1 chương trình đặc biệt, họ phỏng đoán, cả bằng trực giác và kinh nghiệm, các loại lỗi có thể và sau đó viết các ca kiểm thử để đưa ra các lỗi đó.
Thật khó để đưa ra một quy trình cho kỹ thuật đoán lỗi vì nó là một quy trình có tính trực giác cao và không thể dự đoán trước. Ý tưởng cơ bản là liệt kê một danh sách các lỗi có thể hay các trường hợp dễ xảy ra lỗi và sau đó viết các ca kiểm thử dựa trên danh sách đó. Một ý tưởng khác để xác định các ca kiểm thử có liên đới với các giả định mà lập trình viên có thể đã thực hiện khi đọc đặc tả (tức là, những thứ bị bỏ sót khỏi đặc tả, hoặc là do tình cờ, hoặc là vì người viết có cảm giác những đặc tả đó là rõ ràng). Nói cách khác, bạn liệt kê những trường hợp đặc biệt đó mà có thể đã bị bỏ sót khi chương trình được thiết kế.
Các hình từ 3-13https://docs.google.com/file/d/0B_pEEI9JRLuqSzNud2lscUZ1WVk/edit

Nguồn testervn.