Автор: Виктор Славчев (Viktor Slavchev) Оригинал статьи Перевод: Ольга Алифанова.
В этой части ретроспективных уроков автоматизации я постараюсь сконцентрироваться на другом ключевом вопросе – что имеет смысл автоматизировать? Почему именно это, а не то? Зачем люди тратят столько времени на UI-тесты? Чтобы перейти к этим вопросам, поговорим об интерфейсах.
Меня зовут Виталий Котов, я работаю в компании Badoo и бо́льшую часть времени занимаюсь вопросами автоматизации тестирования. Решением одного такого вопроса я и хочу поделиться в этой статье.
Речь пойдёт о том, как мы организовали процесс работы UI-тестов с A/B-тестами, коих у нас немало. Я расскажу о том, с какими проблемами мы столкнулись и к какому флоу пришли в итоге. Добро пожаловать под кат!
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Сегодня мы поговорим о добавлении правил в Postman-запросы. Мы уже говорили о том, что значат различные коды ответов на API-запросы, и как писать правила для них в Postman. Теперь мы добавим другие правила, которые более полно протестируют наши запросы.
Мы будем использовать созданную нами коллекцию Postman, поэтому если вы еще этого не сделали – настройте ее, прежде чем продолжать.
Если вы хоть раз делали REST-запрос или изучали раздел инструментов разработчика в браузере, то наверняка видели код ответа из трех цифр, возвращенный в ответ на HTTP-запрос. Давайте поговорим о различных типах кодов ответа, которые можно получить в процессе тестирования API, и том, что они означают.
Сегодня мы закончим обсуждение типов REST-запросов, разобрав DELETE-запрос и специфику его тестирования. Мы также узнаем, как создать цепочку REST-запросов в коллекции Postman.
Как и PUT-запросы, PATCH-запросы меняют существующую запись, однако их куда сложнее тестировать! PUT-запрос меняет запись целиком, а PATCH – только одну часть запроса. С PATCH-запросом можно проводить множество различных операций – вы можете добавлять, заменять, удалять, копировать и перемещать значения в вашей записи. Опишу несколько примеров, а потом поговорим о том, как это тестировать.
Этот ретроспективный урок автоматизации посвящен ее моделям. Когда мы говорим "модель" или "смоделировать", мы обычно имеем в виду "трехмерное представление персоны или вещи или структуры, обычно имеющее меньший в сравнении с оригиналом масштаб" (случайное определение из Google, к счастью, верное).
Говоря о моделировании автоматизации, мы подразумеваем представление структуры автоматизированных проверок, которые мы проводим, и их распределение по разным слоям.
Сегодня мы обсудим тестирование PUT-запросов. В целом они очень похожи на POST-запросы – основное отличие в том, что POST создает новую запись, а PUT заменяют существующую.
Вернемся в Swagger Pet Store, чтобы разобраться, как создавать PUT-запрос. Кликните по запросу PUT /pet, чтобы открыть его:
Представьте, что перед Вами поставили задачу: протестировать API веб-сервиса. На этом этапе возникает довольно много вопросов, начиная от “Что именно требуется протестировать? Функционал? Нагрузку? Юзабилити?” до “Чем отличается список проверок для тестирования API от чек-листа для проверки UI”? В данной статье я поделюсь своим опытом составления проверок и кейсов для функционального тестирования SOAP API крупного государственного проекта со сложной логикой; мы обсудим, как лучше писать проверки и на что следует обратить особое внимание; в конце я представлю примерный вид документа с результатами тест-дизайна, которым будет удобно пользоваться и который не стыдно показать менеджеру или заказчику.
Публикуем запись доклада Антонины Фанталиной "Автоматизация регресса бекендов. Без СМС и автотестов" с прошедшего в Новосибирске QA DevDay.
Тоня тестирует навигатор в 2ГИС. Проект объёмный, а имеющиеся unit-/функциональные/интеграционные тесты не всегда находят проблемы. В своём выступление Тоня рассказала, как проверить API на изменения с помощью diff-ответов от сервера, и поделилась муками выбора между Diffy, Karate и кастомным решением.
