Кстати, возражу вам, поскольку на мой взгляд - это все-таки не совсем тоже самое, что негативные кейсы.
А что для вас негативные кейсы, если не проверка адекватного поведения при неадекватных действиях?
Негативный тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций (срабатывание валидаторов), а также проверяет, что вызываемая приложением функция не выполняется при срабатывании валидатора.
Взято отсюда:
http://www.protesting.ru/testing/testcase.html
Для меня это скорее проверка того, что тест завалится, где надо. А вот
проверка адекватного поведения при неадекватных действиях
Это в какой-то мере exploratory testing. Впрочем, это не суть важно. Просто я решил внести ясность.
Ну не знай, мне кажется это размытой границей, н-р что считать неадекватным поведением, то что не прописано или же наоборот прописано как запрещенное в документации? Н-р по документации длина пароля должна быть больше 5 символов. Соответственно тест на реджект пароля в 4 символа, это негативное или исследовательское тестирование?
Вероятно, вы правы. Я не силен в математике, чтобы спорить. Но в одном я уверен - пока алгоритмы создает человек, а не сама система (с учетом всех имеющихся в ее распоряжении данных и ресурсов) - по итогу совершенно не важно, кто будет выполнять эту работу. Ошибки неизбежны в любом случае. Безусловно человеческий ресурс гораздо более жалко, поскольку специалисты стоят недешево, но в том и суть специалиста, что он может отличить кейс бессмысленный от того, который имеет ценность. Но любое действие человека можно подвергнуть сомнению, что подвергает сомнению и всю систему в целом, поскольку она не существует сама по себе. Мне так кажется.
UPD: на всякий случай: речь ни в коем случае не идет о ручном тестировании. Под “работой” я имею в виду создание алгоритмов, тестов и тестовых систем.
Вы же не тестируете отдельно реджект на 1-2-3-4 символа. Все что меньше 5 - уже неверно. Так что это просто обязательное тестирование бизнес-логики.
Генерация тестов это совсем другая техника чем обычная автоматизация приемочных или регресионных тестов и обычно применятся для совсем других целей.
О регулярном запуске в CI речи вообще может не идти (хотя мощности запуска постоянно растут и тестовые шаги могут быть с чем то быстрее броузера)
У меня были задачи обьемно протестировать интеграцию с чужой системой о которой я ничего не знал чтобы сделать стандартный тестовый дизайн.
Вот берёшь весь перебор данных и вперед - сгенерировал большой перебор комбинаций, запустил, получил большой набор данных, смотришь его в разрезе трендов или каких то выпадающих исключений.
Смотришь - ага, вот все тесты которые использовали шаг Б после шага А упали, а все которые использовали шаг В после А прошли - делаешь выводы, локализуешь проблему.
В целом отличный инструмент в копилку автоматизатора.
При правильном подходе должен поддерживать только модель генерации и входные данные (при условии если генератор уже есть). Сами тесты генерируются перед запуском и всегда актуальны
Это как ковровое бомбометание - тупое, но порой эфективное.
Если вы про вес ребра - то это не самая большая проблема из озвученных мною.
Однако и тут будут некоторые сложности: вес - это не число - это метрика в своем метрическом пространстве. А общем случае искомая метрика будет состоять из композиции метрик из разных пространств.
Например у QA - это приоритеты тест-кейсов, у бизнеса - value для искомого пути по графу, у девов - расстояние от искомого пути до текущего спринта.
Понятно, вы находитесь в стадии когда все нужно автоматизировать … это хорошо но почитать
https://bytextest.ru/2017/12/22/speaking-about-testing/
Не мешает
А что в этом плохого? Прикольно же когда за тебя все делает автоматика
Оно то прикольно но когда на ручное проходждение требуеться час а на разработку, сопровождение, анализ результатов автоматизации 2 дня - опытный менеджер даст по рукам )
Так не нужно писать непонятные тесты, логирование, стэк-трэйс в помощь. И почему именно 2 дня? Личный опыт?
Хм… а мне нравится! Очень крутая затея!
Это типа бдд только круче
Для интеграционных тестов будет очень полезно и плюс при описании и связвании шагов может выявиться куча проблем в документации или логике системы
- А почему жс? А не пайтон например или дот нет, или жвмное что-то?
В жс мире более скептически относятся к новой либе чем в жвм, дотнет или питон - А есть какие-то ещё аналоги?
- В одном из комментов ты описал:
Один процесс/машина занимается генерацией большого количества кейсов. Затем сгенерированный файл передается в балансер, который нарезает из одно файла, несколько сьютов поменьше и раcкидывает их по агентам, где запускается фреймворк, который умеет не только сам генерировать тесты, но и запускать предгенерированные сьюты.
Вопросы:
- Сколько времни может занимать генерация 8! сценариев?
- Балансер может запускать в n потоков все сценарии?
Спасибо
Сейчас это мой рабочий язык. Хотя когда это задумывалось, еще работал на python. Но сейчас портировать это python нет желания, хотя конечно там больше возможностей развернуться в плане машинного обучения.
Аналоги я тоже знаю только те, которые здесь приводятся в комментах выше от spotify и apache.
Если мы говорим о том, чтобы получить 40320, то конечно сильно будут влиять значения параметров --gen-tests-limit, --gen-steps-limit, --gen-steps-uniq, а также условия взаимодействия шагов. Н-р в своих экспериментах я получал и 20 тыс. тестов за 1 мин, и 4 тыс. за 10 мин. Думаю можно получить 40 тыс. за 3-5 мин.
Если вы имеете параллельно запустить тесты на одном агенте, то сейчас это не поддерживается тестовым нашим фреймворком. Возможно в дальнейшем будет механизм параллельного запуска тестов, но сейчас нет таких задач в работе.
А если параллельный запуск агентов. Да, конечно, это может быть и баш-скрипт, который запускает n процессов на одной машине, либо можно сделать связку из jenkins job’ов. В одной джобе можно сгенерировать тесты и нарезать на файлы, после чего стриггерить матричную джобу, которая динамически создаст n джоб внутри себя, используя DynamicAxes Plugin.