Kiểm thử tích hợp là gì?
KIỂM TRA TÍCH HỢP được định nghĩa là một loại kiểm thử trong đó các mô-đun 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 mô-đun phần mềm, được mã hóa bởi các lập trình viên khác nhau. Mục đích của mức độ kiểm tra này là để lộ ra các khiếm khuyết trong sự tương tác giữa các mô-đun phần mềm này 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 mô-đun này. Do đó, nó còn được gọi là 'I & T' (Tích hợp và thử nghiệm), 'Kiểm tra chuỗi' và đôi khi là 'Kiểm tra luồng' .
- Kiểm thử tích hợp là gì?
- Tại sao phải kiểm tra tích hợp?
- Ví dụ về trường hợp kiểm tra tích hợp
- Phương pháp tiếp cận, chiến lược, phương pháp luận của kiểm tra tích hợp
- Cách tiếp cận Big Bang:
- Cách tiếp cận gia tăng
- Stub và Driver là gì?
- Tích hợp từ dưới lên
- Tích hợp từ trên xuống:
- Tích hợp Hybrid / Sandwich
- Làm thế nào để thực hiện Kiểm tra tích hợp?
- Mô tả ngắn gọn về kế hoạch kiểm tra tích hợp:
- Tiêu chí đầu vào và thoát ra của thử nghiệm tích hợp
- Các nguyên tắc / Thực tiễn Tốt nhất cho Kiểm tra Tích hợp
Tại sao phải kiểm tra tích hợp?
Mặc dù mỗi mô-đun phần mềm đều được kiểm tra đơn vị, nhưng các lỗi vẫn tồn tại vì nhiều lý do như
- Nói chung, một Mô-đun được thiết kế bởi một nhà phát triển phần mềm cá nhân mà sự 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 trở nên cần thiết để xác minh các mô-đun phần mềm hoạt động thống nhất
- Tại thời điểm phát triển mô-đun, có rất nhiều cơ hội thay đổi các yêu cầu của khách hàng. Các yêu cầu mới này có thể không được kiểm thử đơn vị và do đó việc kiểm tra tích hợp hệ thống trở nên cần thiết.
- Giao diện của các mô-đun 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
- Xử lý ngoại lệ không thích hợp có thể gây ra sự cố.
Bấm vào đây nếu video không thể truy cập được
Ví dụ về trường hợp kiểm tra tích hợp
Integration Test Case 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 & luồng dữ liệu / thông tin giữa các mô-đun . Ở đây ưu tiên dành cho các liên kết tích hợp hơn là các chức năng đơn vị đã được thử nghiệm.
Các trường hợp kiểm tra tích hợp mẫu cho tình huống sau: Ứng dụng có 3 mô-đun nói rằng '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ợp lý.
Ở đây không tập trung nhiều vào kiểm tra Trang đăng nhập vì nó đã được thực hiện trong Kiểm thử đơn vị. Nhưng hãy kiểm tra cách nó được liên kết với Trang Hộp thư.
Tương tự Hộp thư: Kiểm tra sự tích hợp của nó với Mô-đun Xóa Thư.
| ID trường hợp thử nghiệm | Mục tiêu trường hợp thử nghiệm | Mô tả trường hợp thử nghiệm | Kết quả mong đợi |
|---|---|---|---|
| 1 | Kiểm tra liên kết giao diện giữa mô-đun Đă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 | Để được chuyển đến Hộp thư |
| 2 | Kiểm tra liên kết giao diện giữa Hộp thư và Mô-đun Xóa Thư | Từ Hộp thư, chọn email và nhấp vào nút xóa | Email đã chọn sẽ xuất hiện trong thư mục Đã xóa / Thùng rác |
Phương pháp tiếp cận, chiến lược, phương pháp luận của kiểm tra tích hợp
Kỹ thuật phần mềm xác định nhiều chiến lược khác nhau để thực hiện kiểm thử Tích hợp, viz.
- Cách tiếp cận Big Bang:
- Phương pháp tiếp cận gia tăng: được chia thành nhiều cách sau
- Phương pháp tiếp cận từ trên xuống
- Phương pháp tiếp cận từ dưới lên
- 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 khác nhau, cách chúng được thực hiện và những hạn chế cũng như ưu điểm của chúng.
Thử nghiệm Big Bang
Kiểm thử Big Bang là một cách tiếp cận kiểm thử Tích hợp trong đó tất cả các thành phần hoặc mô-đun được tích hợp với nhau 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 kết hợp này được coi là một thực thể trong khi thử nghiệm. Nếu tất cả các thành phần trong đơn vị không được hoàn thành, quá trình tích hợp sẽ không thực thi.
Ưu điểm:
- Thuận tiện cho các hệ thống nhỏ.
Nhược điểm:
- Bản địa hóa lỗi rất khó.
- Với số lượng lớn các giao diện cần được kiểm tra trong cách tiếp cận này, một số liên kết giao diện cần được kiểm tra có thể bị bỏ sót một cách dễ dàng.
- Vì thử nghiệm Tích hợp chỉ có thể bắt đầu sau khi "tất cả" các mô-đun được thiết kế, nhóm thử nghiệm sẽ có ít thời gian hơn để thực hiện trong giai đoạn thử nghiệm.
- Vì tất cả các mô-đun đều được kiểm tra cùng một lúc, nên các mô-đun quan trọng có rủi ro cao không bị cô lập và được kiểm tra theo thứ tự ưu tiên. Các mô-đun ngoại vi xử lý giao diện người dùng cũng không bị cô lập và được kiểm tra ưu tiên.
Thử nghiệm gia tăng
Trong phương pháp Thử nghiệm gia tăng , thử nghiệm được thực hiện bằng cách tích hợp hai hoặc nhiều mô-đun có liên quan đến nhau về mặt logic và sau đó được kiểm tra để ứng dụng hoạt động bình thường. Sau đó, các mô-đun liên quan khác được tích hợp từng bước và quá trình tiếp tục cho đến khi tất cả các mô-đun liên quan đến logic được tích hợp và thử nghiệm thành công.
Đến lượt mình, Phương pháp Tiếp cận Gia tăng được thực hiện bằng hai Phương pháp khác nhau:
- Từ dưới lên
- Từ trên xuống
Stubs và trình điều khiển
Stubs và Drivers 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 hoạt động như một sự thay thế cho các mô hình bị thiếu trong thử nghiệm. Chúng không thực hiện toàn bộ logic lập trình của mô-đun phần mềm nhưng chúng mô phỏng giao tiếp dữ liệu với mô-đun gọi trong khi thử nghiệm.
Stub : Được gọi bởi Mô-đun đang Kiểm tra.
Trình điều khiển : Gọi Mô-đun được kiểm tra.
Kiểm tra tích hợp từ dưới lên
Kiểm tra tích hợp từ dưới lên là một chiến lược trong đó các mô-đun cấp thấp hơn được kiểm tra trước. Sau đó, các mô-đun đã thử nghiệm này được tiếp tục sử dụng để tạo điều kiện thuận lợi cho việc thử nghiệm các mô-đun cấp cao hơn. Quá trình tiếp tục cho đến khi tất cả các mô-đun ở cấp cao nhất được kiểm tra. Sau khi các mô-đun cấp thấp hơn được kiểm tra và tích hợp, thì cấp độ tiếp theo của các mô-đun sẽ được hình thành.
Biểu diễn theo sơ đồ :
Ưu điểm:
- Bản địa hóa lỗi dễ dàng hơn.
- Không lãng phí thời gian chờ đợi tất cả các mô-đun được phát triển không giống như cách tiếp cận Big-bang
Nhược điểm:
- Các mô-đun quan trọng (ở cấp cao nhất của kiến trúc phần mềm) kiểm soát luồng ứng dụng được kiểm tra lần cuối và có thể dễ bị lỗi.
- Một nguyên mẫu ban đầu là không thể
Kiểm tra tích hợp từ trên xuống
Kiểm thử tích hợp từ trên xuống là một phương pháp trong đó kiểm thử tích hợp 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ác mô-đun cấp cao hơn được kiểm tra đầu tiên và sau đó các mô-đun cấp thấp hơn được kiểm tra và tích hợp để kiểm tra chức năng phần mềm. Stubs được sử dụng để kiểm tra nếu một số mô-đun chưa sẵn sàng.
Biểu diễn theo sơ đồ:
Ưu điểm:
- Bản địa hóa lỗi dễ dàng hơn.
- Khả năng có được một nguyên mẫu sớm.
- Các Mô-đun quan trọng được kiểm tra theo mức độ ưu tiên; Các lỗi thiết kế lớn có thể được tìm thấy và sửa chữa trước.
Nhược điểm:
- Cần nhiều Stub.
- Các mô-đun ở cấp độ thấp hơn được kiểm tra không đầy đủ.
Thử nghiệm bánh sandwich
Kiểm thử Sandwich là một chiến lược trong đó các mô-đun cấp cao nhất được kiểm tra với các mô-đun cấp thấp hơn đồng thời các mô-đun thấp hơn được tích hợp với các mô-đun hàng đầu và được kiểm tra như một hệ thống. Nó là sự kết hợp của các cách tiếp cận Từ trên xuống và Từ dưới lên, do đó nó được gọi là Thử nghiệm tích hợp kết hợp . Nó sử dụng cả phần sơ khai cũng như trình điều khiển.
Làm thế nào để thực hiện Kiểm tra tích hợp?
Quy trình kiểm tra tích hợp bất kể chiến lược kiểm thử Phần mềm (đã thảo luận ở trên):
- Chuẩn bị Kế hoạch Kiểm tra Tích hợp
- Thiết kế các tình huống, trường hợp và tập lệnh thử nghiệm.
- Thực hiện các trường hợp kiểm tra sau đó là báo cáo các khiếm khuyết.
- Theo dõi và kiểm tra lại các khiếm khuyết.
- Các 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.
Mô tả ngắn gọn về kế hoạch kiểm tra tích hợp:
Nó bao gồm các thuộc tính sau:
- Phương pháp / Cách tiếp cận để kiểm tra (như đã thảo luận ở trên).
- Phạm vi và Ngoài phạm vi Các hạng mục của Kiểm thử tích hợp.
- Vai trò và trách nhiệm.
- Điều kiện tiên quyết để kiểm tra Tích hợp.
- Môi trường thử nghiệm.
- Kế hoạch giảm thiểu và rủi ro.
Tiêu chí đầu vào và thoát ra của thử nghiệm tích hợp
Tiêu chí đầu vào và thoát giai đoạn thử nghiệm tích hợp trong bất kỳ mô hình phát triển phần mềm nào
Tiêu chuẩn nhập cảnh:
- Đơn vị đã kiểm tra các thành phần / mô-đun
- Tất cả các lỗi được ưu tiên cao đã được sửa và đóng
- Tất cả các Mô-đun được hoàn thành mã và tích hợp thành công.
- Kiểm thử tích hợp Kế hoạch, trường hợp thử nghiệm, các tình huống được ký kết và lập thành văn bản.
- Môi trường kiểm tra bắt buộc phải được thiết lập để kiểm tra tích hợp
Tiêu chí thoát:
- Thử nghiệm thành công ứng dụng tích hợp.
- Các trường hợp thử nghiệm đã thực thi được lập thành tài liệu
- Tất cả các lỗi được ưu tiên cao đã được sửa và đóng
- Các tài liệu kỹ thuật sẽ được đệ trình sau đó là Ghi chú phát hành.
Các nguyên tắc / Thực tiễn Tốt nhất cho Kiểm tra Tích hợp
- Đầu tiên, xác định Chiến lược kiểm tra tích hợp có thể được thông qua và sau đó chuẩn bị các trường hợp kiểm thử và dữ liệu kiểm tra cho phù hợp.
- 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 thứ này cần được kiểm tra theo thứ tự ưu tiên.
- Nhận thiết kế giao diện từ nhóm Kiến trúc và tạo các trường hợp thử nghiệm để xác minh chi tiết tất cả các giao diện. Giao diện với cơ sở dữ liệu / ứng dụng phần cứng / phần mềm bên ngoài phải được kiểm tra chi tiết.
- Sau các trường hợp thử nghiệm, dữ liệu thử nghiệm đóng vai trò quan trọng.
- Luôn chuẩn bị sẵn dữ liệu giả trước khi thực thi. Không chọn dữ liệu thử nghiệm trong khi thực hiện các trường hợp thử nghiệm.