AkinyimeПодставить как реальный объект другого класса, так и заглушку, тогда интеграционное тестирование – это то же модульное тестирование, но с передачей реальных зависимостей. Целью интеграционного тестирования является проверка соответствия проектируемых единиц функциональным, приёмным и требованиям надежности. Тестирование этих проектируемых единиц — объединения, множества или группы модулей — выполняется через их интерфейс, с использованием тестирования «чёрного ящика». Множественные секции действий в тестах оправданны только в том случае, если тест работает с внепроцессными зависимостями, которые трудно привести в нужное состояние. Никогда не включайте несколько действий в юнит-тест, потому что юнит-тесты не работают с внепроцессными зависимостями. Взаимодействия с управляемыми зависимостями являются деталями имплементации; взаимодействия с неуправляемыми зависимостями являются частью наблюдаемого поведения вашей системы.
Применить алгоритм, составляющий оптимальное число тестов с полным перебором пар. Сверху вниз — начинается с тестирования более крупных и сложных модулей и постепенно спускается до более мелких и базовых. Циклические зависимости увеличивают когнитивную нагрузку при попытках разобраться в коде.
Тест-кейс и тестовый сценарий
Интеграционное тестирование может быть сложным процессом, особенно при тестировании интеграции множества различных систем, включая базы данных, платформы и среды. Кроме того, необходимо уделить должное внимание тому, чтобы каждый тест не оказывал негативного влияния на производительность сам по себе и не мешал другим текущим тестам, выполняющимся одновременно в параллельных потоках. Такая зависимость от различных ресурсов может увеличить сложность набора тестов и затруднить последовательное воспроизведение результатов на последующих этапах разработки. Они могут включать в себя одновременный запуск нескольких различных тестов против нескольких копий производственного кода или данных.
- Это означает, что интеграционное тестирование является важным этапом в процессе тестирования для большинства команд разработчиков программного обеспечения.
- Интеграционное тестирование проверяет работу нескольких модулей в группе.
- Это тоже является ошибкой процессов, особенно в краткосрочных циклах — контрпродуктивно долго ждать результатов интеграционных тестов, когда функция готова.
- Подход Большого взрыва (Big Bang Approach) — это подход в тестировании, при котором все компоненты тестируются одновременно после сборки в одну систему.
- Кроме того, в отличие от ZAPTEST, который предлагает неограниченное количество лицензий за фиксированную плату, большинство инструментов интеграционного тестирования уровня предприятия ограничивают количество лицензий.
- На самом низком уровне пирамиды, во время юнит-тестирования, проверяются отдельные модули приложения.
Применение парного тестирования сократило количество тестовых случаев с 18 до 9, обеспечив эффективную проверку взаимодействия параметров. Техника попарного тестирования очень помогает при разработке тестов для приложений, включающих множество параметров. Тесты разрабатываются таким образом, что для каждой пары входных параметров существуют все возможные комбинации этих параметров. Поэтому техника хоть и не обеспечивает исчерпывающее тестирование, но все же является эффективной для поиска ошибок. Используя интеграционное тестирование, разработчики и тестировщики могут убедиться в том, что система работает как ожидается в реальной среде. Первым этапом проведения интеграционных тестов всегда является создание тщательного плана интеграционных тестов.
Для чего нужно интеграционное тестирование?
Доменная модель представляет собой совокупность знаний о предметной области задачи, для решения которой предназначен ваш проект. Юнит-тесты должны ориентироваться на доменную модель и алгоритмы, тогда как интеграционные тесты — на контроллеры. Таким образом, четкое разграничение между доменными классами и контроллерами также помогает отделить юнит-тесты от интеграционных. Для интеграционного теста выберите самый длинный позитивный путь, проверяющий взаимодействия со всеми внепроцессными зависимостями.
Поддерживать обратную совместимость во взаимодействиях с управляемыми зависимостями не обязательно, потому что никто, кроме вашего приложения, с ними не работает. Внешних клиентов не интересует, как устроена ваша база данных; важно только итоговое состояние вашей системы. Использование реальных экземпляров управляемых зависимостей в интеграционных тестах помогает проверить это итоговое состояние с точки зрения внешних клиентов. Интеграционное тестирование «снизу вверх» имеет высокие показатели успешности и является относительно быстрой и эффективной формой интеграционного тестирования. Даже если каждый модуль в отдельности работает идеально, если они не работают слаженно вместе, программное приложение не соответствует своему назначению. Это означает, что интеграционное тестирование является важным этапом в процессе тестирования для большинства команд разработчиков программного обеспечения.
Пример №2. Тестирование мобильного приложения видеозвязи
Многие разработчики стремятся к абстрагированию и обобщению кода путем введения дополнительных уровней абстракции. База данных — не лучший механизм для интеграции между системами, потому что она связывает эти системы друг с другом и усложняет дальнейшую их разработку. Правильнее осуществлять интеграцию через API (для синхронных взаимодействий) или шину сообщений (для асинхронных взаимодействий). Инструменты тестирования корпоративной интеграции, такие как ZAPTEST, являются более дорогим вариантом, но они предлагают более продвинутые, мощные и масштабируемые функции.
Применение попарного тестирования обеспечивает оптимальное соотношение стоимости и качества. Это означает, что использование попарного тестирования позволяет достигнуть высокого уровня качества программного обеспечения с меньшими затратами по сравнению с другими методами. Техника попарного тестирования помогает существенно уменьшить количество комбинаций проверок, достаточных для обеспечения необходимого уровня качества программного обеспечения. Это в самом деле умная техника тест-дизайна, которая гарантирует беспроигрышный результат как с точки зрения усилий и задействованных ресурсов, так и с точки зрения эффективности тестирования. ISTQB определяет попарное тестирование как технику тест-дизайна методом черного ящика, при которой тест-кейсы создаются таким образом, чтобы выполнить все возможные отдельные комбинации каждой пары входных параметров. Процесс повторяется до тех пор, пока не будет проверен компонент в верхней части иерархии.
Когда использовать
Интеграционное тестирование снизу вверх — это процесс, в котором отдельные компоненты тестируются и интегрируются, начиная с самого нижнего модуля в архитектуре и работая вверх. Преимущество использования подхода интеграционного тестирования «сверху вниз» заключается в том, что он относительно прост в реализации и имеет минимальные зависимости от других частей вашего приложения. Наиболее популярными подходами в инкрементальном интеграционном тестировании являются нисходящее тестирование, восходящее тестирование и многослойное тестирование. Интеграционное тестирование «большого взрыва» подходит для небольших систем, где в случае возникновения ошибки меньше возможностей для путаницы относительно ее местонахождения и причины. Ручное тестирование проводится поэтапно, при этом тестировщики добавляют каждый новый модуль по очереди и проверяют функциональность и производительность каждого модуля на каждом этапе процесса тестирования.
В следующих абзацах я расскажу дополнительные подробности относительно этих условий, а также объясню разницу между интеграционным и функциональным тестированием. Важно отметить, что моки не являются полноценными реализациями зависимостей, а лишь эмулируют их поведение в контролируемой среде тестирования. Моки создаются с целью контролировать и проверять, как компонент взаимодействует с внешними зависимостями. При использовании моков можно установить ожидаемое поведение этих зависимостей и проверить, что компонент правильно взаимодействует с ними в рамках тестируемого сценария. Spring Test — швейцарский нож для написания автоматизированных тестов.
Улучшить покрытие тестов и надежность
Для определения возможных значений могут быть полезны такие техники, как анализ граничных значений и использование классов эквивалентности. Однако тестировать все возможные комбинации значений для всех факторов — непрактично. Поэтому, чтобы удовлетворить все факторы, генерируется подмножество комбинаций. Моки попарное интеграционное тестирование часто используются в изоляционном тестировании, когда требуется проверить функциональность отдельного компонента в изоляции от остальной системы. Они помогают создать управляемую среду тестирования и сосредоточиться на конкретном компоненте, исключая возможные проблемы, связанные с реальными зависимостями.
В таких случаях QA-инженеры создают «заглушки» различных типов, заменяющие функции отсутствующих модулей. Делая это заблаговременно, можно обеспечить быстрый проход интеграции. Ручное тестирование сложный процесс, случаются ошибки, особенно в сложных и многократно повторяемых тест-кейсах. В таких случаях автоматизация дает избавление от монотонных задач, требующих внимательности, и экономит кучу времени, позволяя команде сфокусироваться на критических проблемах. При этом следует позаботиться, чтобы было правильно настроено тестовое окружение, которое эмулирует продакшен-окружение. Это тоже является ошибкой процессов, особенно в краткосрочных циклах — контрпродуктивно долго ждать результатов интеграционных тестов, когда функция готова.