Тестирование интеграционное. Классы и виды тестов
Лекция является второй из трех рассматривающих уровни процесса верификации. Тема данной лекции - процесс интеграционного тестирования, его задачи и цели. Рассматриваются организационные аспекты интеграционного тестирования - структурная и временная классификации методов интеграционного тестирования, планирование интеграционного тестирования. Цель данной лекции: дать представление о процессе интеграционного тестирования, его технической и организационной составляющих
Задачи и цели интеграционного тестирования
Результатом тестирования и верификации отдельных модулей, составляющих программную систему, должно быть заключение о том, что эти модули являются внутренне непротиворечивыми и соответствуют требованиям. Однако отдельные модули редко функционируют сами по себе, поэтому следующая задача после тестирования отдельных модулей - тестирование корректности взаимодействия нескольких модулей, объединенных в единое целое. Такое тестирование называют интеграционным. Его цель удостовериться в корректности совместной работы компонент системы.
Интеграционное тестирование называют еще тестированием архитектуры системы. С одной стороны, это название обусловлено тем, что интеграционные тесты включают в себя проверки всех возможных видов взаимодействий между программными модулями и элементами, которые определяются в архитектуре системы - таким образом, интеграционные тесты проверяют полноту взаимодействий в тестируемой реализации системы. С другой стороны, результаты выполнения интеграционных тестов - один из основных источников информации для процесса улучшения и уточнения архитектуры системы, межмодульных и межкомпонентных интерфейсов. Т.е., с этой точки зрения, интеграционные тесты проверяют корректность взаимодействия компонент системы.
Примером проверки корректности взаимодействия могут служить два модуля, один из которых накапливает сообщения протокола о принятых
Синицын С.В., Налютин Н.Ю. Верификация программного обеспечения
файлах, а второй выводит этот протокол на экран. В функциональных требованиях к системе записано, что сообщения должны выводиться в обратном хронологическом порядке. Однако, модуль хранения сообщений сохраняет их в прямом порядке, а модуль вывода использует стек для вывода в обратном порядке. Модульные тесты, затрагивающие каждый модуль по отдельности, не дадут здесь никакого эффекта - вполне реальна обратная ситуация, при которой сообщения хранятся в обратном порядке, а выводятся с использованием очереди. Обнаружить потенциальную проблему можно только проверив взаимодействие модулей при помощи интеграционных тестов. Ключевым моментом здесь является то, что в обратном хронологическом порядке сообщения выводит система в целом, т.е., проверив модуль вывода и обнаружив, что он выводит сообщения в прямом порядке, мы не сможем гарантировать, что мы обнаружили дефект.
В результате проведения интеграционного тестирования и устранения всех выявленных дефектов получается согласованная и целостная архитектура программной системы, т.е. можно считать, что интеграционное тестирование - это тестирование архитектуры и низкоуровневых функциональных требований.
Интеграционное тестирование, как правило, представляет собой итеративный процесс, при котором проверяется функциональной все более и более увеличивающейся в размерах совокупности модулей.
12 ответов
Интеграционное тестирование - это когда вы тестируете несколько компонентов и как они работают вместе. Например, как другая система взаимодействует с вашей системой или база данных взаимодействует с уровнем абстракции данных. Обычно для этого требуется полностью установленная система, хотя в ее чистых формах она не работает.
Функциональное тестирование - это когда вы тестируете систему в соответствии с функциональными требованиями продукта. Управление продуктами/проектами обычно записывает эти данные, и QA формализует процесс того, что пользователь должен видеть и испытывать, и каков конечный результат этих процессов. В зависимости от продукта это может быть автоматизировано или нет.
Функциональное тестирование: Да, мы тестируем продукт или программное обеспечение в целом функционально независимо от того, работает ли он функционально или нет (кнопки тестирования, ссылки и т.д.)
Например: Страница входа
вы указываете имя пользователя и пароль, вы проверяете, ведет ли он вас на домашнюю страницу или нет.
Тестирование интеграции: Да, вы тестируете только интегрированное программное обеспечение, но вы проверяете, где происходит поток данных, и происходят ли какие-либо изменения в базе данных.
Например: Отправка электронной почты
Вы отправляете кому-то одно сообщение, есть поток данных, а также изменение в базе данных (отправленная таблица увеличивает значение на 1)
Надеюсь, это помогло вам.
Это важное различие, но, к сожалению, вы никогда не найдете согласия. Проблема в том, что большинство разработчиков определяют их с их собственной точки зрения. Это очень похоже на дебаты о Плутоне. (Если бы это было ближе к Солнцу, это была бы планета?)
Единичное тестирование легко определить. Он тестирует CUT (Code Under Test ) и ничего больше. (Ну, как можно меньше.) Это значит, что это издевательства, подделки и светильники.
На другом конце спектра есть то, что многие люди называют тестированием системной интеграции. Это тестирование как можно больше, но все еще ищет ошибки в вашем собственном CUT.
Но как насчет обширного пространства между?
- Например, что, если вы проверите немного больше, чем CUT? Что делать, если вы включили функцию Фибоначчи вместо использования приспособления, которое вы ввели? Я бы назвал это функциональное тестирование, но мир не согласен со мной.
- Что делать, если вы включили time() или rand() ? Или что, если вы вызываете http://google.com ? Я бы назвал это тестирование системы, но опять же, я один.
Почему это имеет значение? Потому что системные тесты ненадежны. Они необходимы, но иногда они могут потерпеть неудачу по причинам, не зависящим от вас. С другой стороны, функциональные тесты всегда должны проходить, а не случайным образом; если они бывают быстрыми, их можно также использовать с самого начала, чтобы использовать Test-Driven Development без написания слишком большого количества тестов для вашей внутренней реализации. Другими словами, я думаю, что модульные тесты могут быть более сложными, чем они того стоят, и у меня хорошая компания .
Я поставил тесты на 3 оси, со всеми их нулями при модульном тестировании:
- Функциональное тестирование: использование реального кода глубже и глубже в вашем стеке вызовов.
- Интеграция-тестирование: выше и выше ваш стек вызовов; другими словами, тестирование вашего CUT путем запуска кода, который будет использовать его.
- Системное тестирование: все больше и больше неповторимых операций (планировщик O/S, часы, сеть и т.д.).
Тест может легко быть все 3 в разной степени.
Функциональное тестирование: это процесс тестирования, в котором тестируются каждый компонент модуля. Например: если веб-страница содержит текстовое поле, необходимо проверить флажки радиобота, кнопок и выпадающих и т.д.
Тестирование интеграции: процесс, в котором проверяется поток данных между двумя модулями.
Интеграционное тестирование. Тестирование интеграции - это не что иное, как тестирование различных модулей. Вы должны проверить взаимосвязь между модулями. Например, вы открываете facebook, после чего вы видите страницу входа в систему после ввода идентификатора входа и пароля, вы можете видеть домашнюю страницу facebook, поэтому страница входа - это один модуль, а домашняя страница - это еще один модуль. вы должны проверять только связь между ними, когда вы вошли в систему, тогда только домашняя страница должна быть открыта, а не поле сообщения или что-то еще. Существует два основных типа интеграционного тестирования: подход TOP-DOWN и подход BOTTOM UP.
Функциональное тестирование. В функциональном тестировании вы должны думать только о вводе и выводе. В этом случае вы должны думать, как настоящий пользователь. Тестирование того, что вы дали и какой результат вы получили, - это функциональное тестирование. вам нужно только наблюдать за выходом. При функциональном тестировании вам не нужно тестировать кодирование приложения или программного обеспечения.
В тесте функционального тестирования основное внимание уделяется функциональности и вспомогательной функциональности приложения. Функциональность приложения должна работать правильно или нет.
В тесте тестирования интеграции необходимо проверить зависимость между модулями или подмодулями. Пример для записей модулей должен быть корректно отображен и отображен в другом модуле.
Интеграционный тест: - Когда выполняется тестирование модуля и устранены проблемы с соответствующими компонентами, тогда все необходимые компоненты должны интегрироваться в одну систему, чтобы она могла выполнять операцию. После объединения компонентов системы Чтобы проверить, работает ли система правильно или нет, этот тип тестирования называется интеграционным тестированием.
Функциональное тестирование: - Тестирование в основном разделено на две категории: 1.Функциональное тестирование 2. Нефункциональное тестирование ** Функциональное тестирование: - Проверить, работает ли программное обеспечение в соответствии с требованиями пользователя или нет. ** Нефункциональное тестирование: - Чтобы проверить, соответствует ли программное обеспечение критериям качества, таким как стресс-тест, тест безопасности и т.д.
Обычно Клиент предоставляет требования только для функционального теста и для не-функционального теста, требования не должны упоминаться, но приложение обязательно выполняет эти действия.
Я бы сказал, что оба они тесно связаны друг с другом и очень сложно различать их. На мой взгляд, тестирование интеграции - это подмножество функционального тестирования.
Проверка функциональности основана на исходных требованиях, которые вы получаете. Вы будете тестировать поведение приложения, как и ожидалось, с требованиями.
Когда дело доходит до интеграционного тестирования, это взаимодействие между модулями. Если модуль отправляет вход, модуль B может обрабатывать его или нет.
Тестирование интеграции
Можно видеть, как разные модули системы работают вместе. Мы в основном ссылаемся на интегрированную функциональность различных модулей, а не на разные компоненты системы. Для эффективной работы любой системы или программного продукта каждый компонент должен синхронизироваться друг с другом. В большинстве случаев инструмент, который мы использовали для тестирования интеграции, будет выбран, который мы использовали для модульного тестирования. Он используется в сложных ситуациях, когда модульное тестирование оказывается недостаточным для тестирования системы.
Функциональное тестирование
Его можно определить как тестирование отдельных функциональных возможностей модулей. Это относится к тестированию программного продукта на индивидуальном уровне, чтобы проверить его функциональность. Для проверки программного обеспечения для ожидаемых и неожиданных результатов разработаны тестовые примеры. Этот тип тестирования выполняется больше с точки зрения пользователя. То есть, он учитывает ожидание пользователя для ввода типа. Он также называется тестированием черного ящика, а также тестом с закрытым ящиком
Всего приложения. Но между этими двумя этапами тестирования происходят и другие. Я, как и многие другие, называю такие тесты интеграционными.
Несколько слов о терминологии
Много общаясь с любителями разработки через тестирование, я пришёл к выводу, что они имеют другое определение для термина «интеграционные тесты». С их точки зрения, интеграционный тест проверяет «внешний» код, то есть тот, который взаимодействует с «внешним миром», миром приложения.
Поэтому, если их код использует Ajax или localStorage, или IndexedDB и, следовательно, не может быть протестирован с помощью юнит-тестов, они оборачивают этот функционал в интерфейс и мокают этот интерфейс для юнит-тестов, а тестирование реальной реализации интерфейса называют «интеграционным тестом». С этой точки зрения «интеграционный тест» просто тестирует код, который взаимодействует с «реальным миром» вне тех юнитов, которые работают без учета реального мира.
Я, как и многие другие, склонен использовать понятие «интеграционные тесты» для обозначения тестов, которые проверяют интеграцию двух или более юнитов (модулей, классов и т. д.). При этом неважно, скрываете ли вы реальный мир через замоканные интерфейсы.
Мое эмпирическое правило о том, следует ли использовать реальные реализации Ajax и других операций I/O (ввода-вывода) в интеграционных тестах, заключается в следующем: если вы можете это сделать и тесты все еще выполняются быстро и не ведут себя странно, то проверяйте I/O. Если операция I/O сложная, медленная или просто странная, то используйте в интеграционных тестах mock-объекты.
В нашем калькуляторе, к счастью, единственным реальным I/O является DOM. Нет вызовов Ajax и других причин писать «моки».
Фейковый DOM
Возникает вопрос: нужно ли писать фейковый DOM в интеграционных тестах? Применим моё правило. Использование реального DOM сделает тесты медленными? К сожалению, ответ - «да»: использование реального DOM означает использование реального браузера, что делает тесты медленными и непредсказуемыми.
Мы отделим большую часть кода от DOM или протестируем всё вместе в E2E-тестах? Оба варианта не оптимальны. К счастью, есть третье решение: jsdom . Этот замечательный и удивительный пакет делает именно то, чего от него ждёшь - реализует DOM в NodeJS.
Он работает, он быстр, он запускается в Node. Если вы используете этот инструмент, то можете перестать рассматривать DOM как «I/O». А это очень важно, ведь отделить DOM от фронтенд-кода сложно, если не невозможно. (Например, я не знаю, как сделать это.) Я предполагаю, что jsdom был написан именно для запуска фронтенд-тестов под Node.
Давайте посмотрим, как он работает. Как обычно, есть инициализирующий код и есть тестовый код, но на этот раз мы начнём с тестового. Но перед этим - отступление.
Отступление
Эта часть является единственной частью серии, которая ориентирована на конкретный фреймворк. И фреймворк, который я выбрал - это React. Не потому, что это лучший фреймворк. Я твердо верю, что нет такого понятия. Я даже не считаю, что существуют лучшие фреймворки для конкретных случаев использования. Единственное, во что я верю - люди должны использовать среду, в которой им наиболее комфортно работать.
И фреймворком, с которым мне наиболее комфортно работать, является React, поэтому следующий код написан на нём. Но, как мы увидим, интеграционные тесты фронтенда с использованием jsdom должны работать во всех современных фреймворках.
Вернемся к использованию jsdom.
Использование jsdom
const React = require("react") const e = React.createElement const ReactDom = require("react-dom") const CalculatorApp = require("../../lib/calculator-app") ... describe("calculator app component", function () { ... it("should work", function () { ReactDom.render(e(CalculatorApp), document.getElementById("container")) const displayElement = document.querySelector(".display") expect(displayElement.textContent).to.equal("0")Интересными являются строки с 10 по 14. В строке 10 мы визуализируем компонент CalculatorApp , который (если вы следите за кодом в репозитории) также отображает компоненты Display и Keypad .
Затем мы проверяем, что в строках 12 и 14 элемент в DOM показывает на дисплее калькулятора начальное значение, равное 0.
И этот код, который работает под Node, использует document ! Глобальная переменная document является переменной браузера, но вот она здесь, в NodeJS. Чтобы эти строки работали, требуется очень большой объем кода. Этот очень большой объем кода, который находится в jsdom, является, по сути, полной реализацией всего, что есть в браузере, за вычетом самого рендеринга!
Строка 10, которая вызывает ReactDom для визуализации компонента, также использует document (и window), так как ReactDom часто использует их в своем коде.
Итак, кто создает эти глобальные переменные? Тест - давайте посмотрим на код:
Before(function () { global.document = jsdom(`