1. Теория тестирования
1.2. Виды тестирования
Вид тестирования (в зависимости от источника может называться типом) – это совокупность активностей тестирования, направленных на тестирование заданных характеристик системы или ее части, основываясь на конкретных целях.
К таким целям можно отнести следующие:
- Оценку функциональных характеристик качества системы, таких как полнота, корректность, целесообразность
- Оценку нефункциональных характеристик качества, таких как надежность, продуктивность работы, безопасность, совместимость и удобство использования
- Оценку правильности, полноты структуры или архитектуры компонента или системы, их соответствие спецификации
- Оценку влияния изменений, например, подтверждение того, что дефекты были исправлены (подтверждающее тестирование) и поиск непреднамеренных изменений в поведении, вызванных изменениями в программном обеспечении или окружении (регрессионное тестирование)
- Функциональное
- Нефункциональное
- Связанное с изменениями
Все описанные виды тестирования можно проводить на любом уровне тестирования.
Функциональное тестирование
Тестирование по оценке функций, которые должна выполнять система. Отвечает на вопрос: "Что делает система?". Как правило, эти функции описываются в требованиях, функциональных спецификациях или в виде случаев использования системы (use cases).
Тестирование функциональности может проводиться в двух аспектах:
- требования
- бизнес-процессы
Тестирование в перспективе «требования» использует спецификацию функциональных требований к системе как основу для дизайна тестовых случаев. В этом случае необходимо сделать список того, что будет тестироваться, а что нет, приоритезировать требования на основе рисков (если это не сделано в документе с требованиями), а на основе этого приоритезировать тестовые сценарии (test cases). Это позволит сфокусироваться и не упустить при тестировании наиболее важный функционал.
Тестирование в перспективе «бизнес-процессы» использует знание этих самых бизнес-процессов, которые описывают сценарии ежедневного использования системы. В этой перспективе тестовые сценарии, как правило, основываются на случаях использования системы.
Нефункциональное тестирование
Тестирование атрибутов системы, не относящихся к функциональности: сопровождаемость, переносимость, удобство использования, производительность, безопасность. Отвечает на вопрос: "Насколько хорошо работает система?"
- Удобство пользования (Способность продукта быть понимаемым, изучаемым, используемым и привлекательным для пользователя в заданных условиях, тестирование внешнего вида, верстки и т.д.)
- Безопасность (Защита пользовательских данных, защита данных приложения, стойкость на взлом)
- Переносимость (Проверка работы приложения на различные окружениях, платформах, адаптируемости и кроссбраузерности страниц в случае проверки сайта т.д.)
- Сопровождаемость (Документированность функционала, инфраструктуры, проблем и рисков, наличие информации об используемых инструментах, наличие комментариев и описания кода)
- Производительность (Способность работы приложения при различных нагрузках)
Можно выделить основные виды тестирования, которые производятся во время этапа тестирования производительности системы. Основные типы тестирования и вопросы, которые они решают представлены в таблице.
| № | Вид тестирования | Вид тестирования по английский | Вопрос на который отвечает тестирование |
|---|---|---|---|
| 1 | Нагрузочное тестирование | Load Testing | Достаточно ли быстро работает система? |
| 2 | Тестирование стабильности/надежности | Stability Testing | Достаточно ли надежно работает система на долгом интервале времени? |
| 3 | Тестирование отказоустойчивости | Failover Testing | Сможет ли система переместиться сама на другой сервер в случае сбоя основного сервера? |
| 4 | Тестирование восстановления | Recovery Testing | Как быстро восстановится система? |
| 5 | Стрессовое тестирование | Stress Testing | Что произойдет при незапланированной нагрузке? |
| 6 | Тестирование объемов | Volume Testing | Как будет работать система, если объем базы данных увечится в 100 раз? |
| 7 | Тестирование масштабируемости | Scalability Testing | Как будет увеличиться нагрузка на компоненты системы при увеличении числа пользователей? |
| 8 | Тестирование потенциальных возможностей | Capacity Testing | Какое количество пользователей может работать? |
| 9 | Конфигурационное тестирование | Configuration Testing | Как заставить систему работать быстрее? |
| 10 | Тестирование сравнения | Compare Testing | Какое оборудование и ПО выбрать? |
Тестирование, связанное с изменениями
Когда в систему вносятся изменения, выполненные для исправления дефекта, либо из-за новой или изменяющейся функциональности, необходимо провести тестирование, чтобы подтвердить, что изменения исправили дефект или что функциональность правильно реализована
и изменения не вызвали каких-либо непредвиденных неблагоприятных последствий.
- Подтверждающее (повторное) тестирование - тестирование, при котором выполняются тестовые сценарии, которые упали при последнем запуске, с целью подтвердить успешность исправлений.
- Регрессионное тестирование - тестирование программы, проводящееся после модификации для уверенности в том, что процесс модификации не внес или не активизировал ошибки в областях, не подвергшихся изменениям. Проводится после изменений в коде ПО или его окружении.
- Смоук- тестирование - выборка из общего числа запланированных тестовых сценариев, покрывающая по верхам критическую функциональность компонента или системы. Проводится с целью удостовериться, что базовые функции программы в целом работают
корректно. Итоги подобных проверок применяются для того, чтобы понять, можно ли характеризовать созданное ПО как максимально стабильную сборку для последующего тестирования. Иными словами дымовое тестирование проводят для того, чтобы убедиться в пригодности
полученного билда к тестированию. Именно этот вид тестирования не даст потратить время впустую. Логично,
что тестирование всего приложения не имеет смысла, если есть проблемы с
ключевыми характеристиками и не исправлены критичные баги.
- Санитарное - используется каждый раз, когда мы получаем относительно стабильный билд ПО, чтобы определить работоспособность в деталях. Здесь проходит валидация того, что важные части функциональности системы работают
согласно требованиям. Дальше, в какие-то специфические положительные или негавтиные обычно не углубляются. Такое
тестирование иногда называют сокращенной версией регрессионного
тестирования. Например, когда сроки релиза поджимают, выполнить тщательное регрессионное
тестирование практически невозможно. В этом случае с работой отлично
справляется санитарное тестирование, которое проверяет работу главных
функций приложения.
Для лучшего понимания ниже представлена сравнительная таблица этих понятий и области применения:
| Дымовое (Smoke) | Санитарное (Sanity) |
Регрессионное (Regression) | Повторное (Re-test) |
|---|---|---|---|
| Исполняются с целью проверить что критически важные функциональные части AUT работают как положено | Нацелено на установление факта того, что определённые части AUT всё так же работают как положено после минорных изменений или исправлений багов | Подтверждает, что свежие изменения в коде или приложении в целом не оказали негативного влияния на уже существующую функциональность/набор функций | Перепроверяет и подтверждает факт того, что ранее заваленные тест-кейсы проходят после того, как дефекты исправлены |
| Цель — проверить «стабильность» системы в целом, чтобы дать зелёный свет проведению более тщательного тестирования | Целью является проверить общее состояние системы в деталях, чтобы приступить к более тщательному тестированию | Цель — убедиться что свежие изменения в коде не оказали побочных эффектов на устоявшуюся работающую функциональность | Ре-тест проверяет что дефект исправлен |
| Перепроверка дефектов не является целью Smoke | Перепроверка дефектов не является целью Sanity | Перепроверка дефектов не является целью Regression | Факт того что дефект исправлен подтверждает Re-Test |
| Дымовое тестирование выполняется перед регрессионным | Санитарное тестирование выполняется перед регрессионным и после smoke-тестов | Проводится на основании требований проекта и доступности ресурсов (закрывается автотестами), «регресс» может проводиться в параллели с ре-тестами | — Ре-тест выполняется перед sanity-тестированием — Так же, приоритет ре-теста выше регрессионных проверок, поэтому должно выполняться перед ними |
| Может выполняться автоматизированно или вручную | Чаще выполняется вручную | Лучший повод для автоматизации данного вида тестирования, т.к. ручное может быть крайне затратным по ресурсам или времени | Не поддаётся автоматизации |
| Является подмножеством регрессионного тестирования | Подмножество приёмочного тестирования | Выполняется при любой модификации или изменениях в уже существующем проекте | Ре-тест проводится на исправленной сборке с использованием тех же данных, на том же окружении, но с различным набором входных данных |
| Тест-кейсы часть регрессионных тест-кейсов, но покрывающие крайне критичную функциональность | Санитарное может выполняться без тест-кейсов, но знание тестируемой системы обязательно | Тест-кейсы регрессионного тестирования могут быть получены из функциональных требований или спецификаций, пользовательских мануалов, и проводятся вне зависимости от того, что исправили разработчики | Используется тот же самый тест-кейс, который выявил дефект |
Также тестирование может быть статическим и динамическим
Статическое тестирование — не требует выполнения кода; это его суть. При этом оно может быть ручным или автоматизированным (например автоматические чекеры синтаксиса).
Статические тесты начинаются на ранних этапах цикла разработки. Такие тесты незаменимы при проверке MVP. Иногда даже не нужен компьютер — просто вручную проверяются самые базовые функции.
Техники статического тестирования включают, например, “тестирование” базовой документации приложения; поверхностную проверку кода; также документации по дизайну; спецификации функций; и требований по основным функциям.
Динамическое тестирование подразумевает выполнение кода при тестировании. Проверяется поведение приложения и функции, оценивается как задействованы память и процессор, и в целом производительность. QA-команда убеждается, что софт работает в соответствии с use-кейсами, ориентированными на бизнес-цели.В заключение стоит отметить, что в литературе представлено многообразие классификаций видов тестирования. Наиболее полное представление видов тестирования находится на схеме ниже:
