Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 54 trang
THÔNG TIN TÀI LIỆU
Cấu trúc
Phương pháp Kiểm thử phần mềm
Outline
Khái niệm
Lý do cần kiểm thử phần mềm
Mục tiêu kiểm thử
Quan niệm sai
Basic Concepts in Testing Theory
Failure, Error, Fault and Defect
Nguyên tắc của việc hoàn thành kiểm thử
Adequacy of Testing
Giới hạn của kiểm thử
Test Planning and Design
Chính sách kiểm thử
Qui trình kiểm thử
Slide 15
Testing Levels
Phân chia giai đọan
System testing
Integration testing
Incremental integration testing
Testing approaches của integration testing
Release testing
Testing levels (detailed)
Testing levels (tiếp)
Performance testing
Stress testing
What is a Test Case?
Test case design
Structural testing
Slide 30
Binary search - equiv. partitions
Binary search equiv. partitions
Binary search - test cases
Binary search flow graph
Black-box testing
Black-box testing (tiếp)
Các kỹ thuật của Black-box testing
Requirements based testing
LIBSYS requirements
LIBSYS tests
Partition testing
Equivalence partitioning
Equivalence partitions
Search routine specification
Search routine - input partitions
Slide 46
Path testing
Independent paths
Test automation
A testing workbench
Testing workbench adaptation
Key points
Slide 53
Tài liệu tham khảo
Nội dung
Phương pháp Kiểm thử phầnmềm Outline Khái niệm kiểm thử Phương pháp thử Kỹ thuật thiết kế trường hợp thử Phương pháp thử môđun Khái niệm Kiểm thử phầnmềm hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phầnmềm môi trường chúng dự định triển khai nhằm cung cấp cho người có lợi ích liên quan thông tin chất lượng sản phẩm hay dịch vụ phầnmềm Mục đích kiểm thử phầnmềm tìm lỗi hay khiếm khuyết phầnmềm nhằm đảm bảo hiệu hoạt động tối ưu phầnmềm nhiều ngành khác Lý cần kiểm thử phầnmềm Mong muốn thu phầnmềmphần tử hệ thống hoạt động lớn Hạn chế chi phí phải trả cho thất bại lỗi gây sau Có kế hoạch tốt cho suốt trình phát triển Tầm quan trọng Kiểm thử chiếm: 40% tổng công sức phát triển >=30% tổng thời gian phát triển Với phầnmềm ảnh hưởng tới sinh mạng chi phí gấp từ dến lần tổng chi phí khác cộng lại Mục tiêu kiểm thử mục tiêu Kiểm thử trình vận hành chương trình để tìm lỗi Thiết kế ca kiểm thử Một ca kiểm thử tốt ca kiểm thử có xác suất cao việc tìm lỗi chưa phát Nghiên cứu thiết kế ca kiểm thử thắng lợi Một ca kiểm thử thắng lợi ca kiểm thử làm lộ lỗi chưa phát Một ca kiểm thử thắng lợi làm lộ khiếm khuyết, đồng thời mang lại lợi ích phụ: chứng tỏ chức phầm mềm làm việc tương ứng với đặc tả, chứng tỏ yêu cầu thực thi phù hợp có thêm số độ tin cậy phầnmềm số chất lượng phầnmềm nói chung Kiểm thử khơng thể chứng minh việc khơng có khiếm khuyết, chứng minh khiếm khuyết phầnmềm hữu Quan niệm sai Người phát triển không tham gia kiểm thử Phầnmềmcông bố cách rộng rãi để người lạ kiểm thử Kiểm thử chứng minh phầnmềm khơng có khiếm khuyết Phép kiểm thử thành cơng kiểm thử khơng tìm lỗi Chỉ cần kiểm thử lần Basic Concepts in Testing Theory Lý thuyết kiểm thử dựa nội dung: Phát khuyết tật qua trình chạy chương trình Thiết kế test case từ nguồn khác nhau: requirement specification, source code, and input and output domains of programs Lựa chọn tập test case từ toàn input domain Tình hiệu chiến lược lựa chọn liệu kiểm thử Test oracles sử dụng testing Có độ ưu tiên liệu test cases Phân tích tính đầy đủ test cases Failure, Error, Fault and Defect Failure Error An error is a state of the system An error state could lead to a failure in the absence of any corrective action by the system Fault A failure is said to occur whenever the external behavior of a system does not conform to that prescribed in the system specification A fault is the adjudged cause of an error Defect It is synonymous of fault It a.k.a bug Nguyên tắc việc hoàn thành kiểm thử Kiểm thử hoàn thành hay kiểm thử đầy đủ nghĩa “Khơng có lỗi chưa phát vào cuối giai đoạn kiểm thử” Kiểm thử hồn thành khó khả thi phần lớn hệ thống Vùng liệu inputs chương trình lớn Valid inputs Invalid inputs Thiết kế liệu kiểm thử hồn thành vấn đề phức tạp Khó khả thi vấn đề tạo môi trường để chạy thử hệ thống Adequacy of Testing Reality: New test cases, in addition to the planned test cases, are designed while performing testing Let the test set be T If a test set T does not reveal any more faults, we face a dilemma: P is fault-free OR T is not good enough to reveal (more) faults Need for evaluating the adequacy (i.e goodness) of T Some ad hoc stopping criteria Allocated time for testing is over It is time to release the product Test cases no more reveal faults LIBSYS tests Initiate user search for searches for items that are known to be present and known not to be present, where the set of databases includes database Initiate user searches for items that are known to be present and known not to be present, where the set of databases includes databases Initiate user searches for items that are known to be present and known not to be present where the set of databases includes more than databases Select one database from the set of databases and initiate user searches for items that are known to be present and known not to be present Select more than one database from the set of databases and initiate searches for items that are known to be present and known not to be present Partition testing Input data and output results often fall into different classes where all members of a class are related Each of these classes is an equivalence partition or domain where the program behaves in an equivalent way for each class member Test cases should be chosen from each partition Equivalence partitioning Invalid in pu t s Valid in pu t s Syst em Ou tpu ts Equivalence partitions Less t h an 11 10 Bet ween an d M ore t h an 01 N u m ber ofin pu t alu v es 9999 10000 Less t h an 0000 In pu t alu v es 50000 100000 99999 Bet ween 10000 an d 99999 M ore t h an 99999 Search routine specification procedure Search (Key : ELEM ; T: SEQ of ELEM; Found : in out BOOLEAN; L: in out ELEM_INDEX) ; Precondition the sequence has at least one element T’FIRST = i