ISTQB - международная некоммерческая организация, созданная в 2002 году с целью стандартизации методологий и предоставления официальной сертификации. В настоящее время руководство ISTQB считается официальным руководством по процессу разработки тестов и каталогизирует тесты по типам и уровням.
ISTQB классифицирует тесты по типу в соответствии с целью тестирования и по уровню в соответствии с этапом процесса, на котором проводится тестирование.
Ранее я объяснил историю и различные уровни в мире тестирования программного обеспечения, а теперь, чтобы закончить эту серию быстрых обзоров тестирования, мы увидим, что это за типы, и на основе того, что они классифицируются. Для этого я рекомендую вам прочитать эти сообщения, чтобы лучше понять тему, которая будет обсуждаться ниже, поскольку они будут упомянуты позже.
Объяснив это, давайте рассмотрим различные типы тестирования программного обеспечения: функциональное, нефункциональное, структурное и регрессионное:
Функциональное тестирование
Функциональные тесты, как следует из названия, сосредоточены на проверке функциональности продукта или компонента.
Дизайн этих тестов основан на требованиях и случаях использования, обычно документированных, системы или функции. Функциональные тесты могут быть разработаны для всех уровней тестирования, упомянутых выше.
Эти тесты считаются тестами черного ящика, поскольку пользователь, который разрабатывает, разрабатывает и выполняет тест, не должен знать логику или внутреннюю структуру программы.
Нефункциональное тестирование
Нефункциональные тесты подтверждают поведение системы, особенно инфраструктуры. Они также считаются черным ящиком и могут быть разработаны для всех уровней. Внутри нефункциональных тестов есть разные подтипы:
Нагрузка
Этот тест направлен на то, чтобы узнать поведение приложения для различных объемов транзакций, которые могут происходить в приложении, всегда в пределах реальных границ. Они часто используются для тестирования функций с высоким потреблением ресурсов или для написания действий в приложении, но могут также возникать в других менее важных областях.
Стресс
В отличие от нагрузочного теста, стресс-тест пытается вызвать коллапс приложения с большим объемом транзакций. Цель состоит в том, чтобы узнать, где находится предел транзакции, и убедиться, что приложение возвращает управляемую ошибку.
Представление
Тестирование производительности выполняется для определения производительности системы путем проверки атрибутов качества системы, таких как отзывчивость, скорость, масштабируемость и стабильность при различных условиях нагрузки.
Как вы могли заметить, между нагрузочными, стрессовыми и производственными тестами проходит тонкая грань. Все они стремятся ограничить приложение, и часто один и тот же тест может быть либо нагрузочным, либо стрессовым, в зависимости от количества настроенных транзакций. Основное различие заключается в цели теста и в мерах, которые принимаются и экспортируются в конце выполнения.
Пользовательский опыт
Юзабилити-тесты или UX (пользовательский опыт) нацелены на то, чтобы предложить пользователю наиболее удобный, интуитивно понятный и эффективный опыт. Цель этих тестов - заставить новых клиентов почувствовать себя привлеченными приложением, а текущими - комфортными.
Структурные испытания
Структурный тест подтверждает, что внутренние потоки приложения соответствуют установленному планированию на основе кода приложения, поэтому мы говорим о тестировании белого ящика, когда пользователь, который разрабатывает тест, имеет полный доступ к исходному коду.
Цель состоит в том, чтобы гарантировать, что приложение соответствует установленному потоку для неожиданных входных значений и нет аномалий, которые могут быть использованы, использованы или приведут к сбою приложения.
С помощью анализа кода с использованием различных методов можно определить, среди прочего, какая часть кода не была протестирована (тесты покрытия), какие потоки никогда не будут маршрутизироваться (условия) или доступность между различными компонентами. приложения.
Тестирование, связанное с изменениями
Как сказал Люсьен Гинда, этот тип теста, ранее называвшийся «Регрессия», теперь известен как «Тестирование, связанное с изменениями», и он содержит не только регрессию, но и повторное тестирование / подтверждающее тестирование.
Исправление ошибки, обнаруженной в тесте, обычно включает добавление или удаление части кода, и эта модификация может вызвать новые ошибки в модуле или даже в других, которые кажутся не связанными.
Чтобы этого не произошло, существуют регрессионные тесты. Регрессия заключается в повторном прохождении определенных тестов на компоненте, на который был внесен патч, для обнаружения возможных новых ошибок. В тестах этого типа особенно важна возможность повторно использовать или повторить тест, не начиная с известного набора данных.
Это тесты, которые, в свою очередь, могут быть функциональными, нефункциональными или структурными, а также могут относиться к любому уровню.
