Публикуем запись доклада Антонины Фанталиной "Автоматизация регресса бекендов. Без СМС и автотестов" с прошедшего в Новосибирске QA DevDay.
Тоня тестирует навигатор в 2ГИС. Проект объёмный, а имеющиеся unit-/функциональные/интеграционные тесты не всегда находят проблемы. В своём выступление Тоня рассказала, как проверить API на изменения с помощью diff-ответов от сервера, и поделилась муками выбора между Diffy, Karate и кастомным решением.
Сегодня мы рассмотрим POST-запросы. Они, пожалуй, наиболее важные из всех REST-запросов, потому что добавляют новые записи в базу данных приложения. Очень важно как следует их протестировать, потому что они напрямую влияют на качество данных вашей базы.
Усилия по тестированию прилагаются на различных уровнях автоматизации в приложении. Вот некоторые из них, которые я, согласно личному опыту, нахожу интересными:
Автоматизация на юнит-уровне – она редко касается кого-либо, кроме разработчиков, и я считаю, что это правильно. В норме цель юнит-тестов – это предоставление быстрой обратной связи о правильности работы кода. Конечно, они подвержены тем же болезням, что и автоматизация в целом – "утверждающе-демонстративному" образу мышления при создании тестов. Даже если тесты используются в методологии управления через тестирование, они не особенно полезны, если сообщают только о том, что продукт работает. Фактически любой тест, который не подвергает систему суровым испытаниям с целью выявления проблем – это просто показуха.
Тут важно помнить, что очень глупо полагать, что наличие юнит-тестов означает, что что-то вообще тестировалось, или же что нужда в других уровнях тестирования благодаря наличию юнит-тестов снизилась. Юнит-тесты просто сообщают, что наш код готов двигаться дальше по цепочке тестирования. Не больше, не меньше!
Все больше и больше компаний переходит на микросервисы в своих приложениях. Это означает, что разные секции приложения могут иметь отдельные хранилища данных и отдельные команды для взаимодействия с ними. Преимущество такого подхода в том, что в небольшой компонент внедрять изменения куда проще, нежели менять все приложение. Это также означает, что если упадет один микросервис, оставшаяся часть приложения продолжит функционировать. К примеру, представьте, что у вас есть сайт проката велосипедов. У него есть микросервис системы бронирования, и еще один – для учета оборудования. Если микросервис оборудования упадет, пользователи все равно смогут бронировать велосипеды, используя кэшированные данные сервиса оборудования.
Большинство микросервисов используют API – программные интерфейсы приложения, которые представляют собой наборы команд, описывающих, как можно использовать службу. Большая часть API использует REST-запросы (Representational State Transfer — «передача состояния представления») для отправки и получения данных.
Однако, несмотря на широкое применение REST API в современных приложениях, многие тестировщики даже не подозревают, как легко их тестировать! Эта статья – введение в REST-запросы и их использование в тестировании API.
Публикуем запись доклада Антона Малев-Ланецкого "Postman и Newman — автоматизация API для бедных" с прошедшего в Новосибирске QA DevDay.
Антон привык работать в условиях ограниченных сроков-бюджетов и с радостью делится своими лайфхаками. В докладе рассказывает, как подружить Postman и Newman, уйти от запуска руками и получить отчёт в удобном виде. Бесценный навык и бесплатная реализация.
О, благословенная страна тест-автоматизации, сберегающая столько денег, времени и сил! Мы беремся за автоматизацию, чтобы повысить эффективность и частоту проверок, однако большая часть усилий в области автотестов пропадает впустую. Это плохо, если учитывать, что правильно внедренные автотесты очень выгодны.
В проекте по начислению пенсии мы внедряли решение по автоматическому приему, отказу или постановку в очередь на ручную обработку уведомлений о состоянии здоровья – в зависимости от четырех разных оценок. Пока оно внедрялось, я сделала автоматизированный набор тестов, управляемый через данные, проверяющий все возможные комбинации и диапазоны оценок.
Финальный тест был запущен спустя месяц разработки и занял десять минут. Вообще-то пять, но менеджер проекта не верила своим ушам и заставила меня прогнать его повторно.
Этот проект отлично подходил для автотестов, но не все проекты так же хороши. Я собрала ряд рекомендаций для тех, кто раздумывает над внедрением автотестов.
Если вы сталкивались с автоматизацией тестирования, то это, скорее всего, были автотесты для web-страницы, web-блога, web-интерфейса. Возможно, ваша команда использует Appium для функционального тестирования мобильного приложения или инструментальные тесты Android (Espresso).
Но в 2018 году всё ещё нужно разрабатывать десктопные приложения, поддерживать legacy-проекты. Банки, финансовые отделы компаний, производства и лаборатории, сегмент HoReCa применяют Windows Desktop-приложения. Множество бизнесов разных направлений применяют их для учета, организации и автоматизации бизнес-процессов.
Пользовательская машина дает не меньше возможностей, чем web. А иногда и больше. Например, это работа с локальными файлами и устройствами: обработка больших данных, возможность использовать специфичное оборудование, обращаться к различным сервисам. Причин для сохранения десктопных приложения масса:
Подключение внешних устройств. К примеру, использование сканера отпечатков пальцев для идентификации, сканера паспорта и других устройств.
Соблюдение политики безопасности. Например, на заводе или в банке, где запрещен выход в Internet.
Уже существующий парк машин, который может состоять, например, из PС на OC Windows 7.
Всё вышеперечисленное — потребности реальных заказчиков, и достижения web для таких задач неприменимы.
За последние пять лет, по данным Google Trends, значительно вырос интерес к тестированию API. Такая тенденция отражает сдвиг парадигмы в сторону web и мобильных приложений, а также разделение серверных служб и пользовательских интерфейсов.
Тестирование API - это тестирование, которое включает в себя проверку и валидацию API и веб-служб. В отличие от традиционного тестирования, в котором основное внимание уделяется функциональности графического интерфейса и взаимодействию с конечным пользователем, тестирование API проверяет программные интерфейсы, находящиеся на среднем уровне приложения, которые используются разработчиками (например, headless или GUI-less компоненты, обычно невидимые для конечных пользователей).
В обычном web или мобильном приложении, Web-API могут объединять между собой различные компоненты, такими компонентами могут быть особенные представления или пользовательский интерфейса c веб-сервером. Тем самым, автоматизация тестирования API становится все более привлекательным выбором в современном тестировании программного обеспечения. (Подробнее о тестировании API)
Что бы успешно реализовать тестирование API, команды должны иметь хороший набор инструментов, соответствующих конкретным требованиям. Однако это сложная задача, согласно нашему опросу более чем 2200 профессионалов в области программного обеспечения. Отчасти проблема заключается в том, что выбранный инструмент по началу вроде бы и справлялся со своей задачей, однако, проблемы начинаются, когда приходит время интегрировать его с уже существующими инструментами и процессами в долгосрочной перспективе.
Чтобы помочь вам разобраться, какие же все-таки инструменты лучше всего подходят для автоматизации тестирования API, в этой статье для вас будет представлены обзор и сравнение трех популярных инструментов для тестирования API: SoapUI, Postman и Katalon Studio. SoapUI и Postman специализируются исключительно на тестировании API, в то время как, Katalon Studio предоставляет полный набор инструментов для тестирования API, Web и мобильных приложений. (Подробнее о 5 лучших и бесплатных инструментах для тестирования API)
Поговорим про интернет вещей. Согласно Gartner, в мире уже уже используется более 7 миллиардов IoT-устройств, а к 2020 году превысит 20 миллиардов. Как тестировать эти устройства, такие как холодильники, самостоятельно заказывающие продукты через интернет, или самоуправляемые автомобилями — вот вопрос, который будут задавать себе их производители ближайшие несколько лет.
В Перфоманс Лаб этим вопросом тоже задались и провели тестирование простого IoT устройства на платформе Renesas. Получилось очень интересно, решили снять небольшое видео, на котором Дмитрий Химион, подробно рассказывает о нашей технологии и показывает крутые мигающие лампочки.
Надеемся, что этот материал поможет многим командам, найти свой подход к тестированию умных устройств.
