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

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

А что для вас негативные кейсы, если не проверка адекватного поведения при неадекватных действиях?

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

Взято отсюда:

http://www.protesting.ru/testing/testcase.html

Для меня это скорее проверка того, что тест завалится, где надо. А вот

проверка адекватного поведения при неадекватных действиях

Это в какой-то мере exploratory testing. Впрочем, это не суть важно. Просто я решил внести ясность.

1 лайк

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

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

UPD: на всякий случай: речь ни в коем случае не идет о ручном тестировании. Под “работой” я имею в виду создание алгоритмов, тестов и тестовых систем.

Вы же не тестируете отдельно реджект на 1-2-3-4 символа. Все что меньше 5 - уже неверно. Так что это просто обязательное тестирование бизнес-логики.

Генерация тестов это совсем другая техника чем обычная автоматизация приемочных или регресионных тестов и обычно применятся для совсем других целей.
О регулярном запуске в CI речи вообще может не идти (хотя мощности запуска постоянно растут и тестовые шаги могут быть с чем то быстрее броузера)

У меня были задачи обьемно протестировать интеграцию с чужой системой о которой я ничего не знал чтобы сделать стандартный тестовый дизайн.
Вот берёшь весь перебор данных и вперед - сгенерировал большой перебор комбинаций, запустил, получил большой набор данных, смотришь его в разрезе трендов или каких то выпадающих исключений.
Смотришь - ага, вот все тесты которые использовали шаг Б после шага А упали, а все которые использовали шаг В после А прошли - делаешь выводы, локализуешь проблему.

В целом отличный инструмент в копилку автоматизатора.
При правильном подходе должен поддерживать только модель генерации и входные данные (при условии если генератор уже есть). Сами тесты генерируются перед запуском и всегда актуальны

Это как ковровое бомбометание - тупое, но порой эфективное.

1 лайк

Если вы про вес ребра - то это не самая большая проблема из озвученных мною.
Однако и тут будут некоторые сложности: вес - это не число - это метрика в своем метрическом пространстве. А общем случае искомая метрика будет состоять из композиции метрик из разных пространств.
Например у QA - это приоритеты тест-кейсов, у бизнеса - value для искомого пути по графу, у девов - расстояние от искомого пути до текущего спринта.

Понятно, вы находитесь в стадии когда все нужно автоматизировать … это хорошо но почитать

https://bytextest.ru/2017/12/22/speaking-about-testing/
Не мешает

А что в этом плохого? Прикольно же когда за тебя все делает автоматика

1 лайк

Оно то прикольно но когда на ручное проходждение требуеться час а на разработку, сопровождение, анализ результатов автоматизации 2 дня - опытный менеджер даст по рукам )

Так не нужно писать непонятные тесты, логирование, стэк-трэйс в помощь. И почему именно 2 дня? Личный опыт?

Хм… а мне нравится! Очень крутая затея!
Это типа бдд только круче
Для интеграционных тестов будет очень полезно и плюс при описании и связвании шагов может выявиться куча проблем в документации или логике системы

  1. А почему жс? А не пайтон например или дот нет, или жвмное что-то?
    В жс мире более скептически относятся к новой либе чем в жвм, дотнет или питон
  2. А есть какие-то ещё аналоги?
  3. В одном из комментов ты описал:

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

Вопросы:

  • Сколько времни может занимать генерация 8! сценариев?
  • Балансер может запускать в n потоков все сценарии?

Спасибо :slight_smile:

Сейчас это мой рабочий язык. Хотя когда это задумывалось, еще работал на 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.

1 лайк