Integration testing là cấp độ thứ hai của quá trình kiểm thử phần mềm sau Unit Testing. Trong thử nghiệm này, các đơn vị hoặc thành phần riêng lẻ của phần mềm được thử nghiệm trong một nhóm. Trọng tâm của cấp độ Integration testing là để lộ ra các khiếm khuyết tại thời điểm tương tác giữa các thành phần hoặc đơn vị được tích hợp.
Các bài viết liên quan:
Unit Testing sử dụng các mô-đun cho mục đích kiểm thử và các mô-đun này được kết hợp và kiểm tra trong Integration testing. Phần mềm được phát triển với một số mô-đun phần mềm được mã hóa bởi những người lập trình hoặc lập trình viên khác nhau. Mục tiêu của Integration testing là để kiểm tra tính đúng đắn của giao tiếp giữa tất cả các mô-đun.
Khi tất cả các thành phần hoặc mô-đun đang hoạt động độc lập, thì chúng ta cần kiểm tra luồng dữ liệu giữa các mô-đun phụ thuộc được gọi là Integration testing.
Hãy để chúng tôi xem một ví dụ mẫu về ứng dụng ngân hàng, như chúng ta có thể thấy trong hình ảnh bên dưới về chuyển số tiền.
Đầu tiên, chúng ta sẽ đăng nhập với tư cách là người dùng P để chuyển số tiền và gửi số tiền Rs200, thông báo xác nhận sẽ hiển thị trên màn hình là chuyển số tiền thành công. Bây giờ đăng xuất với tư cách P và đăng nhập với tư cách người dùng Q và đi đến trang số dư số tiền và kiểm tra số dư trong tài khoản đó = Số dư hiện tại + Số dư đã nhận. Do đó, Integration testing thành công.
Xem thêm AngularJS Modules
Ngoài ra, chúng tôi kiểm tra xem số dư có giảm 200 Rs trong tài khoản người dùng P hay không.
Nhấp vào giao dịch, ở P và Q, thông báo sẽ được hiển thị liên quan đến dữ liệu và thời gian chuyển số tiền.
Hướng dẫn Integration testing
- Chúng tôi chỉ tiến hành Integration testing sau khi hoàn thành Functional Testing trên từng mô-đun của ứng dụng.
- Chúng tôi luôn thực hiện Integration testing bằng cách chọn từng mô-đun để tuân theo một trình tự thích hợp và chúng tôi cũng không bỏ sót bất kỳ tình huống tích hợp nào.
- Đầu tiên, xác định chiến lược test case mà qua đó các test case thực thi có thể được chuẩn bị theo dữ liệu thử nghiệm.
- Kiểm tra cấu trúc và kiến trúc của ứng dụng và xác định các mô-đun quan trọng để kiểm tra chúng trước tiên và cũng xác định tất cả các tình huống có thể xảy ra.
- Thiết kế các trường hợp kiểm thử để xác minh chi tiết từng giao diện.
- Chọn dữ liệu đầu vào để thực thi test case. Dữ liệu đầu vào đóng một vai trò quan trọng trong thử nghiệm.
- Nếu chúng tôi tìm thấy bất kỳ lỗi nào thì hãy thông báo các báo cáo lỗi cho các nhà phát triển và sửa các lỗi cũng như kiểm tra lại.
- Thực hiện Integration testing tích cực và tiêu cực.
Ở đây kiểm tra tích cực ngụ ý rằng nếu tổng số dư là 15.000 Rs và chúng tôi đang chuyển 1500 Rs và kiểm tra xem việc chuyển số tiền có hoạt động tốt hay không. Nếu đúng, thì bài kiểm tra sẽ đạt.
Và kiểm tra tiêu cực có nghĩa là, nếu tổng số dư là 15, 000 Rs và chúng tôi đang chuyển 20, 000 Rs và kiểm tra xem việc chuyển số tiền có xảy ra hay không, nếu nó không xảy ra thì bài kiểm tra là đạt. Nếu điều này xảy ra, thì có một lỗi trong mã và chúng tôi sẽ gửi nó đến nhóm phát triển để sửa lỗi đó.
Lưu ý: Bất kỳ ứng dụng nào trên thế giới này đều sẽ thực hiện Functional Testing bắt buộc, trong khi Integration testing sẽ chỉ được thực hiện nếu các mô-đun phụ thuộc vào nhau. Mỗi kịch bản tích hợp bắt buộc phải có nguồn → dữ liệu → đích. Bất kỳ kịch bản nào cũng có thể được gọi là kịch bản tích hợp chỉ khi dữ liệu được lưu vào đích.
Ví dụ: Trong ứng dụng Gmail, Nguồn có thể là Soạn, Dữ liệu có thể là Email và Đích có thể là Hộp thư đến.
Ví dụ về Integration testing
Hãy giả sử rằng chúng tôi có một ứng dụng Gmail mà chúng tôi thực hiện Integration testing.
Đầu tiên, chúng tôi sẽ thực hiện Functional Testing trên trang đăng nhập, trang này bao gồm các thành phần khác nhau như tên người dùng, mật khẩu, nút gửi và hủy. Sau đó, chỉ chúng tôi mới có thể thực hiện Integration testing.
Các tình huống tích hợp khác nhau như sau:
Các tình huống 1:
- Đầu tiên, chúng tôi đăng nhập với tư cách người dùng P và nhấp vào Soạn thư và thực hiện Functional Testing cho các thành phần cụ thể.
- Bây giờ chúng ta nhấp vào Gửi và cũng kiểm tra Lưu bản nháp.
- Sau đó, chúng tôi gửi thư cho Q và xác minh trong thư mục Gửi các mục của P để kiểm tra xem thư đã gửi có ở đó hay không.
- Bây giờ, chúng ta sẽ đăng xuất với tên P và đăng nhập là Q và chuyển đến Hộp thư đến và xác minh xem thư đã đến chưa.
Các tình huống 2: Chúng tôi cũng thực hiện Integration testing trên các thư mục Spam. Nếu địa chỉ liên hệ cụ thể đã bị đánh dấu là thư rác, thì bất kỳ thư nào được gửi bởi người dùng đó sẽ đi đến thư mục thư rác chứ không phải trong hộp thư đến.
Lưu ý: Chúng tôi sẽ thực hiện Functional Testing cho tất cả các tính năng, chẳng hạn như gửi các mục, hộp thư đến, v.v.
Như chúng ta có thể thấy trong hình ảnh bên dưới, chúng tôi sẽ thực hiện Functional Testing cho tất cả các trường văn bản và mọi tính năng. Sau đó, chúng tôi sẽ thực hiện Integration testing cho các chức năng liên quan. Đầu tiên chúng tôi kiểm tra thêm người dùng, danh sách người dùng, xóa người dùng, chỉnh sửa người dùng và sau đó tìm kiếm người dùng.
Ghi chú:
- Có một số tính năng, chúng tôi có thể chỉ thực hiện thử nghiệm chức năng và có một số tính năng mà chúng tôi đang thực hiện cả thử nghiệm chức năng và tích hợp dựa trên các yêu cầu của tính năng.
- Ưu tiên là điều cần thiết và chúng ta nên thực hiện ở tất cả các giai đoạn, có nghĩa là chúng tôi sẽ mở ứng dụng và chọn tính năng nào cần được kiểm tra trước. Sau đó vào tính năng đó và chọn thành phần nào phải được kiểm tra trước. Chuyển đến các thành phần đó và xác định giá trị nào sẽ được nhập trước.
- Và không áp dụng cùng một quy tắc ở mọi nơi vì logic kiểm tra khác nhau giữa các tính năng.
- Trong khi thực hiện kiểm tra, chúng tôi nên kiểm tra toàn bộ một tính năng và sau đó chỉ tiến hành một chức năng khác.
- Trong số hai tính năng, chúng tôi phải thực hiện chỉ Integration testing tích cực hoặc Integration testing cả tích cực và tiêu cực, và điều này cũng phụ thuộc vào các tính năng cần.
Lý do đằng sau Integration testing
Mặc dù tất cả các mô-đun của ứng dụng phần mềm đã được kiểm tra trong Unit Testing, nhưng lỗi vẫn tồn tại do các nguyên nhân sau:
- Mỗi mô-đun được thiết kế bởi nhà phát triển phần mềm riêng lẻ mà logic lập trình của họ có thể khác với các nhà phát triển của các mô-đun khác; Integration testing trở nên cần thiết để xác định hoạt động của các mô-đun phần mềm.
- Để kiểm tra sự tương tác của các mô-đun phần mềm với cơ sở dữ liệu xem nó có bị lỗi hay không.
- Các yêu cầu có thể được thay đổi hoặc nâng cao tại thời điểm phát triển mô-đun. Các yêu cầu mới này có thể không được kiểm tra ở cấp độ Unit Testing, do đó Integration testing trở thành bắt buộc.
- Sự không tương thích giữa các mô-đun của phần mềm có thể tạo ra lỗi.
- Để kiểm tra khả năng tương thích của phần cứng với phần mềm.
- Nếu việc xử lý ngoại lệ không đầy đủ giữa các mô-đun, nó có thể tạo ra lỗi.
Các loại Integration testing
Integration testing có thể được phân thành hai phần:
- Incremental integration testing
- Non-incremental integration testing
Incremental integration testing
Trong Phương pháp Tiếp cận Tăng dần, các mô-đun được thêm vào theo thứ tự tăng dần từng cái một hoặc tùy theo nhu cầu. Các mô-đun được chọn phải có liên quan về mặt logic. Nói chung, hai hoặc nhiều hơn hai mô-đun được thêm vào và kiểm tra để xác định tính đúng đắn của các chức năng. Quá trình tiếp tục cho đến khi kiểm tra thành công tất cả các mô-đun.
HOẶC LÀ
Trong loại thử nghiệm này, có một mối quan hệ chặt chẽ giữa các mô-đun phụ thuộc. Giả sử chúng ta lấy hai hoặc nhiều mô-đun và xác minh rằng luồng dữ liệu giữa chúng hoạt động tốt. Nếu đúng, hãy thêm nhiều mô-đun hơn và kiểm tra lại.
Ví dụ: Giả sử chúng ta có một ứng dụng Flipkart, chúng ta sẽ thực hiện Integration testing gia tăng và luồng của ứng dụng sẽ như sau:
Flipkart → Đăng nhập → Trang chủ → Tìm kiếm → Thêm giỏ hàng → Thanh toán → Đăng xuất
Integration testing gia tăng được thực hiện bằng các phương pháp khác:
Top-Down Approach
Chiến lược kiểm tra từ trên xuống giải quyết quá trình trong đó các mô-đun cấp cao hơn được kiểm tra với các mô-đun cấp thấp hơn cho đến khi hoàn thành thành công việc kiểm tra tất cả các mô-đun. Các lỗi thiết kế lớn có thể được phát hiện và khắc phục sớm vì các mô-đun quan trọng đã được kiểm tra trước. Trong loại phương pháp này, chúng tôi sẽ thêm các mô-đun tăng dần hoặc từng mô-đun một và kiểm tra luồng dữ liệu theo cùng một thứ tự.
Trong cách tiếp cận từ trên xuống, chúng tôi sẽ đảm bảo rằng mô-đun chúng tôi đang thêm là phần tử con của mô-đun trước đó như Phần tử C là phần tử con của Phần tử B, v.v. như chúng ta có thể thấy trong hình ảnh bên dưới:
Thuận lợi:
- Việc xác định lỗi rất khó.
- Có thể có một nguyên mẫu ban đầu.
Nhược điểm:
- Do số lượng bản khai cao, nó trở nên khá phức tạp.
- Các mô-đun cấp thấp hơn được kiểm tra không đầy đủ.
- Các mô-đun quan trọng được kiểm tra đầu tiên để có ít khả năng bị lỗi hơn.
Bottom-Up Method
Chiến lược kiểm tra từ dưới lên đề cập đến quá trình trong đó các mô-đun cấp thấp hơn được kiểm tra với các mô-đun cấp cao hơn cho đến khi hoàn thành thành công việc kiểm tra tất cả các mô-đun. Các mô-đun quan trọng cấp cao nhất được kiểm tra sau cùng, vì vậy nó có thể gây ra lỗi. Hoặc chúng ta có thể nói rằng chúng ta sẽ thêm các mô-đun từ dưới lên trên và kiểm tra luồng dữ liệu theo cùng một thứ tự.
Trong phương pháp từ dưới lên, chúng tôi sẽ đảm bảo rằng các mô-đun chúng tôi đang thêm là mô-đun gốc của mô-đun trước đó như chúng ta có thể thấy trong hình ảnh dưới đây:
Thuận lợi
- Xác định khuyết tật rất dễ dàng.
- Không cần đợi sự phát triển của tất cả các mô-đun vì nó tiết kiệm thời gian.
Nhược điểm
- Các mô-đun quan trọng được kiểm tra lần cuối do các sai hỏng có thể xảy ra.
- Không có khả năng có một nguyên mẫu ban đầu.
- Trong trường hợp này, chúng tôi có một cách tiếp cận bổ sung được gọi là thử nghiệm kết hợp.
Hybrid Testing Method
Trong cách tiếp cận này, cả hai cách tiếp cận Từ trên xuống và Từ dưới lên được kết hợp để thử nghiệm. Trong quá trình này, các mô-đun cấp cao nhất được kiểm tra với các mô-đun cấp thấp hơn và cấp thấp hơn các mô-đun được kiểm tra đồng thời với các mô-đun cấp cao. Có ít khả năng xảy ra lỗi hơn vì mỗi giao diện mô-đun đều được kiểm tra.
Thuận lợi
- Phương pháp kết hợp cung cấp các tính năng của cả hai phương pháp Bottom Up và Top Down.
- Đó là phương pháp giảm thời gian nhất.
- Nó cung cấp thử nghiệm hoàn chỉnh của tất cả các mô-đun.
Nhược điểm
- Phương pháp này cần mức độ tập trung cao hơn vì quá trình được thực hiện đồng thời theo cả hai hướng.
- Phương pháp phức tạp.
Non- incremental integration testing
Chúng ta sẽ thực hiện phương pháp này, khi luồng dữ liệu rất phức tạp và khi khó tìm được ai là cha mẹ và ai là con cái. Và trong trường hợp như vậy, chúng tôi sẽ tạo dữ liệu trong bất kỳ mô-đun nào trên tất cả các mô-đun hiện có khác và kiểm tra xem dữ liệu có tồn tại hay không. Do đó, nó còn được gọi là phương pháp Vụ nổ lớn.
Big Bang Method
Trong cách tiếp cận này, kiểm tra được thực hiện thông qua tích hợp tất cả các mô-đun cùng một lúc. Nó là thuận tiện cho các hệ thống phần mềm nhỏ, nếu được sử dụng cho các hệ thống phần mềm lớn, việc xác định các khiếm khuyết là khó khăn.
Vì việc kiểm tra này có thể được thực hiện sau khi hoàn thành tất cả các mô-đun do nhóm kiểm tra có ít thời gian hơn để thực hiện quy trình này nên có thể dễ dàng bỏ sót các giao diện được liên kết nội bộ và các mô-đun quan trọng có rủi ro cao.
Thuận lợi:
Nó thuận tiện cho các hệ thống phần mềm kích thước nhỏ.
Nhược điểm:
- Việc xác định lỗi rất khó khăn vì việc tìm ra lỗi từ đâu là một vấn đề nan giải và chúng tôi không biết nguồn gốc của lỗi.
- Các mô-đun nhỏ bị bỏ sót một cách dễ dàng.
- Thời gian cung cấp cho thử nghiệm là rất ít.
- Chúng tôi có thể bỏ lỡ thử nghiệm một số giao diện.
Hãy để chúng tôi xem các ví dụ để hiểu rõ hơn về phương pháp Integration testing không gia tăng hoặc vụ nổ lớn:
Ví dụ 1
Trong ví dụ dưới đây, nhóm phát triển phát triển ứng dụng và gửi nó cho Giám đốc điều hành của nhóm thử nghiệm. Sau đó, CEO sẽ đăng nhập vào ứng dụng và tạo tên người dùng, mật khẩu và gửi mail cho người quản lý. Sau đó, CEO sẽ yêu cầu họ bắt đầu thử nghiệm ứng dụng.
Sau đó, người quản lý quản lý tên người dùng và mật khẩu và tạo tên người dùng và mật khẩu và gửi nó đến các đầu mối kiểm tra. Và các đầu mối thử nghiệm sẽ gửi nó cho các kỹ sư thử nghiệm để phục vụ các mục đích thử nghiệm tiếp theo. Lệnh này từ Giám đốc điều hành đến kỹ sư thử nghiệm là Integration testing gia tăng từ trên xuống.
Theo cách tương tự, khi các kỹ sư kiểm thử đã hoàn thành việc kiểm tra, họ sẽ gửi báo cáo đến các trưởng nhóm kiểm tra, người này sau đó sẽ gửi báo cáo cho người quản lý và người quản lý sẽ gửi báo cáo cho Giám đốc điều hành. Quá trình này được gọi là Integration testing gia tăng từ dưới lên như chúng ta có thể thấy trong hình ảnh bên dưới:
Lưu ý: Integration testing gia tăng kết hợp (I.I.T) và Integration testing không gia tăng được gọi là thử nghiệm sandwich.
Ví dụ2
Ví dụ dưới đây minh họa trang chủ của Hộp thư đến của Gmail, nơi chúng tôi nhấp vào liên kết Hộp thư đến và chúng tôi được chuyển đến trang hộp thư đến. Ở đây chúng ta phải thực hiện Integration testing không gia tăng vì không có khái niệm cha và con.
Ghi chú
Stub và trình điều khiển
Phần sơ khai là một mô-đun giả nhận dữ liệu và tạo ra nhiều dữ liệu có thể xảy ra, nhưng nó hoạt động giống như một mô-đun thực. Khi một dữ liệu được gửi từ mô-đun P đến Stub Q, nó sẽ nhận dữ liệu mà không cần xác nhận và xác thực, đồng thời tạo ra kết quả ước tính cho dữ liệu đã cho.
Chức năng của một trình điều khiển được sử dụng để xác minh dữ liệu từ P và gửi nó đến sơ khai và cũng kiểm tra dữ liệu mong đợi từ sơ khai và gửi nó đến P.
Trình điều khiển là người thiết lập môi trường thử nghiệm và cũng đảm nhận việc giao tiếp, đánh giá kết quả và gửi báo cáo. Chúng tôi không bao giờ sử dụng sơ khai và trình điều khiển trong quá trình thử nghiệm.
Trong thử nghiệm Hộp trắng, Integration testing từ dưới lên là lý tưởng vì có thể truy cập trình điều khiển bằng văn bản. Và trong thử nghiệm hộp đen, không có ưu tiên nào được đưa ra cho bất kỳ thử nghiệm nào vì nó phụ thuộc vào ứng dụng.
Các câu hỏi phổ biến nhất về Integration testing
- Integration testing là gì?
Integration testing là một loại kiểm thử phần mềm, được sử dụng để kiểm tra tính tương thích và tính hợp nhất của các thành phần phần mềm khác nhau trong một hệ thống.
- Integration testing được thực hiện như thế nào?
Trong quá trình kiểm thử hợp nhất, các thành phần phần mềm khác nhau được kết hợp với nhau và kiểm tra tính hợp nhất của chúng. Kiểm thử hợp nhất có thể được thực hiện bằng cách sử dụng các phương pháp khác nhau như top-down approach, bottom-up approach, hay middle-out approach.
- Integration testing có những lợi ích gì?
Integration testing có thể giúp phát hiện lỗi phần mềm sớm, giảm thiểu rủi ro trong quá trình triển khai phần mềm, tăng tính tin cậy và tính sẵn sàng của hệ thống, đảm bảo tính tương thích và tính hợp nhất của các thành phần phần mềm.
- Integration testing khác gì với unit testing?
Unit testing được sử dụng để kiểm tra tính đúng đắn của từng thành phần phần mềm độc lập. Trong khi đó, integration testing được sử dụng để kiểm tra tính hợp nhất và tính tương thích của các thành phần phần mềm khi chúng được kết hợp với nhau.
- Integration testing được chia làm mấy loại?
Integration testing được chia làm hai loại chính: kiểm thử hợp nhất dọc (vertical integration testing) và kiểm thử hợp nhất ngang (horizontal integration testing).
- Làm thế nào để chọn phương pháp kiểm thử phù hợp cho việc kiểm thử hợp nhất?
Việc chọn phương pháp kiểm thử hợp nhất phù hợp phụ thuộc vào nhiều yếu tố như mức độ phức tạp của hệ thống, số lượng thành phần phần mềm cần kiểm thử, thời gian và ngân sách cho quá trình kiểm thử.
- Điểm khác nhau giữa top-down và bottom-up approach trong kiểm thử hợp nhất là gì?
Top-down approach bắt đầu từ phần mềm cao nhất của hệ thống và dần xuống các thành phần phần mềm cấp thấp hơn, trong khi bottom-up approach bắt đầu từ các thành phần phần mềm cấp thấp nhất và dần lên đến phần mềm cao nhất của hệ thống.
