Kiểm thử chức năng- Kiểm thử phần mềm pot

Kiểm thử chức năng


Nội dung




Giới thiệu kiểm thử chức năng
Các kỹ thuật kiểm thử chức năng




Kiểm thử giá trị biên
Kiểm thử phân hoạch tương đương
Kỹ thuật đồ thị nhân quả - bảng quyết định

2


Kiểm thử chức năng

3


Kiểm thử chức năng


Kiểm thử chức năng: các test cases dẫn xuất
từ các đặc tả chương trình





Chức năng đề cập đến nguồn gốc của thông tin
được sử dụng để thiết kế trường hợp kiểm thử,
không phải để kiểm thử như thế nào

Còn được gọi là:





Kiểm thử dựa trên đặc tả (từ đặc tả)
kiểm tra hộp đen (khơng có mã nguồn)

Đặc tả chức năng mơ tả hành vi chương trình
dự định


Hình thức hoặc khơng hình thức
4


Kiểm thử hệ thống và kiểm thử
ngẫu nhiên


Ngẫu nhiên (đồng đều):








Chọn các yếu tố đầu vào có thể thống nhất
Tránh thiên vị thiết kế
 Một vấn đề thực tế: Các nhà thiết kế kiểm thử cũng có thể tạo
ra cùng những lỗi logic và giả thiết tồi giống nhà thiết kế
chương trình (đặc biệt là nếu họ là cùng một người)
Nhưng đối xử với tất cả các đầu vào là có giá trị như nhau

Có hệ thống (khơng đồng đều):




Cố gắng chọn đầu vào là có giá trị đặc biệt
Thơng thường bằng việc lựa chọn đại diện của các lớp mà ứng
dụng gặp lỗi thường xuyên hoặc không phải tất cả trường hợp
Kiểm thử chức năng là kiểm thử có hệ thống thử nghiệm

5


Tại sao khơng ngẫu nhiên?




Sự phân bố lỗi khơng đều
Ví dụ: Lớp căn bậc hai Java áp dụng cho phương
trình bậc hai



Logic thực hiện khơng đầy đủ: Chương trình khơng
hợp lí trong các trường hợp trong đó b2 - 4ac = 0 và a
=0



Lấy mẫu ngẫu nhiên thường không chọn a = 0,0 và b
= 0,0
6


Systematic Partition Testing
The space of possible input values
(the haystack)

Failure (valuable test case)
No failure

Thất bại là thưa thớt
trong không gian
đầu vào có thể ...

Nếu chúng ta kiểm thử một cách có
hệ thống một số trường hợp trong
từng phần, chúng tôi sẽ có các bộ
phận dày đặc

... nhưng dày đặc
trong một số bộ phận
của không gian

Kiểm thử chức năng là một trong
những cách vẽ đường màu hồng để
cơ lập khu vực có khả năng thất bại
7


Kiểm thử chức năng: khai thác
các đặc tả




Kiểm thử chức năng sử dụng các đặc tả (hình
thức hoặc khơng hình thức) để phân vùng
khơng gian đầu vào
Ví dụ, đặc tả của chương trình "gốc" gợi ý phân
chia giữa các trường hợp với không, một, và hai
nghiệm thực




Kiểm tra từng trường hợp, và ranh giới giữa các
trường hợp

Không đảm bảo, nhưng kinh nghiệm cho thấy
thất bại thường nằm ở ranh giới
8


Tại sao kiểm thử chức năng?


kịp thời




hiệu quả




tìm một vài lớp lỗi (ví dụ, thiếu logic) có thể vượt q
cách tiếp cận khác

áp dụng rộng rãi





Thường hữu ích trong việc tinh chỉnh đặc tả và đánh
giá khả năng kiểm thử trước khi mã được viết

cho bất kỳ mô tả hành vi của chương trình phục vụ
như một đặc tả
ở bất kỳ mức độ nào từ module để kiểm thử hệ thống.

Kinh tế


thường ít tốn kém để thiết kế và thực thi hơn so với
các trường hợp kiểm thử cấu trúc (mã)

9


Thiết kế kiểm thử chức năng
sớm


Mã nguồn chương trình là khơng cần thiết





Chỉ có một mơ tả về hành vi được dự kiến là cần thiết
Thậm chí các đặc tả khơng đầy đủ và chính thức có thể được sử
dụng

 Mặc dù chính xác, đặc tả đầy đủ dẫn đến bộ thử tốt hơn

Thiết kế kiểm thử chức năng sớm có những lợi ích phụ





Thường cho thấy sự mơ hồ và mâu thuẫn trong đặc tả
Hữu ích cho việc đánh giá khả năng kiểm thử
 Và cải thiện tiến độ Và ngân sách kiểm thử bằng cách cải
thiện đặc tả
Giải thích hữu ích của đặc tả
 hoặc trong trường hợp cực đoan (như trong XP), trường hợp
kiểm thử chính là đặc tả
10


Chức năng và cấu trúc: Các
lớp lỗi


Chiến lược kiểm thử khác nhau (chức năng,
cấu trúc) là hiệu quả nhất cho các lớp lỗi
khác nhau



