Pull to refresh

Comments 37

>Руководитель отдела качества и тестирования
>Excel...Postman

Кхм…

Вот прямо навскидку:

1. Как версионирование поддерживать? Вместо человекочитабельных YAML (что есть тот же JSON) в гите теперь у вас эксель-файл непонятно где.
2. Как в CI интегрировать? Почему не Python+unittest+requests? Или вы посадили своего интерна нажимать на кнопки «Поставь программу, скачай эксель-файл, открой эсель-файл, нажми кнопку, убедись, что все зеленое»?
3. Как валидацию-то сделали? VBA вместо простой функции на Питоне?
Добрый день!

1. Версионирование можно поддерживать через svn или git, где будут храниться версии excel файла. Сравнение изменений они не поддерживают, но при введении валидации файла, как шага процесса, другим тестировщиком имеет право на жизнь.
2. Для интеграции с CI у Postman есть newman CLI. Я её пока не реализовывал, но читал, что такая возможность есть. По поводу убедись что все зеленое не понял. Excel используется только для подготовки данных, прогон на стороне Postman. Он же предоставляет результат прогона (пример на предпоследнем скриншоте)
3. Валидация идет при прогоне на стороне Postman. VBA перегоняет данные из Excel в Json, который потребляет Postman.

Дополнительно: Все это делалось, чтобы тестировщики, которые не умеют писать код могли заниматься тестированием API, используя шаблонный excel и шаблонную коллекцию Postman
Сравнение изменений они не поддерживают,

Вот это и ужасно.

тестировщики, которые не умеют писать код могли заниматься тестированием API


(дисклеймер: я тестировщик)

Когда такое читаю, то понимаю, как же мне повезло, ибо я работаю в компании, где такой вариант в принципе даже не рассматривают. Естественно, тестировщик должен уметь писать код. Естественно, даже black-box тестировщик должен иметь представление о «закулисной» части софта. Тестировщик может принимать участие в код-ревью (но не обязан).
Да, может код будет не продакшн-качества как у девелоперов, но «писать код» тестировщик должен уметь. Иначе вы нанимаете макаку для тыканья кнопок без каких-либо перспектив. Это не «тестировщик», это тест-макака, будьте честными. Это именно то, почему в головах многих стереотип «тестирование — это скучно», «тестирование — это бесперспективно», «тестировщик — значит мало платят», «тестирование — мало программирования». И своими действиями вы этот миф только усиливаете.

На самом же деле, задача тестировщика — обеспечить достаточное качество продукта, а метод достижения этой цели может быть любым. Если тест-инженер решает, что определенную часть не стоит автоматизировать и он руками эти тесты прогонит — ок. Если решает, что ему надоело и стоит написать скрипт\тестовую систему — велком. Но нанимать макаку, чтобы нажать кнопки, которые легко автоматизируются и говорить «макака не умеет писать код» — не удивлюсь, если у вас текучка макак огромна и раз в полгода меняются люди.

Раз вы руководитель отдела, то, наверное, к найму макак имели какое-то отношение. Так почему вы решили нанять, условно, 3 макак, вместо того, чтобы нанять одного тест-инженера на зарплату в три раза больше, который эту работу за два вечера автоматизирует и пойдет дальше искать дыры в процессах и фиксить самостоятельно?
Рад за Вас и Вашу фирму.

Не согласен с Вашим тезисом, что тестировщик, который не умеет писать код = макака.
Тестировщик минимально должен обладать следующим:
1. Знать и уметь применять техники тест-дизайна.
2. Уметь работать с документацией, в том числе проверять их на непротиворечивость и полноту.
3. Уметь постороить отношения с разработчиками, аналитиками и другими участниками процесса.

Макака этого не может. И у нас нет Макак, у нас есть специалисты по тестированию.
Текучки у нас также практически нет, за 2 года моей работы от нас ушел 1 человек из 10 и с ним у нам до сих пор нормальные отношения.

Я решил задачу по тестированию API таким образом, и поделился результатами с сообществом. Если есть вопросы по инструменту, постараюсь ответить.
По работе отдела и тем более по моим сотрудникам, я обсуждение продолжать не буду.
Ваша фирма из тех что перекладывает работу разработчиков на плечи тестировщиков, тут не чем гордиться…

А в чем, по вашему, состоит та работа, которую здесь должны бы сделать разработчики?

Протестировать свою поделку, очевидно же!
UFO just landed and posted this here
Результаты прогона не сохраняются в Excel?
Нет, прогон осуществляется средствами Postman. Excel хранит данные о том, что подать и что сверить (Сверяется на стороне Postman), а также последовательности вызовов API методов
Раз уж вам так нравится Excel, то было бы кажется логичным также и выгружать туда статистику по прогону тестов. Но это вам виднее, стоит оно того или нет.
В экселе обычные входные — выходные данные для тестов.
На что только люди идут, лишь бы не пользоваться тестовыми фреймворками.
А если понадобится сравнивать со значением из базы?
Также тут хранится последовательность выполнения запросов. С базой работать не умеет, в Excel надо хранить точные данные (или ссылки на postman переменные).

