Перейти к содержанию

Обзор методик тестирования

Определение

Test Case (тестовый случай, вариант тестирования) — это формально описанный алгоритм тестирования программы, специально созданный для определения возникновения в программе определённой ситуации, определённых выходных данных1.

Иными словами, целью теста является проверка поведения тестируемой системы. Под системой здесь понимается элемент программного обеспечения, к которому применяется тест. Коллекция взаимосвязанных тестов формирует тестовый набор (test suite).

Написание автоматических тестов

Каждый тест реализуется в виде метода, который принадлежит тестовому классу.
Типичный автоматический тест состоит из 4 этапов:

  1. Подготовка — инициализирует среду тестирования, состоящую из самой системы и ее зависимостей, приводя ее в нужное состояние. Например, создает тестируемый класс.
  2. Выполнение — запускает тестируемую систему, например, вызов метода из тестируемого класса
  3. Проверка — делает выводы о результате выполнения и состоянии тестируемой системы.
  4. Очистка — удаляет среду тестирования.

Pasted image 20211018205722.png
Тестовые классы могут объединяться в тестовый набор.

Тестирование с помощью макетов и заглушек

Тестируемая система обычно имеет зависимости, которые могут осложнить и замедлить тесты. Поэтому зависимости мы заменяем дублерами — объектами, которые симулируют поведение зависимости.
Существуют два вида дублеров: заглушки(stubs) и макеты(mocks). Заглушка — это дублер, который возвращает значения тестируемой системе. Макет — это дублер, используемый тестом для проверки того, что тестируемая система корректно вызывает свои зависимости. Во многих случаях макет может быть заглушкой.

Типы тестов

Существует много типов тестов. Например, тесты производительности (нагрузочные?) и удобства использования. Однако здесь рассмотрим 4 типа тестов, которые проверяют функциональные аспекты приложения или сервисов, а именно:

  • модульные тесты (unit tests), которые тестируют небольшую часть сервиса, такую как класс
  • интеграционные тесты, которые проверяют, может ли сервис взаимодействовать с инфраструктурными компонентами, такими как БД или другие сервисы приложения
  • компонентные тесты — приемочные тесты для отдельного сервиса
  • сквозные тесты — приемочные тесты для целого приложения

Использование тестового квадранта для классификации тестов

Тестовый квадрант — это схема, предложенная Брайаном Мариком (Brian Marick). Он группирует тесты по двум основаниям:

  • К чему относится тест — к бизнесу или к технологиям. Бизнес-тест описывается в терминологии проблемной области, для описания технологического теста используется терминология реализации
  • Какова цель теста — помочь с написанием кода или дать оценку приложению. Разработчики применяют тесты, помогающие в работе. Тесты, оценивающие приложение, нужны для проблемных участков

Pasted image 20211018211719.png

Применение пирамиды тестов как средства приоритизации тестирования

Рассмотрим пирамиду тестов.
pyramid-of-tests.png
Суть подхода в том, что с продвижением вверх по пирамиде мы должны писать всё меньше и меньше тестов. Модульных тестов должно быть много, а сквозных — мало.


Последнее обновление : 30 мая 2023 г.
Дата создания : 31 июля 2022 г.

Комментарии

Комментарии