intTypePromotion=1
zunia.vn Tuyển sinh 2024 dành cho Gen-Z zunia.vn zunia.vn
ADSENSE

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

Chia sẻ: Lê Quang Vũ | Ngày: | Loại File: PDF | Số trang:84

362
lượt xem
71
download
 
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

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....

Chủ đề:
Lưu

Nội dung Text: Kiểm thử chức năng- Kiểm thử phần mềm

  1. Kiểm thử chức năng
  2. 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
  3. Kiểm thử chức năng 3
  4. 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
  5. 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
  6. 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
  7. Systematic Partition Testing Thất bại là thưa thớt ... nhưng dày đặc Failure (valuable test case) trong không gian trong một số bộ phận No failure đầu vào có thể ... của không gian The space of possible input values (the haystack) Nếu chúng ta kiểm thử một cách có hệ thống một số trường hợp trong Kiểm thử chức năng là một trong từng phần, chúng tôi sẽ có các bộ những cách vẽ đường màu hồng để phận dày đặc cô lập khu vực có khả năng thất bại 7
  8. 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
  9. Tại sao kiểm thử chức năng?  kịp thờ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  hiệu quả  tìm một vài lớp lỗi (ví dụ, thiếu logic) có thể vượt quá cách tiếp cận khác  áp dụng rộng rãi  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
  10. 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
  11. 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
  12. 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
  13. Các bước: Từ đặc tả đến test cases  1.Phân rã đặc tả  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ử  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ử  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
  14. Từ đặc tả đến test cases Functional Specifications Independently Testable Feature Representative Model Values Test Test Case Cases Specifications 14
  15. 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
  16. Example: Representative values Simple example with one input, one output  Correct zip code Note prevalence of boundary values (0 cities, 6 characters)  With 0, 1, or many cities and error cases  Malformed zip code  Empty; 1-4 characters; 6 characters; very long  Non-digit characters  Non-character data 16
  17. Các kỹ thuật kiểm thử chức năng  Boundary Value testing  Equivalence Class testing  Decision Tables 17
  18. Ví dụ 18
  19. 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 a b c2 a + c > b c3 b + c > a Một tam giác là :  Đều nếu 3 cạnh bằng nhau c  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 19
  20. 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
ADSENSE

CÓ THỂ BẠN MUỐN DOWNLOAD

 

Đồng bộ tài khoản
2=>2