Что такое тестирование модулей и тестирование интеграции, а также какие другие типы тестирования я должен знать?

Ответ 1

Сверху моей головы:

• Единичное тестирование в смысле "тестирования самой маленькой изолирующей единицы приложения"; это обычно метод или класс, в зависимости от масштаба.
• Интеграционное тестирование
• Тестирование функций: это может пересекать единицы измерения и находится в центре внимания TDD.
• Тестирование Black-box: тестирование только открытого интерфейса без знания того, как это работает.
• Тестирование стеклопакетов: тестирование всех частей вещи с полным пониманием того, как она работает.
• Регрессионное тестирование: тестовые примеры, созданные для воспроизведения ошибок, чтобы они не появлялись позже.
• Бесцельное тестирование: тестирование одного и того же базового случая более чем одним способом или тестирование настолько тривиальных вещей, что их действительно не нужно тестировать (например, автогенераторы и сеттеры)

Ответ 2

Должен ли я быть в курсе любого другого важного тестирования моего кода?

Это некоторые из разных видов тестов в соответствии с различными этапами жизненного цикла программного обеспечения:

• Unit test: работает ли этот немного кода?
• Unit test suite: последовательность многих модульных тестов (для многих небольших фрагментов кода)
• Интеграционный тест: проверьте, работают ли два компонента вместе, когда они объединены (или "интегрированы" ).
• Системный тест: проверьте, работают ли компоненты все, когда они объединены (или "интегрированы" )
• Приемочный тест: что клиент делает, чтобы решить, что он хочет вам заплатить (системный тест обнаруживает, работает ли программное обеспечение как разработанное... приемочный тест обнаруживает, является ли "как-то" желаемый клиент)

Там больше:

• Тест удобства использования
• Тест производительности
• Тест нагрузки
• Стресс-тест

И многое другое... программное обеспечение для тестирования почти такое же, как и написание программного обеспечения.

Ответ 3

MSDN: Тестирование устройств

Основная цель модульного тестирования - взять самую маленькую часть проверяемого программного обеспечения в приложении, изолировать это от остальной части кода и определить, будет ли он вести себя точно как вы ожидаете. Каждый блок проверен отдельно до их интеграции в модули для тестирования интерфейсов между модулями. Единичное тестирование доказал свою ценность в том, что большой процент дефектов идентифицирован во время его использования.

MSDN: тестирование интеграции

Тестирование интеграции является логическим расширение модульного тестирования. В своем простейшая форма, две единицы, которые имеют уже протестированные, объединены в компонент и интерфейс между они протестированы. Компонент в этом смысл, относится к интегрированному совокупность более чем одной единицы. В реалистичный сценарий, многие единицы объединены в компоненты, которые находятся в превратиться в еще более крупные части программы. Идея состоит в том, чтобы проверить комбинации частей и, в конечном счете, разверните процесс, чтобы проверить свои модули с другими группами. В конечном итоге все модули, составляющие процесс тестируются вместе. за что если программа состоит из более одного процесса, они должны быть испытаны парами, а не один раз.

Проверьте сайты для получения дополнительной информации. Существует много информации из других источников, кроме Microsoft.

Ответ 4

Другим важным методом является регрессионное тестирование. В этом методе вы поддерживаете набор тестов (называемых регрессионным набором), которые обычно выполняются как по ночам, так и перед каждой проверкой. Каждый раз, когда вы исправляете ошибку, вы добавляете один или несколько тестов в набор. Цель состоит в том, чтобы остановить вас от повторного введения старых ошибок, которые уже исправлены. (Проблема удивительно распространена!)

Начните накапливать набор регрессии рано, прежде чем ваш проект станет большим, или вы пожалеете об этом. У меня наверняка есть!

Ответ 5

Существуют различные уровни тестирования, соответствующие тому, на каком этапе вы находитесь в жизненном цикле разработки программного обеспечения. Самый высокий уровень - это анализ требований, а самый низкий уровень - это реализация решения.

Что такое модульное тестирование?

