Big Bang Integration Testing là gì

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ũng được gọi là ‘I & T’ (Tích hợp và Kiểm tra), ‘String Testing’ và đôi khi ‘Thread Testing’.

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ị, 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 để khách hàng thay đổi các yêu cầu. Các yêu cầu mới này có thể không được kiểm tra đơ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

Trường hợp thử nghiệm tích hợp khác với các trường hợp thử nghiệm khác theo nghĩa nó focuses mainly on the interfaces & flow of data/information between the modules. Ở đây ưu tiên được dành cho integrating links chứ không phải 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 xem nó được liên kết với Trang Hộp Thư như thế nào.

Tương tự Hộp thư: Kiểm tra sự tích hợp của nó với Mô-đun Xóa Thư.

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 bánh 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.

Big Bang Testing là một phương pháp kiểm tra 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.

Advantages:

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

Disadvantages:

• 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 all các mô-đun được thiết kế, nhóm kiểm thử sẽ có ít thời gian hơn để thực hiện trong giai đoạn kiểm thử.
• 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.

bên trong Incremental Testingroach, kiểm tra đượ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:

Stubs and Drivers là các chương trình giả trong kiểm thử Tích hợp được sử dụng để tạo điều kiện cho 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.

Driver: Gọi Mô-đun được kiểm tra.

Bottom-up Integration Testing là một chiến lược trong đó các mô-đun cấp thấp hơn được kiểm tra trước. Các mô-đun đã thử nghiệm này sau đó được sử dụng tiếp để 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.

Diagrammatic Representation:

Advantages:

• Bản địa hóa lỗi dễ dàng hơn.
• Không lãng phí thời gian khi 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

Disadvantages:

• 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ể

Top Down Integration Testing 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.

Diagrammatic Representation:

Advantages:

• 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.

Disadvantages:

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

Sandwich Testing 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à Hybrid Integration Testing. Nó sử dụng cả phần gốc 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):

1. Chuẩn bị Kế hoạch Kiểm tra Tích hợp
2. Thiết kế các tình huống, trường hợp và tập lệnh thử nghiệm.
3. Thực hiện các trường hợp kiểm tra sau đó là báo cáo các lỗi.
4. Theo dõi & kiểm tra lại các khuyết tật.
5. 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 mục của Kiểm tra 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.
• Các kế hoạch giảm thiểu và rủi ro.

Tiêu chí đầu vào và đầu ra của kiểm tra tích hợp

Tiêu chí đầu vào và thoát ra cho 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

Entry Criteria:

• Đơ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 sẽ được hoàn thành mã và tích hợp thành công.
• Kiểm thử tích hợp Lậ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

Exit Criteria:

• 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 để 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.