Kiểm thử tích hợp là gì ?

Kiểm thử tích hợp là gì?

KIỂM THỬ TÍCH HỢP được định nghĩa là một kiểu 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 thử 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 thử 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 thử 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à kiểm thử),  ‘Kiểm thử chuỗi’ và đôi khi là ‘Kiểm thử luồng’ .

 

Tại sao phải kiểm thử tích hợp?

Mặc dù mỗi mô-đun phần mềm đều được kiểm thử đơ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 thử 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ố.

Ví dụ về trường hợp kiểm thử 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 kiểm thử.

Các trường hợp kiểm thử 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 thử Trang đăng nhập vì nó đã được thực hiện trong Kiểm thử đơn vị . Nhưng hãy kiểm thử cách nó được liên kết với Trang Hộp thư.

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

ID trường hợp kiểm thử Mục tiêu trường hợp kiểm thử Mô tả trường hợp kiểm thử Kết quả mong đợi
1 Kiểm thử 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 thử 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 thử 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.

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 mô-đun được tích hợp với nhau cùng một lúc và sau đó được kiểm thử 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 kiểm thử. 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 thử trong cách tiếp cận này, một số liên kết giao diện cần được kiểm thử có thể bị bỏ sót một cách dễ dàng.
  • Vì kiểm thử 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 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 thử 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 thử 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 thử ưu tiên.

Kiểm thử gia tăng

Trong phương pháp Kiểm thử gia tăng , kiểm thử đượ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 thử để ứ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 về mặt logic được tích hợp và kiểm thử 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 kiểm thử. 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 kiểm thử.

Stub : Được gọi bởi Mô-đun đang Kiểm thử.

Trình điều khiển : Gọi Mô-đun được kiểm thử.

Kiểm thử tích hợp từ dưới lên

Kiểm thử 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 thử trước. Các mô-đun đã kiểm thử này sau đó được sử dụng thêm để tạo điều kiện cho việc kiểm thử 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 thử. Khi các mô-đun cấp thấp hơn được kiểm thử và tích hợp, thì các mô-đun cấp tiếp theo 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 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

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 thử 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 thử 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 thử trước và sau đó các mô-đun cấp thấp hơn được kiểm thử và tích hợp để kiểm thử chức năng phần mềm. Stubs được sử dụng để kiểm thử 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 thử 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 thử không đầy đủ.

Kiểm thử 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 thử 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 thử 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à Kiểm thử tích hợp kết hợp . 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 thử tích hợp?

Quy trình kiểm thử 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 thử Tích hợp
  2. Thiết kế các tình huống, trường hợp và tập lệnh kiểm thử.
  3. Thực hiện các trường hợp kiểm thử sau đó là báo cáo các khiếm khuyết.
  4. Theo dõi và kiểm thử lại các khiếm khuyế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 thử 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 thử (như đã thảo luận ở trên).
  • Phạm vi và Ngoài phạm vi Các 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 thử Tích hợp.
  • Môi trường kiểm thử.
  • Kế hoạch giảm thiểu và rủi ro.

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

Tiêu chí đầu vào và thoát cho giai đoạn kiểm thử 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 thử 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 kiểm thử, 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 thử bắt buộc được thiết lập để kiểm thử tích hợp

Tiêu chí thoát:

  • Kiểm thử thành công Ứng dụng Tích hợp.
  • Các trường hợp kiểm thử đã 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 thử Tích hợp

  • Đầu tiên, xác định Chiến lược kiểm thử 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 thử 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 thử theo mức độ ư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 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 / ứng dụng phần cứng / phần mềm bên ngoài phải được kiểm thử chi tiết.
  • 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 giả trước khi thực thi. Không chọn dữ liệu kiểm thử trong khi thực hiện các trường hợp kiểm thử.
Back to top button