Тестирование программного обеспечения – это всеобъемлющий термин, охватывающий широкий спектр различных видов тестирования. Эти виды классифицируются по целям и подходам. Понимание того, как применять их на практике, поможет вам и вашей команде лучше разработать план тестирования.
В этой статье мы узнаем, как классифицируются виды тестирования и каково их место в жизненном цикле тестирования ПО. В частности, мы рассмотрим:
- Модульное тестирование
- Интеграционное тестирование
- Сквозное тестирование
- Ручное тестирование
- Автоматизированное тестирование
- Тестирование с помощью искусственного интеллекта
- Функциональное тестирование
- Визуальное тестирование
- Тестирование производительности
- Регрессионное тестирование
- Тестирование на совместимость
- Тестирование доступности
- Smoke и Sanity тестирование
- Тестирование “белого ящика” и “черного ящика”
- Тестирование различных приложений
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.
Классификация видов тестирования
Существует 6 основных способов классифицировать виды тестирования:
- По тестируемым приложениям: группировка по типу тестируемого ПО (т.е. веб-приложения, мобильные приложения, настольные приложения и т.д.)
- По области приложения: группировка на основе традиционной трехуровневой архитектуры, используемой при разработке ПО, включающей пользовательский интерфейс, бэкэнд или API
- По атрибутам: группировка на основе конкретных характеристик или свойств, которые тестируются (например, визуальное тестирование, функциональное тестирование, тестирование производительности и т. д.)
- По подходу: группировка на основе общей стратегии проведения тестирования (т.е. ручное, автоматизированное или управляемое искусственным интеллектом)
- По уровню: группировка на основе уровня детализации и масштаба, в котором проводится тестирование (т.е. модульное тестирование, сквозное тестирование и т.д.)
- По методам тестирования: группировка, основанная на способе разработки и выполнения теста. Важно отметить, что классификация по методам тестирования является более целенаправленной и узкой, чем классификация по подходам. В качестве примера можно привести тестирование черного, белого и серого ящика.
Существует иерархия этих категорий, и наиболее всеобъемлющей является классификация по подходам. Например, автоматизированное тестирование – это просто тестирование с помощью скриптов или инструментов автоматизации. При этом автоматизировать можно практически любые другие виды тестирования.
15 различных видов тестирования
1. Юнит-тестирование
Юнит-тестирование – одна из важнейших практик разработки программного обеспечения. Оно включает в себя тестирование небольших частей программного приложения, таких как функции, методы, модули или классы. Эти отдельные части составляют все приложение, и если они не работают должным образом сами по себе, то не будут работать и вместе. Юнит-тестирование гарантирует, что до интеграции в большую систему каждый компонент работает правильно.
Для юнит-тестирования обычно нужны:
- Тестовая структура. Компоненты модульного теста, отвечающие за подготовку необходимого окружения для выполнения тест-кейса. Они создают начальные состояния для тестируемого модуля, чтобы обеспечить более контролируемое выполнение без вмешательства внешних компонентов.
- Тест-кейсы. Сценарии для проверки поведения тестируемого модуля.
- Тест-раннер (Test Runner). Фреймворк для организации выполнения множества модульных тестов, а также для создания отчетов и анализа результатов тестирования.
- Тестовые данные. Список значений, имитирующих данные реального пользователя для входа в систему.
- Моки и заглушки. Заменители реальных зависимостей тестируемого модуля в случае, если тестировщикам требуется два модуля для выполнения теста.
2. Интеграционное тестирование
Интеграционное тестирование – это метод, при котором компоненты объединяются и тестируются вместе как единое целое. Эти компоненты прошли модульное тестирование, что означает, что они хорошо работают независимо, но при взаимодействии друг с другом могут возникнуть проблемы. Тестировщики используют интеграционное тестирование для выявления дефектов, возникающих из-за конфликтов кода при интеграции модулей.
Существует несколько стратегий проведения интеграционного тестирования, из которых наиболее распространены две:
- Подход “большого взрыва”: интеграция всех компонентов и тестирование всего сразу
- Инкрементальный подход: интеграция и тестирование нескольких компонентов с тесно связанной логикой группа за группой
Инкрементный подход осуществляется 3 различными методами:
- Подход “снизу вверх”: сначала интегрируются и тестируются компоненты меньшего объема, а затем постепенно переходят к более крупным компонентам
- Подход “сверху вниз”: сначала интегрируются и тестируются компоненты большего размера, затем постепенно переходят к компонентам меньшего размера
- Сэндвич-подход объединяет 2 предыдущих подхода
3. Сквозное тестирование
Сквозное тестирование (End-to-end, E2E) – это метод тестирования ПО, который проверяет функциональность и производительность всего программного приложения от начала до конца, моделируя реальные пользовательские сценарии.
Благодаря сквозному тестированию тестировщики получают представление о том, как функционирует приложение с точки зрения конечного пользователя, что дает им более полное представление о качестве продукта до его выпуска.
4. Ручное тестирование
Ручное тестирование – это процесс оценки программного обеспечения тестировщиками без использования инструментов автоматизации тестирования или автоматизации запуска тестовых сценариев. Чтобы обнаружить ошибки, дефекты и проблемы, которые влияют на работу пользователей, тестировщики взаимодействуют с системой так же, как и конечные пользователи.
Ручное тестирование – это традиционный способ тестирования ПО. Оно требует много ресурсов, времени и, как правило, не масштабируется, поэтому многие тестировщики перешли к автоматизации тестирования, чтобы повысить его эффективность. Однако в некоторых случаях без ручного тестирования не обойтись. Это особенно касается случаев, когда нужно применять творческий подход и задействовать интуицию. Например, вручную проводятся:
- Ad-hoc тестирование. Незапланированный и спонтанный подход к ручному тестированию, при котором тесты выполняются без заранее составленных планов. Тестировщики полагаются на свой опыт и интуицию, чтобы выявить возможные дефекты в программном обеспечении, иногда даже делая обоснованные предположения.
- Исследовательское тестирование. Подход, схожий с ad-hoc тестированием в его акценте на спонтанность, но при этом более систематичный и предполагающий изучение и исследование ПО с одновременной разработкой и выполнением тест-кейсов по ходу исследования.
- Тестирование удобства использования. Вид ручного тестирования, который фокусируется на оценке интерфейса, удобства использования и общего пользовательского опыта. Тестировщики ставят себя на место пользователя и взаимодействуют с системой, не прибегая к помощи специализированных инструментов тестирования. Такое человеческое отношение помогает обнаружить ошибки, которые могли быть пропущены при автоматизированном тестировании.
5. Автоматизированное тестирование
Автоматизированное тестирование, в отличие от ручного, использует фреймворки автоматизации и специальные инструменты для автоматического запуска набора тест-кейсов. Весь процесс от создания теста до его выполнения происходит без вмешательства человека, что позволяет сократить ручные усилия и повысить точность и эффективность тестирования.
6. Тестирование с помощью искусственного интеллекта
ИИ-тестирование – это оценка функциональности, производительности и надежности системы с помощью искусственного интеллекта. Оно проходит по тому же традиционному жизненному циклу тестирования ПО, но все его этапы значительно улучшены благодаря технологиям ИИ, таким как машинное обучение, NLP или компьютерное зрение. Использование ИИ помогает командам QA выполнять сложные задачи, которые раньше требовали человеческого интеллекта, такие как анализ данных, планирование и принятие решений.
ИИ может помочь тестировщикам несколькими эффективными способами:
- Автономная генерация тест-кейсов на основе собранных данных о поведении пользователей
- Генерация тест-кейсов на основе плана тестирования
- Автоматическое ожидание, пока на экране появятся все необходимые элементы, прежде чем продолжить тест
- Автоматическое исправление локаторов элементов и их использование в последующих прогонах тестов, что снижает затраты на обслуживание
7. Функциональное тестирование
Функциональное тестирование – это этап, на котором инженеры по качеству подтверждают, что функции тестируемого приложения работают в соответствии с заданными требованиями. Мы можем проводить его как вручную, так и с помощью инструментов автоматизации на основе конкретных тест-кейсов. Примеры функциональных тестов включают:
- Успешный вход в систему с действительными учетными данными
- Проверка поведения системы при авторизации с недействительными учетными данными
- Проверка функциональности поиска товаров
- Проверка потока данных бэкэнда.
8. Визуальное тестирование
Визуальное тестирование – это метод тестирования программного обеспечения, направленный на проверку визуальных аспектов пользовательского интерфейса (UI) приложения. Она включает в себя изучение графических элементов, макета и общего внешнего вида ПО, чтобы убедиться, что все это соответствует ожидаемому дизайну и поведению.
Тестировщикам приходится выполнять проверку многих эстетических аспектов визуального элемента, включая:
- Размер
- Ширину
- Длину
- Позицию
- Видимость (может ли пользователь видеть элемент)
- Читабельность (может ли пользователь легко прочитать текст и информацию на элементе)
- Выравнивание (хорошо ли расположен элемент пользовательского интерфейса по отношению к другим элементам)
- Согласованность при любом разрешении экрана (остается ли макет одинаковым на разных экранах).
Обычно тестировщикам приходится полагаться на собственные глаза, чтобы обнаружить эти ошибки. Если они решают написать сценарии автоматизации для визуального тестирования, они будут следовать подходу сравнения скриншотов. Он предполагает сравнение эталонного или базового изображения желаемого пользовательского интерфейса с реальным UI для выявления любых пиксельных различий между ними. Это означает, что даже визуальные ошибки размером в один пиксель не смогут ускользнуть.
Однако иногда разница в пикселях не обязательно означает визуальные ошибки. Например, на всех сайтах и в приложениях есть динамические элементы, которые часто меняются. Например, дата, время или значок корзины на сайтах электронной коммерции. Скрипты визуального автоматизированного тестирования регистрируют эти изменения как ошибки, но реальные пользователи так не считают. Именно поэтому тестировщикам очень нужны инструменты визуального тестирования, дополненные ИИ, которые умеют отличать ошибки, действительно влияющие на пользователей.
9. Тестирование производительности
Тестирование производительности – это вид тестирования, который оценивает производительность программного приложения в различных условиях. Его основная цель – определить и измерить поведение системы с точки зрения скорости, стабильности, масштабируемости и использования ресурсов.
Существует несколько подвидов тестирования производительности:
- Нагрузочное тестирование. Предполагает моделирование определенной рабочей нагрузки, которая имитирует нормальное и пиковое количество одновременных пользователей с последующим замером, насколько сильно это влияет на время отклика.
- Стресс-тестирование. Предполагает моделирование нагрузки, выходящей за пределы возможностей приложения. Какой бы ни была средняя нагрузка на систему, стресс-тестирование позволяет определить точку разрыва. Результаты стресс-тестирования помогут командам разработчиков оптимизировать свои ресурсы и улучшить инфраструктуру.
10. Регрессионное тестирование
Регрессионное тестирование проводится после обновления кода, чтобы убедиться, что обновление не внесло новых ошибок. Это связано с тем, что в новом коде может появиться новая логика, которая будет конфликтовать с существующим кодом, что приведет к появлению дефектов. Обычно команды QA имеют серию регрессионных тестов для важных функций, которые они будут выполнять заново при каждом изменении кода, чтобы сэкономить время и повысить эффективность тестирования.
11. Тестирование на совместимость
Тестирование на совместимость – проверка корректности работы ПО в различных средах, устройствах, браузерах и операционных системах. Основная цель тестирования на совместимость – убедиться, что приложение остается неизменным и пригодным для использования в различных конфигурациях. Существует несколько терминов для обозначения различных областей тестирования совместимости, в том числе:
- Кроссбраузерное тестирование
- Тестирование на разных устройствах
- Кроссплатформенное тестирование
12. Тестирование доступности
Тестирование доступности – это процесс оценки возможности использования ПО, сайтов или цифрового контента людьми с особыми потребностями или проблемами, связанными с нарушениями здоровья. Этот вид тестирования направлен на поиск и устранение барьеров в приложении, которые могут помешать этим людям эффективно использовать цифровой продукт и получать к нему доступ. При тестировании доступности мы проверяем доступность или наличие:
- Клавиатуры
- Устройства для чтения с экрана
- Цветового контраста
- Альтернативного текста (Alt text)
- Мультимедиа.
13. Smoke и Sanity тестирование
Smoke и Sanity тестирование – это два вида тестирования ПО, которые проводятся для быстрой оценки базовой функциональности приложения. Они часто проводятся для определения необходимости дальнейшего тестирования. Проще говоря, эти два вида тестирования очень похожи по сфере применения.
| Аспект | Smoke Testing | Sanity Testing |
| Цель | Проверка критических функциональных возможностей | Проверка последних изменений или исправлений |
| Сфера | Широкая, охватывает основные функциональные возможности | Ограниченная. В фокусе конкретные области, затронутые недавними изменениями |
| Глубина | Поверхностное тестирование | Ограниченное регрессионное тестирование |
| Назначение | Определение проблемы, мешающей дальнейшему тестированию | Подтверждение, что недавние изменения не привели к серьезным дефектам |
| Время выполнения | Быстрое выполнение после каждой сборки | Быстрое выполнение после каждого небольшого релиза или исправления ошибок |
| Решение | Определение, возможно ли дальнейшее тестирование | Определение, стабильно ли приложение для всестороннего тестирования |
| Отношения | Предшествует более комплексному тестированию | Подраздел регрессионного тестирования |
| Результат | Прохождение оценивает работу основных функций | Прохождение указывает на стабильность последних изменений |
| Обработка неудач | Неудача требует дальнейшего изучения перед детальным тестированием | Неудача требует дальнейшего изучения и исправления до полного регрессионного тестирования |
14. Тестирование “белого ящика” и “черного ящика”
Тестирование белого ящика исследует внутреннюю структуру программного приложения. С другой стороны, тестирование черного ящика фокусируется на проверке функциональности приложения без знания внутреннего кода или деталей реализации, подобно тому, как нельзя увидеть содержимое черного ящика.
15. Тестирование различных приложений
Для каждого вида тестируемого приложения существует свой термин. Наиболее распространенные виды тестирования включают:
- Веб-тестирование
- Тестирование десктопного приложения
- Тестирование API
- Мобильное тестирование.
Перевод статьи «15 Different Types Of QA Testing You Should Know».