Узнайте, как объединить различные типы тестирования в разумную стратегию, соответствующую вашему проекту.
Добро пожаловать! В последней статье было заложено много основ о том, как подходить к различным типам тестирования и тому, что они содержат, а также разъяснены определения типов тестирования. Помните это маленькое изображение мема ? Возможно, вы задавались вопросом, как все те типы тестирования, о которых вы узнали, могут работать вместе.
Далее вы узнаете именно это. В этой статье рассказывается, как объединить эти типы тестирования в разумные стратегии и выбрать ту, которая соответствует вашему проекту.
Вы можете сравнить стратегии с несколькими фигурами, чтобы лучше понять их значение. Вот список стратегий с соответствующими размерами и масштабами разработки.
Давайте подробнее рассмотрим стратегии и узнаем значение их названий.
Определите цели тестирования. Чего вы хотите достичь с помощью этих тестов?
Прежде чем приступить к созданию хорошей стратегии, определите цель тестирования. Когда вы считаете, что ваше приложение было достаточно протестировано?
Достижение высокого покрытия тестированием часто рассматривается как конечная цель разработчиков, когда дело доходит до тестирования. Но всегда ли это лучший подход? При выборе стратегии тестирования может существовать еще один важный фактор, который следует учитывать — удовлетворение потребностей ваших пользователей.
Как разработчик, вы также используете множество других приложений и устройств. В этом отношении вы являетесь пользователем, который полагается на то, что все эти системы «просто работают». В свою очередь, вы полагаетесь на бесчисленное количество разработчиков, которые сделают все возможное, чтобы их приложения и устройства работали. Чтобы изменить ситуацию вспять, вы как разработчик также стремитесь оправдать это доверие. Поэтому вашей первой целью всегда должно быть предоставление работающего программного обеспечения и обслуживание пользователей. Это распространяется и на тесты, которые вы пишете для обеспечения качества приложения. Кент К. Доддс очень хорошо резюмирует это в своей статье «Статическое, модульное, интеграционное и E2E-тестирование для фронтенд-приложений »:
Чем больше ваши тесты напоминают способ использования вашего программного обеспечения, тем больше уверенности они могут вам дать.
Кент К. Доддс
Кент описывает это как обретение уверенности в тестах. Чем ближе вы подходите к пользователям, выбирая подходящий тип тестирования, тем больше вы можете доверять своим тестам в получении достоверных результатов. Другими словами, чем выше вы поднимаетесь по пирамиде, тем увереннее вы становитесь. Но подождите, что такое пирамида?
Определение стратегии тестирования: Как выбрать стратегию тестирования
В качестве первого шага определите, какие части требований необходимо проверить, чтобы убедиться в их выполнении. Узнайте, какие типы тестов использовать и на каком уровне детализации можно добиться наибольшей уверенности, сохраняя при этом эффективную структуру затрат. Многие разработчики подходят к этой теме, используя аналогии. Вот самые распространенные из них, начиная с всем известной классики.
Классика: тестовая пирамида
Как только вы начнете искать стратегии тестирования, вы, вероятно, встретите в качестве первой аналогии пирамиду автоматизации тестирования. Майк Кон представил эту концепцию в своей книге «Достижение успеха с помощью Agile». Позже Мартин Фаулер расширил эту концепцию в своей статье «Практическая пирамида испытаний» . Визуально пирамиду можно представить следующим образом:
Как показано на этом рисунке, тестовая пирамида состоит из трех слоев:
Единица . Эти тесты находятся на базовом уровне пирамиды, потому что они быстро выполняются и просты в обслуживании. Они изолированы и нацелены на самые незначительные тестовые единицы. Например, см. типичный модульный тест для очень небольшого продукта.
Интеграция . Эти тесты находятся в середине пирамиды, поскольку имеют приемлемую скорость выполнения, но приближают вас к пользователю, чем модульные тесты. Примером интеграционного теста является тест API . К этому типу также можно отнести тесты компонентов .
E2E-тесты (также называемые UI-тестами ). Эти тесты имитируют настоящего пользователя и его взаимодействие. Такие тесты требуют больше времени для выполнения и, следовательно, более дороги. Они находятся на вершине пирамиды.
Уверенность против ресурсов
Как кратко говорилось ранее, порядок слоев не случаен. Они показывают приоритеты и соответствующие затраты. Это дает вам четкое представление о том, сколько тестов вам следует написать для каждого слоя. Вы уже видели это в определении типов тестирования.
Поскольку тесты E2E наиболее близки к вашим пользователям, они дают вам максимальную уверенность в том, что ваше приложение работает должным образом. Однако для них требуется полный стек приложений и моделируемый пользователь, поэтому они также потенциально являются самыми дорогими. Таким образом, уверенность заключается в прямой конкуренции с ресурсами, необходимыми для выполнения тестов.
Пирамида пытается решить эту проблему, заставляя вас больше сосредоточиться на модульных тестах и строго расставлять приоритеты для случаев, охватываемых E2E-тестами. Например, наиболее важные пользовательские маршруты или места, наиболее уязвимые для дефектов. Как подчеркивает Мартин Фаулер, двумя наиболее важными моментами в пирамиде Кона являются следующие:
- Пишите тесты с разной степенью детализации.
- Чем более высокий уровень вы получите, тем меньше испытаний вам придется пройти.
Пирамида эволюционировала! Адаптации тестовых пирамид
В течение нескольких лет дискуссии вращались вокруг пирамиды. Кажется, что пирамида слишком упрощает стратегии тестирования, не учитывает множество типов тестирования и больше не подходит для всех реальных проектов. Поэтому оно может ввести в заблуждение. Пирамида потеряла форму? У Гильермо Рауха свое мнение по этому поводу:
Пишите тесты. Не слишком много. В основном интеграция.
Гильермо Раух
Это одна из наиболее часто цитируемых цитат на эту тему, поэтому давайте разберем ее:
- «Написать тесты». Не только потому, что это укрепляет доверие, но и потому, что экономит время на обслуживании.
- "Не слишком много". 100%-ное покрытие не всегда хорошо, потому что тогда ваше тестирование не будет приоритетным и потребуется много обслуживания.
- «В основном интеграция». Здесь снова акцент делается на интеграционные тесты: они имеют наибольшую ценность для бизнеса, поскольку ежедневно обеспечивают высокий уровень уверенности, сохраняя при этом разумное время выполнения.
Это заставляет еще раз задуматься о пирамиде тестирования и переключить внимание на интеграционное тестирование. За последние несколько лет было предложено множество адаптаций, поэтому давайте рассмотрим наиболее распространенные из них.
Тестовый алмаз
Первая адаптация устраняет чрезмерный акцент на модульном тестировании, как это видно на пирамиде тестирования. Представьте, что вы достигли 100% покрытия модульными тестами. Однако при следующем рефакторинге вам придется обновить многие из этих модульных тестов, и у вас может возникнуть соблазн пропустить их. Поэтому они разрушаются.
В результате, вместе с повышенным вниманием к интеграционному тестированию, может возникнуть следующая форма:
Пирамида превращается в алмаз. Вы можете видеть предыдущие три слоя, но другого размера, а единичный слой был обрезан:
- Единица . Пишите модульные тесты так, как вы их определили ранее. Однако, поскольку они имеют тенденцию к размыванию, расставляйте приоритеты и охватывайте только самые критические случаи.
- Интеграция . Вы знаете интеграционные тесты, проверяющие комбинацию отдельных модулей.
- Е2Е . Этот уровень обрабатывает тесты пользовательского интерфейса, аналогичные пирамиде тестов. Позаботьтесь о том, чтобы писать E2E-тесты только для наиболее важных тестовых случаев.
Тестирование сот
Существует еще одна адаптация, представленная Spotify , которая похожа на тестовый алмаз, но дополнительно специализируется на программных системах на основе микросервисов. Соты тестирования — это еще одна визуальная аналогия детализации, объема и количества тестов, которые необходимо написать для программной системы на основе микросервисов . Из-за небольшого размера самая значительная сложность микросервиса связана не с самим сервисом, а с тем, как он взаимодействует с другими. Поэтому стратегия тестирования микросервиса должна в первую очередь фокусироваться на интеграционных тестах.
Эта форма напоминает нам соты, отсюда и название. Он имеет следующие слои:
- Интегрированные тесты . В статье Spotify для определения этого слоя используется цитата Дж. Б. Райнсбергера : «Тест, который пройдет или не пройден в зависимости от правильности другой системы». Такие тесты имеют внешние зависимости, которые вам необходимо учитывать, и наоборот, ваша система может оказаться зависимостью, которая нарушает работу других систем. Подобно тестам E2E в других аналогиях, используйте эти тесты осторожно, только в самых важных случаях.
- Интеграционные тесты . Как и в случае с другими адаптациями, вам следует сосредоточиться на этом слое. Он содержит тесты, которые проверяют корректность вашего сервиса более изолированно, но все же в сочетании с другими сервисами. Это означает, что тесты будут включать и некоторые другие системы и фокусироваться на точках взаимодействия, например, через тесты API.
- Тесты на детали реализации . Эти тесты напоминают модульные тесты — тесты, которые фокусируются на частях кода, которые естественным образом изолированы и, следовательно, имеют свою внутреннюю сложность.
Если вы хотите узнать больше об этой стратегии тестирования, прочтите пост Мартина Фаулера, в котором сравнивается тестовая пирамида с сотами, и оригинальную статью на Spotify .
Тестовый трофей
Вы уже можете видеть постоянное внимание к интеграционным тестам. Однако другой тип, с которым вы столкнулись в предыдущей статье, теоретически не является тестированием, но все же является важным аспектом, который вам следует учитывать в стратегии тестирования. Статический анализ отсутствует в пирамиде тестирования и в большинстве адаптаций, которые вы видели до сих пор. Существует адаптация трофея тестирования, которая учитывает статический анализ, сохраняя при этом акцент на интеграционных тестах. Трофей за тестирование взят из более ранней цитаты Гильермо Рауха и разработан Кентом К. Доддсом:
Трофей за тестирование — это аналогия, показывающая степень детализации тестов немного по-другому. Он имеет четыре слоя:
- Статический анализ . Он играет жизненно важную роль в этой аналогии и позволяет выявлять опечатки, ошибки стиля и другие ошибки, просто выполняя уже описанные шаги отладки.
- Юнит-тесты . Они гарантируют, что ваш самый маленький модуль будет надлежащим образом протестирован, но приз за тестирование не подчеркнет их в той же степени, что и пирамида испытаний.
- Интеграция . Это основное внимание, поскольку оно наилучшим образом балансирует стоимость и более высокую надежность, как и в случае с другими адаптациями.
- Пользовательские тесты . Включая E2E и визуальные тесты, они находятся на вершине трофея тестирования, аналогично их роли в пирамиде тестирования.
Чтобы узнать больше о награде за тестирование, прочтите запись в блоге Кента К. Доддса на эту тему.
Еще несколько подходов, ориентированных на пользовательский интерфейс
Это все хорошо, но как бы вы ни называли свою стратегию: «пирамидой», «сотой» или «ромбом», все равно чего-то не хватает. Хотя автоматизация тестирования ценна, важно помнить, что ручное тестирование по-прежнему важно. Автоматизированное тестирование должно облегчить рутинные задачи и освободить инженеров по обеспечению качества, чтобы они могли сосредоточиться на важнейших областях. Вместо замены ручного тестирования его должна дополнять автоматизация. Есть ли способ объединить ручное тестирование с автоматизацией для получения оптимальных результатов?
Тестирование ледяного конуса и тестирование краба
Действительно, существуют две адаптации пирамиды тестирования, которые больше ориентированы на способы тестирования, ориентированные на пользовательский интерфейс. Оба имеют преимущество высокой достоверности, но, естественно, более затратны из-за более медленного выполнения теста.
Первый, тестовый ледяной конус, выглядит как перевернутая пирамида. Без этапа ручного тестирования его также называют «тестовой пиццей».
Ледяной конус больше внимания уделяет ручному тестированию или тестированию пользовательского интерфейса и меньше всего — модульному тестированию. Это часто проявляется в проектах, где разработчики начали работу, имея лишь несколько мыслей о стратегии тестирования. Ледовый кодекс считается антипаттерном, и это справедливо. Это затратно с точки зрения ресурсов и ручной работы.
Тестовый краб похож на тестовый ледяной конус, но с большим упором на E2E и визуальное тестирование:
Эта стратегия тестирования включает еще один аспект: она проверяет, что ваше приложение работает и выглядит хорошо. Краб тестирования подчеркивает важность визуального тестирования , определенного в предыдущей статье . Интеграционное тестирование, разделенное на компонентное и API-тестирование, отходит дальше на второй план, а юнит-тестирование играет здесь еще более второстепенную роль. Более подробную информацию об этой стратегии тестирования вы можете найти в этой статье о тестирующем крабе .
Хотя эти две стратегии тестирования являются более дорогостоящими, они имеют свое место: например, в небольших проектах, где требуется меньше тестов или необходимо охватить меньшую сложность. В этом случае полноценная стратегия тестирования, ориентированная на интеграционное тестирование, может оказаться перегруженной.
Хотя эти две стратегии тестирования являются более дорогостоящими, они имеют свое место, например, в небольших проектах, которые требуют меньшего количества тестов и не должны охватывать большую сложность. В этом случае стратегия полномасштабного тестирования, ориентированная на интеграционное тестирование, может оказаться излишне сложной.
Практический совет: давайте выработаем стратегию!
Теперь вы узнали о наиболее распространенных стратегиях тестирования. Вы начали с классической пирамиды тестов и познакомились с ее многочисленными модификациями. Теперь вам нужно оценить их для вашего продукта и решить, какой из них лучше всего подходит для вашего проекта. Ответ на этот вопрос следует начать со всеми любимого « Это зависит от ситуации ». Однако это не делает его менее точным.
Выбор наиболее подходящей стратегии тестирования из описанных (и даже неучтенных) зависит от вашего приложения. Он должен соответствовать вашей архитектуре, вашим требованиям и, наконец, что не менее важно, вашим пользователям и их требованиям. Все это может отличаться от приложения к приложению. Это совершенно нормально. Помните, что ваша самая важная цель — служить пользователям, а не следовать определениям из учебника.
Чаще всего реальные тесты сложно разделить и определить индивидуально. Даже сам Мартин Фаулер подчеркивает положительный аспект разных определений , например, в случае с модульными тестами. Как правильно заметил Джастин Сирлс в своем твите :
[…] писать выразительные тесты, которые устанавливают четкие границы, выполняются быстро и надежно и терпят неудачу только по полезным причинам.
Джастин Сирлс
Сосредоточьтесь на тестах, которые сообщают о реальных ошибках, с которыми могут столкнуться пользователи, и не отвлекайтесь от своей цели. Тесты должны быть разработаны так, чтобы приносить пользу пользователю, а не просто обеспечивать 100% покрытие или обсуждать, какой процент какого типа тестирования писать.
Сосредоточьтесь на тестах, которые сообщают о реальных ошибках, с которыми могут столкнуться ваши пользователи, и не отвлекайтесь от своей цели. Тесты должны быть разработаны так, чтобы приносить пользу пользователю, а не просто обеспечивать 100% охват или вызывать споры о том, какой процент определенного типа тестирования вам следует написать.