Почтальон: Более продвинутое тестирование на основе данных - как структурировать и запускать тесты?

У меня большой опыт написания наборов автоматических тестов для API в Postman. Я всегда использовал тестирование, управляемое данными, и поэтому меня всегда немного расстраивали ограничения Postmans в этой области. Когда я говорю «управляемый данными», я пытаюсь достичь двух целей. Сначала я хочу отделить тест от тестовых данных, но, что более важно, я хочу иметь возможность параметризовать свои тесты, чтобы я перебирал каждый с разными данными, которые представляют разные сценарии / случаи. У меня есть несколько конечных точек API, которые я ударял десятки раз, но с разными данными. Мне нужен совет, как лучше структурировать и провести тестирование. Ниже я изложу проблемы.

В Postman вы можете запустить коллекцию для выбранной среды и / или файла данных. Проблема здесь в том, что вы можете передать только один файл данных для полного сбора. Хотя технически вы можете иметь все необходимые данные в одном файле, он может стать раздутым, поэтому для краткости на самом деле лучше жестко закодировать данные в тесте в пользовательском интерфейсе Postman.

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

На сегодняшний день моим обходным решением было использование Newman для выполнения определенных тестов или групп тестов с определенным файлом данных. Это позволяет мне разделять мои тестовые данные для соответствия коллекциям, а также означает, что я могу запустить все свои тесты за один раз (запустив все команды за один раз). Проблема в том, что я все еще просто запускаю подколлекции, когда делаю это, и хотел бы получить единый отчет, как если бы все тесты были запущены из одной коллекции одновременно.

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

Я видел pm.iterationData и могу представить себе создание сценария предварительного запроса перед каждым тестом для загрузки данных итерации для теста, но это кажется немного взломанным. Не знаю, возможно ли это вообще.

Спасибо




Ответы (1)


Попробуйте vREST NG. Он без проблем поддерживает файлы CSV прямо из коробки. Это решит следующие проблемы:

  1. Каждый тестовый набор API может быть связан с собственным файлом CSV.
  2. Легче параметризовать параметры запроса, параметры формы, тело запроса и т. Д.
  3. Нет необходимости жестко кодировать какие-либо данные.
  4. Полная интеграция и никаких специальных взломов для поддержки DDT.
  5. Живая интеграция с файлом CSV. т.е. просто свяжите свой CSV-файл. Во время выполнения тест всегда выбирает последние данные файла CSV. Никакой загрузки файлов CSV снова и снова.
  6. В конце у вас будет единый отчет.
  7. Он позволяет записывать входные данные API и данные проверки ответа API (код состояния, ожидаемое тело ответа, ожидаемое имя схемы), а также в файл CSV.
  8. И наконец, никаких специальных технических навыков не требуется.

Я также написал статью в LinkedIn, в которой будут приведены пошаговые инструкции о том, как проводить тестирование на основе данных. https://www.linkedin.com/pulse/swagger-excel-sheets-wonderful-way-validating-rest-apis-aggarwal/.

person Dheeraj Kumar Aggarwal    schedule 21.05.2020