• Единичное тестирование оценивает программное обеспечение в отношении его реализации.
• Мы фокусируемся на тестировании единиц программы (то есть на отдельных методах) и игнорируем, кто вызывает/использует эти единицы. Следовательно, мы по существу рассматриваем каждую единицу как отдельную единицу.

• Существует множество инструментов для тестирования модулей, один из самых популярных - JUnit.

• При выполнении модульного тестирования мы хотим построить тестовый набор (набор тестовых примеров), который удовлетворяет определенным критериям покрытия. Это могут быть некоторые критерии структурного охвата (NC, EC, PPC и т.д.) Или критерии потока данных (ADC, AUC, ADUPC и т.д.).

• Обратите внимание, что модульное тестирование является самым низким уровнем тестирования, поскольку оно оценивает фактические единицы кода, созданные после реализации. Этот тип тестирования, который выполняется перед тестированием интеграции.
• Эффективное модульное тестирование помогает гарантировать, что интеграционное тестирование не будет болезненным, поскольку дешевле и проще обнаруживать и исправлять ошибки при проведении модульного тестирования.

Что такое тестирование интеграции?

• Тестирование интеграции необходимо для обеспечения того, чтобы наше программное обеспечение все еще работало при объединении двух или более компонентов.
• Вы можете выполнить интеграционное тестирование до завершения системы.
• Задача порядка интеграции классов (CITO) связана с интеграционным тестированием. CITO имеет отношение к стратегии интеграции компонентов. Существует много предлагаемых решений для CITO, таких как интеграция сверху вниз, интеграция с нижним индексом и т.д. Основная цель состоит в том, чтобы интегрировать компоненты таким образом, чтобы обеспечить эффективное тестирование и наименьшее количество прерываний, поскольку писать заглушки кода не всегда легко и требует времени, Обратите внимание, что это все еще активная область исследований!
• Тестирование интеграции выполняется после модульного тестирования.
• Часто бывает, что отдельные компоненты работают нормально, но когда все объединяется, мы внезапно видим ошибки, возникающие из-за несовместимостей/проблем с интерфейсами.

Другие уровни тестирования включают в себя:

• Тестирование регрессии

  • Этот тип тестирования имеет большое значение, поскольку разработчики часто нередко фиксируют изменения в программном обеспечении, поэтому мы хотим убедиться, что эти изменения не вносят ошибок.
  • Ключом к эффективному регрессионному тестированию является ограничение размера регрессионных тестов, поэтому для завершения тестирования не требуется слишком много времени, иначе тестовый набор не завершится до следующего фиксации. Мы также должны выбрать эффективные тестовые примеры, которые не будут пропускать ошибки.
  • Этот тип тестирования должен быть автоматизирован.
  • Важно отметить, что мы всегда можем добавлять больше машин, чтобы противодействовать увеличению количества регрессионных тестов, но в какой-то момент компромисс не стоит.

• Приемочное тестирование

  • При таком тестировании мы оцениваем программное обеспечение в соответствии с предоставленными требованиями, в основном мы видим, соответствует ли предоставленное нами программное обеспечение требованиям, которые мы предоставили.
  • Обычно это последний тип тестирования, выполняемый в последовательности действий по разработке программного обеспечения. Вследствие этого этот тип тестирования выполняется после модульного тестирования и тестирования интеграции.

Ответ 6

Модульное тестирование - это просто идея написания (надеюсь) небольших блоков кода для проверки независимых частей вашего приложения.

Например, у вас может быть приложение калькулятора, и вы должны убедиться, что функция добавления работает. Для этого вы пишете отдельное приложение, которое вызывает функцию добавления напрямую. Затем ваша тестовая функция будет оценивать результат, чтобы увидеть, если он дживется с тем, что вы ожидали.

Он в основном вызывает ваши функции с известными входами и проверяет вывод именно так, как вы ожидали.

Ответ 7

Первые два результата поиска в google для "типов тестирования" выглядят всеобъемлющими

