Kiểm thử tích hợp là gì và nó được thực hiện như thế nào?

Kiểm thử tích hợp là gì và nó được thực hiện như thế nào?

Nền tảng

Chúng ta đã học về nhiều mô hình vòng đời phát triển phần mềm khác nhau. Tất cả những mô hình vòng đời phát triển phần mềm đều có kiểm thử tích hợp như một trong các lớp của nó. Theo quan điểm của tôi, kiểm thử tích hợp trong thực tế là một mức độ của kiểm thử hơn là một loại kiểm thử.

Nhiều thời điểm chúng ta cảm thấy rằng kiểm thử tích hợp đòi hỏi việc viết những đoạn code nhỏ để kiểm thử những module được tích hợp, vì vậy về cơ bản nó là phương pháp kiểm thử hộp trắng. Điều này không hoàn toàn sai, nhưng tôi cảm thấy khái niệm về kiểm thử tích hợp cũng có thể được sử dụng trong phương pháp kiểm thử hộp đen.

Khi nói về thuật ngữ kiểm thử ứng dụng lớn sử dụng phương pháp kiểm thử hộp đen, bao gồm sự kết hợp của nhiều module được liên kết một cách chặt chẽ với nhau, chúng ta có thể sử dụng các khái niệm phương pháp kiểm thử tích hợp cho việc kiểm thử các loại kịch bản này.

Trong phần tiếp theo, tôi sẽ cố gắng chi tiết hóa khái niệm kiểm thử tích hợp và việc thực hiện nó trong cả phương pháp kiểm thử hộp trắng và hộp đen.

Ý nghĩa:

Thông thường, chúng ta thực hiện kiểm thử tích hợp sau kiểm thử đơn vị. Khi mà tất cả các đơn vị độc lập đã được phát triển và đã được kiểm thử, chúng ta bắt đầu kết hợp những module bao gồm các đơn vị đã được kiểm thử đó và bắt đầu thực hiện kiểm thử tích hợp. Vì vậy ý nghĩa của kiểm thử tích hợp khá là rõ minh bạch – Tích hợp/kết hợp module mà các đơn vị của nó đã được kiểm tra từng cái một và kiểm thử hoạt động của nó như một đơn vị được kết hợp.

Vai trò hay mục đích chính của kiểm thử tích hợp là để kiểm thử các giao diện giữa các unit/module. Các module riêng biệt được kiểm thử độc lập trước. Khi việc kiểm thử các module hoàn thành, chúng được tích hợp với nhau từng cái một, cho đến khi tất cả các module được tích hợp, để kiểm tra hoạt động sau phối hợp, và xác nhận liệu những yều cầu của ứng dụng được implement đúng hay không.

Ở đây, chúng ta nên hiểu rằng, kiểm thử tích hợp không xảy ra ở giai đoạn cuối của vòng đời phát triển phần mềm, đúng hơn nó được tiến hành đồng thời với sự phát triển. Do vậy trong hầu hết các trường hợp tất cả các module không thực sự có sẵn để kiểm thử và đây là những thách thức đi kèm để kiểm thử một số thứ không tồn tại!

Phương pháp tiếp cận

Có 2 phương pháp tiếp cận cơ bản cho việc thực hiện kiểm thử tích hợp: Tiếp cận từ dưới lên và Tiếp cận từ trên xuống.

Hãy xem xét ví dụ minh họa dưới đây để kiểm tra các phương pháp tiếp cận:

Phương pháp tiếp cận từ dưới lên: Kiểm thử từ dưới lên, như gợi ý tên gọi, bắt đầu từ đơn vị thấp nhất hoặc trong cùng của ứng dụng, và dần dần di chuyển lên. Kiểm thử tích hợp bắt đầu từ module thấp nhất và dần dần tiến tới các module cao hơn của ứng dụng. Sự tích hợp này tiếp tục cho tới khi tất cả các module được tích hợp và toàn bộ ứng dụng được kiểm thử như một đơn vị duy nhất.

Trong trường hợp này, các module B1C1, B1C2 & B2C1, B2C2 là những module thấp nhất hay là những đơn vị đã được kiểm thử. Module B1 và B2 chưa được phát triển. Vai trò của module B1 và B2 là , nó gọi tới các modules B1C1, B1C2 và B2C1, B2C2. Khi B1 và B2 chưa được phát triển, chúng ta sẽ cần một số chương trình hoặc một trình giả lập để gọi các modules B1C1, B1C2 và B2C1, B2C2. Những chương trình giả lập này được gọi là Drivers (các trình điều khiển).