Значение из базы известно на момент написания теста или может быть не определено?

Подход не претендует на 100% покрытие потребностей и замену остальных инструментов. Нам он подходит и я им поделился.
А если понадобится сравнивать со значением из базы?

Что сравнивать? Я про то, чтобы выгружать статистику прошел тест или нет в excel
Отвечал на другой комментарий, а не Ваш.

Теперь по Вашему комментарию:
Визуализация не делалась и осталась стандартной, которую выдает Postman runner.
Позже, возможно, займусь работой с CI и визуализацией результатов.
Я промахнулся, вопрос был к автору статьи.

Надеюсь что не требуется ответ на то, зачем нужно смотреть что — то в базе при тестировании.
Неожиданный подход) Думается, что есть большой минус в плане невозможности ревью изменений тестов. Мы в Test Mace совершили целый ряд телодвижений именно для того, чтобы удобно было хранить и ревьювить в системе контроля версий. У вас основной мотив был именно в удобстве работы с данными в табличном формате или необходимость использования скриптов для валидации ответа тоже сыграла свою роль?
Изменения для ревью можно получать сравнивая Json сформированный по предыдущей и текущей версии Excel. Если их заливать вместе с тестами, то изменения будут видны и в системе контроля версий.
Основные мотивы были следующие:
1. При появлении нового API, для написания тестов не писать код. — не у всех есть компетенции
2. Отказаться от Json как источника данных. — Не удобно наполнять и валидировать (первоначальное формирование)
3. Excel удобно наполнять данными. Также есть ряд средств для работы с тестовым набором (функции; условное форматирование, которое подсветит изменения от кейса к кейсу и т.д.)

— Мне в табличном формате действительно удобно работать с данными
— Не понял вопрос про скрипты валидации ответа.
В некоторых инструментах, например, SoapUI, реализована концепция источников данных. С их помощью вы можете загружать данные из различных источников и подставлять их в запросы. Очень похоже на то, что реализовали вы в своем решении. Мы в своем инструменте тоже планируем добавить такой механизм. Можем ли мы написать вам и проконсультироваться подробнее по поводу ваших потребностей, когда будем приступать к этой задаче?
Подскажите куда можно устроиться руководителем отдела тестирования с такими навыками?
Postman знаю, Excel тоже…
Мне честно говоря кажется, что уж пусть лучше тестировщики научатся работать с Постманом и json, чем использовать какую-то надстройку из Excel.
Если нужна нормальная визуализация результатов — в том же Newman есть нормальные репортеры для Постмана, да даже для дженкинса плагины можно найти, где-то на хабре был недавно пост…
В общем Postman инструмент полезный, но данная реализация со временем быстро станет неактуальной.
Масштабировать сложно, поддерживать тоже сложно — например появится у вас десяток другой новых параметров в запросе, или логика интеграции какая нибудь сложная — что вы будете с Excel файлом делать — каждый раз вручную менять?
Куда устроиться не могу подсказать, посмотрите на hh, я нашел. При этом опыта работы с Postman у меня на тот момент времени не было, освоил недавно.

В решении не затрагивается часть с визуализацией результатов, здесь есть визуализация подаваемых значений и ожиданий, а также последовательности вызовов. Визуализация результатов стандартная через Postman runner

На счет поддерживаемости и маштабирования нас на текущий момент устраивает, дальше посмотрим, может и изменим подход.

По поводу изменений в Excel при смене параметров или логики. В этом случае все равно придется вносить изменения, в любом инструменте, само оно не подстроится.
Михаил, спасибо за ответы и за статью.
В любом случае в последнее время редко выкладывают что то действительно полезное по тестированию. А этот подход хоть и спорный, но интересный и его можно развивать.
Согласен, у такого подхода есть плюсы. Когда jsonа много и запросы сами по себе большие, то наборы тестов быстро превращаюся в какие-то портянки. Однозначно нужно что-то для более удобного представления. Excel всем знаком, все сделано просто и понятно, почему бы и нет?
Вообще, про реальный, может быть и спорный опыт, всегда читать интересно. Это не пересказ документации и не маркетинговая вода без реальных примеров.
Excel всем знаком, все сделано просто и понятно, почему бы и нет?

Потому что версионировать неудобно. С равным успехом можно было бы хранить все в CSV, который и можно версионировать, и можно открыть в Excel.

можно открыть в Excel

Ключевое слово — можно. Он, конечно, откроется. Только в екселе есть форматирование и прочие штуки. Однозначного соответствия не добиться.
Подход, конечно, имеет и минусы. Проблема в том, что CSV для версионирования тоже далеко не фонтан. Хранить его в системе контроля версий можно, как и екселевский файл или json. Но сравнивать изменения на достаточно больших файлах неудобно.
Идея генерировать json тоже весьма и весьма здравая.
Предлагаемый подход не панацея, но как один из вариантов вполне годится.
Только в екселе есть форматирование и прочие штуки.

А зачем эти "прочие штуки" нужны в конкретной задаче?


