testomat.io управление авто тестамиещё на тему генерации тест кейсов - у Spotify есть тул для генерации сценариев при обходе дерева
Опять же годится для тех систем которые можно в виде такого дерева представить
http://graphwalker.github.io/introduction/
2 лайка
В реальном мире графы состояний цикличны и взвешены, вершины не обязательно являются действиями, а состояние системы зависит не только от искомой вершины, но и от полного пути по графу.
Какая разница, штампованная фраза или нет, сути-то это не меняет. Если бы вы, скажем, создали нейронную сеть, которая на основе заложенных вами сценариев, со временем смогла бы создавать новые и уникальные сценарии - это одно. Вы же, если я правильно все понял (возможно я заблуждаюсь), используете простой перебор (комбинаторику) шагов. Да, вы получаете много тестов, которые бегают и, может быть, даже не падают. Но в чем их смысл, если большинство из них - это безжизненные кейсы, которые никогда не будут использоваться реальными пользователями? Поправьте меня, если я не прав.
Под сомнением здесь ценность таких сценариев. Впрочем, если для вас это работает так, как надо и позволяет избежать множества багов, значит вы делаете все верно 
примерно таким же образом можно занять тысячу компьютеров генерацией бинарей, которые авось станут рабочим софтом через N итераций. В такого рода тестах я бы заигнорил весь набор после очередной необходимости дебага упавшего теста, никак не соотносящегося с реальным юзкейсом в жизни. Хотя почему “бы” - в текущей работе как раз и были такие тесты, не дававшие фидбека примерно никакого.
К чему я? любой пейрвайз и перебор будет полезным, если есть какая-то надстройка, которая позволит сократить когнитивную нагрузку на анализ и категоризацию проблемы. В остальном - это боль, ад и страдание от поддержки такого зоопарка автоматизированного хаоса.
Единственное, что реально можно рассмотреть в кач-ве proof of concept этого подхода - количество заведенных багов*priority и их процент от общего кол-ва багов * priority. Если бизнес не оценивает результаты этих багов - то решение не имеет практической ценности. А то, что нашлось железо, где оно что-то будет делать (греть комнату на +1-2 градуса ) - это конечно, тоже положительная работа … в физическом плане.
Постараюсь поправить, если вы делаете систему, которая проходит только ожидаемые кейсы, не отражающие всех возможностей, то с большой долей вероятности в ней будет куча неожиданного поведения, т.к. то что программист предполагает, и то как работает на самом деле - 2 большие разницы. Все равно что утверждать, что нет смысла проверять, что пароль не должен быть меньше 6 символов, и понадеяться на команду разработки.
Если система позволяет выполнить кейс, который с точки зрения человека будет бессмысленным (или избыточным), и если иметь два варианта: не проходить его или пройти задешево, не привлекая человекоресурсы, я предпочту второй.
А что значит, новые и уникальные в вашем понимании? Максимальный перебор даст все возможные варианты, в том числе и “новые” и “уникальные”, и другие субъективные формы. Нельзя из воздуха сделать новый кейс, если уже перебраны все доступные варианты.
Другое дело, что возможно вас интересует именно весовой граф, что есть какие-то приоритеты в последовательностях шагов (более предпочитаемые сценарии). Да технически это тоже возможно, преобразовав генератор перебора в генератор цепей Маркова.
А есть конкретный пример? Конечно, в реальности, есть наиболее предпочитаемые варианты. Но ведь есть и варианты, когда реально веса приблизительно равны, например в плаггабл-системах, когда важно увидеть, что в комплексе все плагины работают, и не ломают поведение в целом.
Вы, похоже, не до конца поняли, что я имел в виду. Я ни в коем случае не подразумеваю, что вы должны тестировать только ожидаемое поведение системы (хотя с точки зрения бизнеса, этого достаточно). Это было бы абсурдным утверждением. Что касается надежды на кого/что-либо - тем более; это совсем не в рамках нашей профессии, верно ведь? 
Если система позволяет выполнить кейс, который с точки зрения человека будет бессмысленным (или избыточным), и если иметь два варианта: не проходить его или пройти задешево, не привлекая человекоресурсы, я предпочту второй.
Проблема в том, что кейс, который выполняет ваша система, запрограммирован вами же. Зачем тогда изначально создавать бессмысленный кейс, даже если его будет выполнять система?
А что значит, новые и уникальные в вашем понимании?
В моем понимании - это такие сценарии, которые как раз и вызывают незапланированное поведение системы (как сами по себе, так и в рамках бизнес-логики)
Максимальный перебор даст все возможные варианты, в том числе и “новые” и “уникальные”, и другие субъективные формы.
Не совсем согласен. Тут все зависит от входных параметров и вашей изначальной фантазии. Но возможно, что мы с вами говорим об одном и том же, только по-разному, не уверен
Другое дело, что возможно вас интересует именно весовой граф, что есть какие-то приоритеты в последовательностях шагов (более предпочитаемые сценарии). Да технически это тоже возможно, преобразовав генератор перебора в генератор цепей Маркова.
Честно, я мало что из этого понял. Как это выглядит на практике?
Ну, и самое главное - если для вас это работает, то и нет смысла спорить. Ваша работа в любом случае заслуживает уважения.
Честно говоря, не вижу аналогии. Результатом генерации являются кейсы, чье поведение валидно для системы, а не а бы что.
А как вы относитесь к фаззи-тестингу? По сути ситуация схожая, только здесь подаются не случайные данные, а реальные валидные кейсы, от которых ожидается прохождение. Насколько на ваш взгляд, бизнес будет оценивать фаззинг, когда продукт падает при каких-то нереальных входных данных?
Затем чтобы узнать, проходит он или нет. Он ведь валидный, и неважно, кажется он человеку субъективно бессмысленным или нет. Вы не можете утверждать, что на большом количестве пользователей такой вариант не случится.
Иными словами, на ваш взгляд, уникальными и новыми сценариями являются тесты, ориентированные на незапланированное поведение, то есть негативные кейсы.
К какой же категории вы относите позитивные кейсы?
Возможно. Но часто вы пишете код, который кажется вам бессмысленным? Думаю, что нет. В этом и смысл. Если бы система сама до этого додумалась и создала бы такой сценарий, то у меня бы не было вопросов. Но так как этим изначально занимается человек, я сомневаюсь, что такой кейс вообще попадет в систему. Просто потому, что он покажется вам бессмысленным и вы не станете его создавать
К бизнес-логике, пожалуй.
Я тоже не могу показать на своем коде, поскольку не делал такое. Но вот простой и понятный пример на питоне Создаем генератор текста на основе цепей Маркова: теория и практика (лучше чем в википедии).
Ну отчего же, если есть время, почему бы и не обсудить. Если это работает, это еще не значит, что все ок
Спасибо, я обязательно ознакомлюсь со статьей.
Ну это сейчас слишком уж много для машины Кстати думаю, не открою секрет, что машинная математика совсем не символьная. Это тупо численные методы решения перебором во многих случаях, но зато быстрые. Но результат-то вычисления верный, пусть и бездушная машина сделала это бессознательно, только подчиняясь алгоритму.
фаззи тестирование - генерит кейсы в одном месте, рост получается линейным, а гипотеза, как и дебаг - легко распозноваемым. при факториальном росте с кучей факторов, которые даже никак не сгрупированны, это вообще никак не соотносится с фаззи-тестированием. Комбинаторный взрыв отчасти такой не потому, что сложно составить комбинации и их выполнить, а потому, что нужно результаты эти оценить. Кажется, я об этом уже писал выше.
А что значит “генерит кейсы в одном месте”? И почему именно линейным, почему не может подаваться на вход матрица m*n, или n-мерное пространство входных данных?
Вы имеете в виду, что дебаг фаззи-тестинга легко распознаваем? Если да, откуда такая информация?
Давайте определимся с тем, что считать критерием фаззинга.
Н-р для меня, это подача в тестируемую систему случайных данных и получение какого-то адекватного поведения, человеко-понятной ошибки н-р. При этом количество факторов, размерность имеют к фаззингу перпендикулярное отношение. А для вас?
Да факториал дает огроменное количество вариантов, но правила взаимодействия между шагами существенно ограничивают финальное количество. Плюс можно ограничить искусственно, сказав получить не больше n тестов. Хотя конечно это уже не будет “полным” покрытием.