Ну ок. Я могу запускать тесты в разных браузерах с разными capability, могу локально, могу через грид, могу в один поток, могу параллелить по методам/классам/тестам. Могу запустить пэкэдж/класс/группу, могу тесты которые входят в группу А и не входят в группу Б.
Могу менять параметры каждого теста. Могу менять значения пяти различных таймаутов. Могу ранать на N-разных энвайроментах, для каждого из которых нужно по пять различных урлов, логинов, некоторое количество уникальных тестовых данных. И да - у некоторых тестов/сьютов есть тоже общие тестовые данные которые я могу менять.
Так что чекбоксами тут не отделаешься - и никакой внятной модели UI, в которой будет работать проще, чем с парой текстовых файлов, у меня в голове не возникает.
В свое время думал создать подобный GUI, который бы позволял конфигурировать ряд задач, ОС, на которых будет тестироваться продукт. С написанием тестов пришел к выводу, что как и большинство отписавшихся тут: автотесты для непросвещенных не нужны. Все отчетовые красивости (thucydides, allure) для меня оказались тратой времени. И единственное что может помочь, так это GUI для формирования конфига для тестов (json файл), который уже потом скрармливается скриптам, крутящимся в CI. И то - гораздо лучше на мой взгляд ночами обходить тупо все тесты ( или тесты с рандомным или ротирующимся сетом генерируемой даты\тестов ). Если же что-то нужно делать быстро и очень точечно - то это вопрос коммандлайновых аргументов, которые отметут полный перечень тестов и отработают по сокращенному списку.
Решил проблему добавлением в джоб Jenkins’а параметров выбора и тестов и энвайрмента и других конфиг) Вроде пока testers with non-programmer skills не путаются)
Мы тоже думали над чем то похожим. Но не смогли придумать как в случае таких запусков (через самописный GUI или какие .bat) - хранить историю выполнения и возможность ее просматривать например в разрезе браузеров и или env
к примеру, в случае с mstest:
можно парсить файл с результатами.*.trx (по сути - это xml) и сохранять результат парсинга в базу (mongo / mysql / xml / etc)
По-моему, тут слишком все запарились по поводу однокнопочности запуска тестов. Зачем писать какой-то GUI, когда уже все есть Я 1 раз настроил TeamCity и сейчас он автоматически гоняет тесты после каждого коммита в ветку, при этом отсылая отчеты ответственному за коммит и мне(настраиваемо). Если же мне нужно принудительно запустить тесты, то я захожу в TC и нажимаю Run. После чего получаю удобные отчеты с графиками, которые можно предоставить менеджменту(они любят графички, ползущие вверх xD ) и довольных программистов. Ну и недавно я сделал билд-светофор на ардуине, который стоит в кабинете у разработчиков.
Менеджеры, просящие действие в один клик, часто идут лесом, а если менеджеру нужно что-то дополнительно сделать - он, как и все, пишет тикет , который выносится на обсуждение всего коллектива.
Не реклама, но TC мне понравился больше чем Jenkins и я не вижу смысла в GUI. На локальном компе мне не сложно прописать 5 слов для запуска теста, а CI работает и без моего вмешательства.
testomat.io управление авто тестами
Я 1 раз настроил TeamCity и сейчас он автоматически гоняет тесты после каждого коммита в ветку, при этом отсылая отчеты ответственному за коммит и мне(настраиваемо). Если же мне нужно принудительно запустить тесты, то я захожу в TC и нажимаю Run. После чего получаю удобные отчеты с графиками, которые можно предоставить менеджменту(они любят графички, ползущие вверх xD ) и довольных программистов. Ну и недавно я сделал билд-светофор на ардуине, который стоит в кабинете у разработчиков.