Но сравнивать изменения на достаточно больших файлах неудобно.

Ну так и большие файлы в данной задаче тоже не очень нужны, набор сценариев в фиче ограничен, между фичами файлы должны быть разными, а нагрузочное тестирование все равно надо делать иначе.

А зачем эти «прочие штуки» нужны в конкретной задаче?

Первое, ексель дает форматирование «из коробки», этого уже хватит.
Второе, там используется макрос, для генерации json.
Третье, прямо вот в конкретной задаче, может и не нужны. А вообще можно добавить комментарии к полям, также в екселе есть встроенная сортировка/фильтрация, графики.
Опять же, если говорить о конкретной задаче, то нужно ли там удобно версионировать?
Ну так и большие файлы в данной задаче тоже не очень нужны

Тут может и не особо нужны, а вообще надо смотреть по обстоятельствам. Я имел опыт хранения таких вот тестовых json, мне не особо понравилось.
Первое, ексель дает форматирование «из коробки», этого уже хватит.

Так я еще раз спрошу: а зачем оно нужно, это форматирование?


Второе, там используется макрос, для генерации json.

Который можно написать на любом скриптовом языке.


А вообще можно добавить комментарии к полям, также в екселе есть встроенная сортировка/фильтрация, графики.

А зачем? Если речь идет о результатах, то этого всего в решении в посте нет. А если о входных данных, то я не понимаю, зачем.


Опять же, если говорить о конкретной задаче, то нужно ли там удобно версионировать?

В разработке ПО почти всегда нужно удобно версионировать. В моей практике, собственно, исключений нет (но это не означает, что их вообще не бывает).


Тут может и не особо нужны, а вообще надо смотреть по обстоятельствам.

А когда те обстоятельства случатся, тогда и будем думать, как решать.


Я имел опыт хранения таких вот тестовых json, мне не особо понравилось.

Я, вроде, не предлагал хранить тестовые JSON.

Михаил, прежде всего хочу поблагодарить за полезную статью! Сейчас по работе сталкнулся с необходимостью тестирования апи и кроме excel не было инструментов под рукой. Поделившись информацией про Postman и json вы буквально открыли мне глаза! Подскажите где можно скачать json и как его установить?


Михаил я впечатлен вашим професиональным уровнем, нсли не секрет подскажите где вы работаете начальником отдела тестирования?

Добрый день, спасибо.

Работаю в Москве, название фирмы раскрывать не буду.
Json с данными и последовательностью выполнения запросов генерируется на основе Excel — скачать его и коллекцию Postman можно на GitHub, ссылка в конце статьи.

Что нужно сделать для запуска:
1. Импортировать коллецию в Postman
2. Наполнить Excel данными и запустить генерацию Json
3. Запустить Postman Runner и импортировать файл сгенерированный на шаге 2.
4. Запустить прогон

Если требуется дополнительная консультация, пишите с описанием того, что не получилось.

Михаил, спасибо за исчерпывающий ответ! Но то что вы боитесь назвать компанию в которой работаете заставляет задуматься.

Может быть работа на аутсорсе с соответствующим NDA.
А попытка засунуть всё в эксель напомнила любимое японское развлечение делать всё на MSOffice :-)
Жалко, что визуализацию результата в эксель не получилось сделать — может, нашим бы удалось наконец автотесты навязать, вместо усаживания кого-то из разрабов протыкивать 1500+ пунктов в списке в экселе через самопальную штуку из кучи скриптов и curl.

> Да и проводить валидацию данных в JSON не удобно.

Решительно не согласен. Валидация данных в любом JSON прекрасно проводится посредством схем.

Подход интересный, но, на мой взгляд, тесты API (как у вас в примере) могут и должны быть максимально автоматизированы и не запускаться вручную. Ваш же Excel-файл не впишется в CI :-)
Любая утилита, помогающая тестировщику, это, конечно, хорошо. Но с конкретно этим решением, мне кажется, вы выбрали тупиковую ветвь развития. Тут очень много ограничений, в которые вы упретесь со временем. И, либо бросите развивать дальше, либо придется начинать все с начала.

Если следовать вашей мотивации, то решение, вроде как, и подходит. Но мне кажется, вы немного неправильно поставили изначальный вопрос. Он бы «неудобно работать с тестовыми данными в json, как сделать удобно?». Ок, excel удобный, поехали. А если бы вы задали вопрос типа: «мне неудобно работать с данными, как сделать так, чтобы с ними вообще не работать?». Тогда бы вы пришли к построению классической системы автотестирования, которая сама подготавливает для себя тестовые данные.

В целом, у вас получилась неплохая приблуда в помощь при ручном тестировании. Но это не автотесты (хотя вы, вроде, и не претендовали). За статью, таки, минус. В карму плюс. Удачи!
Автору спасибо.
Пускай это не лучшее решение Вашей задачи, но многие как и я могут использовать эту информацию по своему усмотрению.
Не обращайте внимание на ехидства, тех кто родился якобы сразу с клавиатурой.
Sign up to leave a comment.

Articles