Kiểm thử tích hợp

Kiểm thử tích hợp - Intergration testing là bước rất quan trọng trong quá trình kiểm thử. Muốn phần mềm được đảm bảo chất lượng, hệ thống được vận hành theo đúng mong muốn người dùng thì kiểm thử tích hợp là không thể thiếu.

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

Kiểm thử tích hợp (Integration Testing) được định nghĩa 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).

Bài viết này được đăng tại [free tuts .net]

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

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:

• 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 có thể khác với các developer khác. Kiểm thử tích hợp trở nên cần thiết để xác minh các module trong phần mềm hoạt động thống nhất.
• Tại thời điểm phát triển các module, có thể có những thay đổi yêu cầu từ khách hàng. Các yêu cầu mới này có thể không được unit testing, 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 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ụ về test case kiểm thử tích hợp

Test Cases kiểm thử tích hợp khác với các Test Cases 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 / thông tin giữa các module. Ở đây tích hợp các liên kết được ưu tiên kiểm thử thay vì kiểm thử các đơn vị chức năng.

Ví dụ: kiểm thử tích hợp cho kịch bản sau: Ứng dụng có 3 module là 'Trang đăng nhập', 'Hộp thư' và 'Xóa email' và mỗi module đượ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 Unit testing. Nhưng hãy kiểm thử xem Trang đăng nhập được liên kết với Trang Hộp thư như thế nào.

Tương tự, Kiểm thử sự tích hợp của Trang Hộp thư với module Xóa Thư.

4. Cách tiếp cận / Phương pháp / Chiến lược của Kiểm thử tích hợp

Có 2 cách tiếp cận trong Kiểm thử tích hợp:

• Cách tiếp cận Big Bang:
• Cách tiếp cận tăng dần (Incremental), được chia thành các cách sau:

1. Cách tiếp cận từ trên xuống (Top Down)
2. Cách tiếp cận từ dưới lên (Bottom Up)
3. 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, cách thực hiện và những ưu điểm cũng như những nhược điểm của chúng.

Cách tiếp cận 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ử.

Cách tiếp cận tăng dần

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

Tích hợp từ dưới lên

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ể

Tích hợp từ trên xuống

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 kiểm thử tích hợp?

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:

1. Chuẩn bị kế hoạch kiểm thử tích hợp
2. Thiết kế các test scenarios, test cases và test scripts.
3. Thực thi các test cases, báo cáo các lỗi nếu có.
4. Theo dõi & kiểm thử lại các test cases có lỗi.
5. 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 kiểm thử tích hợp

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