Integration Testing Là Gì (Kiểm Thử Tích Hợp Là Gì ?)

Integration Testing là gì? Tại sao cần phải Integration Testing? Các Phương pháp tiếp cận, chiến lược của Integration Testing…Và để hiểu rõ hơn về loại kiểm thử này Techacademy sẽ giới thiệu với các bạn một chút về Integration Testing.

I. Integration Test Là Gì

• Kiểm thử tích hợp (Integration testing) hay còn gọi là tích hợp và kiểm thử (integration and testing, viết tắt: I&T) là 1 giai đoạn trong kiểm thử phần mềm. Mỗi môđun phần mềm riêng biệt được kết hợp lại và kiểm thử theo nhóm.
• Kiểm thử tích hợp xảy ra sau kiểm thử đơn vị (Unit Test) và trước kiểm thử xác nhận. Kiểm thử tích hợp nhận các môđun đầu vào đã được kiểm thử đơn vị, nhóm chúng vào những tập hợp lớn hơn, áp dụng các ca kiểm thử đã được định nghĩa trong kế hoạch kiểm thử tích hợp vào tập hợp đó, và cung cấp đầu ra cho hệ thống tích hợp.

II. Integration Test Có Mục Tiêu Chính Là Gì

Intergration test có mục đích là cho ra hai ứng dụng tốt nhất, mượt mà nhất mà người dùng cần đến. Từ đó, loại bỏ được các Bug cũng như những nguy cơ có thể xảy ra gây ra lỗi cho hệ điều hành trước khi chuyển đến tay người tiêu dùng. Chắc chắn rằng, bất kỳ hệ điều hành nào cũng mong muốn rằng mình có thể đạt được các chất lượng tốt nhất.

Mà muốn đạt được những điều đó thì buộc bạn phải trải nghiệm qua 3 bài đánh giá vô cùng quan trọng và nó có tên đại diện chính là Integration testing. Đây là một thuật ngữ đã được viết tắt bởi I&T và còn được hiểu là ý nghĩa kiểm thử và trang bị. Integration test là giai đoạn quan trọng không thể thiểu để bảo đảm hiệu quả cho hệ điều hành, trong khi đó thì các mô đun thường sẽ được trang bị phần mềm riêng và được đánh giá dựa theo từng nhóm.

Đây được xem là một trong những quá trình trung gian nằm giữa bài kiểm tra Unit Testing các thủ tục sử dụng cũng như vận hành cho các công ty nguồn hoặc Acceptance test. Đây là một dạng kiểm thử xác nhận, ở đó thì tester và khách hàng sẽ có khả năng kiểm thử tại địa chỉ thiết kế phần mềm rồi đánh giá hầu hết tính năng của phần mềm này sau khi chuyển hướng hoạt động về nền tảng của họ.

III. Tại Sạo Lại Phải Thực Hiện Kiểm Thử Tích Hợp

Mặc dù mỗi module đều được unit test nhưng các lỗi vẫn còn tồn tại với những lý do khác nhau:

• Một Module nói chung được thiết kế bởi một lập trình viên có hiểu biết và logic lập trình 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 để bảo đảm tính hợp nhất của phần mềm.
• Tại thời điểm phát triển module vẫn có thể có đổi thay trong spec của khách hàng, những thay đổi này có thể không được kiểm tra ở giai đoạn unit test trước đó.
• Giao diện và cơ sở dữ liệu của các module có thể chưa hoàn chỉnh lúc được ghép lại
• Khi tích hợp hệ thống các module có thể không tương thích với cấu hình chugn của hệ thống
• Thiếu các xử lý ngoại lệ có thể xảy ra

IV. Ví Dụ Về Kiểm Thử Tích Hợp

Giả sử bạn làm việc cho 1 tổ chức CNTT đã được yêu cầu phát triển trang web mua sắm trực tuyến cho Camp World, một công ty bán dụng cụ cắm trại. Sau khi thu thập yêu cầu, phân tích và thiết kế hoàn tất, một nhà phát triển đã được chỉ định để phát triển từng mô-đun bên dưới.

• Đăng ký và xác thực người dùng / Đăng nhập
• Danh mục sản phẩm
• Giỏ hàng
• Thanh toán
• Tích hợp cổng thanh toán
• Theo dõi vận chuyển và gói hàng

Sau khi mỗi mô-đun được gán cho nhà phát triển, nhà phát triển bắt đầu mã hóa chức năng trên những máy riêng lẻ của họ. Họ đã triển khai các mô-đun tương ứng trên các máy của mình để xem những gì đã hoạt động và những gì đã làm, khi họ bắt đầu phát triển mô-đun.

Sau khi họ hoàn thành việc phát triển, các nhà phát triển đã kiểm tra các chức năng cá nhân của họ như là một phần của kiểm thử đơn vị của họ và tìm thấy một số khiếm khuyết. Họ đã sửa những khuyết điểm này. Tại thời điểm này, họ cảm thấy các mô-đun của họ đã hoàn thành.

