Tóm Tắt
Định nghĩa
KIỂM THỬ TÍCH HỢP được định nghĩa là một loại kiểm thử trong đó những mô-đun ( modules ) ứng dụng được tích hợp một cách hài hòa và hợp lý và được thử nghiệm dưới dạng một nhóm. Một dự án Bất Động Sản ứng dụng điển hình bao gồm nhiều mô-đun ứng dụng, được mã hóa bởi những lập trình viên khác nhau. Mục đích của Lever kiểm tra này là để lộ ra những khiếm khuyết ( lỗi ) trong tương tác giữa những mô-đun ứng dụng khi chúng được tích hợp với nhau .
Vị trí của kiểm thử tích hợp
2. Tại sao phải kiểm tra tích hợp?
Mặc dù từng mô-đun ứng dụng sẽ được Unit Test ( kiểm thử đơn vị chức năng ), nhưng lỗi vẫn sẽ sống sót vì nhiều nguyên do như :
Một mô-đun, nhìn chung, được thiết kế bởi một nhà phát triển phần mềm độc lập mà có sự hiểu biết và lập trình logic có thể khác với các lập trình viên khác. Kiểm thử tích hợp là cần thiết để xác minh các mô-đun phần mềm hoạt động cùng nhau một cách nhất quán.
- Tại thời gian tăng trưởng mô-đun, sẽ có nhiều lúc người mua đưa ra những biến hóa về nhu yếu. Các nhu yếu mới này hoàn toàn có thể sẽ không được Unit Test ( kiểm thử đơn vị chức năng ) và do đó Kiểm thử tích hợp mạng lưới hệ thống trở nên thiết yếu .
- Các giao diện của những mô-đun ứng dụng cùng với cơ sở tài liệu hoàn toàn có thể sẽ bị lỗi
- Giao diện phần cứng bên ngoài, nếu có, hoàn toàn có thể bị lỗi
- Xử lý những trường hợp ngoại lệ một cách không tương thích hoàn toàn có thể gây ra những yếu tố khác
3. Ví dụ về trường hợp kiểm thử tích hợp
Test cases của Kiểm thử tích hợp cũng khác so với những loại kiểm thử khác trên phương diện là nó tập trung chuyên sâu hầu hết vào những giao diện và luồng tài liệu / thông tin giữa những mô-đun. Các link tích hợp được ưu tiên để đưa ra thay vì những tính năng đơn vị chức năng mà đã được kiểm thử .Test cases mẫu cho việc Kiểm thử tích hợp sẽ đi theo những ngữ cảnh sau : Ứng dụng mà có 3 mô-đun ‘ Trang đăng nhập ’, ‘ Hộp thư ’ và ‘ Xóa email ’ và mỗi mô-đun được tích hợp một cách hài hòa và hợp lý .Ở đây không tập trung chuyên sâu nhiều vào kiểm tra Trang đăng nhập vì nó đã được triển khai trong Unit Test ( kiểm thử đơn vị chức năng ). Nhưng hãy kiểm tra xem nó được link với Trang Hộp thư như thế nào .Tương tự với Hộp thư : Kiểm tra sự tích hợp của nó với Mô-đun Xóa Thư .
Test case của việc xóa thư
Các phương pháp kiểm tra tích hợp
Các kỹ sư ứng dụng hoàn toàn có thể xác lập những kế hoạch để triển khai Kiểm thử tích hợp như :
1. Phương pháp Big Bang:
Theo cách này, tổng thể những thành phần được tích hợp với nhau cùng một lúc và sau đó được kiểm thử .* Ưu điểm : Thuận tiện cho những mạng lưới hệ thống nhỏ .* Nhược điểm :
- Kiểm tra lỗi nội địa hóa ( Localization ) là một thử thách .
- Có nhiều lỗi về giao diện cần được kiểm thử theo giải pháp này, 1 số ít link giao diện cần kiểm thử hoàn toàn có thể thuận tiện bị bỏ lỡ .
- Vì Kiểm thử Tích hợp chỉ hoàn toàn có thể mở màn sau khi “ tổng thể ” những mô-đun được phong cách thiết kế, nên nhóm thử nghiệm sẽ có ít thời hạn thực thi hơn trong tiến trình thử nghiệm .
- Vì tổng thể những mô-đun được kiểm tra cùng một lúc, những mô-đun quan trọng có rủi ro đáng tiếc cao không được ưu tiên hay kiểm tra riêng. Các mô-đun ngoại vi tương quan đến giao diện người dùng cũng không được ưu tiên hay kiểm tra riêng .
2. Phương pháp gia tăng:
Trong chiêu thức này, thực thi kiểm thử bằng cách nối hai hoặc nhiều mô-đun có tương quan đến logic. Sau đó, những mô-đun tương quan khác được thêm vào và được kiểm tra tính năng thích hợp. Quá trình liên tục cho đến khi toàn bộ những mô-đun được tham gia và kiểm thử thành công xuất sắc. Cách tiếp cận ngày càng tăng được thực thi bởi hai Phương pháp khác nhau :
- Phương pháp Bottom up
- Phương pháp Top Down
- Phương pháp Sandwich – Kết hợp từ trên xuống và từ dưới lên
2.1. Stub và Driver là gì?
Phương pháp tiếp cận ngày càng tăng được triển khai bằng cách sử dụng những chương trình giả có tên là Stub và Driver. Stub và Driver không triển khai hàng loạt logic lập trình của mô-đun ứng dụng mà chỉ mô phỏng tiếp xúc tài liệu bằng cách gọi module .Stub : Được gọi bởi Mô-đun đang được kiểm thử. Driver : Gọi Mô-đun để được kiểm tra .
2.2. Phương pháp Bottom up:
Phương pháp Bottom UpTrong Phương pháp Bottom up, mỗi mô-đun ở những cấp thấp hơn được kiểm tra với những mô-đun cao hơn cho đến khi tổng thể những mô-đun được kiểm tra. Lúc này, sẽ cần tới sự tương hỗ của Driver trong việc kiểm thử .Biểu đồ trình diễn :
*Ưu điểm:
- Việc tìm kiếm bug trong từng module riêng không liên quan gì đến nhau là một thử thách .
- Không có thời hạn bị tiêu tốn lãng phí khi chờ đón toàn bộ những mô-đun được tăng trưởng ( không giống như chiêu thức Big-bang )
* Nhược điểm :
- Các mô-đun quan trọng ( ở cấp cao nhất của kiến trúc ứng dụng ) mà trấn áp luồng ứng dụng được kiểm tra ở đầu cuối và hoàn toàn có thể dễ bị lỗi .
- Xây dựng một bản mẫu ( prototype ) ngay từ bắt đầu – là một điều không hề
2.3. Phương pháp Top Down:
Phương pháp Top DownTrong Phương pháp Top Down, việc kiểm thử diễn ra từ trên xuống dưới theo luồng tinh chỉnh và điều khiển của mạng lưới hệ thống ứng dụng. Lúc này, sẽ cần tới sự tương hỗ của Stubs trong việc kiểm thử .Biểu đồ màn biểu diễn :* Ưu điểm :
- Việc tìm kiếm bug trong từng module riêng không liên quan gì đến nhau trở nên thuận tiện hơn
- Xây dựng một bản mẫu ( prototype ) ngay từ khởi đầu là hoàn toàn có thể
- Các mô-đun quan trọng được kiểm thử ưu tiên ; lỗi phong cách thiết kế chính hoàn toàn có thể được tìm thấy và thay thế sửa chữa trước
* Nhược điểm :
- Cần nhiều Stubs .
- Các mô-đun ở mức thấp hơn được kiểm thử không khá đầy đủ .
2.4. Phương pháp Sandwich
Phương pháp SandwichPhương pháp sandwich / hybrid là sự tích hợp của giải pháp Top Down và bottom up. Ở đây, những mô-đun số 1 được kiểm tra với những mô-đun thấp hơn đồng thời những mô-đun thấp hơn được tích hợp với những mô-đun số 1 và được kiểm thử. Chiến lược này sử dụng cả Stubs cũng như Drivers .
Làm thế nào để kiểm thử tích hợp?
Quy trình kiểm thử tích hợp bất kể kế hoạch kiểm thử ứng dụng ( đã luận bàn ở trên ) :
- Chuẩn bị kế hoạch kiểm tra tích hợp
- Thiết kế các kịch bản thử nghiệm, các trường hợp test và scripts
- Thực hiện các trường hợp kiểm thử tiếp theo bằng cách báo cáo các lỗi
- Theo dõi & kiểm tra lại các lỗi
- Bước 3 và 4 được lặp lại cho đến khi hoàn thành Tích hợp thành công.
1. Mô tả tóm tắt về kế hoạch kiểm thử tích hợp:
Nó gồm có những thuộc tính sau :
- Phương pháp / Phương pháp kiểm tra ( như đã luận bàn ở trên ) .
- Phạm vi và những vùng ngoài khoanh vùng phạm vi của kiểm thử tích hợp .
- Vai trò và nghĩa vụ và trách nhiệm .
- Điều kiện tiên quyết để thử nghiệm tích hợp .
- Môi trường thử nghiệm .
- Rủi ro và kế hoạch giảm thiểu rủi ro đáng tiếc
2. Hướng dẫn kiểm thử tích hợp
- Đầu tiên, xác lập Chiến lược kiểm thử tích hợp mà hoàn toàn có thể được trải qua và sau đó chuẩn bị sẵn sàng những Test cases và tài liệu kiểm thử cho tương thích .
Nghiên cứu thiết kế Kiến trúc của Ứng dụng và xác định các Mô-đun quan trọng. Những điều này cần phải được kiểm thử trước tiên.
- Có được những phong cách thiết kế giao diện từ nhóm Kiến trúc và tạo những trường hợp thử nghiệm để xác định cụ thể tổng thể những giao diện. Giao diện với cơ sở tài liệu / ứng dụng phần cứng / ứng dụng bên ngoài phải được kiểm tra chi tiết cụ thể .
- Luôn chuẩn bị sẵn sàng mock data trước khi triển khai test. Không nên chọn tài liệu kiểm tra trong khi triển khai những trường hợp kiểm tra .
Ngoài ra, bạn hoàn toàn có thể tìm hiểu và khám phá về Các giải pháp kiểm thử
Source: https://final-blade.com
Category : Kiến thức Internet
