Я видел, как другие люди упоминают несколько типов тестирования в Stack Overflow.
Я могу вспомнить модульное тестирование и тестирование интеграции. Особенно часто упоминается модульное тестирование. Что такое единичное тестирование? Что такое интеграционное тестирование? О каких других важных методах тестирования я должен знать?
Программирование - это не моя профессия, но я бы хотел, чтобы это было когда-нибудь, и т.д. приветствуется.
Сверху моей головы:
Должен ли я быть в курсе любого другого важного тестирования моего кода?
Это некоторые из разных видов тестов в соответствии с различными этапами жизненного цикла программного обеспечения:
Там больше:
И многое другое... программное обеспечение для тестирования почти такое же, как и написание программного обеспечения.
Основная цель модульного тестирования - взять самую маленькую часть проверяемого программного обеспечения в приложении, изолировать это от остальной части кода и определить, будет ли он вести себя точно как вы ожидаете. Каждый блок проверен отдельно до их интеграции в модули для тестирования интерфейсов между модулями. Единичное тестирование доказал свою ценность в том, что большой процент дефектов идентифицирован во время его использования.
Тестирование интеграции является логическим расширение модульного тестирования. В своем простейшая форма, две единицы, которые имеют уже протестированные, объединены в компонент и интерфейс между они протестированы. Компонент в этом смысл, относится к интегрированному совокупность более чем одной единицы. В реалистичный сценарий, многие единицы объединены в компоненты, которые находятся в превратиться в еще более крупные части программы. Идея состоит в том, чтобы проверить комбинации частей и, в конечном счете, разверните процесс, чтобы проверить свои модули с другими группами. В конечном итоге все модули, составляющие процесс тестируются вместе. за что если программа состоит из более одного процесса, они должны быть испытаны парами, а не один раз.
Проверьте сайты для получения дополнительной информации. Существует много информации из других источников, кроме Microsoft.
Другим важным методом является регрессионное тестирование. В этом методе вы поддерживаете набор тестов (называемых регрессионным набором), которые обычно выполняются как по ночам, так и перед каждой проверкой. Каждый раз, когда вы исправляете ошибку, вы добавляете один или несколько тестов в набор. Цель состоит в том, чтобы остановить вас от повторного введения старых ошибок, которые уже исправлены. (Проблема удивительно распространена!)
Начните накапливать набор регрессии рано, прежде чем ваш проект станет большим, или вы пожалеете об этом. У меня наверняка есть!
Существуют различные уровни тестирования, соответствующие тому, на каком этапе вы находитесь в жизненном цикле разработки программного обеспечения. Самый высокий уровень - это анализ требований, а самый низкий уровень - это реализация решения.
Что такое модульное тестирование?
Существует множество инструментов для тестирования модулей, один из самых популярных - JUnit.
При выполнении модульного тестирования мы хотим построить тестовый набор (набор тестовых примеров), который удовлетворяет определенным критериям покрытия. Это могут быть некоторые критерии структурного охвата (NC, EC, PPC и т.д.) Или критерии потока данных (ADC, AUC, ADUPC и т.д.).
Что такое тестирование интеграции?
Другие уровни тестирования включают в себя:
Тестирование регрессии
Приемочное тестирование
Модульное тестирование - это просто идея написания (надеюсь) небольших блоков кода для проверки независимых частей вашего приложения.
Например, у вас может быть приложение калькулятора, и вы должны убедиться, что функция добавления работает. Для этого вы пишете отдельное приложение, которое вызывает функцию добавления напрямую. Затем ваша тестовая функция будет оценивать результат, чтобы увидеть, если он дживется с тем, что вы ожидали.
Он в основном вызывает ваши функции с известными входами и проверяет вывод именно так, как вы ожидали.
Первые два результата поиска в google для "типов тестирования" выглядят всеобъемлющими
Те, которые я считаю наиболее важными. См. здесь.
Это была запись, которую я написал: Различные типы автоматизированных тестов.
Тестирование устройств. Тестирование выполняется на устройстве или на самом маленьком программном обеспечении. Выполнено, чтобы проверить, удовлетворяет ли оно его функциональной спецификации или предполагаемой структуре дизайна.
Тестирование интеграции: Тестирование связанных модулей вместе для совместной работы.
Регрессионное тестирование: Тестирование приложения для проверки того, что изменения не вызвали непреднамеренных эффектов.
Тестирование дыма: проверка дыма проверяется, является ли сборка проверяемой или нет.
Различные типы тестовых случаев:
Случаи проверки функциональности
Функциональные тестовые примеры используются, чтобы определить, работает ли интерфейс приложений с остальной частью системы и ее пользователями. Тесты идентифицируют успех или неудачу функций, которые программа должна выполнять. Случаи - это тип тестирования "черного ящика", который использует для своей базы спецификации или истории пользователей тестируемого программного обеспечения. Это позволяет проводить тесты без необходимости доступа к работам или внутренним структурам тестируемого программного обеспечения. Команда QA - обычные авторы тестов функциональности, потому что они попадают в обычные процессы QA. Их можно написать и запустить, как только разработка сделает первую функцию доступной для тестирования. Чтобы помочь в управлении разработкой, они могут быть написаны заранее до кода, если все тестер имеет доступ к требованиям. Как указано выше, их можно написать и запустить, как только это станет возможным, и их следует повторять при добавлении обновлений, вплоть до того, когда клиенты станут возможными.
Пример. Подтверждение того, что пользователь может успешно загрузить фотографию профиля.
Тесты пользовательского интерфейса
Тесты пользовательского интерфейса используются для проверки того, что определенные части графического интерфейса пользователя (GUI) выглядят и работают должным образом. Эти типы тестовых примеров могут использоваться для выявления косметических несоответствий, грамматики и орфографических ошибок, ссылок и любых других элементов, с которыми пользователь взаимодействует или видит. Эти случаи обычно пишутся группой тестирования, но команда разработчиков также может быть задействована, поскольку они наиболее знакомы с интерфейсом. Тесты пользовательского интерфейса - это типы тестовых примеров при тестировании программного обеспечения, которые обычно управляют кросс-браузерным тестированием. Браузеры, как правило, делают вещи по-разному, а тестовые примеры пользовательского интерфейса помогают обеспечить постоянство поведения вашего приложения в нескольких браузерах. Эти тестовые примеры будут запускаться после завершения фазы разработки и пользовательского интерфейса подключается к базе данных.
Пример. Что происходит, когда веб-сайт просматривается на маленьком экране, таком как мобильный телефон? Разрыв UI?
Служебные тесты производительности
Тесты производительности проверяют время отклика и общую эффективность приложения. То есть, после выполнения действия, сколько времени потребуется системе для ответа? Тесты производительности должны иметь очень четкий набор критериев успеха. Команда тестирования обычно записывает эти тестовые примеры, и они часто автоматизированы. Большое приложение может иметь сотни или тысячи тестов производительности. Автоматизация этих тестов и их частое использование помогает выявлять сценарии, в которых приложение не работает на ожидаемом уровне. Тесты производительности помогают понять, как приложение будет работать в реальном мире. Эти случаи могут быть записаны после того, как у тестирующей команды есть требования к производительности от группы продуктов. Тем не менее, многие проблемы с производительностью можно идентифицировать вручную без определенных требований.
Пример. Сколько времени требуется, чтобы система проверила подлинность пользователя и загрузила следующую страницу? Когда несколько пользователей заходят в одно и то же время, приложение остается стабильным?
Служебные тесты интеграции
Служебные тесты интеграции предназначены для определения того, как разные модули взаимодействуют друг с другом. Основная цель с интеграционными тестовыми примерами - обеспечить правильную работу интерфейсов между различными модулями. Группа тестирования определяет, какие области должны проходить интеграционное тестирование, а команда разработчиков будет иметь информацию о том, как эти тестовые примеры должны быть написаны. Любая из этих двух команд может работать над написанием дел. Они проверяют, что модули, которые уже работают индивидуально, также могут работать вместе.
Пример: проверка связи между главной страницей и разделом "избранное". Когда вы добавляете элемент в качестве "любимого", с домашней страницы отображается в разделе "Избранное"?
Случаи проверки удобства использования
Случаи проверки удобства использования часто можно назвать "задачами" или "сценариями". Вместо того, чтобы предоставлять подробные пошаговые инструкции для выполнения теста, тестеру предоставляется сценарий или задача высокого уровня для завершения. Тесты удобства использования помогают определить, как пользователь естественно подходит и использует приложение. Они помогают вести тестер через различные ситуации и потоки. Предварительное знание приложения не требуется. Эти тестовые примеры, как правило, разрабатываются командой разработчиков вместе с группой тестирования. Тестирование юзабилити должно проводиться до проведения приемочных испытаний пользователей.
Пример. Может ли пользователь успешно добавить более одного элемента в свою корзину покупок? Что это за опыт?
Служебные тесты базы данных
Тесты для тестирования базы данных проверяют, что происходит за кулисами. Пользовательский интерфейс чист, и все, кажется, работает... но где все эти данные идут? Чтобы написать эти тестовые примеры, вам необходимо хорошо понимать все приложение, таблицы базы данных и хранимые процедуры. Команда тестирования часто использует SQL-запросы для разработки тестов базы данных. Тесты базы данных используются для проверки того, что разработчик написал код таким образом, чтобы хранить и обрабатывать данные согласованным, безопасным образом.
Пример: Давайте рассмотрим создание профиля пользователя. Когда пользователь отправляет свой профиль, в отношении базы данных необходимо проверить следующее. Было ли приложение хранить введенные данные в базе данных? Были ли какие-либо данные потеряны в процессе? Частично выполненные данные не должны быть сохранены. Неавторизованные пользователи не могут просматривать или получать информацию о пользователях.
Случаи проверки безопасности
Случаи проверки безопасности помогают гарантировать, что приложение ограничивает действия и разрешения там, где это необходимо. Эти тестовые примеры написаны для защиты данных, когда и где они должны быть защищены. Тесты безопасности используются для тестирования проникновения и других типов тестов на основе безопасности. Аутентификация и шифрование часто являются основным направлением в тестах безопасности. Команда безопасности (если таковая существует) обычно несет ответственность за составление и проведение этих тестов.
Пример. Если пользователь достигает X числа неудачных попыток входа в систему, становится ли учетная запись заблокирована? Пользователь может загружать данные без регистрации?
Служебные тесты при приеме пользователя
Приемочные тесты пользователей или тестовые примеры "UAT" помогают команде протестировать среду тестирования приёма пользователей. Эти тестовые примеры должны быть широкими, охватывая все области применения. Цель этих тестовых примеров - не найти ошибок (надеюсь, они уже были найдены и исправлены в предыдущем тестировании), но для проверки того, что приложение приемлемо для пользователя. Итак, когда они выполняют тест, являются ли результаты этого теста, и опыт этого теста приемлемым? Так как многие другие типы тестирования уже были сделаны к моменту запуска UAT, фокус не столько на гранулированном уровне, сколько больше на большей картине. Пользовательские тестовые примеры используются конечным пользователем или клиентом и подготовлены группой тестирования или менеджером продуктов. Это, пожалуй, самый важный этап тестирования, поскольку он является последним шагом перед входом в производство.
Пример. Если тестирование, например, приложение для управления фотографиями для студии фотографии, клиент (пользователь) должен проверить, что они могут загружать и управлять своими фотографиями таким образом, который соответствует их бизнес-потребностям.