Kiểm thử chức năng là tốt nhất cho việc tìm
kiếm các lỗi thiết kế



Kiểm thử cấu trúc là tốt nhất cho việc tìm
kiếm lỗi lập trình
11


Kiểm thử chức năng và cấu
trúc: các mức


Kiểm thử chức năng được áp dụng tại tất cả các
mức độ:








Đơn vị (từ đặc tả giao diện module)
Tích hợp (từ API hoặc đặc tả hệ thống con)
Hệ thống (từ đặc tả yêu cầu hệ thống)
Hồi quy ( từ yêu cầu hệ thống + lịch sử lỗi)

Kiểm thử cấu trúc (dựa trên mã) áp dụng cho
phần tương đối nhỏ của hệ thống:




Đơn vị
Tích hợp
12


Các bước: Từ đặc tả đến test
cases


1.Phân rã đặc tả




2. Chọn đại diện






Đại diện các giá trị của mỗi đầu vào,
hoặc Hành vi đại diện của một mơ hình
 Biến đổi đầu vào / đầu ra thường đơn giản không mô tả một
hệ thống. Chúng ta sử dụng các mô hình trong đặc tả chương
trình, trong thiết kế chương trình, và thiết kế kiểm thử

3. Hình thành đặc tả kiểm thử





Nếu đặc tả lớn, chia nó thành các tính năng độc lập có thể kiểm
thử được để xem xét trong kiểm thử

Thông thường: kết hợp các giá trị đầu vào, hoặc hành vi mơ hình

4. Triển khai và thực thi các kiểm thử thực tế
13


Từ đặc tả đến test cases
Functional
Specifications

Independently
Testable
Feature

Representative
Values

Model

Test
Case
Specifications

Test
Cases
14


Ví dụ: Tìm kiếm mã thư tín







Đầu vào: mã ZIP (5-chữ số
mã thư tín US)
Đầu ra: Danh sách thành
phố
What are some
representative values (or
classes of value) to test?
15


Example: Representative
values
Simple example with
one input, one output



Correct zip code




With 0, 1, or many cities

Malformed zip code





Note prevalence of boundary
values (0 cities, 6 characters)
and error cases

Empty; 1-4 characters; 6 characters; very long
Non-digit characters
Non-character data
16


Các kỹ thuật kiểm thử chức
năng





Boundary Value testing
Equivalence Class testing
Decision Tables

17


Ví dụ

18


Chương trình tam giác
Để 3 số nguyên a, b, c là 3 cạnh tam
giác, cần phải có:
c1 a + b > c
c2 a + c > b
c3 b + c > a
Một tam giác là :





Đều nếu 3 cạnh bằng nhau
Cân nếu có 2 cạnh bằng nhau
Thường nếu khơng có cạnh nào bằng
nhau

a

b

c

19


Chương trình Tam giác






Chương trình Tam giác đọc trong 3 số
nguyên và quyết định chúng có tạo thành một
tam giác đều, một tam giác cân, một tam giác
cạnh không đều, hoặc nếu không tạo thành
một tam giác nào trong các loại trên
Các logic của chương trình là rõ ràng, nhưng
phức tạp, do các mối quan hệ giữa các yếu
tố đầu vào và đầu ra
Chúng tôi giả định rằng mỗi chiều dài bên là
giữa 1 và 200

20


Hàm NextDate







Chương trình này đọc một ngày trong một
định dạng nhất định và in ra ngày của ngày
hơm sau.
Ví dụ, một đầu vào 03 31 1998 cho kết quả
04 01 1998.
Năm bị hạn chế nằm giữa 1812 và 2012, bao
gồm

21


Vấn đề tính tiền hoa hồng







Một nhân viên bán hàng bán ổ khóa, nguyên vật
liêu và thùng
Trên một cơ sở hàng tháng, nhân viên bán hàng
báo cáo có bao nhiêu mỗi ông hoặc bà đã bán
được

Do hạn chế sản xuất, chúng tôi đã:
1 ≤ # locks≤ 70
1 ≤ # stocks ≤ 80
1 ≤ # barrels ≤ 90
Mục tiêu: Xác định tổng doanh thu và hoa hồng
22


Vấn đề tính tiền hoa hồng






Các bộ phận bán được như sau:
Khóa $ 45 /mỗi
Nguyên vật liệu $ 30/ mỗi
Thùng $ 25/ mỗi
Hoa hồng được tính trên doanh số bán hàng:
10% trên doanh số bán hàng lên đến và bao
gồm cả $ 1000, 15% cho $ 800 tiếp , và 20%
trên khoản tiền trên $ 1800
Chương trình này có logic tính tốn để kiểm tra
đầu vào và đầu ra là không phức tạp
23


Kiểm thử giá trị biên

24


Kiểm thử biên


Kiểm thử các giá trị, hoặc kích thước hoặc số
lượng gần giới hạn thiết kế








Giá trị giới hạn
chiều dài giới hạn
Khối lượng giới hạn
Chuỗi Null vs chuỗi rỗng

Lỗi có xu hướng xảy ra gần các giá trị cực đầu
vào
Robustness(Mạnh mẽ): phần mềm phản ứng
như thế nào khi được vượt quá giới hạn?
25