• www.aptest.com/testtypes.html
• www.softwaretestinghelp.com/types-of-software-testing/

Те, которые я считаю наиболее важными. См. здесь.

Ответ 8

Это была запись, которую я написал: Различные типы автоматизированных тестов.

Ответ 9

Тестирование устройств. Тестирование выполняется на устройстве или на самом маленьком программном обеспечении. Выполнено, чтобы проверить, удовлетворяет ли оно его функциональной спецификации или предполагаемой структуре дизайна.

Тестирование интеграции: Тестирование связанных модулей вместе для совместной работы.

Регрессионное тестирование: Тестирование приложения для проверки того, что изменения не вызвали непреднамеренных эффектов.

Тестирование дыма: проверка дыма проверяется, является ли сборка проверяемой или нет.

Ответ 10

Различные типы тестовых случаев:

Случаи проверки функциональности

Функциональные тестовые примеры используются, чтобы определить, работает ли интерфейс приложений с остальной частью системы и ее пользователями. Тесты идентифицируют успех или неудачу функций, которые программа должна выполнять. Случаи - это тип тестирования "черного ящика", который использует для своей базы спецификации или истории пользователей тестируемого программного обеспечения. Это позволяет проводить тесты без необходимости доступа к работам или внутренним структурам тестируемого программного обеспечения. Команда QA - обычные авторы тестов функциональности, потому что они попадают в обычные процессы QA. Их можно написать и запустить, как только разработка сделает первую функцию доступной для тестирования. Чтобы помочь в управлении разработкой, они могут быть написаны заранее до кода, если все тестер имеет доступ к требованиям. Как указано выше, их можно написать и запустить, как только это станет возможным, и их следует повторять при добавлении обновлений, вплоть до того, когда клиенты станут возможными.

Пример. Подтверждение того, что пользователь может успешно загрузить фотографию профиля.

Тесты пользовательского интерфейса

Тесты пользовательского интерфейса используются для проверки того, что определенные части графического интерфейса пользователя (GUI) выглядят и работают должным образом. Эти типы тестовых примеров могут использоваться для выявления косметических несоответствий, грамматики и орфографических ошибок, ссылок и любых других элементов, с которыми пользователь взаимодействует или видит. Эти случаи обычно пишутся группой тестирования, но команда разработчиков также может быть задействована, поскольку они наиболее знакомы с интерфейсом. Тесты пользовательского интерфейса - это типы тестовых примеров при тестировании программного обеспечения, которые обычно управляют кросс-браузерным тестированием. Браузеры, как правило, делают вещи по-разному, а тестовые примеры пользовательского интерфейса помогают обеспечить постоянство поведения вашего приложения в нескольких браузерах. Эти тестовые примеры будут запускаться после завершения фазы разработки и пользовательского интерфейса подключается к базе данных.

Пример. Что происходит, когда веб-сайт просматривается на маленьком экране, таком как мобильный телефон? Разрыв UI?

Служебные тесты производительности

Тесты производительности проверяют время отклика и общую эффективность приложения. То есть, после выполнения действия, сколько времени потребуется системе для ответа? Тесты производительности должны иметь очень четкий набор критериев успеха. Команда тестирования обычно записывает эти тестовые примеры, и они часто автоматизированы. Большое приложение может иметь сотни или тысячи тестов производительности. Автоматизация этих тестов и их частое использование помогает выявлять сценарии, в которых приложение не работает на ожидаемом уровне. Тесты производительности помогают понять, как приложение будет работать в реальном мире. Эти случаи могут быть записаны после того, как у тестирующей команды есть требования к производительности от группы продуктов. Тем не менее, многие проблемы с производительностью можно идентифицировать вручную без определенных требований.

Пример. Сколько времени требуется, чтобы система проверила подлинность пользователя и загрузила следующую страницу? Когда несколько пользователей заходят в одно и то же время, приложение остается стабильным?

Служебные тесты интеграции

