Component Integration Testing là gì

07/07/2021 - vừa được xem lúc 7 giờ trước

[image]

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

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

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 Techacademy sẽ giới thiệu với các bạn một chút về Integration Testing.

I. Integration Test Là Gì

• Kiểm thử tích hợp [Integration testing] hay còn gọi là tích hợp và kiểm thử [integration and testing, viết tắt: I&T] là 1 giai đoạn trong kiểm thử phần mềm. Mỗi môđun phần mềm riêng biệt được kết hợp lại và kiểm thử theo nhóm.
• Kiểm thử tích hợp xảy ra sau kiểm thử đơn vị [Unit Test] và trước kiểm thử xác nhận. Kiểm thử tích hợp nhận các môđun đầu vào đã được kiểm thử đơn vị, nhóm chúng vào những tập hợp lớn hơn, áp dụng các ca kiểm thử đã được định nghĩa trong kế hoạch kiểm thử tích hợp vào tập hợp đó, và cung cấp đầu ra cho hệ thống tích hợp.

Integration Test Là Gì

II. Integration Test Có Mục Tiêu Chính Là Gì

Intergration test có mục đích là cho ra hai ứng dụng tốt nhất, mượt mà nhất mà người dùng cần đến. Từ đó, loại bỏ được các Bug cũng như những nguy cơ có thể xảy ra gây ra lỗi cho hệ điều hành trước khi chuyển đến tay người tiêu dùng. Chắc chắn rằng, bất kỳ hệ điều hành nào cũng mong muốn rằng mình có thể đạt được các chất lượng tốt nhất.

Mà muốn đạt được những điều đó thì buộc bạn phải trải nghiệm qua 3 bài đánh giá vô cùng quan trọng và nó có tên đại diện chính là Integration testing. Đây là một thuật ngữ đã được viết tắt bởi I&T và còn được hiểu là ý nghĩa kiểm thử và trang bị. Integration test là giai đoạn quan trọng không thể thiểu để bảo đảm hiệu quả cho hệ điều hành, trong khi đó thì các mô đun thường sẽ được trang bị phần mềm riêng và được đánh giá dựa theo từng nhóm.

Đây được xem là một trong những quá trình trung gian nằm giữa bài kiểm tra Unit Testing các thủ tục sử dụng cũng như vận hành cho các công ty nguồn hoặc Acceptance test. Đây là một dạng kiểm thử xác nhận, ở đó thì tester và khách hàng sẽ có khả năng kiểm thử tại địa chỉ thiết kế phần mềm rồi đánh giá hầu hết tính năng của phần mềm này sau khi chuyển hướng hoạt động về nền tảng của họ.

Integration Test Có Mục Tiêu Chính Là Gì

III. Tại Sạo Lại Phải Thực Hiện Kiểm Thử Tích Hợp

Mặc dù mỗi module đều được unit test nhưng các lỗi vẫn còn tồn tại với những lý do khác nhau:

• Một Module nói chung được thiết kế bởi một lập trình viên có 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 là cần thiết để bảo đảm tính hợp nhất của phần mềm.
• Tại thời điểm phát triển module vẫn có thể có đổi thay trong spec của khách hàng, những thay đổi này có thể không được kiểm tra ở giai đoạn unit test trước đó.
• Giao diện và cơ sở dữ liệu của các module có thể chưa hoàn chỉnh lúc được ghép lại
• Khi tích hợp hệ thống các module có thể không tương thích với cấu hình chugn của hệ thống
• Thiếu các xử lý ngoại lệ có thể xảy ra

Tại Sạo Lại Phải Thực Hiện Kiểm Thử Tích Hợp

IV. Ví Dụ Về Kiểm Thử Tích Hợp

Giả sử bạn làm việc cho 1 tổ chức CNTT đã được yêu cầu phát triển trang web mua sắm trực tuyến cho Camp World, một công ty bán dụng cụ cắm trại. Sau khi thu thập yêu cầu, phân tích và thiết kế hoàn tất, một nhà phát triển đã được chỉ định để phát triển từng mô-đun bên dưới.

• Đăng ký và xác thực người dùng / Đăng nhập
• Danh mục sản phẩm
• Giỏ hàng
• Thanh toán
• Tích hợp cổng thanh toán
• Theo dõi vận chuyển và gói hàng

Sau khi mỗi mô-đun được gán cho nhà phát triển, nhà phát triển bắt đầu mã hóa chức năng trên những máy riêng lẻ của họ. Họ đã triển khai các mô-đun tương ứng trên các máy của mình để xem những gì đã hoạt động và những gì đã làm, khi họ bắt đầu phát triển mô-đun.

Sau khi họ hoàn thành việc phát triển, các nhà phát triển đã kiểm tra các chức năng cá nhân của họ như là một phần của kiểm thử đơn vị của họ và tìm thấy một số khiếm khuyết. Họ đã sửa những khuyết điểm này. Tại thời điểm này, họ cảm thấy các mô-đun của họ đã hoàn thành.

Kiểm tra tích hợp nên được thực hiện để xác nhận rằng tất cả các mô-đun hoạt động cùng nhau. Khi họ triển khai tất cả mã của họ trong một máy chung, họ thấy rằng ứng dụng không hoạt động như mong đợi vì các mô-đun riêng lẻ không hoạt động tốt với nhau. Có một số lỗi như – sau khi đăng nhập, giỏ hàng của người dùng không hiển thị các mục họ đã thêm trước đó, số tiền hóa đơn không bao gồm chi phí vận chuyển, v.v.

Theo cách này, Kiểm thử tích hợp giúp chúng ta xác định, khắc phục các sự cố và bảo đảm rằng hầu hết ứng dụng hoạt động như mong đợi.

Ví Dụ Về Kiểm Thử Tích Hợp

V. 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 1 lúc, sau ấy 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 tới 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 cách 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:

Tích hợp 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:

Tích hợp 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.

Tích hợp Hybrid/ Sandwich

VI. Sự Khác Nhau Giữa Integration Test Và System Test

Unit Testing Integration Testing Functional Testing

Định nghĩa và mục đích	Kiểm thử riêng biệt từng đơn vị hoặc từng module	Kiểm thử tích hợp hai hay nhiều đơn vị/modules kết hợp cùng với nhau để hoàn thành nhiệm vụ	Kiểm tra các hành vi của các ứng dụng theo yêu cầu.
Mức độ phức tạp	Không hề phức tạp vì nó bao gồm các dòng code nhỏ nhất	Phức tạp hơn một chút so với kiểm thử đơn vị	Phức tạp hơn so với kiểm thử đơn vị và kiểm thử tích hợp
Kỹ thuật kiểm thử	Kiểm thử hộp trắng	Kiểm thử hộp trắng, đen và xám	Kiểm thử hộp đen
Những điểm cần lưu ý chính	Những đơn vị hoặc module riêng lẻ	Tích hợp những đơn vị hoặc module	Toàn bộ chức năng ứng dụng
Lỗi/vấn đề được tìm thấy	Tìm các vấn đề có thể xảy ra thường xuyên trong các module	Tìm các vấn đề có thể xảy ra trong lúc tích hợp các module khác nhau	Tìm thấy vấn đề không cho phép 1 ứng dụng thực hiện các chức năng của nó. Điều này bao gồm một số vấn đề dựa trên kịch bản dựa test.
Lọt bug	Không có cơ hội lọt bug	Ít có cơ hội	Nhiều cơ hội lọt issue lúc danh sách chức năng phải test luôn là vô hạn.

Sự Khác Nhau Giữa Integration Test Và System Test