Публикуем запись доклада Антона Малев-Ланецкого "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 минут. И решили, что впредь на всех крупных проектах бизнес-процесс «клиент — тестирование — отчетность» должен быть автоматизирован. Хотите узнать, какой эффект оказывает отказ от бесконечных таблиц, справок, сводных табелей на процесс тестирования и отношения с клиентами? Тогда следуйте за нами. Но начнем мы с короткого рассказа-утопии…
Размышляя о новом наборе автотестов, вы наверняка начнете с вопроса, что именно вы собираетесь автоматизировать. Неважно, требует ли автоматизации ваш менеджер, или за нее боретесь вы – прежде чем выбирать инструмент, вам нужно разработать стратегию тестового покрытия.
На решение, что конкретно автоматизировать, влияет множество факторов. Если вы пытаетесь определить масштаб автоматизации изолированно, вы, возможно, наделаете ошибок. Ниже – ряд советов, которые помогут вам мыслить шире и вовлечь в такое обсуждение широкую аудиторию.
Я начал этот цикл статей с программирования, и сделал наиболее распространенную ошибку, которую делают все автоматизаторы – углубился в объяснения, как автоматизировать, вместо того, чтобы рассказать, почему это важно и выгодно для нас (спасибо Джиму Хейзену за то, что он обратил на это мое внимание).
На самом деле я рад, что все произошло именно так, потому что это лишняя демонстрация того, как люди, включая меня, подходят к автоматизации – они просто учатся программировать и ныряют в код, не зная, что они, черт возьми, делают. Делаем шаг назад, переосмысляем…
Еще несколько лет назад к организации автоматизированного тестирования предъявлялось, по сути, лишь одно требование — исключить из большинства рутинных проверок труд человека. Активнее всего автоматизацию внедряли крупные компании, для которых производительность и скорость прохождения тестов редко являлись критическими показателями. Они без особых проблем могли «залатать» деньгами любую дыру в структуре тестов, подключив несколько дополнительных мощных серверов или расширив парк тестовых устройств.
Но рынок быстро меняется: число профессиональных автоматизаторов растет с каждым днем, поэтому не удивительно, что у многих QA-компаний появились выгодные предложения для среднего и малого бизнеса. Сегодня заказать создание 100-200 автотестов могут позволить себе владельцы практически любого небольшого приложения или сервиса. А вот заставить их работать эффективно, не «проглатывая» дорогостоящие ресурсы и не тратя десятки часов на выполнение, — и есть настоящий вызов. В этой статье мы поделимся двумя историями из нашей борьбы за производительность, не упуская трудностей, с которыми столкнулись во время путешествия сквозь мрачный лес прожорливых автотестов.
«Как начать автоматизировать» - первая тема в серии статей. Так как я обещал, я разъясню как для себя, так и для читателей, то, что я знаю про автоматизацию как специфически направленную деятельность со своими целями, поддерживающую тестирование.
Эта серия статей будет:
Короткой, примерно 5 минут на чтение, хотя это очень сложно для меня.
Практической – без воды, только эмпирические, полезные советы.
Основанной на личном опыте и плохих решениях. Я думаю, это очень полезно.