Nói một cách đơn giản, Drivers là các chương trình giả cái mà được sử dụng để gọi các functions của module thấp nhất trong trường hợp các function được gọi không tồn tại. Phương pháp tiếp cận từ dưới lên yêu cầu trình điều khiển module để cung cấp test case đầu vào cho giao diện của module đang được kiểm thử.

Ưu điểm: Nếu một lỗi lớn tồn tại ở đơn vị thấp nhất của chương trình, sẽ dễ dàng hơn để phát hiện ra nó, và những biện pháp đúng sẽ được thực hiện.

Nhược điểm: Chương trình chính thực sự không tồn tại cho đến khi module cuối cùng được tích hợp và kiểm thử. Kết quả là, các lỗ hổng về thiết kế ở cấp cao hơn sẽ được phát hiện chỉ ở cuối vòng đời.

Phương pháp tiếp cận từ trên xuống:

Phương pháp này bắt đầu từ module cao nhất và dần dần tiến tới các module thấp hơn. Chỉ module cao nhất là đơn vị được kiểm thử độc lập. Sau đó, những module thấp hơn được tích hợp từng cái một. Qúa trình được lặp lại cho đến khi tất cả các modules được tích hợp và kiểm thử.

Trong bối cảnh ví dụ minh họa của chúng ta, việc kiểm thử bắt đầu từ Module A, và các modules thấp hơn B1 và B2 được tích hợp từng cái một. Hiện tại, đây là những modules thấp hơn B1 và B2 không thực sự có sẵn cho sự tích hợp. Vì vậy, trong yêu cầu để kiểm thử module cao nhất A, chúng ta phát triển “STUBS” . “Stubs” có thể được coi như việc viết một đoạn mã cái mà chấp nhận những dữ liệu đầu vào/ yêu cầu từ modue cao nhất và trả về kết quả. Theo cách này, mặc dù những modules thấp hơn không tồn tại, chúng ta vẫn có thể kiểm thử module cao nhất.

Trong các kịch bản thực hành, hoạt động của stubs không đơn giản như nó biểu hiện. Trong thời đại của những modules và kiến trúc phức tạp, module được gọi, trong hầu hết các trường hợp bao gồm logic doanh nghiệp phức tạp như việc kết nối với một cơ sở dữ liệu. Kết quả là việc tạo Stubs trở lên phức tạp và mất thời gian như một module thực sự . Trong một số trường hợp, Stubs module có thể thành ra lớn hơn những module được giả lập. Cả Stubs và Drivers là những đoạn mã giả cái mà được sử dụng cho việc kiểm thử những module không tồn tại. Chúng khởi động các functions và trả về câu trả lời, cái mà được so sahs với kết quả mong đợi.

Chỉ có thay đổi là hằng số trong thế giới này, vì vậy chúng ta có một cách tiếp cận khác gọi là “kiểm thử Sandwich” cái mà kết hợp đặc điểm của cả hai phương pháp tiếp cận từ dưới lên và từ trên xuống. Khi chúng ta kiểm thử một chương trình lớn như các hệ điều hành, chúng ta phải có nhiều hơn những phương pháp hiệu quả và gia tăng nhiều hơn sự tự tin. Kiểm thử Sandwich đóng một vai trò vô cùng quan trọng ở đây, khi mà cả kiểm thử từ trên xuống và từ dưới lên được bắt đầu đồng thời.

Sự tích hợp bắt đầu từ lớp giữa và di chuyển đồng thời lên trên và xuống dưới. Trong trường hợp ví dụ minh họa của chúng ta, việc kiểm thử sẽ bắt đầu từ B1 và B2, một nhánh sẽ kiểm thử module A cao hơn và nhánh khác sẽ kiểm thử các module thấp hơn B1C1, B1C2 và B2C1, B2C2. Khi cả 2 kiểu tiếp cận bắt đầu đồng thời, phương pháp này hơi phức tạp một chút và yêu cầu nhiều người hơn cùng với bộ các kĩ năng cụ thể và do đó làm tăng thêm chi phí.

Trong phần sau, tôi sẽ giới thiệu phần còn lại của bài báo: Kiểm thử tích hợp giao diện đồ họa của ứng dụng và Tại sao lại cần kiểm thử tích hợp?

Link dịch: http://www.softwaretestinghelp.com/what-is-integration-testing/