Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Генерация тестовых данных (python)

(Павел Ветохин) #1

Задача

Каждый автоматизатор сталкивается с задачей генерации тестовых данных. Кто-то генерит их в полуручном режиме (раз, два, три). Кто-то использует различные библиотеки (раз, два, три, четыре). А кто-то вообще не парится и хардкодит данные прямо в тестах. Я же хочу поделиться своим “велосипедом”.

Решение

Cases библиотека для генерации тестовых данных. Понятное дело, что мне не хватало именно такой библиотечки :smile: . Она предоставляет всего 4 основных метода:

  1. cases.get_each_choice
  2. cases.get_negative
  3. cases.get_pairwise
  4. cases.get_one

Здесь можно посмотреть примеры. Все методы, кроме последнего, возвращают генератор, который, в свою очередь, будет возвращать набор объектов. Каждый из объектов представляет 1 тестовый случай. Для генерации тестовых случаев используется дефолтный класс. При желании можно использовать свой класс, передав его первым аргументом в любой из методов.

На текущий момент реализация “устаканилась”. Пришла пора поделиться с сообществом и получить обратную связь.

(vlogvinov) #2

А на java есть ли подобные генераторы тестовых данных?

(Павел Ветохин) #3

Не знаю, есть ли что-то точь-в-точь такое же. Но, например, есть java-faker.

(Artur Korobeynyk) #4

Вобще с этой задачей отлично справляются фазеры. Я конечно тоже предпочитаю использовать свои решения, но иногда описывать все варианты мутаций входных данных очень накладно по времени, так что можно обращаться к Burp Suite, xmlfuzzer, powerfuzzer… Кто не брезгует целостностью мозга может пробовать микрософтовский FuzzGuru

(Павел Ветохин) #5

Все-таки основная задача фазеров - это поиск уязвимостей. Поэтому использовать их для обычного тестирования в agile-проекте да еще и на этапе создания первой версии не совсем правильно, на мой взгляд.

(Artur Korobeynyk) #6

Не понимаю, почему так много людей на этом форуме имеют понятие “обычное тестирование” и “необычное тестирование”, в одном из которых обращают внимание на ошибки уязвимости, а во втором нет. Я придерживаюсь мнения что тест изначально должен быть наиболее полным, а разработчики должны менять код, пока этот тест не будет успешно выполнен.

(Александр Таранков) #7

Что тут непонятного. Или ты не встречал ситуаций, когда релизить надо срочно? В такой ситуации приходится выпускать не отполированный до блеска функционал, а то, что есть, но максимально возможного качества, которого можно добиться в таких условиях.

Здесь и пригождается умение отделять зерна от плевел, а мух от котлет и тестировать в условиях жесткой приоритезации проверок. Тут уже не до фазеров и уязвимостей - успеть бы проверить успешные сценарии и минимальную защиту от дурака

(Artur Korobeynyk) #8

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

(Павел Ветохин) #9

Я, как тестировщик, хочу тестировать все и сразу. Но реальность вносит свои коррективы. Бывают следующие проекты:

  1. agile-проекты, в которых требования по безопасности сознательно реализуются позже требований по основной функциональности
  2. корпоративные проекты, в которых требования по безопасности минимальны или вообще отсутствуют
  3. проекты по созданию прототипов, в которых тестировать все и вся просто глупо
  4. горящие проекты уже упоминались