Kiểm tra tích hợp nên được thực hiện để xác nhận rằng tất cả các mô-đun hoạt động cùng nhau. Khi họ triển khai tất cả mã của họ trong một máy chung, họ thấy rằng ứng dụng không hoạt động như mong đợi vì các mô-đun riêng lẻ không hoạt động tốt với nhau. Có một số lỗi như – sau khi đăng nhập, giỏ hàng của người dùng không hiển thị các mục họ đã thêm trước đó, số tiền hóa đơn không bao gồm chi phí vận chuyển, v.v.

Theo cách này, Kiểm thử tích hợp giúp chúng ta xác định, khắc phục các sự cố và bảo đảm rằng hầu hết ứng dụng hoạt động như mong đợi.

V. Cách Tiếp Cận, Phương Pháp, Chiến Lược Của Kiểm Thử Tích Hợp

Có 2 cách tiếp cận trong Kiểm thử tích hợp:

+ Cách tiếp cận Big Bang:

+ Cách tiếp cận tăng dần (Incremental), được chia thành các cách sau:

1. Cách tiếp cận từ trên xuống (Top Down)
2. Cách tiếp cận từ dưới lên (Bottom Up)
3. Phương pháp tiếp cận Sandwich – Kết hợp từ trên xuống và từ dưới lên

Dưới đây là các chiến lược, cách thực hiện và những ưu điểm cũng như những nhược điểm của chúng.

Cách tiếp cận Big Bang

Tất cả các thành phần được tích hợp cùng 1 lúc, sau ấy tiến hành kiểm thử.

Ưu điểm:

Thuận tiện cho các hệ thống nhỏ.

Nhược điểm:

• Khó khăn trong việc phát hiện bug.
• Với số lượng giao diện cần được kiểm thử theo phương pháp này, một số giao diện liên kết cần kiểm thử có thể dễ dàng bị bỏ qua.
• Vì kiểm thử Tích hợp chỉ có thể bắt đầu sau khi tất cả các module được thiết kế, nên nhóm kiểm thử sẽ có ít thời gian thực hiện hơn trong giai đoạn kiểm thử.
• Vì tất cả các module được kiểm thử đồng thời, các module quan trọng có rủi ro cao không bị cô lập và được ưu tiên kiểm thử. Các module có liên quan tới giao diện người dùng cũng không bị cô lập và được ưu tiên kiểm thử.

Cách tiếp cận tăng dần

Trong cách này, kiểm thử được thực hiện bằng cách ghép hai hoặc nhiều module có liên quan đến logic. Sau đó, các module liên quan khác được thêm vào và kiểm thử chức năng thích hợp. Quá trình tiếp tục cho đến khi tất cả các module được thêm và hoàn thành quá trình kiểm thử.

Cách tiếp cận tăng dần được thực hiện bởi hai Phương pháp khác nhau:

• Từ dưới lên (Bottom Up)
• Từ trên xuống (Top Down)

Stub và Driver là gì?

Phương pháp tiếp cận tăng dần được thực hiện bằng cách sử dụng các chương trình giả lập là Stub và Driver. Stub và Driver không thực hiện toàn bộ logic của module mà chỉ mô phỏng kết nối dữ liệu với module đang được gọi.

Stub: Được gọi bởi module đang kiểm thử.

Driver: Gọi module để được kiểm thử.

Tích hợp từ dưới lên

Trong cách tích hợp từ dưới lên, mỗi module ở các cấp thấp hơn được kiểm thử với các module cao hơn cho đến khi tất cả các module được kiểm thử. Tích hợp từ dưới lên cần sự hỗ trợ của Driver để kiểm thử

Sơ đồ biểu diễn cách tiếp cận từ dưới lên:

Ưu điểm:

• Việc phát hiện lỗi dễ dàng hơn.
• Không bị lãng phí thời gian chờ đợi tất cả các module được xây dựng, không giống như phương pháp Big-bang

Nhược điểm:

• Các module quan trọng (ở cấp cao nhất của kiến ​​trúc phần mềm) có luồng điều khiển được kiểm thử lần cuối nên dễ bị sót lỗi.
• Thực hiện kiểm thử tích hợp từ dưới lên từ sớm là không thể

Tích hợp từ trên xuống

Trong cách tiếp cận từ trên xuống, kiểm thử diễn ra từ trên xuống dưới theo luồng điều khiển của hệ thống phần mềm. Cần sự hỗ trợ của Stub để kiểm thử.

Sơ đồ biểu diễn cách tiếp cận từ trên xuống:

Ưu điểm:

• Việc phát hiện lỗi dễ dàng hơn.
• Có khả năng thực hiện tích hợp từ trên xuống từ sớm.
• Các module quan trọng được ưu tiên kiểm thử; lỗi thiết kế quan trọng có thể được tìm thấy và sửa chữa đầu tiên.

Nhược điểm:

• Cần nhiều Stub.
• Các module ở mức thấp hơn không được kiểm thử đầy đủ.

Tích hợp Hybrid/ Sandwich

Chiến lược sandwich / hybrid là sự kết hợp của phương pháp Top Down và Bottom up. Các module trên cùng được kiểm thử cùng thời điểm với các module thấp hơn, đồng thời các module thấp hơn được tích hợp với các module ở trên và được thực hiện kiểm thử. Chiến lược này sử dụng Stubs cũng như Drivers.

VI. Sự Khác Nhau Giữa Integration Test Và System Test