Начнем с основ! Изучим два основных режима тестирования и три распространенных типа автоматизации тестирования.
Мы все через это проходили: какой мем о кодировании повторяется слишком часто в реальной жизни?
Этот мем довольно хорошо это подводит: каждый ящик работает отлично по отдельности, но в сочетании с другим ящиком они блокируют друг друга и не работают. Вы хотите, чтобы оба ящика хорошо работали друг с другом и были работоспособны одновременно.
Примените это к веб-разработке: вы написали несколько тестов, возможно, даже достигли 100% тестового покрытия, но ваше приложение все еще должно работать, когда другие части встанут на свои места. Модули могут хорошо работать сами по себе, но не в сочетании друг с другом. Написание нескольких тестов имеет решающее значение, но это только одна часть идеальной настройки тестирования для вашего проекта. В качестве самого первого шага вам нужно определить, какие части качества приложения вам необходимо обеспечить и как вы можете этого добиться.
Проще говоря, вам нужен план, прежде чем вы начнете писать фактический тестовый код. Чтобы подойти к теме того, как тестировать на практике, давайте начнем с чистого листа и ответим на два основных вопроса:
- Как вы хотите провести тестирование?
- Что вы хотите протестировать?
В этой статье основное внимание уделяется общим вещам, которые вам нужно знать, чтобы ответить на первый вопрос. Чтобы начать с общей основы, давайте сначала узнаем, какие существуют режимы тестирования, а затем сосредоточимся на распространенных типах тестирования. В следующих статьях мы ответим на второй вопрос, объединим ответы и найдем стратегию тестирования, которая лучше всего подходит для вашего проекта. Поехали! 🙌
Начните с основ: общие режимы тестирования
При ответе на вопрос, как тестировать, первый момент, который нужно прояснить, очень абстрактный. Стоит ли тестировать вручную или позволить компьютеру взять на себя эту работу? Однако важно не впадать в бинарное мышление.
Ручное тестирование против автоматизированного тестирования
Если вы попросите инженеров по обеспечению качества дать определение тестированию, они, скорее всего, сначала разделят его на два «режима»:
- Ручное тестирование . Это типичный метод тестирования, проводимый реальными людьми. Инженер по обеспечению качества просматривает приложение, проверяет, работает ли оно, и в то же время пытается его сломать. Наиболее распространенный способ — исследовательское тестирование, когда инженер исследует приложение, используя свои знания о приложении по заранее определенному пути или контрольному списку.
- Автоматизированное тестирование . Это тип тестирования, проводимого компьютером. Инженеры по обеспечению качества применяют его для автоматизации повторяющихся и монотонных тестов.
Эта серия руководств в основном будет посвящена автоматизированному тестированию. Однако вам не следует сосредотачиваться только на одном способе тестирования. Даже если автоматизация экономит много времени и усилий, люди и ручное тестирование всегда будут играть важную роль. Вместо этого автоматизация тестирования должна освободить людей, чтобы они могли сосредоточиться на исследовательском тестировании и творческом решении проблем. Например, обеспечение качества пользовательского опыта или защита высокорисковой бизнес-логики. Другими словами, автоматизация прикрывает вашу спину. ❤️
Непрозрачная коробка против прозрачной коробки
Итак, вы определили общие режимы тестирования. Однако этого пока недостаточно. Чтобы спланировать стратегию тестирования, нужно ответить еще на один вопрос: нужно ли вам знать, как работает ваше приложение «под капотом», или лучше проводить тестирование без этих знаний? В зависимости от ответа, есть две процедуры на выбор для получения и выбора тестовых случаев:
- Тестирование непрозрачного ящика (или тестирование черного ящика). Оно основано на анализе функциональных или нефункциональных требований (спецификации) компонента или системы без учета его внутренней структуры.
- Тестирование прозрачного ящика (или тестирование белого ящика) — это процедура, которая учитывает внутреннюю структуру указанного ящика. Другими словами, как ваше приложение работает под капотом.
Обе процедуры могут применяться к ручному и автоматизированному тестированию. Однако некоторые аспекты общих режимов тестирования могут быть больше сосредоточены на одном из двух — мы рассмотрим это позже. А пока давайте еще разберем автоматизацию тестирования по типам.
Типы автоматизации тестирования: Как вы хотите проводить тестирование?
По мере приближения к ответу на вопрос «как», вы уже решили провести ручное тестирование. Однако выбор и применение типов автоматизации тестирования немного сложнее. Типы автоматизированного тестирования тесно связаны с метриками, которые вы хотите создать в своих проектах. Итак, давайте подробнее рассмотрим самые важные из них.
Как показано в меме, упомянутом ранее, вы уже сталкивались с двумя типами: модульное тестирование и интеграционное тестирование. Сквозное тестирование — это третье важное, что следует рассмотреть. Но это еще не все. Давайте рассмотрим подробнее.
Модульное тестирование
Модульное тестирование — это тип тестирования, при котором незначительные тестируемые части или блоки приложения индивидуально и независимо тестируются на предмет правильной работы. Эти блоки могут различаться по объему от функций, классов или интерфейсов до служб или полных компонентов. Их основными характеристиками являются скорость выполнения, изоляция и удобная поддержка. Если вы хотите глубже погрузиться в модульное тестирование, перейдите к этому руководству по модульному тестированию .
Интеграционное тестирование
Интеграционное тестирование фокусируется на взаимодействии между компонентами или системами. Другими словами, на том, насколько хорошо они работают вместе. Типичными примерами интеграционных тестов являются API или компонентные тесты.
Сквозное тестирование
Эти тесты часто называют тестами пользовательского интерфейса, и это название еще лучше объясняет их функцию. Эти тесты взаимодействуют с пользовательским интерфейсом вашего приложения, включая полный стек приложения, и тестируют ваше приложение от начала до конца.
Они напоминают системный тест, если ссылаться на теорию обеспечения качества. Эти тесты имитируют реального пользователя и его взаимодействие. Сквозные тесты требуют больше времени выполнения, поскольку они охватывают всю систему, а большее время выполнения требует больше вычислительной мощности. В результате эти дополнительные усилия приводят к более высоким расходам на обслуживание.
Тестирование визуального пользовательского интерфейса
Интересная подкатегория тестов пользовательского интерфейса — визуальные тесты. Эти тесты представляют собой расширенные сквозные тесты, которые предоставляют средства для проверки видимого вывода приложения. Такой тест делает снимок экрана после изменения и еще один снимок экрана, содержащий «статус-кво» (или золотой файл), затем предоставляет эти результаты рецензенту-человеку для проверки и изучения. Другими словами, он помогает находить «визуальные ошибки» во внешнем виде страницы, выходящие за рамки чисто функциональных ошибок и явно не записанные в утверждения.
Статический анализ
Здесь есть еще одна вещь, которую следует представить: статический анализ. Это не тип тестирования в смысле учебника. Однако позже он станет важным аспектом в стратегиях обеспечения качества. Вы можете представить, что он работает как функция проверки орфографии: он сканирует ваш код на наличие более существенных дефектов и синтаксических ошибок без запуска программы, таким образом обнаруживая проблемы со стилем кода. Эта простая мера может предотвратить множество ошибок. Это хороший момент, чтобы узнать о статическом анализе, если вы хотите узнать о нем более подробно.
Тестирование во всех формах: как все это работает вместе?
В поисках ответов на все эти вопросы вы можете найти возможное решение в некоторых аналогиях. В веб-сообществах и сообществах тестирования разработчики, как правило, используют эти аналогии, чтобы дать вам представление о том, сколько тестов и какого типа вам следует использовать.
Наиболее распространенными являются следующие пять стратегий, изображенных на этом изображении:
- Тестовая Пирамида
- Тестовый алмаз
- Тестовый ледяной рожок (также известный как Тестовая пицца)
- Тестовые соты
- Тестовый трофей
Это действительно большой объем информации для обработки. Как вам выбрать стратегию тестирования соответствия на основе всего этого? Не волнуйтесь, мы вам поможем. В следующей статье мы более подробно обсудим эти различные стратегии и объясним, как выбрать наиболее подходящую для вашего проекта. Оставайтесь с нами! 🔥