Служебные тесты интеграции предназначены для определения того, как разные модули взаимодействуют друг с другом. Основная цель с интеграционными тестовыми примерами - обеспечить правильную работу интерфейсов между различными модулями. Группа тестирования определяет, какие области должны проходить интеграционное тестирование, а команда разработчиков будет иметь информацию о том, как эти тестовые примеры должны быть написаны. Любая из этих двух команд может работать над написанием дел. Они проверяют, что модули, которые уже работают индивидуально, также могут работать вместе.

Пример: проверка связи между главной страницей и разделом "избранное". Когда вы добавляете элемент в качестве "любимого", с домашней страницы отображается в разделе "Избранное"?

Случаи проверки удобства использования

Случаи проверки удобства использования часто можно назвать "задачами" или "сценариями". Вместо того, чтобы предоставлять подробные пошаговые инструкции для выполнения теста, тестеру предоставляется сценарий или задача высокого уровня для завершения. Тесты удобства использования помогают определить, как пользователь естественно подходит и использует приложение. Они помогают вести тестер через различные ситуации и потоки. Предварительное знание приложения не требуется. Эти тестовые примеры, как правило, разрабатываются командой разработчиков вместе с группой тестирования. Тестирование юзабилити должно проводиться до проведения приемочных испытаний пользователей.

Пример. Может ли пользователь успешно добавить более одного элемента в свою корзину покупок? Что это за опыт?

Служебные тесты базы данных

Тесты для тестирования базы данных проверяют, что происходит за кулисами. Пользовательский интерфейс чист, и все, кажется, работает... но где все эти данные идут? Чтобы написать эти тестовые примеры, вам необходимо хорошо понимать все приложение, таблицы базы данных и хранимые процедуры. Команда тестирования часто использует SQL-запросы для разработки тестов базы данных. Тесты базы данных используются для проверки того, что разработчик написал код таким образом, чтобы хранить и обрабатывать данные согласованным, безопасным образом.

Пример: Давайте рассмотрим создание профиля пользователя. Когда пользователь отправляет свой профиль, в отношении базы данных необходимо проверить следующее. Было ли приложение хранить введенные данные в базе данных? Были ли какие-либо данные потеряны в процессе? Частично выполненные данные не должны быть сохранены. Неавторизованные пользователи не могут просматривать или получать информацию о пользователях.

Случаи проверки безопасности

Случаи проверки безопасности помогают гарантировать, что приложение ограничивает действия и разрешения там, где это необходимо. Эти тестовые примеры написаны для защиты данных, когда и где они должны быть защищены. Тесты безопасности используются для тестирования проникновения и других типов тестов на основе безопасности. Аутентификация и шифрование часто являются основным направлением в тестах безопасности. Команда безопасности (если таковая существует) обычно несет ответственность за составление и проведение этих тестов.

Пример. Если пользователь достигает X числа неудачных попыток входа в систему, становится ли учетная запись заблокирована? Пользователь может загружать данные без регистрации?

Служебные тесты при приеме пользователя

Приемочные тесты пользователей или тестовые примеры "UAT" помогают команде протестировать среду тестирования приёма пользователей. Эти тестовые примеры должны быть широкими, охватывая все области применения. Цель этих тестовых примеров - не найти ошибок (надеюсь, они уже были найдены и исправлены в предыдущем тестировании), но для проверки того, что приложение приемлемо для пользователя. Итак, когда они выполняют тест, являются ли результаты этого теста, и опыт этого теста приемлемым? Так как многие другие типы тестирования уже были сделаны к моменту запуска UAT, фокус не столько на гранулированном уровне, сколько больше на большей картине. Пользовательские тестовые примеры используются конечным пользователем или клиентом и подготовлены группой тестирования или менеджером продуктов. Это, пожалуй, самый важный этап тестирования, поскольку он является последним шагом перед входом в производство.

Пример. Если тестирование, например, приложение для управления фотографиями для студии фотографии, клиент (пользователь) должен проверить, что они могут загружать и управлять своими фотографиями таким образом, который соответствует их бизнес-потребностям.