Первоначально на каждый API я писал свои коллекции и готовил тестовые данные в JSON формате. Это достаточно удобно, но при большом количестве тестов и коллекций поддерживать это становится накладно. Да и проводить валидацию данных в JSON не удобно.
Для решения этих проблем я написал макрос для Excel и коллекцию в Postman. Теперь в Postman у меня одна коллекция на все API и стандартный набор функций для обработки входящих данных и валидации возвращаемых результатов. Мне удалось перенести управление тестовыми данными и последовательность выполнения запросов в Excel.
Что было
1. JSON с данными
Раньше тестовый набор хранился в таком виде
2. 2. Последовательность выполнения запросов с обработчиками на JS хранилась в коллекциях Postman.
Что стало
1. Тестовый набор переехал в Excel
Все данные вносятся в Excel (управляющие ключевые символы: R, H, I и т.д. распишу ниже) и дальше при помощи макроса перегоняются в json формат:
2. В Postman
Эксперимент проводил на стандартном наборе CRUD операций, который в дальнейшем можно расширять.
Так как в Postman все операций выполняются только в рамках запроса, пришлось ввести пустой get запрос в конце выполнения которого определяется следующий запрос из последовательности. Выполнить JS код до запроса и определить первый запрос без пустого не получилось.
Во всех запросах Pre-request script и Test секции пустые, весь код унифицирован для запросов и хранится в общих секциях Pre-request script и Test папки API Collection.
Во всех запросах важно обратить внимание на url и на секцию Body в запросах POST и PUT, их значения определяются переменными, значения в которые вносятся из JSON с данными.
Теперь о самих тестах
Как читать Excel. Первой не пустой строкой идет номер тест кейса, то есть тест кейс хранится вертикально и на этой странице 9 тест кейсов. В текущем наборе в каждом тест кейсе будут выполнены сначала POST запрос, потом Delete.
Как запустить генерацию Json из Excel. В Excel нажать F11 и перейти на «ЭтаКнига», там запустить макрос.
Ключевые слова
R – request, означает начало нового запроса, во второй ячейке строки хранится тип запроса, в третьей адрес, по которому надо обращаться. Обратите внимание, что в url можно указывать переменные Postman
Значение из переменной подтянется
H – Данные для сверки в заголовке, пока ввел только response code, в Postman зашита проверка только на него. Важно чтобы в Excel название было таким же «response code», либо поправить в Postman
I, I2 … – Секция входных данных, поддерживает хранение моделей данных любой вложенности, цифра справа от I отвечает за уровень вложенности. Следующий набор данных вот так завернется в JSON. Если переменная, которая хранит данные пустая, то она не добавится. То есть если в переменной inn не будет значения, то она не добавится, а переменная chief добавится, так как она хранит модель. При этом если вся модель пустая, то она также не добавится.
Данные этой секции будут поданы в теле запроса
O, O2 … — Секция выходных параметров, они будут сравнены с теми, что возвращает response. Как и секция Input поддерживает хранение моделей.
При сравнении данные конвертируются в string, еще я дополнительно ограничил уровень рекурсии, это можно убрать
PO – Postman Output, значения из этой секции будут по имени переменной браться из response body запроса и записываться в переменную Postman.
В Excel достаточно поставить любой символ, в переменную запишется значение из response, а не excel
Эта секция нужна, чтобы хранить данные между скриптами, например чтобы удалить объект с id, который был создан в предыдущем реквесте
PC – Postman command, ввел только одну команду “terminate”, она используется для принудительного обрывания после выполнения текущего запроса. Полезно при негативном тесте, чтобы не вызывать шаг с удалением созданного объекта.
Ввод этой команды позволил на одном листе хранить и позитивные и негативные тесты
PI – Postman Input, значения из этой секции будут записаны в переменные Postman перед определением url
Может быть полезным, если надо переопределить переменные, которые указаны в url запроса.
Кстати, в подаваемых данных можно использовать данные из Postman переменных, для этого требуется использовать специальную конструкцию
В кейсе 1 мы внесли полученное значение в переменную, в кейсе 2 его использовали. Можно использовать не только в следующем кейсе, но и в текущем при следующем запросе. Например может потребоваться, если определение объекта для изменения идет не по url, а по значению переменной в запросе.
Подготовка к прогону
А теперь прогон, запускаем Postman runner, в нем выбираем нужную коллекцию и подгружаем файл с тестовыми данными:
Подавать будем следующий набор:
Здесь описано 15 тестов, при этом шаги 1-11, 13, 15 положительные с результатом 200 при POST запросе и шаги 12, 14 негативные с результатом 400. По ним информация в базу не будет внесена и поэтому секция Output пустая, а также указана команда terminate. Эта команда прервет выполнение последовательности и запрос на удаление «Delete» отправлен не будет.
После кейсов 1-11, 13, 15 мы запоминаем id который присвоился новому объекту, чтобы потом его удалить.
Запускаем
Все 15 тестов прошли успешно, на картинке виден тест 14, в котором не вызывается Delete после POST
В тестах 1-11,13,15 после POST вызывается удаление созданного объекта:
Резюме
- Последовательность выполнения запросов для тестирования API вынесена в Excel и обрабатывается в Postman.
- Все тестовые данные также вынесены в Excel ими удобно управлять и валидировать их. По крайней мере удобней чем в JSON формате.
- Коллекция Postman стандартизирована и при тестировании схожих API не требует доработки.
Ссылки
Комментарии (34)
maxzh83
12.09.2019 12:21Результаты прогона не сохраняются в Excel?
Mikhail_Ivakhnenko Автор
12.09.2019 12:26Нет, прогон осуществляется средствами Postman. Excel хранит данные о том, что подать и что сверить (Сверяется на стороне Postman), а также последовательности вызовов API методов
maxzh83
12.09.2019 14:01Раз уж вам так нравится Excel, то было бы кажется логичным также и выгружать туда статистику по прогону тестов. Но это вам виднее, стоит оно того или нет.
Ommonick
12.09.2019 13:20В экселе обычные входные — выходные данные для тестов.
На что только люди идут, лишь бы не пользоваться тестовыми фреймворками.
А если понадобится сравнивать со значением из базы?Mikhail_Ivakhnenko Автор
12.09.2019 14:01Также тут хранится последовательность выполнения запросов. С базой работать не умеет, в Excel надо хранить точные данные (или ссылки на postman переменные).
Значение из базы известно на момент написания теста или может быть не определено?
Подход не претендует на 100% покрытие потребностей и замену остальных инструментов. Нам он подходит и я им поделился.
maxzh83
12.09.2019 14:02А если понадобится сравнивать со значением из базы?
Что сравнивать? Я про то, чтобы выгружать статистику прошел тест или нет в excelMikhail_Ivakhnenko Автор
12.09.2019 14:19Отвечал на другой комментарий, а не Ваш.
Теперь по Вашему комментарию:
Визуализация не делалась и осталась стандартной, которую выдает Postman runner.
Позже, возможно, займусь работой с CI и визуализацией результатов.
Ommonick
12.09.2019 19:00Я промахнулся, вопрос был к автору статьи.
Надеюсь что не требуется ответ на то, зачем нужно смотреть что — то в базе при тестировании.
kotokur
12.09.2019 13:15+1Неожиданный подход) Думается, что есть большой минус в плане невозможности ревью изменений тестов. Мы в Test Mace совершили целый ряд телодвижений именно для того, чтобы удобно было хранить и ревьювить в системе контроля версий. У вас основной мотив был именно в удобстве работы с данными в табличном формате или необходимость использования скриптов для валидации ответа тоже сыграла свою роль?
Mikhail_Ivakhnenko Автор
12.09.2019 13:58Изменения для ревью можно получать сравнивая Json сформированный по предыдущей и текущей версии Excel. Если их заливать вместе с тестами, то изменения будут видны и в системе контроля версий.
Основные мотивы были следующие:
1. При появлении нового API, для написания тестов не писать код. — не у всех есть компетенции
2. Отказаться от Json как источника данных. — Не удобно наполнять и валидировать (первоначальное формирование)
3. Excel удобно наполнять данными. Также есть ряд средств для работы с тестовым набором (функции; условное форматирование, которое подсветит изменения от кейса к кейсу и т.д.)
— Мне в табличном формате действительно удобно работать с данными
— Не понял вопрос про скрипты валидации ответа.kotokur
12.09.2019 15:19В некоторых инструментах, например, SoapUI, реализована концепция источников данных. С их помощью вы можете загружать данные из различных источников и подставлять их в запросы. Очень похоже на то, что реализовали вы в своем решении. Мы в своем инструменте тоже планируем добавить такой механизм. Можем ли мы написать вам и проконсультироваться подробнее по поводу ваших потребностей, когда будем приступать к этой задаче?
Faenor
12.09.2019 13:35Подскажите куда можно устроиться руководителем отдела тестирования с такими навыками?
Postman знаю, Excel тоже…
Мне честно говоря кажется, что уж пусть лучше тестировщики научатся работать с Постманом и json, чем использовать какую-то надстройку из Excel.
Если нужна нормальная визуализация результатов — в том же Newman есть нормальные репортеры для Постмана, да даже для дженкинса плагины можно найти, где-то на хабре был недавно пост…
В общем Postman инструмент полезный, но данная реализация со временем быстро станет неактуальной.
Масштабировать сложно, поддерживать тоже сложно — например появится у вас десяток другой новых параметров в запросе, или логика интеграции какая нибудь сложная — что вы будете с Excel файлом делать — каждый раз вручную менять?Mikhail_Ivakhnenko Автор
12.09.2019 13:50Куда устроиться не могу подсказать, посмотрите на hh, я нашел. При этом опыта работы с Postman у меня на тот момент времени не было, освоил недавно.
В решении не затрагивается часть с визуализацией результатов, здесь есть визуализация подаваемых значений и ожиданий, а также последовательности вызовов. Визуализация результатов стандартная через Postman runner
На счет поддерживаемости и маштабирования нас на текущий момент устраивает, дальше посмотрим, может и изменим подход.
По поводу изменений в Excel при смене параметров или логики. В этом случае все равно придется вносить изменения, в любом инструменте, само оно не подстроится.Faenor
12.09.2019 14:00Михаил, спасибо за ответы и за статью.
В любом случае в последнее время редко выкладывают что то действительно полезное по тестированию. А этот подход хоть и спорный, но интересный и его можно развивать.
piton_nsk
12.09.2019 19:51Согласен, у такого подхода есть плюсы. Когда jsonа много и запросы сами по себе большие, то наборы тестов быстро превращаюся в какие-то портянки. Однозначно нужно что-то для более удобного представления. Excel всем знаком, все сделано просто и понятно, почему бы и нет?
Вообще, про реальный, может быть и спорный опыт, всегда читать интересно. Это не пересказ документации и не маркетинговая вода без реальных примеров.
lair
12.09.2019 23:13Excel всем знаком, все сделано просто и понятно, почему бы и нет?
Потому что версионировать неудобно. С равным успехом можно было бы хранить все в CSV, который и можно версионировать, и можно открыть в Excel.
piton_nsk
13.09.2019 10:26можно открыть в Excel
Ключевое слово — можно. Он, конечно, откроется. Только в екселе есть форматирование и прочие штуки. Однозначного соответствия не добиться.
Подход, конечно, имеет и минусы. Проблема в том, что CSV для версионирования тоже далеко не фонтан. Хранить его в системе контроля версий можно, как и екселевский файл или json. Но сравнивать изменения на достаточно больших файлах неудобно.
Идея генерировать json тоже весьма и весьма здравая.
Предлагаемый подход не панацея, но как один из вариантов вполне годится.lair
13.09.2019 12:17Только в екселе есть форматирование и прочие штуки.
А зачем эти "прочие штуки" нужны в конкретной задаче?
Но сравнивать изменения на достаточно больших файлах неудобно.
Ну так и большие файлы в данной задаче тоже не очень нужны, набор сценариев в фиче ограничен, между фичами файлы должны быть разными, а нагрузочное тестирование все равно надо делать иначе.
piton_nsk
13.09.2019 14:00А зачем эти «прочие штуки» нужны в конкретной задаче?
Первое, ексель дает форматирование «из коробки», этого уже хватит.
Второе, там используется макрос, для генерации json.
Третье, прямо вот в конкретной задаче, может и не нужны. А вообще можно добавить комментарии к полям, также в екселе есть встроенная сортировка/фильтрация, графики.
Опять же, если говорить о конкретной задаче, то нужно ли там удобно версионировать?
Ну так и большие файлы в данной задаче тоже не очень нужны
Тут может и не особо нужны, а вообще надо смотреть по обстоятельствам. Я имел опыт хранения таких вот тестовых json, мне не особо понравилось.lair
13.09.2019 14:04Первое, ексель дает форматирование «из коробки», этого уже хватит.
Так я еще раз спрошу: а зачем оно нужно, это форматирование?
Второе, там используется макрос, для генерации json.
Который можно написать на любом скриптовом языке.
А вообще можно добавить комментарии к полям, также в екселе есть встроенная сортировка/фильтрация, графики.
А зачем? Если речь идет о результатах, то этого всего в решении в посте нет. А если о входных данных, то я не понимаю, зачем.
Опять же, если говорить о конкретной задаче, то нужно ли там удобно версионировать?
В разработке ПО почти всегда нужно удобно версионировать. В моей практике, собственно, исключений нет (но это не означает, что их вообще не бывает).
Тут может и не особо нужны, а вообще надо смотреть по обстоятельствам.
А когда те обстоятельства случатся, тогда и будем думать, как решать.
Я имел опыт хранения таких вот тестовых json, мне не особо понравилось.
Я, вроде, не предлагал хранить тестовые JSON.
Bogik92
12.09.2019 17:55Михаил, прежде всего хочу поблагодарить за полезную статью! Сейчас по работе сталкнулся с необходимостью тестирования апи и кроме excel не было инструментов под рукой. Поделившись информацией про Postman и json вы буквально открыли мне глаза! Подскажите где можно скачать json и как его установить?
Михаил я впечатлен вашим професиональным уровнем, нсли не секрет подскажите где вы работаете начальником отдела тестирования?
Mikhail_Ivakhnenko Автор
12.09.2019 17:58Добрый день, спасибо.
Работаю в Москве, название фирмы раскрывать не буду.
Json с данными и последовательностью выполнения запросов генерируется на основе Excel — скачать его и коллекцию Postman можно на GitHub, ссылка в конце статьи.
Что нужно сделать для запуска:
1. Импортировать коллецию в Postman
2. Наполнить Excel данными и запустить генерацию Json
3. Запустить Postman Runner и импортировать файл сгенерированный на шаге 2.
4. Запустить прогон
Если требуется дополнительная консультация, пишите с описанием того, что не получилось.
Bogik92
12.09.2019 18:24Михаил, спасибо за исчерпывающий ответ! Но то что вы боитесь назвать компанию в которой работаете заставляет задуматься.
vladkorotnev
13.09.2019 05:59Может быть работа на аутсорсе с соответствующим NDA.
А попытка засунуть всё в эксель напомнила любимое японское развлечение делать всё на MSOffice :-)
Жалко, что визуализацию результата в эксель не получилось сделать — может, нашим бы удалось наконец автотесты навязать, вместо усаживания кого-то из разрабов протыкивать 1500+ пунктов в списке в экселе через самопальную штуку из кучи скриптов и curl.
squizduos
13.09.2019 02:09> Да и проводить валидацию данных в JSON не удобно.
Решительно не согласен. Валидация данных в любом JSON прекрасно проводится посредством схем.
Подход интересный, но, на мой взгляд, тесты API (как у вас в примере) могут и должны быть максимально автоматизированы и не запускаться вручную. Ваш же Excel-файл не впишется в CI :-)
qwez
13.09.2019 09:30Любая утилита, помогающая тестировщику, это, конечно, хорошо. Но с конкретно этим решением, мне кажется, вы выбрали тупиковую ветвь развития. Тут очень много ограничений, в которые вы упретесь со временем. И, либо бросите развивать дальше, либо придется начинать все с начала.
Если следовать вашей мотивации, то решение, вроде как, и подходит. Но мне кажется, вы немного неправильно поставили изначальный вопрос. Он бы «неудобно работать с тестовыми данными в json, как сделать удобно?». Ок, excel удобный, поехали. А если бы вы задали вопрос типа: «мне неудобно работать с данными, как сделать так, чтобы с ними вообще не работать?». Тогда бы вы пришли к построению классической системы автотестирования, которая сама подготавливает для себя тестовые данные.
В целом, у вас получилась неплохая приблуда в помощь при ручном тестировании. Но это не автотесты (хотя вы, вроде, и не претендовали). За статью, таки, минус. В карму плюс. Удачи!
Bu1313
14.09.2019 14:10Автору спасибо.
Пускай это не лучшее решение Вашей задачи, но многие как и я могут использовать эту информацию по своему усмотрению.
Не обращайте внимание на ехидства, тех кто родился якобы сразу с клавиатурой.
TheGodfather
>Руководитель отдела качества и тестирования
>Excel...Postman
Кхм…
Вот прямо навскидку:
1. Как версионирование поддерживать? Вместо человекочитабельных YAML (что есть тот же JSON) в гите теперь у вас эксель-файл непонятно где.
2. Как в CI интегрировать? Почему не Python+unittest+requests? Или вы посадили своего интерна нажимать на кнопки «Поставь программу, скачай эксель-файл, открой эсель-файл, нажми кнопку, убедись, что все зеленое»?
3. Как валидацию-то сделали? VBA вместо простой функции на Питоне?
Mikhail_Ivakhnenko Автор
Добрый день!
1. Версионирование можно поддерживать через svn или git, где будут храниться версии excel файла. Сравнение изменений они не поддерживают, но при введении валидации файла, как шага процесса, другим тестировщиком имеет право на жизнь.
2. Для интеграции с CI у Postman есть newman CLI. Я её пока не реализовывал, но читал, что такая возможность есть. По поводу убедись что все зеленое не понял. Excel используется только для подготовки данных, прогон на стороне Postman. Он же предоставляет результат прогона (пример на предпоследнем скриншоте)
3. Валидация идет при прогоне на стороне Postman. VBA перегоняет данные из Excel в Json, который потребляет Postman.
Дополнительно: Все это делалось, чтобы тестировщики, которые не умеют писать код могли заниматься тестированием API, используя шаблонный excel и шаблонную коллекцию Postman
lair
Вот это и ужасно.
TheGodfather
(дисклеймер: я тестировщик)
Когда такое читаю, то понимаю, как же мне повезло, ибо я работаю в компании, где такой вариант в принципе даже не рассматривают. Естественно, тестировщик должен уметь писать код. Естественно, даже black-box тестировщик должен иметь представление о «закулисной» части софта. Тестировщик может принимать участие в код-ревью (но не обязан).
Да, может код будет не продакшн-качества как у девелоперов, но «писать код» тестировщик должен уметь. Иначе вы нанимаете макаку для тыканья кнопок без каких-либо перспектив. Это не «тестировщик», это тест-макака, будьте честными. Это именно то, почему в головах многих стереотип «тестирование — это скучно», «тестирование — это бесперспективно», «тестировщик — значит мало платят», «тестирование — мало программирования». И своими действиями вы этот миф только усиливаете.
На самом же деле, задача тестировщика — обеспечить достаточное качество продукта, а метод достижения этой цели может быть любым. Если тест-инженер решает, что определенную часть не стоит автоматизировать и он руками эти тесты прогонит — ок. Если решает, что ему надоело и стоит написать скрипт\тестовую систему — велком. Но нанимать макаку, чтобы нажать кнопки, которые легко автоматизируются и говорить «макака не умеет писать код» — не удивлюсь, если у вас текучка макак огромна и раз в полгода меняются люди.
Раз вы руководитель отдела, то, наверное, к найму макак имели какое-то отношение. Так почему вы решили нанять, условно, 3 макак, вместо того, чтобы нанять одного тест-инженера на зарплату в три раза больше, который эту работу за два вечера автоматизирует и пойдет дальше искать дыры в процессах и фиксить самостоятельно?
Mikhail_Ivakhnenko Автор
Рад за Вас и Вашу фирму.
Не согласен с Вашим тезисом, что тестировщик, который не умеет писать код = макака.
Тестировщик минимально должен обладать следующим:
1. Знать и уметь применять техники тест-дизайна.
2. Уметь работать с документацией, в том числе проверять их на непротиворечивость и полноту.
3. Уметь постороить отношения с разработчиками, аналитиками и другими участниками процесса.
Макака этого не может. И у нас нет Макак, у нас есть специалисты по тестированию.
Текучки у нас также практически нет, за 2 года моей работы от нас ушел 1 человек из 10 и с ним у нам до сих пор нормальные отношения.
Я решил задачу по тестированию API таким образом, и поделился результатами с сообществом. Если есть вопросы по инструменту, постараюсь ответить.
По работе отдела и тем более по моим сотрудникам, я обсуждение продолжать не буду.
vmm86
Всё-таки тестовые данные, особенно иерархически связанные между собой, гораздо удобнее хранить в таблицах реляционной БД (хотя бы SQLite, если хочется легковесной портабельности), а в системе контроля версий хранить текстовые дампы.
Я недавно для фана ухитрился имитировать в Excel реляционные связи по внешнему ключу с помощью формул — подставлять значения из одного листа книги в другой по соответствию значений «ключевого» столбца. Но для production это такое себе решение.-)