|
| Kiểm Thử Tích Hợp (Integration Testing) Là Gì? |
Kiểm thử tích hợp được định nghĩa là một loại kiểm thử trong đó các module phần mềm được tích hợp một cách logic và được kiểm tra như một nhóm. Một dự án phần mềm điển hình bao gồm nhiều module phần mềm, được lập trình bởi các lập trình viên khác nhau. Mục đích của mức kiểm thử này là phát hiện các lỗi trong quá trình tương tác giữa các module phần mềm khi chúng được tích hợp.
Kiểm thử tích hợp tập trung vào việc kiểm tra giao tiếp dữ liệu giữa các module. Do đó, nó còn được gọi là 'I & T' (Tích hợp và Kiểm thử), 'Kiểm thử chuỗi' và đôi khi là 'Kiểm thử luồng'.
Mục lục
Tại Sao Phải Thực Hiện Kiểm Thử Tích Hợp?
Mặc dù mỗi module phần mềm đã được kiểm thử đơn vị, nhưng các lỗi vẫn tồn tại vì nhiều lý do:
- Mỗi module thường được thiết kế bởi một nhà phát triển phần mềm riêng lẻ, với cách hiểu và logic lập trình có thể khác nhau. Kiểm thử tích hợp là cần thiết để xác minh các module hoạt động thống nhất.
- Trong quá trình phát triển module, khách hàng có thể thay đổi yêu cầu. Những yêu cầu mới này có thể chưa được kiểm thử đơn vị, do đó kiểm thử tích hợp hệ thống trở nên cần thiết.
- Các giao diện của module phần mềm với cơ sở dữ liệu có thể bị lỗi.
- Các giao diện phần cứng bên ngoài (nếu có) có thể bị lỗi.
- Việc xử lý ngoại lệ không đầy đủ có thể gây ra các vấn đề.
Ví Dụ Về Trường Hợp Kiểm Thử Tích Hợp
Trường hợp kiểm thử tích hợp khác với các trường hợp kiểm thử khác ở chỗ nó tập trung chủ yếu vào các giao diện và luồng dữ liệu/thông tin giữa các module. Ưu tiên là các điểm kết nối thay vì các chức năng đơn vị đã được kiểm tra.
Ví dụ: Một ứng dụng có 3 module: 'Trang Đăng Nhập', 'Hộp Thư' và 'Xóa Email', được tích hợp một cách logic.
Bảng trường hợp kiểm thử:
| ID Trường Hợp | Mục Tiêu | Mô Tả | Kết Quả Mong Đợi |
|---|---|---|---|
| 1 | Kiểm tra liên kết giao diện giữa module Đăng Nhập và Hộp Thư | Nhập thông tin đăng nhập và nhấp vào nút Đăng Nhập | Chuyển đến Hộp Thư |
| 2 | Kiểm tra liên kết giao diện giữa module Hộp Thư và Xóa Email | Chọn email từ Hộp Thư và nhấp nút xóa | Email đã chọn phải xuất hiện trong thư mục Đã Xóa/Thùng rác |
Các Loại Kiểm Thử Tích Hợp
Kỹ thuật phần mềm xác định các chiến lược thực hiện kiểm thử tích hợp:
- Big Bang Approach (Phương pháp Big Bang)
- Incremental Approach (Phương pháp Tăng Dần): được chia thành:
- Top Down Approach (Phương pháp Từ Trên Xuống0
- Bottom Up Approach (Phương pháp Từ Dưới Lên)
- Sandwich Approach (Phương pháp Sandwich): Kết hợp Từ Trên Xuống và Từ Dưới Lên
Kiểm Thử Big Bang
Kiểm thử Big Bang là một phương pháp kiểm thử tích hợp trong đó tất cả các thành phần hoặc module được tích hợp cùng một lúc và sau đó được kiểm tra như một đơn vị. Tập hợp các thành phần được coi như một thực thể trong quá trình kiểm thử. Nếu không phải tất cả các thành phần trong đơn vị đều hoàn thiện, quá trình tích hợp sẽ không thể thực hiện.
Ưu điểm:
- Thuận tiện cho các hệ thống nhỏ.
Nhược điểm:
- Khó xác định vị trí lỗi.
- Do số lượng giao diện cần kiểm tra lớn, một số liên kết giao diện có thể bị bỏ sót.
- 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ế, do đó nhóm kiểm thử sẽ có ít thời gian thực thi trong giai đoạn kiểm thử.
- Vì tất cả module được kiểm tra cùng một lúc, các module then chốt rủi ro cao không được cô lập và ưu tiên kiểm tra. Các module ngoại vi liên quan đến giao diện người dùng cũng không được cô lập và ưu tiên kiểm tra.
Kiểm Thử Tăng Dần
Trong phương pháp Kiểm thử Tăng Dần, việc kiểm thử được thực hiện bằng cách tích hợp hai hoặc nhiều module có liên quan logic với nhau, sau đó kiểm tra chức năng của ứng dụng. Tiếp theo, các module liên quan khác được tích hợp tăng dần và quá trình tiếp tục cho đến khi tất cả các module có liên quan logic được tích hợp và kiểm tra thành công.
Phương pháp Tăng Dần được thực hiện bằng hai phương thức:
- Bottom Up
- Top Down
Stub và Driver
Stub và Driver là các chương trình giả trong kiểm thử tích hợp được sử dụng để hỗ trợ hoạt động kiểm thử phần mềm. Các chương trình này đóng vai trò thay thế cho các module còn thiếu trong quá trình kiểm thử. Chúng không triển khai toàn bộ logic lập trình của module phần mềm nhưng mô phỏng giao tiếp dữ liệu với module gọi trong quá trình kiểm thử.
- Stub: Được gọi bởi Module đang được Kiểm thử.
- Driver: Gọi Module sẽ được kiểm thử.
Kiểm Thử Tích Hợp Bottom-up
Kiểm thử tích hợp Bottom-up là một chiến lược trong đó các module ở mức thấp nhất được kiểm tra trước. Các module đã được kiểm tra này sau đó được sử dụng để hỗ trợ việc kiểm thử các module ở mức cao hơn. Quá trình tiếp tục cho đến khi tất cả các module ở mức trên cùng được kiểm tra.
Ưu điểm:
- Việc xác định vị trí lỗi dễ dàng hơn.
- Không mất thời gian chờ đợi tất cả các module được phát triển như phương pháp Big Bang.
Nhược điểm:
- Các module then chốt (ở mức trên cùng của kiến trúc phần mềm) điều khiển luồng ứng dụng được kiểm tra cuối cùng và có thể dễ bị lỗi.
- Không thể tạo nguyên mẫu sớm.
Kiểm Thử Tích Hợp Top-down
Kiểm thử tích hợp từ trên xuống là phương pháp trong đó việc kiểm thử tích hợp diễn ra từ trên xuống theo luồng điều khiển của hệ thống phần mềm. Các module ở mức cao được kiểm tra trước, sau đó các module ở mức thấp hơn được kiểm tra và tích hợp để kiểm tra chức năng phần mềm. Stub được sử dụng để kiểm tra nếu một số module chưa sẵn sàng.
Ưu điểm:
- Việc xác định vị trí lỗi dễ dàng.
- Khả năng tạo nguyên mẫu sớm.
- Các module then chốt được ưu tiên kiểm tra; các khuyết điểm thiết kế lớn có thể được phát hiện và sửa chữa trước.
Nhược điểm:
- Cần nhiều Stub.
- Các module ở mức thấp được kiểm tra không đầy đủ.
Kiểm Thử Sandwich
Kiểm thử Sandwich là một chiến lược trong đó các module ở mức trên được kiểm tra với các module ở mức thấp đồng thời các module ở mức thấp được tích hợp với các module ở mức trên và được kiểm tra như một hệ thống. Đây là sự kết hợp của các phương pháp Từ Trên Xuống và Từ Dưới Lên, do đó được gọi là Kiểm thử Tích hợp Lai. Nó sử dụng cả Stub và Driver.
Cách Thực Hiện Kiểm Thử Tích Hợp
Quy trình kiểm thử tích hợp bất kể các chiến lược kiểm thử phần mềm:
- Chuẩn bị Kế hoạch Kiểm thử Tích hợp
- Thiết kế Kịch bản, Trường hợp và Kịch bản kiểm thử
- Thực thi các trường hợp kiểm thử và báo cáo lỗi
- Theo dõi và kiểm tra lại các lỗi
- Lặp lại các bước 3 và 4 cho đến khi việc Tích hợp hoàn thành thành công
Tiêu Chí Đầu Vào và Đầu Ra của Kiểm Thử Tích Hợp
Tiêu Chí Đầu Vào:
- Các thành phần/module đã được kiểm thử đơn vị
- Tất cả các lỗi ưu tiên cao đã được sửa và đóng
- Tất cả các module đã hoàn thành mã và tích hợp thành công
- Kế hoạch, trường hợp và kịch bản kiểm thử tích hợp đã được ký và ghi lại
- Môi trường kiểm thử cần thiết đã được thiết lập
Tiêu Chí Đầu Ra:
- Kiểm thử thành công của Ứng dụng Tích hợp
- Các trường hợp kiểm thử đã thực thi được ghi lại
- Tất cả các lỗi ưu tiên cao đã được sửa và đóng
- Tài liệu kỹ thuật được nộp kèm theo Ghi chú phát hành
Các Phương Pháp Hay / Hướng Dẫn cho Kiểm Thử Tích Hợp
- Đầu tiên, xác định Chiến lược Kiểm thử Tích hợp có thể áp dụng, sau đó chuẩn bị các trường hợp kiểm thử và dữ liệu kiểm thử tương ứng
- Nghiên cứu thiết kế kiến trúc của Ứng dụng và xác định các Module Then chốt. Những module này cần được ưu tiên kiểm tra
- Lấy các thiết kế giao diện từ nhóm Kiến trúc và tạo các trường hợp kiểm thử để xác minh chi tiết tất cả các giao diện. Giao diện với cơ sở dữ liệu/phần cứng bên ngoài/ứng dụng phần mềm phải được kiểm tra kỹ lưỡng
- Sau các trường hợp kiểm thử, dữ liệu kiểm thử đóng vai trò quan trọng
- Luôn chuẩn bị sẵn dữ liệu mô phỏng trước khi thực thi. Không chọn dữ liệu kiểm thử trong quá trình thực thi các trường hợp kiểm thử
