Виды тестирования и подходы к их применению
Блочное (модульное, unit testing) тестирование наиболее понятное для программиста. Фактически это тестирование методов какого-то класса программы в изоляции от остальной программы.
Не всякий класс легко покрыть unit тестами. При проектировании нужно учитывать возможность тестируемости и зависимости класса делать явными. Чтобы гарантировать тестируемость можно применять TDD методологию, которая предписывает сначала писать тест, а потом код реализации тестируемого метода. Тогда архитектура получается тестируемой. Распутывание зависимостей можно осуществить с помощью Dependency Injection. Тогда каждой зависимости явно сопоставляется интерфейс и явно определяется как инжектируется зависимость — в конструктор, в свойство или в метод.
Для осуществления unit тестирования существуют специальные фреймворки. Например, NUnit или тестовый фреймфорк из Visual Studio 2008. Для возможности тестирования классов в изоляции существуют специальные Mock фреймворки. Например, Rhino Mocks. Они позволяют по интерфейсам автоматически создавать заглушки для классов-зависимостей, задавая у них требуемое поведение.
По unit тестированию написано много статей. Мне очень нравится MSDN статья Write Maintainable Unit Tests That Will Save You Time And Tears, в которой хорошо и понятно рассказывается как создавать тесты, поддерживать которые со временем не становится обременительно.
Интеграционное тестирование
Интеграционное тестирование, на мой взгляд, наиболее сложное для понимания. Есть определение — это тестирование взаимодействия нескольких классов, выполняющих вместе какую-то работу. Однако как по такому определению тестировать не понятно. Можно, конечно, отталкиваться от других видов тестирования. Но это чревато.
Если к нему подходить как к unit-тестированию, у которого в тестах зависимости не заменяются mock-объектами, то получаем проблемы. Для хорошего покрытия нужно написать много тестов, так как количество возможных сочетаний взаимодействующих компонент — это полиномиальная зависимость. Кроме того, unit-тесты тестируют как именно осуществляется взаимодействие (см. тестирование методом белого ящика). Из-за этого после рефакторинга, когда какое-то взаимодействие оказалось выделенным в новый класс, тесты рушатся. Нужно применять менее инвазивный метод.
Подходить же к интеграционному тестированию как к более детализированному системному тоже не получается. В этом случае наоборот тестов будет мало для проверки всех используемых в программе взаимодействий. Системное тестирование слишком высокоуровневое.
Идея простая. У нас есть входные данные, и мы знаем как программа должна отработать на них. Запишем эти знания в текстовый файл. Это будет спецификация к тестовым данным, в которой записано, какие результаты ожидаются от программы. Тестирование же будет определять соответствие спецификации и того, что действительно находит программа.
| Проиллюстрирую на примере. Программа конвертирует один формат документа в другой. Конвертирование хитрое и с кучей математических расчетов. Заказчик передал набор типичных документов, которые ему требуется конвертировать. Для каждого такого документа мы напишем спецификацию, где запишем всякие промежуточные результаты, до которых дойдет наша программа при конвертировании. 1) Допустим в присланных документах есть несколько разделов. Тогда в спецификации мы можем указать, что у разбираемого документа должны быть разделы с указанными именами: $SectionNames = Введение, Текст статьи, Заключение, Литература 2) Другой пример. При конвертировании нужно разбивать геометрические фигуры на примитивы. Разбиение считается удачным, если в сумме все примитивы полностью покрывают оригинальную фигуру. Из присланных документов выберем различные фигуры и для них напишем свои спецификации. Факт покрываемости фигуры примитивами можно отразить так: $IsCoverable = true |
Понятно, что для проверки подобных спецификаций потребуется движок, который бы считывал спецификации и проверял их соответствие поведению программы. Я такой движок написал и остался доволен данным подходом. Скоро выложу движок в Open Source. (UPD: Выложил)
Данный вид тестирования является интеграционным, так как при проверке вызывается код взаимодействия нескольких классов. Причем важен только результат взаимодействия, а не детали и порядок вызовов. Поэтому на тесты не влияет рефакторинг кода. Не происходит избыточного или недостаточного тестирования — тестируются только те взаимодействия, которые встречаются при обработке реальных данных. Сами тесты легко поддерживать, так как спецификация хорошо читается и ее просто изменять в соответствии с новыми требованиями.
Системное тестирование
Системное — это тестирование программы в целом. Для небольших проектов это, как правило, ручное тестирование — запустил, пощелкал, убедился, что (не) работает. Можно автоматизировать. К автоматизации есть два подхода.
Первый подход — это использовать вариацию MVC паттерна — Passive View (вот еще хорошая статья по вариациям MVC паттерна) и формализовать взаимодействие пользователя с GUI в коде. Тогда системное тестирование сводится к тестированию Presenter классов, а также логики переходов между View. Но тут есть нюанс. Если тестировать Presenter классы в контексте системного тестирования, то необходимо как можно меньше зависимостей подменять mock объектами. И тут появляется проблема инициализации и приведения программы в нужное для начала тестирования состояние. В упомянутой выше статье Scenario Driven Tests об этом говорится подробнее.
Обзор модульного и интеграционного тестирования Spring Boot
С чего начать мои усилия по тестированию?
Как Spring Boot может помочь мне в написании эффективных тестов?
Какие библиотеки мне использовать?
В этом блоге вы получите обзор того, как модульное и интеграционное тестирование работает со Spring Boot. Кроме того, вы узнаете, на каких функциях и библиотеках Spring следует сосредоточиться в первую очередь. Эта статья действует как агрегатор, и в нескольких местах вы найдете ссылки на другие статьи и руководства, которые более подробно объясняют концепции.
Модульное тестирование с помощью Spring Boot
Модульные тесты составляют основу вашей стратегии тестирования. Каждый проект Spring Boot, который вы запускаете с помощью Spring Initializr, имеет прочную основу для написания модульных тестов. Настраивать практически нечего, так как Spring Boot Starter Test включает в себя все необходимые строительные блоки.
Помимо включения и управления версией Spring Test, этот Spring Boot Starter включает и управляет версиями следующих библиотек:
Библиотеки проверки утверждений, такие как AssertJ, Hamcrest, JsonPath и т. Д.
В большинстве случаев ваши модульные тесты не нуждаются в какой-либо конкретной функции Spring Boot или Spring Test, поскольку они будут полагаться исключительно на JUnit и Mockito.
С помощью модульных тестов вы изолированно тестируете, например, свои *Service классы и имитируете каждого сотрудника тестируемого класса:
Как видно из раздела import тестового класса выше, Spring вообще не включается. Следовательно, вы можете применять методы и знания, полученные из модульного тестирования любого другого приложения Java.
Вот почему важно изучить основы JUnit 4/5 и Mockito, чтобы максимально использовать возможности модульного тестирования.
Для некоторых частей вашего приложения модульное тестирование не принесет особой пользы. Хорошими примерами для этого являются уровень персистентности или тестирование HTTP-клиента. Тестируя такие части вашего приложения, вы в конечном итоге почти копируете свою реализацию, поскольку вам приходится имитировать много взаимодействий с другими классами.
Лучшим подходом здесь является работа с нарезанным контекстом Spring, который можно легко автоматически настроить с помощью аннотаций теста Spring Boot.
Тесты фрагментов Spring Context
В дополнение к традиционным модульным тестам вы можете писать тесты с помощью Spring Boot, которые нацелены на определенные части (фрагменты) вашего приложения. TestContext Spring фреймворка вместе с Spring Boot адаптирует Spring контекст с достаточным количеством компонентов для конкретного теста.
Как назвать такие тесты? На мой взгляд, они не попадают на 100% в категорию модульных или интеграционных тестов. Некоторые разработчики называют их модульными тестами, потому что они тестируют, например, один контроллер изолированно. Другие разработчики относят их к интеграционным тестам, поскольку в них задействована поддержка Spring. Как бы вы их ни называли, убедитесь, что у вас есть общее понимание, по крайней мере, в вашей команде.
Все они автоматически настраивают фрагменты Spring TestContext и включают только компоненты Spring, относящиеся к тестированию определенной части вашего приложения. Я посвятил целую статью представлению наиболее распространенных из этих аннотаций и объяснению их использования.
Две наиболее важные аннотации (сначала изучите их):
Также доступны аннотации для других нишевых частей вашего приложения:
При их использовании важно понимать, какие компоненты входят в состав, TestContext а какие нет. Документация Javadoc каждой аннотации объясняет выполненную автоконфигурацию и цель.
Вы всегда можете расширить контекст автонастройки для своего теста, явно импортировав компоненты с помощью @Import или определив дополнительные компоненты Spring Beans, используя @TestConfiguration :
Вы можете найти дополнительные методы устранения потенциальных исключений NoSuchBeanDefinitionException, с которыми вы можете столкнуться при таких тестах, в этом сообщении в блоге.
Ловушка JUnit 4 и JUnit 5
Важно следить за импортом, особенно за @Test аннотацией:
С помощью JUnit 5 vintage-engine ваш набор тестов может содержать как тесты JUnit 3/4, так и JUnit Jupiter, но каждый тестовый класс может использовать только одну конкретную версию JUnit. Рассмотрите возможность миграции существующих тестов, чтобы использовать различные новые функции JUnit Jupiter (параметризованные тесты, распараллеливание, модель расширения и т. д.). Вы можете постепенно мигрировать свой набор тестов, так как вы можете запускать тесты JUnit 3/4 рядом с тестами JUnit 5.
Документация JUnit включает советы по миграции JUnit 4, а также имеются инструменты (JUnit Pioneer или эта функция IntelliJ) для автоматической миграции тестов (например, импорт или проверки утверждений).
После того, как вы мигрировали свой набор тестов на JUnit 5, важно исключить любое появление устаревшей версии JUnit. Не все в вашей команде могут постоянно обращать пристальное внимание на импорт библиотек тестирования. Чтобы избежать случайного смешивания разных версий JUnit, исключение их из вашего проекта помогает всегда выбирать правильный импорт:
Кроме Spring Boot Starter Test другие зависимости тестования также могут включать более старые версии JUnit:
Чтобы избежать (случайного) включения зависимостей JUnit 4 в будущем, вы можете использовать Maven Enforcer Plugin и определить его как запрещенную зависимость. Это приведет к сбою сборки, как только кто-то включит новую тестовую зависимость, которая транзитивно потянет JUnit 4.
Обратите внимание, что, начиная с Spring Boot 2.4.0, зависимость Spring Boot Starter Test больше не включает vintage-engine файл по умолчанию.
Интеграционные тесты с Spring Boot: @SpringBootTest
Вы можете переопределить это поведение, указав либо, DEFINE_PORT либо RANDOM_PORT :
Для интеграционных тестов, которые запускают встроенный контейнер сервлетов, вы можете затем внедрить порт своего приложения и получить к нему доступ извне, используя TestRestTemplate или WebTestClient :
Поскольку TestContext Spring фреймворка будет заполнять весь контекст приложения, вы должны убедиться, что присутствуют все зависимые компоненты инфраструктуры (например, база данных, очереди сообщений и т. д.).
Здесь в игру вступают Testcontainers. Testcontainers будет управлять жизненным циклом любого Docker контейнера для вашего теста:
Для ознакомления с Testcontainers рассмотрите следующие ресурсы:
Если ваше приложение обменивается данными с другими системами, вам нужно решение для имитации этого HTTP-взаимодействия. Это довольно часто бывает, когда вы, например, получаете данные из удаленного REST API или токенов доступа OAuth2 при запуске приложения. С помощью WireMock вы можете заглушить и подготовить HTTP-ответы для имитации удаленной системы.
Кроме того, TestContext Spring фреймворк имеет удобную функцию кеширования и повторного использования, а также уже запущенный контекст. Это может помочь сократить время сборки и значительно улучшить циклы обратной связи.
Сквозные тесты с Spring Boot
Целью сквозных (E2E) тестов является проверка системы с точки зрения пользователя. Сюда входят тесты для основных сценариев работы пользователя (например, размещение заказа или создание нового клиента). По сравнению с интеграционными тестами такие тесты обычно включают пользовательский интерфейс (если он есть).
Вы также можете выполнить тесты E2E для развернутой версии приложения, например, в среде dev или staging прежде чем приступить к развертыванию в рабочей среде.
Для приложений, которые используют рендеринг на стороне сервера (например, Thymeleaf) или автономной системы, когда серверная часть Spring Boot обслуживает интерфейс, вы можете использовать @SpringBootTest для этих тестов.
Следующий тест демонстрирует, как получить доступ и протестировать общедоступную страницу приложения Spring Boot с помощью Selenide:
Вы можете найти больше информации о Selenide в этом сообщении в блоге.
Для компонентов инфраструктуры, которые необходимо запустить для тестов E2E, Testcontainers играет большую роль. Если вам нужно запустить несколько Docker контейнеров, вам пригодится модуль Docker Compose из Testcontainers :
Резюме
Spring Boot предлагает отличную поддержку как для модульного, так и для интеграционного тестирования. Это делает тестирование первоклассным гражданином, поскольку каждый проект Spring Boot включает в себя Spring Boot Starter Test. Этот стартер подготовит ваш базовый набор инструментов для тестирования с необходимыми библиотеками тестирования.
Кроме того, аннотации Spring Boot test упрощают написание тестов для различных частей вашего приложения. Вы получите специально созданный Spring TestContext только с соответствующими Spring beans.
Чтобы познакомиться с модульными и интеграционными тестами для ваших проектов Spring Boot, рекомендуются следующие шаги:
Избегайте ловушки JUnit 4 и JUnit 5.
Ознакомьтесь с различными аннотациями тестирования Spring Boot, которые автоматически настраивают фрагменты контекста.
Узнайте, как Spring TestContext Caching может помочь сократить общее время выполнения вашего набора тестов.
Удачного модульного и интеграционного тестирования с помощью Spring Boot,
Модульное, интеграционное, системное и приемочное тестирование
Тестирование – это очень важный этап в создании программного обеспечения. Существует несколько типов тестов, которые позволяют определить, насколько качественно работает программа или приложение. О некоторых из них и пойдет речь в данной статье.
Модульное тестирование www.a1qa.ru или, как его еще называют тестировщики и программисты, юнит-тестирование, направлено на проверку корректности функционирования отдельных модулей кода программы. Другими словами, каждый элемент тестируется изолированно, что позволяет специалисту определить проблему и установить ошибку гораздо быстрее. Наиболее эффективный подход в этом случае – это использование автоматизированных тестов, которые подготавливаются до начала разработки программного продукта. Использование такого метода тестирования дает возможность значительно сократить количество ошибок в коде, а также упростить процесс поддержки программного обеспечения.
Интеграционное тестирование http://www.a1qa.ru/functional_testing/ — это такой процесс, который подразумевает тестирование модулей программы, объединенных в группу. Как правило, этот этап проводится после юнит-тестирования. Главная задача этого этапа – удостовериться в том, что взаимосвязи между программными компонентами отвечают всем функциональным требованиям. Данные, которые будут получены в ходе этой фазы тестирования, будут использованы тестировщиками в дальнейшем для проведения системного тестирования.
Системное тестирование – это процесс, направленный на проверку функциональных и нефункциональных требований системы в целом, не принимая во внимания ее отдельные компоненты. Соответственно, оно должно проводиться после того, как полностью будет завершен этап тестирования, описанный выше. С его помощью можно установить, насколько верно система использует свои ресурсы, совместима ли она с другими системами, насколько она удобна в использовании и т.д.
Приемочное тестирование направлено на проверку готового продукта конечными пользователями. В его ходе устанавливается, соответствует ли система изначальным требованиям и соответствует ли уровень качества ожиданиям заказчика. Этот этап предполагает вынесение решения заказчиком о том, принимать разработанный программный продукт или отправить на доработку. Этот этап тестирование проводится до тех пор, пока заказчик не будет полностью удовлетворен результатом.
Уровни тестирования
Существует 4 уровня тестирования [1]:
В этой статье разберемся что такое уровни тестирования, зачем они нужны и что собой представляет каждый из них.
Начнем с простого примера.
Давай вспомним, что такое конструктор LEGO.
Это набор разноцветных деталей разной формы и размеров, которые после «магического» соединения превращаются в прикольную игрушку.
Обычно, процесс сборки игрушки выглядит так:
Программное обеспечение очень похоже на такой конструктор.
Но оно намного круче, ведь мы сами можем создавать любые детали и использовать детали (и даже блоки), созданные другими людьми (привет Open Source) 😉
Если посмотреть на процесс сборки с точки зрения тестирования, его можно описать так:
Суть процесса проста: проверка любой системы (будь то конструктор LEGO или мобильное приложение) начинается с ее наименьших элементов и двигается в сторону их объединения / увеличения до максимального размера.
Благодаря этому подходу ты никогда не попадешь в ситуацию, когда «колеса не того размера», «двери не от той машины» или «мы хотели самолет, а получили вертолет, платить не будем» 🙂
Теперь ты осознаешь уровни тестирования, но для эффективной работы этого недостаточно. Давай разбираться глубже)
Что такое уровень тестирования?
Уровень тестирования — активности тестирования, объединенные в группу исходя из общих характеристик, связанных с SDLC.
К характеристикам относятся:
Перед тем, как мы перейдем к рассмотрению каждого конкретного уровня и его характеристик, давайте рассмотрим реальный пример этапов тестирования ПО, который поможет нам совместить теорию и практику.
Пример реальной задачи по разработке
Предположим, перед вашей командой ставят задачу:
Создать страницу Contact Us на сайте Х. После отправки формы отдел поддержки должен получить Email, содержащий введенные данные и контактную информацию клиента.
Этап разработки требований и критериев приемки завершен, команда может приступать к реализации, задача переходит на этап дизайна (см. SDLC)
Первым делом разработчики прорабатывают дизайн системы.
Он может представлять собой следующую схему:
Дизайн системы Contact Us
Далее, разработчики детализируют схему добавляя описание шагов:
* логика проверки (валидации данных) опущена для упрощения схемы. Но, это не означает, что ее нет!
** логика отправки Email опущена для упрощения схемы
Имея требования к странице, описание дизайна и логики работы, проект переходит на этап разработки. Разработчики начинают писать код, а тестировщики могут приступать к продумыванию тестов.
Как ты уже знаешь, процесс начинается с наименьших частей системы — модулей / компонентов.
Модульное / Компонентное / Unit тестирование
Модульное / Компонентное / Unit тестирование фокусируется на компонентах / модулях, которые должны быть проверены в изоляции, как самостоятельные, независимые блоки.
Module / Component / Unit testing: A test level that focuses on individual hardware or software components [ISTQB Glossary]
Характеристики модульного тестирования
Цель: проверка правильности реализации функциональных / нефункциональных требований в модуле, раннее обнаружение ошибок
Объект: модуль / компонент / unit
Базис: дизайн системы, код, спецификация компонента
Типичные ошибки: ошибка в реализации требований, ошибка в коде
Ответственный: разработчик (редко тестировщик)
На этом уровне тестирования создаются модульные тесты (unit тесты), которые проверяют правильность работы модуля в тестовых условиях. Эти проверки всегда автоматизированы и выполняются очень быстро (несколько тысяч тестов в минуту).
Unit тесты, кроме поиска ошибок, также помогают оценивать качество кода, измерять покрытие кода тестами, сокращать время и затраты на тестирование.
Продолжая рассмотрение примера со страницей сайта, мы можем выделить следующие модули:
Для примера, рассмотрим модуль «страница Contact Us».
Требования:
В свою очередь, требования к модулю «Contact Us Controller»:
Все описанные выше требования должны проверяться Unit тестами.
Когда проверки компонентов закончены и мы уверены, что модули по отдельности работают как ожидалось, можем переходить на следующий уровень.
Интеграционное тестирование
Интеграционное тестирование фокусируется на взаимодействии между компонентами / модулями / под-системами / системами.
Выделяют 2 подтипа:
Integration testing. Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems. [ISTQB Glossary]
Component integration testing. Testing performed to expose defects in the interfaces and interaction between integrated components. [ISTQB Glossary]
System integration testing. Testing the integration of systems and packages; testing interfaces to external organizations (e.g. Electronic Data Interchange, Internet). [ISTQB Glossary]
Характеристики интеграционного тестирования
Цель: проверка правильности реализации взаимодействия между компонентами / модулями / частями системы
Объект: модули, состоящие из нескольких компонентов; под-системы, API, микросервисы
Базис: дизайн системы, архитектура системы, описание связей компонентов
Типичные ошибки: отсутствие / неправильные связи между элементами системы, неправильные передаваемые данные, отсутствие обработки ошибок, отказы и падения при обращениях к API
Ответственный: разработчик и тестировщик
Системные интеграционные тесты выполняются дольше (несколько десятков в минуту), чем модульные интеграционные тесты (несколько сотен-тысяч в минуту) и являются более творческими.
Продолжим рассмотрение примера.
Теперь, обратим внимание на связи между компонентами / под-системами:
Интеграционное тестирование
Начнем с компонентного интеграционного тестирования.
Обрати внимание на стрелки 5 и 7.
Они описывают связь между компонентами Contact Us Controller и Email Sender внутри под-системы Backend.
Contact Us Controller обращается к Email Sender с запросом для отправки Email сообщения (5), Email Sender отправляет письмо (6) и отвечает Contact Us Controller что все прошло удачно (7). Если при отправке (6) произошла ошибка, в ответе (7) вернется информация об ошибке.
В нашем случае интеграционные тесты проверят, что описанный выше процесс работает и что модуль Contact Us Controller инициирует отправку Email сообщения, а не SMS.
Тестирование интерфейсов (частично) и тестирование API являются примерами интеграционного компонентного тестирования.
В случае с тестированием API мы «имитируем» запрос от клиента — (3) и анализируем ответ сервера — (9), таким образом проверяя интеграцию всех задействованных модулей для конкретного API Endpoint внутри Backend.
Interface Testing. An integration test type that is concerned with testing the interfaces between components or systems. [ISTQB Glossary]
API testing. Testing performed by submitting commands to the software under test using programming interfaces of the application directly. [ISTQB Glossary]
Далее посмотрим на системное интеграционное тестирование.
Обрати внимание на стрелки 3 и 9.
Они описывают связь между двумя под-системами: Frontend, который формирует и отправляет запрос со страницы Contact Us с данными формы, и Backend, который обрабатывает и реагирует на запрос.
Тестирование на этом уровне показывает, что интеграция под-систем реализована в соответствии с заявленными требованиями.
В нашем случае для проверки правильности достаточно написать 1 тест: отправить форму Contact Us с ожидаемым результатом в виде показанного сообщения об успешной отправке — (10) и полученного Email сообщения с данными, оставленными с формы Contact Us.
Теперь, когда мы проверили интеграции компонентов внутри под-систем и интеграции под-систем, мы можем двигаться дальше.
Системное тестирование
Системное тестирование фокусируется на поведении всей системы в целом с точки зрения конечных пользователей.
Внимание уделяется задачам, на решение которых направлена система. Также во внимание берется нефункциональное поведение системы (скорость работы, нагрузка, и т.п.) при выполнении бизнес-задач.
Системное тестирование может проверять выполнение стандартов или законодательных / нормативных требований.
Тестовая среда для системного тестирования должна быть максимально приближенной (в идеальном варианте — идентичной) к окружению для эксплуатации (production).
System testing The process of testing an integrated system to verify that it meets specified requirements. [ISTQB Glossary]
Характеристики системного тестирования
Цель: проверка работы системы в целом
Объект: система, конфигурации системы, рабочее окружение
Базис: системные требования, бизнес требования, сценарии использования, User Stories, системные руководства, инструкции
Типичные ошибки: невозможность выполнять функциональные задачи, для которых создавалась система, неправильная передача данных внутри системы, неспособность системы работать правильно в среде эксплуатации, нефункциональные сбои (уязвимости, зависания, выключения)
Ответственный: тестировщик
Системное тестирование для нашего примера может включать в себя такие типы тестирования:
Системное тестирование системы Contact Us
* слово «тестирование» — убрано с изображения для упрощения 🙂
Помимо проверки отправки формы Contact Us, получения Email сообщения на почту суппорта и показа Success сообщения, в ходе системного тестирования мы должны ответить на вопросы:
На этом уровне тестирования создаются end-to-end тесты, имитирующие бизнес процессы, Use Cases и Use Stories от начала до конца.
Эти тесты все чаще автоматизируется и именно этот вид автоматизации сейчас очень востребован (JAVA, Python, JavaScript, C#, Selenium и т.п. — все здесь).
E2e тесты очень медленные (обычно 5-10 тестов в минуту) и коварные, с их автоматизацией нужно быть очень осторожным 😉
Системное тестирование — одна из самых творческих и объемных областей тестирования. Кроме end-to-end (e2e) тестирования, к этому уровню относятся все виды нефункционального тестирования.
Очень часто начинающие тестировщики видят только одно направление развития: автоматизация.
Но на самом деле направлений много.
Именно в системном тестировании можно развиваться бесконечно, становясь профессионалом в нагрузочном тестировании, юзабилити, тестировании безопасности, производительности и т.п. Конечно, автоматизация не помешает, но не все любят и хотят программировать 🙂
End-to-End Testing A type of testing in which business processes are tested from start to finish under production-like circumstances. [ISTQB Glossary]
После завершения тестирования всей системы нас ждет последняя проверка перед сдачей работы.
Приемочное тестирование
Приемочное тестирование фокусируется на готовности всей системы в целом.
Существуют несколько форм приемочного тестирования:
Пользовательское приемочное тестирование (User Acceptance testing, UAT) — проверяет пригодность системы к эксплуатации конечными пользователями.
Контрактное приемочное тестирование — проводится в соответствии с критериями, указанными в контракте приемки специального ПО.
Альфа-тестирование (alpha testing) и бета-тестирование (beta-testing) — используются для получения обратной связи от потенциальных или существующих клиентов.
Альфа-тестирование проводится “внутри” компании, без участия разработчиков / тестировщиков продукта.
Бета-тестирование проводится реальными пользователями системы.
Acceptance testing A test level that focuses on determining whether to accept the system. [ISTQB Glossary]
User acceptance testing (UAT) A type of acceptance testing performed to determine if intended users accept the system. [ISTQB Glossary]
Contractual acceptance testing A type of acceptance testing performed to verify whether a system satisfies its contractual requirements. [ISTQB Glossary]
Alpha testing A type of acceptance testing performed in the developer’s test environment by roles outside the development organization. [ISTQB Glossary]
Beta testing A type of acceptance testing performed at an external site to the developer’s test environment by roles outside the development organization. [ISTQB Glossary]
Характеристики приемочного тестирования
Цель: проверка готовности системы
Объект: система, конфигурация системы, бизнес процессы, отчеты, аналитика
Базис: системные требования, бизнес требования, сценарии использования, User Stories
Типичные ошибки: бизнес-требования неправильно реализованы, система не соответствует требованиям контракта
Ответственный: заказчик / клиент / бизнес-аналитик / product owner и тестировщик
Завершая рассмотрение примера можем написать приемочный тест, который выполнит заказчик:
Количество тестов на приемочном уровне намного меньше, чем на других уровнях, потому что в этот момент времени вся система уже проверена. Приемочные тесты практически никогда не автоматизируются.
В Agile разработке, конкретно в Scrum, для всех User Stories обязательно прописываются Acceptance Criteria. Именно они являются основой для приемочных тестов и показывают, что команда сделала именно то, что было нужно.
После завершения приемочного тестирования задача передается клиенту.
Резюме
В этой статье мы описали, что такое уровни тестирования, зачем они нужны и что собой представляет каждый из них.
Мы рассмотрели пример тестирования формы Contact Us.
Мы поняли, что тестирование нужно начинать с самых маленьких частей системы — компонентов / модулей.
Далее стоит проверить взаимосвязи между компонентами и всю систему в целом.
А завершает тестирование — заказчик, выполняя приемочное тестирование.
Для того, чтоб ты смог проверить себя — мы создали специальный тест! Он поможет тебе узнать, насколько хорошо ты разобрался в определениях уровней тестирования и подскажет, что нужно повторить)
🔥 А если ты готов к настоящему вызову и хочешь попробовать применить полученные знания на практике, мы подготовили практические задания по тестированию сайтов разной сложности, выполнение которых покажет, на сколько хорошо ты понимаешь и умеешь применять теорию, связанную с уровнями тестирования.
Если тебе интересна тема тестирования и ты хотел бы получать актуальную информацию по этой теме — подписывайся на наш Телеграм канал! Там интересно: статьи, тесты, опросы, нет спама 😉
Если ты хочешь продолжить разбираться с тестированием — узнай больше о тестировании в целом, разберись с типами тестирования или посмотри принципы тестирования ПО, которые являются основой для понимания тестирования ПО в целом.
Если у тебя возникли вопросы или есть предложения по статье — обращайся к нам в Телеграм, будем рады 🙂
Источники
Что такое уровень тестирования?
Уровень тестирования — активности тестирования, объединенные в группу исходя из общих характеристик, связанных с SDLC.
Что такое компонентное тестирование (unit testing)?
Компонентное / модульное / unit testing — фокусируется на компонентах / модулях / классах, которые могут быть проверены изолированно / отдельно.
Что такое интеграционное тестирование (integration testing)?
Интеграционное тестирование / integration testing — фокусируется на взаимодействии между компонентами / модулями, системами.
Что такое системное тестирование (system testing)?
Системное тестирование / system testing — фокусируется на поведении всей системы в целом с точки зрения конечных пользователей.
Что такое приемочное тестирование (acceptance testing)?
Приемочное тестирование / acceptance testing — фокусируется на поведении всей системы в целом. Оно дает возможность оценить готовность системы к развертыванию и использованию.