Kiểm thử tích hợp ( Intergration Testing ) tập trung chuyên sâu vào kiểm tra tiếp xúc tài liệu giữa những mô-đun. Do đó, nó cũng được gọi là “ I&T ” ( Tích hợp và Kiểm tra ), “ Kiểm tra chuỗi ’ và đôi lúc chính là “ Kiểm tra luồng ” .
Đị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?
Bạn đang đọc: Kiểm thử phần mềm chuyên nghiệ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 cũng sẽ sống sót vì nhiều nguyên nhân 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 số 1 quán.
Kiểm thử phần mềm chuyên nghiệp ✅
Tại thời gian tăng trưởng mô-đun, cũng sẽ có nhiều lúc người mua đưa ra những đổi khác về nhu yếu. Các nhu yếu mới này hoàn toàn có thể cũng sẽ chưa đượ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ỗiGiao diện phần cứng bên ngoài, nếu có, hoàn toàn có thể bị lỗiXử lý những trường hợp ngoại lệ một cách chưa 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 các loại kiểm thử khác ở trên phương diện là nó tập trung chuyên sâu đa phần vào những giao diện , 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 công dụ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 chưa tập trung chuyên sâu nhiều vào kiểm tra Trang đăng nhập vì nó đã được thực thi 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 ) chính là một thử thách .Có nhiều lỗi về giao diện cần đã được kiểm thử theo biện 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 “ toàn bộ ” những mô-đun được phong cách thiết kế, nên nhóm thử nghiệm cũng sẽ có ít thời hạn thực thi hơn trong quy trình thử nghiệm .Vì toàn bộ 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. Những 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 công dụng thích hợp. Quá trình thường xuyên cho đến khi tổng thể những mô-đun được tham gia , và kiểm thử thành công xuất sắc. Phương Pháp 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 upPhương pháp Top DownPhương pháp Sandwich – Kết hợp đến từ trên xuống , đến từ dưới lên
2.1. Stub và Driver là gì vậy?
Phương pháp tiếp cận ngày càng tăng đã được thực thi 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 chưa liên quan gì đến nhau chính 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 số 1 của kiến trúc ứng dụng ) mà trấn áp luồng ứng dụng được kiểm tra sau 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 đến từ bắt đầu – là một điều chưa 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, cũng sẽ cần tới sự tương hỗ của Stubs 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 trở nên thuận tiện hơnXây dựng một bản mẫu ( prototype ) ngay đến từ bắt đầu chính 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à sửa chữa thay thế 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ử chưa vừa đủ .
2.4. Phương pháp Sandwich
Phương pháp SandwichPhương pháp sandwich / hybrid là sự phối hợp của giải pháp Top Down , và bottom up. Ở đây, những mô-đun nhất đượ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 nhất 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 ( đã tranh luận trên ) :
Chuẩn bị kế hoạch kiểm tra tích hợpThiết kế các kịch bản thử nghiệm, các trường hợp test và scriptsThực hiện các trường hợp kiểm thử tiếp theo chỉ bằng cách báo cáo các lỗiTheo dõi & kiểm tra lại các lỗiBướ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ư đã đàm đạo ở 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ụ , 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 , 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 , sau đó sẵn sàng chuẩn bị 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 , 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.
Trái Nghĩa Của Intact Là Gì, Intact Là Gì, Nghĩa Của Từ Intact
Có đã được những phong cách thiết kế giao diện đến từ nhóm Kiến trúc và tạo những trường hợp thử nghiệm để xác định chi tiết 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 sẵn sàng chuẩn bị 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ề Những chiêu thức kiểm thử