Запуск коллекции тестов в Postman – это отличный способ быстро протестировать ваше API. Но еще более быстрым способом будет автоматический запуск! Чтобы автоматизировать ваши Postman-тесты, нужно разобраться, как запускать их из командной строки.
Postman использует инструмент запуска командной строки Newman. Это модуль NodeJS, который легко установить через npm (Node Package Manager). Если у вас еще не установлен Node, это легко сделать через https://nodejs.org. Node содержит npm, поэтому после установки Node установить Newman очень легко. Просто откройте командную строку и наберите там следующее:
Меня зовут Елена Расторгуева, я отвечаю за продукт «Фактор» в HFLabs. «Фактор» — чертовски сложный алгоритмический enterprise, он обрабатывает данные в промышленных масштабах.
В статье я расскажу, как мы начинали тестировать «Фактор», как развивали автотесты и почему пришли к самописным фреймворкам.
Автор: Виктор Славчев (Viktor Slavchev) Оригинал статьи Перевод: Ольга Алифанова
Эта часть ретроспективных уроков автоматизации логично вытекает из предыдущей. Обсудим, какие тесты автоматизировать, какие тесты этого достойны, и какие тесты будут хорошими кандидатами на автоматизацию.
Я постараюсь быть честным, основываться на личном опыте и не лить воду. Я легко привлеку в свой блог тысячи читателей, просто повторяя всю ту чушь, которую несут в сети, но у меня есть принципы. Поэтому скажу так:
"Какие тесты автоматизировать" – неверный вопрос
Любой, проработавший в тестировании больше полугода, знает, что мы не "автоматизируем тестирование" – мы не можем и не будем этим заниматься. На самом деле мы автоматизируем часть процесса исполнения тестов, и это очень крошечная часть по сравнению со всем спектром деятельности, которой мы занимаемся в ходе тестирования. Думаю, я потратил достаточно букв, объясняя, что автоматизация – это не превращенное в код человеческое тестирование. Это два раздельных и очень различных типа тестирования, имеющих разные цели. Они не взаимозаменяемы – они дополняют друг друга (см. "Горькая правда об автоматизации", "Не-ручной неавтоматизированный тестировщик").
Учитывая это, неверно говорить о том, "какие тесты автоматизировать" – такой вопрос предполагает, что мы автоматизируем то, что уже делаем вручную.
Публикуем видео доклада спикера прошлогодней конференции TestCon Moscow 2018 - Ивана Катунова «Тест дизайн и автоматизация REST API».
Вы приходите на проект, где вам необходимо организовать тестирование RESTful API сервиса. Впервые столкнувшись с подобным типом приложения у вас может возникнуть множество вопросов. Чем тестирование RESTful API сервисов схоже и чем отличается от тестирования других типов приложений? Какое покрытие тестами является достаточным? Какие лучшие практики существуют для автоматизированного тестирования REST API? В рамках доклада мы сравним RESTful API сервисы с другими типами приложений, рассмотрим как учитывать эти отличия при тестировании. Вспомним базовые техники тест дизайна, которые можно применять для тестирования REST API. Определимся с тем, какое покрытие тестами является достаточным и от каких факторов оно может зависеть. Рассмотрим какие подходы существуют к автоматизации тестирования RESTful API сервисов и к хранению тестовых данных, какой набор инструментов и технологий поможет нам в эффективном тестировании.
Напоминаем, что в этом году конференция TestCon Moscow 2019 пройдет 2, 3 и 4 апреля.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Мне очень нравится, что в тестировании API очень легко организовывать тесты и переменные окружения. Я люблю, когда тест-наборы моментально готовы к использованию, и их можно запустить одной кнопкой при регрессионном тестировании, или же запускать автоматически как часть процесса непрерывной интеграции.
В этот раз мы поговорим о паттернах организации тестов, которые можно использовать для тестирования API. Я обсуждаю их в контексте Postman, но эти концепции останутся неизменными, какой бы платформой для API-тестирования вы ни пользовались.
Для начала давайте поговорим об окружениях. Если вы помните из прошлой статьи, то окружение – это коллекция переменных в Postman. Настраивать окружения можно двумя способами, и чтобы их разъяснить, я буду пользоваться сценариями. В обоих сценариях мы предположим, что у меня есть приложение, которое начинает свой жизненный цикл в разработке, затем переезжает в QA, подготовку и, наконец, в релиз.
В моем первом сценарии у меня есть API, которое получает и обновляет информацию о пользователях моего сайта. В каждом продуктовом окружении (Dev, QA, Staging, Prod) тест-пользователи различаются. У них будут разные ID, имена и фамилии. Ссылки на окружения также будут различными. Однако мои тесты не изменятся: во всех окружениях я буду получать информацию о пользователе (GET) и обновлять ее (PUT).
Анастасия рассказала о том, как на протяжении двух лет они выстраивали процесс обучения функциональных тестировщиков автоматизации. А все для того, чтоб вообще отказаться от разработчиков автотестов. Также, почему и когда выгодно вкладываться в обучение тестировщика. В докладе было рассказано о нескольких “подходах к снаряду” в попытке замотивировать и научить ребят кодить. На какие грабли наступили, какие выводы извлекли. И во что у них трансформировалась программа наставничества новичка. В Альфа-Лабе каждый ручной тестировщик умеет автоматизировать, и эти навыки он получает в течение 3 недель – 2 месяцев с момента приема на работу. На текущий момент у них вообще нет такой позиции, как разработчик автотестов.
Вас ждет исключительно практическая история с конкретными кейсами.
Напоминаем, что в этом году на конференции TestCon Moscow 2019 будет вестись онлайн трансляция всех докладов, в том числе с синхронным переводом.
Идея тестировать вёрстку сравнением изображений не нова: сохраняем эталон, вносим изменения в вёрстку, сравниваем новое изображение с сохранённым ранее. Казалось бы, всё просто. Но на практике возникает достаточно большое количество подводных камней.
Антон Усманский, ведущий разработчик инструментов визуального тестирования Gemini и Hermione, на конференции Heisenbug 2018 Moscow выступил с докладом об особенностях этого подхода. А теперь мы публикуем текстовую версию его доклада (для тех, кому удобнее видео, также прикладываем видеозапись).
Публикуем видео доклада с прошедшей конференции TestCon Moscow.
Дмитрий Гуманюк в докладе «Нейронные сети и машинное обучение для категоризации падений автоматизированных тестов» расскажет
Об опыте использования машинного обучения для категоризации падений автоматизированных тестов, основываясь на логах ошибок и стектрейса.
О том, что они используют в компании, как они это используют, как обучали и оптимизировали. И к каким выводам пришли.
О нейронных сетях – как следующем шаге, для того чтобы улучшить обработку логи и оптимизировать их содержимое. Что для этого делалось, и к каким результатам пришли.
О различных словоформах логов, их содержании, и бесполезных хвостах. И как их предобработка улучшает результаты машинного обучения.
Напоминаем, что до 28 февраля можно приобрести льготные билеты. Всех ждем на конференции TestCon Moscow 2019 со 2 по 4 апреля.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Сегодня мы поговорим о множестве способов использовать переменные в Postman. Мы будем пользоваться ранее созданной нами коллекцией запросов, поэтому посмотрите предыдущие статьи, прежде чем читать дальше.
Первое, что нужно понимать о переменных в Postman: они организуются в окружения. Postman-окружение – это просто коллекция переменных, которые можно использовать в коллекции Postman. Создать окружение очень просто. Нажмите на значок шестеренки в правом верхнем углу окна, а затем на кнопку "Add". Дайте окружению имя (например, "Pet Store"), а затем нажмите на "Add".
Всех нас на работе то и дело пытаются заставить писать юнит-тесты. Многие уже поняли, что от них один вред. Написание тестов отнимает много времени, за которое вы могли бы сделать что-то более полезное. Если тест неожиданно начинает падать, ломается сборка на сервере непрерывной интеграции, не выкатывается вовремя релиз, бизнес теряет деньги и крайним оказываетесь вы, автор упавшего юнит-теста. При рефакторинге тесты причиняют головную боль, потому что начинают падать и приходится с этим разбираться.
Тем не менее злые начальники требуют больше тестов, говоря о так называемом «контроле качества». Особо хитрые менеджеры даже считают покрытие и не отпускают вас с работы, пока оно не будет достигнуто. Ваш код заворачивают на ревью, если в нём нет тестов или они чем-то не понравились. Сплошное расстройство!
