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