Удаленка для jenkins+selenide+selenoid+allure+docker спецов на 2-3 часа в день. 100% remote! Присоединиться к проекту

Как я начал генерировать функциональные тесты для фреймворка glace-js и сэкономил кучу времени на их разработке

nodejs
glacejs
testing
webdriver
Теги: #<Tag:0x00007fedc462e1e8> #<Tag:0x00007fedc462e0a8> #<Tag:0x00007fedc462df40> #<Tag:0x00007fedc462de00>

(Vjacheslav Lukashevich) #21

ещё на тему генерации тест кейсов - у Spotify есть тул для генерации сценариев при обходе дерева
Опять же годится для тех систем которые можно в виде такого дерева представить
http://graphwalker.github.io/introduction/


(vmaximv) #22

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


(Pavel Ozerov) #23

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


(Pavel Ozerov) #24

Под сомнением здесь ценность таких сценариев. Впрочем, если для вас это работает так, как надо и позволяет избежать множества багов, значит вы делаете все верно :wink:


(Евгений Бухгаммер) #25

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

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

Единственное, что реально можно рассмотреть в кач-ве proof of concept этого подхода - количество заведенных багов*priority и их процент от общего кол-ва багов * priority. Если бизнес не оценивает результаты этих багов - то решение не имеет практической ценности. А то, что нашлось железо, где оно что-то будет делать (греть комнату на +1-2 градуса ) - это конечно, тоже положительная работа … в физическом плане.


(Sergei Chipiga) #26

Постараюсь поправить, если вы делаете систему, которая проходит только ожидаемые кейсы, не отражающие всех возможностей, то с большой долей вероятности в ней будет куча неожиданного поведения, т.к. то что программист предполагает, и то как работает на самом деле - 2 большие разницы. Все равно что утверждать, что нет смысла проверять, что пароль не должен быть меньше 6 символов, и понадеяться на команду разработки.
Если система позволяет выполнить кейс, который с точки зрения человека будет бессмысленным (или избыточным), и если иметь два варианта: не проходить его или пройти задешево, не привлекая человекоресурсы, я предпочту второй.

А что значит, новые и уникальные в вашем понимании? Максимальный перебор даст все возможные варианты, в том числе и “новые” и “уникальные”, и другие субъективные формы. Нельзя из воздуха сделать новый кейс, если уже перебраны все доступные варианты.
Другое дело, что возможно вас интересует именно весовой граф, что есть какие-то приоритеты в последовательностях шагов (более предпочитаемые сценарии). Да технически это тоже возможно, преобразовав генератор перебора в генератор цепей Маркова.


(Sergei Chipiga) #27

А есть конкретный пример? Конечно, в реальности, есть наиболее предпочитаемые варианты. Но ведь есть и варианты, когда реально веса приблизительно равны, например в плаггабл-системах, когда важно увидеть, что в комплексе все плагины работают, и не ломают поведение в целом.


(Pavel Ozerov) #28

Вы, похоже, не до конца поняли, что я имел в виду. Я ни в коем случае не подразумеваю, что вы должны тестировать только ожидаемое поведение системы (хотя с точки зрения бизнеса, этого достаточно). Это было бы абсурдным утверждением. Что касается надежды на кого/что-либо - тем более; это совсем не в рамках нашей профессии, верно ведь? :slight_smile:

Если система позволяет выполнить кейс, который с точки зрения человека будет бессмысленным (или избыточным), и если иметь два варианта: не проходить его или пройти задешево, не привлекая человекоресурсы, я предпочту второй.

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

А что значит, новые и уникальные в вашем понимании?

В моем понимании - это такие сценарии, которые как раз и вызывают незапланированное поведение системы (как сами по себе, так и в рамках бизнес-логики)

Максимальный перебор даст все возможные варианты, в том числе и “новые” и “уникальные”, и другие субъективные формы.

Не совсем согласен. Тут все зависит от входных параметров и вашей изначальной фантазии. Но возможно, что мы с вами говорим об одном и том же, только по-разному, не уверен :slight_smile:

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

Честно, я мало что из этого понял. Как это выглядит на практике?

Ну, и самое главное - если для вас это работает, то и нет смысла спорить. Ваша работа в любом случае заслуживает уважения.


(Sergei Chipiga) #29

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


(Sergei Chipiga) #30

А как вы относитесь к фаззи-тестингу? По сути ситуация схожая, только здесь подаются не случайные данные, а реальные валидные кейсы, от которых ожидается прохождение. Насколько на ваш взгляд, бизнес будет оценивать фаззинг, когда продукт падает при каких-то нереальных входных данных?


(Sergei Chipiga) #31

Затем чтобы узнать, проходит он или нет. Он ведь валидный, и неважно, кажется он человеку субъективно бессмысленным или нет. Вы не можете утверждать, что на большом количестве пользователей такой вариант не случится.


(Sergei Chipiga) #32

Иными словами, на ваш взгляд, уникальными и новыми сценариями являются тесты, ориентированные на незапланированное поведение, то есть негативные кейсы.
К какой же категории вы относите позитивные кейсы?


(Pavel Ozerov) #33

Возможно. Но часто вы пишете код, который кажется вам бессмысленным? Думаю, что нет. В этом и смысл. Если бы система сама до этого додумалась и создала бы такой сценарий, то у меня бы не было вопросов. Но так как этим изначально занимается человек, я сомневаюсь, что такой кейс вообще попадет в систему. Просто потому, что он покажется вам бессмысленным и вы не станете его создавать :slight_smile:


(Pavel Ozerov) #34

К бизнес-логике, пожалуй.


(Sergei Chipiga) #35

Я тоже не могу показать на своем коде, поскольку не делал такое. Но вот простой и понятный пример на питоне https://tproger.ru/translations/markov-chains/ (лучше чем в википедии).


(Sergei Chipiga) #37

Ну отчего же, если есть время, почему бы и не обсудить. Если это работает, это еще не значит, что все ок :slight_smile:


(Pavel Ozerov) #38

Спасибо, я обязательно ознакомлюсь со статьей.


(Sergei Chipiga) #39

Ну это сейчас слишком уж много для машины :slight_smile: Кстати думаю, не открою секрет, что машинная математика совсем не символьная. Это тупо численные методы решения перебором во многих случаях, но зато быстрые. Но результат-то вычисления верный, пусть и бездушная машина сделала это бессознательно, только подчиняясь алгоритму.


(Евгений Бухгаммер) #40

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


(Sergei Chipiga) #41

А что значит “генерит кейсы в одном месте”? И почему именно линейным, почему не может подаваться на вход матрица m*n, или n-мерное пространство входных данных?

Вы имеете в виду, что дебаг фаззи-тестинга легко распознаваем? Если да, откуда такая информация?

Давайте определимся с тем, что считать критерием фаззинга.
Н-р для меня, это подача в тестируемую систему случайных данных и получение какого-то адекватного поведения, человеко-понятной ошибки н-р. При этом количество факторов, размерность имеют к фаззингу перпендикулярное отношение. А для вас?

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