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 Anh Tester sẽ giới thiệu với các bạn một chút về Integration Testing.
1. Integration Testing là gì?
Integration Testing (Kiểm thử tích hợp) là một loại kiểm thử trong đó các module của phần mềm được tích hợp logic và được kiểm thử theo nhóm.
Một dự án phần mềm điển hình bao gồm nhiều module, được code bởi các lập trình viên. Kiểm thử tích hợp là kiểm thử sự tương thích giữa các module đó.
Do đó, kiểm thử tích hợp còn được gọi là I & T (Tích hợp và Kiểm thử), String Testing (Kiểm thử chuỗi) và đôi khi là Thread Testing (Kiểm thử luồng).
2. Tại sao cần phải Integration Testing?
Mặc dù mỗi module đã được Unit Testing nhưng lỗi vẫn còn tồn tại vì một số lý do như:
- Do mỗi module được thiết kế bởi một developer độc lập, có kiến thức và logic lập trình khác nhau vì vậy có thể sẽ có lỗi phát sinh khi tích hợp các module với nhau.
- Khách hàng sẽ thay đổi yêu cầu thiết kế trong quá trình phát triển module (thêm yêu cầu, update lại yêu cầu khi thấy không hợp lý…) và các yêu cầu mới này có thể không được Unit Testing hay khi tích hợp sẽ phát sinh lỗi.
- Các giao diện của các module trong phần mềm với cơ sở dữ liệu có thể không tương thích.
- Khi tích hợp các module vào hệ thống có thể không tương thích với cấu hình chung của hệ thống.
- Xử lý các ngoại lệ không đầy đủ có thể gây ra lỗi.
3. Ví dụ Integration Testing
Test Case của Integration Testing khác với các Test Case khác, kiểm thử tích hợp tập trung chủ yếu vào các giao diện và luồng dữ liệu hay thông tin giữa các module. Bởi kiểm thử đơn vị đã được kiểm tra cho từng module nên ở đây không cần thiết để kiểm tra lại.
Ví dụ: Kiểm thử tích hợp cho kịch bản “Quản lý chi phí”
- Nghiệp vụ
– Ứng dụng có 2 menu Product Group và Product Category. Ở đây không tập trung nhiều vào kiểm thử giao diện và chức năng của 2 menu trên vì nó đã được thực hiện trong Unit testing. Nhưng sẽ tập trung kiểm tra phần tích hợp giữa 2 menu đó.
- Trường hợp kiểm thử
Group nào active bên Product Group thì sẽ hiển thị bên Product Category
Và ngược lại Group nào không active thì sẽ không hiển thị
4. Phương pháp tiếp cận và Chiến lược của Integration Testing
Phương pháp tiếp cận trong Kiểm thử tích hợp:
Dưới đây mình sẽ giới thiệu các chiến lược, cách thực hiện và những ưu điểm nhược điểm của các phương pháp.
4.1. Big Bang
Tất cả các thành phần được tích hợp cùng một lúc, sau đó 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 đến giao diện người dùng cũng không bị cô lập và được ưu tiên kiểm thử.
4.2. Incremental Testing
Trong phương pháp 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ử.
Bottom Up
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ể
Top Down
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.
5. Quy trình Integration Testing?
Quy trình kiểm thử tích hợp không phân biệt 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ế các test scenarios, test cases và test scripts.
- Thực thi các test cases, báo cáo các lỗi nếu có.
- Theo dõi & kiểm thử lại các test cases có lỗi.
- Bước 3 và 4 được lặp lại cho đến khi kiểm thử hợp được hoàn thành.
6. Mô tả tóm tắt về kế hoạch Integration Testing
Kiểm thử tích hợp bao gồm các thuộc tính sau:
- Phương pháp / hướng tiếp cận kiểm thử.
- Trong phạm vi và ngoài phạm vi kiểm thử tích hợp.
- Vai trò và trách nhiệm.
- Điều kiện tiền đề để kiểm thử tích hợp.
- Môi trường kiểm thử.
- Kế hoạch giảm thiểu rủi ro.
7. Tiêu chí bắt đầu và kết thúc của kiểm thử tích hợp
Tiêu chí bắt đầu và kết thúc của 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 chí bắt đầu
- Thành phần / module đã được kiểm thử đơn vị.
- Tất cả các lỗi có độ ưu tiên cao đã được sửa.
- Tất cả các module được hoàn thành và được tích hợp.
- Kế hoạch kiểm thử tích hợp, test cases, các kịch bản, tài liệu đã được thông qua.
- Môi trường kiểm thử được thiết lập theo yêu cầu để kiểm thử tích hợp.
Tiêu chí kết thúc
- Kiểm thử tích hợp thành công.
- Các trường hợp kiểm thử đã thực thi được ghi lại
- Tất cả các lỗi có ưu tiên cao đã được sửa
- Tài liệu kỹ thuật được bàn giao.
8. Thực hiện kiểm thử tích hợp như thế nào để đạt kết quả tốt nhất?
- Đầu tiên, xác định Chiến lược kiểm thử tích hợp được thông qua, sau đó chuẩn bị các trường hợp kiểm thử và dữ liệu kiểm thử phù hợp.
- Nghiên cứu Kiến trúc của Ứng dụng trên bản thiết kế và xác định các module quan trọng, cần phải được ưu tiên kiểm thử ở giai đoạn này.
- 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 định 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 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ử cũng đóng vai trò quan trọng.
- Luôn chuẩn bị dữ liệu giả lập trước khi thực hiện kiểm thử. Không chuẩn bị dữ liệu kiểm thử trong khi thực hiện các trường hợp kiểm thử.
Kết Luận
Như vậy có thể thấy kiểm thử tích hợp đóng vai trò rất quan trọng bởi nếu chỉ kiểm tra unit testing nhưng đến khi tích hợp các module lại với nhau lại gây ra lỗi thì như vậy sẽ làm cho phần mềm không đáp ứng được các nghiệp vụ mà khách hàng đã yêu cầu. Vì vậy chúng ta cần nên lưu ý thực hiện kiểm thử này sau kiểm thử đơn vị nhé!
Rất mong nhận được ý kiến đóng góp từ phía bạn đọc! Chúc các bạn học tập vui khỏe!
