Комментарии 15
Наверное с selenium тоже можно кнопать хаотично, надо обдумать.
Выход от таких тестов к сожалению очень не большой. Но подход крайне интересный.
Немного эффективнее будет если всё же перебирать все варианты пусть и хаотично — тогда есть возможность пройти по нескольким формам какой-то осмысленный путь.
Гораздо эффективнее будет написать несколько простых тестов и гонять их в случайном порядке (так можно целенаправленно найти утечки памяти, да и проверить общую стабильность программы при нормальном использовании, но это уже совсем другая история).
Не затронутыми как я понял остаются поля для ввода, без чего многие формы вас дальше просто не пустят.
Немного эффективнее будет если всё же перебирать все варианты пусть и хаотично — тогда есть возможность пройти по нескольким формам какой-то осмысленный путь.
Гораздо эффективнее будет написать несколько простых тестов и гонять их в случайном порядке (так можно целенаправленно найти утечки памяти, да и проверить общую стабильность программы при нормальном использовании, но это уже совсем другая история).
Не затронутыми как я понял остаются поля для ввода, без чего многие формы вас дальше просто не пустят.
> Выход от таких тестов к сожалению очень не большой. Но подход крайне интересный.
Пардон за коменты — я еще не совсем освоился. Исходя из личного опыта только два серьезных кейса было найдено таким способом. Но оно того стоило… А для поиска ликов — самое оно.
На счет предложения. Это поломает концепцию случайного кликанья. Я вот подумываю о том, что бы добавить некоторые цепочки для зависимых элементов. Например, после ввода а edit нажать энтер. Но что бы оставалась случайность, следует наделить второе действие весом (вероятнее всего будет нажат энтер, но может и просто окно закрыть). Но это нужно хорошенько обдумать.
На счет предложения. Это поломает концепцию случайного кликанья. Я вот подумываю о том, что бы добавить некоторые цепочки для зависимых элементов. Например, после ввода а edit нажать энтер. Но что бы оставалась случайность, следует наделить второе действие весом (вероятнее всего будет нажат энтер, но может и просто окно закрыть). Но это нужно хорошенько обдумать.
2 серьёзных кейса это лики? или что-то функциональное?
Нет, краши. Один связан с динамически появляющимися элементами. Если просто, то при попытке открыть опции элемента, которого уже нет на окне.
Второй — это краш сервиса, который стартовал/останавливал тяжелую операцию по команде из GUI. Тут просто повезло.
Вспомнил. Еще были зависания UI — что то с синхронизацией сервис-ui.
А лики систематически приходили с добавлением новой функциональности.
Второй — это краш сервиса, который стартовал/останавливал тяжелую операцию по команде из GUI. Тут просто повезло.
Вспомнил. Еще были зависания UI — что то с синхронизацией сервис-ui.
А лики систематически приходили с добавлением новой функциональности.
ну тот который «один» как я понял не несёт пользы поскольку человек не сможет нажать на опцию которой уже нет на форме. т.е. опять таки пользы от этого нету.
Э, нет. Там был список опций с фильтром. Когда опцию выделяешь, появляется кнопка или чекбокс в зависимости от типа опции. Так вот, если выделить опцию, затем применить фильтр(что бы выбранная опция исчезла), то относящиеся к опции кнопка/чекбокс остаются на UI. Если попытаться нажать/изменить — краш.
Так этож можно автоматизировать кучу действий в винде! Да еще все это на питоне, красота!
Карма или рейтинг позволили — переместил в Тестирование.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Динамическое (нелинейное) тестирование GUI