Стратегии тестирования

Автоматическое тестирование помогает улучшить качество приложения несколькими способами. Например, с его помощью можно выполнять проверку, выявлять регрессии и подтверждать совместимость. Хорошая стратегия тестирования позволяет использовать автоматизированное тестирование, чтобы сосредоточиться на важном преимуществе: повышении эффективности работы разработчиков.

Команды достигают более высоких уровней производительности, когда используют систематический подход к тестированию в сочетании с улучшениями инфраструктуры. Это позволяет своевременно получать отзывы о том, как работает код. Хорошая стратегия тестирования позволяет:

• Выявляет проблемы на ранних этапах.
• Быстрое выполнение.
• Четко указывает, когда что-то нужно исправить.

На этой странице рассказывается, какие типы тестирований можно проводить, где и как часто.

android skills add testing-setup

Пирамида тестирования

В современных приложениях тесты можно классифицировать по размеру. Небольшие тесты проверяют только небольшую часть кода, поэтому они выполняются быстро и надежно. Большие тесты имеют широкий охват и требуют более сложной настройки, которую трудно поддерживать. Однако крупные тесты более точны* и позволяют выявить больше проблем за один раз.

*Точность – это сходство тестовой среды выполнения с рабочей средой.

В большинстве приложений должно быть много небольших тестов и относительно мало крупных. Распределение тестов по категориям должно напоминать пирамиду, где в основании находятся многочисленные небольшие тесты, а на вершине – менее многочисленные крупные.

Минимизируйте стоимость ошибки

Хорошая стратегия тестирования позволяет максимально повысить продуктивность разработчиков и при этом свести к минимуму затраты на поиск ошибок.

Рассмотрим пример неэффективной стратегии. В этом случае количество тестов по размеру не образует пирамиду. Слишком много сквозных тестов и слишком мало тестов компонентов интерфейса:

Это означает, что перед слиянием выполняется слишком мало тестов. Если в коде есть ошибка, она может быть обнаружена только при выполнении сквозных тестов в конце дня или недели.

Важно учитывать, как это влияет на стоимость выявления и исправления ошибок, и почему при тестировании следует отдавать предпочтение небольшим и частым проверкам:

• Если ошибка обнаружена в ходе модульного тестирования, ее обычно можно исправить за несколько минут, поэтому затраты будут небольшими.
• При сквозном тестировании на обнаружение той же ошибки может уйти несколько дней. Это может привлечь внимание нескольких членов команды, снизить общую производительность и, возможно, задержать выпуск. Стоимость этой ошибки выше.

Тем не менее неэффективная стратегия тестирования лучше, чем ее отсутствие. Если ошибка попадает в рабочую версию, исправление доходит до устройств пользователей очень долго, иногда неделями, поэтому цикл обратной связи самый длинный и дорогой.

Масштабируемая стратегия тестирования

Традиционно пирамида тестирования делится на три категории:

• Модульные тесты
• Интеграционные тесты
• Сквозные тесты.

Однако точных определений этих понятий нет, поэтому команды могут по-разному определять категории, например используя пять уровней:

• Модульные тесты выполняются на хост-компьютере и проверяют отдельный функциональный модуль логики без зависимостей от фреймворка Android.
  • Пример: проверка ошибок на единицу в математической функции.
• Компонентный тест проверяет функциональность или внешний вид модуля или компонента независимо от других компонентов системы. В отличие от модульных тестов, область действия компонентного теста распространяется на более высокие уровни абстракции, чем отдельные методы и классы.
  • Пример: Тест скриншота для специальной кнопки.
• Функциональное тестирование позволяет проверить взаимодействие двух или более независимых компонентов или модулей. Тестирование функций более масштабное и сложное и обычно проводится на уровне функций.
  • Пример: тесты поведения интерфейса, которые проверяют управление состоянием на экране.
• Тестирование приложения позволяет проверить работу всего приложения в виде развертываемого двоичного файла. Это крупные интеграционные тесты, в которых в качестве тестируемой системы используется отладочный исполняемый файл, например сборка для разработчиков, которая может содержать обработчики для тестирования.
  • Пример: тестирование поведения интерфейса для проверки изменений конфигурации на складном устройстве, а также тестирование локализации и специальных возможностей.
• Тестирование релиз-кандидата позволяет проверить функциональность сборки. Они похожи на тесты приложений, но двоичный файл приложения сжат и оптимизирован. Это комплексные интеграционные тесты, которые выполняются в среде, максимально приближенной к рабочей, но без доступа к общедоступным аккаунтам пользователей или общедоступным серверным частям.
  • Пример: алгоритмы достижения цели, тестирование производительности

При категоризации учитываются точность, время, масштаб и уровень изоляции. На разных уровнях можно проводить разные типы тестирования. Например, уровень тестирования приложений может содержать тесты поведения, скриншотов и производительности.

Выберите категорию тестирования

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

Например, рассмотрим, как протестировать реализацию функции: интерфейс процесса входа. В зависимости от того, что вы хотите протестировать, выберите одну из категорий:

В некоторых случаях отнесение контента к той или иной категории может быть субъективным. Тест может быть перенесен вверх или вниз по другим причинам, например из-за стоимости инфраструктуры, нестабильности или длительного времени выполнения.

Обратите внимание, что категория тестирования не определяет тип теста, и не все функции должны тестироваться в каждой категории.

Ручное тестирование также может быть частью вашей стратегии тестирования. Обычно тестированием предрелизной версии занимаются команды по обеспечению качества, но они могут участвовать и в других этапах. Например, исследовательское тестирование функции на наличие ошибок без скрипта.

Тестовая инфраструктура

Стратегия тестирования должна поддерживаться инфраструктурой и инструментами, которые помогают разработчикам постоянно проводить тесты и применять правила, гарантирующие их успешное прохождение.

Вы можете классифицировать тесты по области применения, чтобы определить, когда и где их запускать. Например, в пятиуровневой модели:

• Тесты модулей и компонентов выполняются в системе непрерывной интеграции для каждого нового коммита, но только для затронутых модулей.
• Все тесты Unit, Component и Feature выполняются до слияния или отправки изменений.
• Тестирование приложения выполняется после слияния.
• Тестирование версии-кандидата выполняется каждую ночь на телефоне, складном устройстве и планшете.
• Перед выпуском кандидат на релиз тестируется на большом количестве устройств.

Эти правила могут меняться со временем, если количество тестов влияет на производительность. Например, если вы перенесете тестирование на ночное время, то сможете сократить время сборки и тестирования, но при этом увеличите время получения обратной связи.