Сегодня мы рассмотрим 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. Получилось очень интересно, решили снять небольшое видео, на котором Дмитрий Химион, подробно рассказывает о нашей технологии и показывает крутые мигающие лампочки.
Надеемся, что этот материал поможет многим командам, найти свой подход к тестированию умных устройств.
В нашем блоге, равно как и внутри компании, большую часть времени мы обсуждаем одну тему: тестирование и его организацию. Мы часто пишем, как применять те или иные подходы к анализу качества продукта, много времени уделяем автоматизации тестов, постоянно следим за различными конференциями — в общем, все время пытаемся понять, как улучшить нашу работу и принести больше пользы конечным пользователям. Нам интересно писать про эти задачи, а статистика посещений материалов показывает, что и читать их тоже бывает полезно.
Исходная ситуация: крупный клиент со сложным ПО, тестированием которого занимается команда в 20+ специалистов. Клиент хочет, чтобы каждый месяц мы отчитывались о состоянии его продукта и проделанной нами работе. В общем, стандартная для рынка ситуация. Но в какой-то момент заказчик решил изменить формат отчетности. Вместо одного свободного, нас попросили разбить его на сложные категории, позволяющие сразу восьми разным департаментам понять, какая работа, важная именно для них, была проделана за отчетный период. В итоге мы имеем не один отчет, а сразу восемь, на подготовку которых уходит от 25 до 40 часов. Так стандартная для рынка ситуация превратилась в ночной кошмар.
Наше решение: вспомнить, что автоматизировать можно не только тест-кейсы, но и бизнес-процессы. В июле отчет, на который обычно уходило несколько дней и, примерно, 100 кружек кофе для разъяренных менеджеров и тестировщиков, мы подготовили за 10 минут. И решили, что впредь на всех крупных проектах бизнес-процесс «клиент — тестирование — отчетность» должен быть автоматизирован. Хотите узнать, какой эффект оказывает отказ от бесконечных таблиц, справок, сводных табелей на процесс тестирования и отношения с клиентами? Тогда следуйте за нами. Но начнем мы с короткого рассказа-утопии…
