1. Integration testing là gì ?
- Là một trong các test level.
- Được thực hiện trong quá trình kiểm thử tích hợp nhóm các thành phần (module) riêng lẻ.
- Mục đích của kiểm thử tích hợp là tập trung vào các tương tác và chuyển tiếp giữa các thành phần hoặc hệ thống.
2. Đặc điểm
a. Thời điểm
Integration testing được thực hiện sau khi đã tiến hành kiểm thử đơn vị từng thành phần riêng lẻ (Unit testing).
- Sau quá trình thực hiện unit test, các module đều được kiểm tra, tuy nhiên vẫn sẽ còn tồn tại các lỗi với các lý do sau:
- Thông thường mỗi module sẽ được thiết kế bởi mỗi một lập trình viên, họ sẽ có kinh nghiệm và tính logic có thể khác với các lập trình viên khác. Integration testing sẽ đảm bảo được tính nhất quán của phần mềm sau khi tích hợp nhiều module lại với nhau.
- Trong quá trình phát triển, luôn có những thay đổi về yêu cầu đặc tả, những thay đổi này có thể sẽ không được kiểm tra ở giai đoạn unit test.
- Giao diện (interfaces) và cơ sở dữ liệu (database) có thể chưa hoàn chỉnh sau khi tích hợp.
- Các module riêng lẻ đôi khi sẽ không tương thích với cấu hình chung của hệ thống hoặc một số công cụ, APIs của bên thứ 3.
- Sau quá trình thực hiện unit test, các module đều được kiểm tra, tuy nhiên vẫn sẽ còn tồn tại các lỗi với các lý do sau:
b. Các đặc điểm chính
- Test level (trong integration) : Kiểm thử tích hợp đơn vị (Component intergration testing) và Kiểm thử tích hợp hệ thống (System integration testing).
- Test type: Kiểm thử chức năng (functional) và phi chức năng (non-functional).
- Test method: Black-box và White-box
- Môi trường test: Thực hiện trên môi trường test phù hợp (staging)
- Người phụ trách: Developer and tester
- Chiến lược test: Sử dụng phương pháp tiếp cận Big-bang hoặc Incremental
3. Ví dụ về Integration testing
a. Outline
Chúng ta là một công ty quảng cáo, các bài đăng sẽ được hiển thị trên các trang web khác nhau. Vào mỗi cuối tháng, cần phải thống kê dữ diệu về số người đã xem và số người đã nhấp vào quảng cáo là bao nhiêu. Từ đó tính phí tương ứng cho khách hàng của công ty.
b. Design
Chúng ta sẽ có design cơ bản về hệ thống như sau:
- UI - User interface module về giao diện người dùng, nơi lấy được thông tin của đầu vào.
- BL - Business logic module, xử lý các tính toán và phương pháp về kinh doanh cụ thể.
- VAL - Validation module, xác thực tính đúng đắn của đầu nào.
- CNT - Content module, nội dung do người dùng nhập vào, chúng sẽ đưuọc hiển thị trong các báo cáo.
- EN - Engine module, được dùng để đọc tất cả dữ liệu đến từ BL, VAL và CNT sau đó trích xuất truy vấn SQL và đưa nó vào cơ sở dữ liệu.
- Scheduler - Thống kê các báo cáo dựa trên yêu cầu của người dùng (hàng tháng, quý, năm).
- DB - Database, lưu trữ cơ sở dữ liệu.
c. Chúng ta cần test những gì ?
Đối với integration testing, trong trường hợp này, sẽ tập trung vào kiểm tra luồng xử lý giữa các module.
- Làm thế nào BL, VAL và CNT sẽ đọc và giải thích dữ liệu được nhập vào UI ?
- BL, VAL và CNT có nhận được dữ liệu chính xác từ UI không?
- Dữ liệu từ BL, AL và CNT được chuyển sang EN ở định dạng nào?
- EN sẽ đọc dữ liệu và trích xuất truy vấn SQL như thế ào?
- Truy vấn SQL có được trích xuất chính xác không?
- Scheduler có nhận được dữ liệu chính xác cho các báo cáo không ?
- Bộ kết quả mà EN nhận được, từ cơ sở dữ liệu có chính xác không ?
- EN có thể gửi phản hồi lại cho BL, VAL và CNT không ?
- UI có thể đọc dữ liệu và hiển thị phù hợp với giao diện không ?
Hiểu thêm một chút vào hệ thống nào.
- Thông thường, việc giao tiếp dữ liệu được thực hiện ở định dạng XML. Vì vậy, khi người dùng nhập dữ liệu vào UI, nó sẽ được chuyển đổi thành định dạng XML
- Trong ví dụ trên, dữ liệu nhập vào UI sẽ được BL, VAL và CNL thông dịch và chuyển thành tệp XML. EN sẽ đọc tệp XML, trích xuất SQL để truy vấn vào cơ sở dữ liệu, sau đó EN cũng sẽ nhập tập kết quả và chuyển thành tệp XML để trả lại kết quả cho UI và tất nhiên là UI chuyển đổi kết quả sang định dạng mà người dùng có thể đọc được để hiển thị nó.
- Trong quá trình giao tiếp dữ liệu đó, Scheduler sẽ nhập tập hợp kết quả từ module EN để tạo và đưa ra các báo cáo tương ứng.
- Sau khi đã hiểu được cách thức hoạt động, bạn sẽ có thể đưa ra các trường hợp kiểm tra:
- Tập trung vào việc xác thực xem các tệp XML có được tạo đúng cách không ?
- Dữ liệu được tạo có chính xác không ?
- ...
Từ các câu hỏi và kiến thức về hệ thống trên, bạn sẽ đưa ra được các trường hợp test tích hợp các module. Tùy thuộc vào xử lý và logic mà chúng ta sẽ có các kết quả mong đợi tương ứng.
d. Một số trường hợp khác
Các trường hợp kiểm thử tích hợp tập trung chủ yếu vào giao diện giữa các module, liên kết, truyền dữ liệu. Vì vậy ý tưởng chính là kiểm tra xem việc tích hợp hai module làm việc có hoạt động như mong đợi khi tích hợp hay không.
Chúng ta có một số trường hợp khi kiểm tra tích hợp cho ứng dụng Linkedin:
- #1. Xác minh liên kết giữa trang Login và Home : User đăng nhập thành công nó sẽ chuyển hướng đến Home.
- #2. Xác minh liên kết giữa Home và Profile : Khi tap vào menu Profile ở Home sẽ dẫn đến trang Profile.
- #3. Xác minh liên kết ở MyNetwork: Hoạt động chấp nhận lời mời khi nhấp vào Accept button ở trang My Network.
- #4. Xác minh liên kết ở Notifications: Thông tin chi tiết khi nhấp vào một thông báo bất kỳ.
4. Một số defect/ failure điển hình
- Không nhất quán về cấu trúc giữa các hệ thống.
- Dữ liệu không chính xác, thiếu hoặc quá trình mã hóa dữ liệu không chính xác.
- Trình tự hoặc thời gian giao tiếp giữa các module không chính xác.
- Giao diện không khớp.
- Giao tiếp giữa các module thất bại.
- Giao tiếp giữa các module không được xử lý hoặc xử lý không đúng cách.
- Các giả định không chính xác về ý nghĩa, đơn vị hoặc ranh giới của dữ liệu được truyền giữa các module. Ví dụ: Khi call API để hiển thị dữ liệu có đơn vị tiền tệ, nhưng UI chỉ cho phép hiển thị với 4 ký tự.
- Không tuân thủ các quy định bảo mật bắt buộc.
5. Để kiểm thử tích hợp, cần gì?
a. Các bước cần thiết để bắt đầu
- Hiểu được kiến trúc của ứng dụng.
- Xác định các modules.
- Hiểu được vai trò của mỗi module (làm gì?).
- Hiểu cách dữ liệu được chuyển từ module này sang module khác như thế nào.
- Hiểu các dữ liệu được nhập và nhận vào hệ thống như thế nào ( entry và exist point).
- Tách ứng dụng để phù hợp với nhu cầu (chia nhỏ các luồng giao tiếp của các module).
- Xác định và tạo được các điều kiện kiểm thử.
- Xác định được các trường hợp kiểm thử dựa vào thời gian và ngữ cảnh tương ứng.
b. Tiêu chí đầu vào/ ra (Entry/ Exist criteria)
Entry
- Test plan đã được chấp nhận
- Test case (Trường hợp kiểm thử)
- Test data (Dữ liệu thử nghiệm)
- Các module đã được kiểm thử đơn vị (Unit testing)
- Tất cả các lỗi quan trọng và có mức độ ưu tiên cao trước đó đều được fix xong và closed.
- Môi trường thử nghiệm được thiết lập.
Exist
- Tất cả các trường hợp kiểm thử tích hợp đã được thực thi
- Không có defect P1 &P2 còn mở.
- Báo cáo về kiểm thử tích hợp đã được chuẩn bị.
Tham khảo