Действительно ли интеграционное тестирование является обобщающим понятием и если так, какие типы тестов оно включает?
Я нахожу понятие 'интеграционного тестирования' сбивающим с толку. Кажется, существует довольно много объяснений и объемов:
- Функциональные / приемочные испытания (например, тестирование пользовательского интерфейса с, например, Селен)
- Тестирование интеграции различных классов/модулей программного обеспечения вместе (просто тестирующий два или больше класса вместе, без них делающий что-либо специальное как вызовы дб и материал)
- Тестируя конфигурацию системы function/feature-independently (работы интеграции базы данных, зависимости правильно введены, работа базовых классов безопасности),
- Тестируя систему как целую (рабочие сервисы, которые используют базы данных, веб-сервисы, и т.д.),
- и т.д. и т.д.
Я начинаю рассматривать интеграционное тестирование как обобщающее понятие (в противоположность определению его в программировании переговоров, где определенное/строгое значение часто дается ему):
- Интеграционное тестирование содержит:
- Интеграционное тестирование единицы (тестируют интеграцию различных классов в том же пакете, не называя внешние библиотеки),
- Функциональные / приемочные испытания (тестируют окончательный результат программного обеспечения через Селен, например),
- Тестирование системы (включает различный, больше технических и связанных с нефункцией тестов, как перечислено в статье Wikipedia),
В жизненный цикл значения по умолчанию Знатока существуют только фазы 'теста' и 'интеграционного теста'. Это, кажется, разделяет тесты примерно на две категории и согласилось бы с этими предположениями.
Существует много существующих вопросов и ответов, ища различия между поблочным тестированием, функциональным тестированием, регрессионным тестированием, и т.д. в целом. Однако я ищу более определенный ответ относительно интеграционных тестов: как Вы категоризируете интеграционное тестирование и что Вы включаете в нем? Кроме того, сделайте Вы избегаете программного обеспечения разделения, тестирующего примерно в две категории, поскольку я сделал: модульные тесты (1 единица) по сравнению с интеграционными тестами (2 + единицы)?
3 ответа
Вычислительная техника полна перегруженных терминов, которые имеют немного (а иногда и не очень немного) разное значение для любого программиста, с которым вы разговариваете. Интеграционное тестирование - один из таких терминов.
Я склоняюсь к вашей интерпретации интеграционного тестирования как тестирования двух или более модулей, соединенных вместе. Но это все еще довольно нечетко, поскольку у нас могут быть разные определения того, что такое "единица".
Я думаю, что более важно, чтобы команда разработчиков договорилась о том, что они подразумевают под интеграционным тестированием, а не нашла единственно верное определение интеграционного тестирования.
Моя команда видит (используя ваши слова) интеграционное тестирование как охватывающее
- Тестирование интеграции различных классов / модулей программного обеспечения вместе (просто тестирование двух или более классов вместе, при этом они ничего не делают специальные, такие как вызовы базы данных и прочее)
- Независимое тестирование функции / функции конфигурации системы (интеграция с базой данных работает, зависимости правильно введены, базовые классы безопасности работают)
и ничего больше. Системные и приемочные тесты мы рассматриваем как разные семейства.
мы долго обсуждали это, чтобы убедиться, что все мы говорим на одном языке, когда говорим о тестах.
Я не сильно не согласен с тем, что вы определяете как интеграционные тесты, но я просто говорю, что было бы неплохо, если бы все люди, с которыми вы работаете, согласовали классификацию.
Итак, у вас есть модульное тестирование, точное определение которого варьируется, но оно, безусловно, содержит все те тесты, которые определены с помощью инструмента, подобного JUnit, и организованы таким же образом, как и исходный код. Если для любого файла исходного кода вы можете найти один и только один тест, то вы нашли модульный тест.
И затем есть системное тестирование, при котором вся система тестируется настолько близко, насколько это возможно, так, чтобы клиент мог ее увидеть.
Любое тестирование, которое находится в разрыве между этими двумя вещами, является интеграционным тестом - ни изоморфным исходному коду, ни репрезентативным для конечного пользователя.
Это довольно большой разрыв между двумя категориями, которые сами по себе сильно различаются на практике. Этот пробел может содержать множество потенциально полезных тестов, но природа этих тестов, естественно, будет сильно различаться.