Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Графический интерфейс для запуска автоматических тестов

gui
framework
execution
Теги: #<Tag:0x00007f7b68f206f8> #<Tag:0x00007f7b68f20590> #<Tag:0x00007f7b68f20450>

(Evpaty Kolovrat) #1

Всем привет!

Столкнулся с тем, что за последнее время несколько клиентов просили примерно такое: “I would like the test scripts so I can have another tester with non programming skills to run it”. Типа сделайте как можно проще.

В итоге наваял простенький интерфейс, используя Qt.PySide:

Фактически это выбиралка и запускалка тестов. Дальше все происходит в консоли и логах, но можно и сюда добавить.

Как думаете, надо ли дальше изобретать велосипед или может уже есть готовые изящные решения?


(5am) #2

как вариант, билд на запуск тестов в CI (Jenkins / TFS / etc)


(Artur Korobeynyk) #3

batch файлы?


(Sergey Korol) #4

С облаком все решается на уровне CI. Можно добавить спец. choice параметр - список suites для запуска, каждый из которых будет содержать различный набор тестов (регрешен, смоук и т.п.). Т.е. любой юзер сможет залогиниться, выбрать набор тестов и кликнуть кнопку запуска, все остальное сделает CI.

В случае с локальным экзекьюшеном все немного сложнее. Если уж взялись за GUI, то он должен быть универсальным. Вижу, что вы добавили 4 чекбокса с конкретными тестами. А что если завтра их будет 100? Будете обновлять каждый раз свой UI? Гораздо более эффективней будет соорудить парсер ваших тестовых классов, который выдернет список имеющихся методов и вставит в какой-нибудь list вашего GUI (аля динамическая подгрузка по заданному пути). Вы чекните нужные для запуска методы, тем самым объединив их в suite. Далее останется только сохранить его в формате вашего unit фреймворка и подсунуть в качестве аргумента для последующего экзекьюшена.

К слову, тут же вы можете допилить фичу удаленного тригера CI джобы из вашего десктопного апликейшена, отправив POST тому же дженкинсу с параметром suite’а для запуска.

В общем, с универсальным вариантом придется попотеть. Многое зависит от сложности имеющейся конфигурации вашего фреймворка / окружений и т.п.


(Evpaty Kolovrat) #5

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

С CI пока не довелось поработать практически. Но в общих чертах идея понятна, спасибо!


(vmaximv) #6

Кастомный UI для рана тестов - это явный оверхед.
Вариантов дальнейшего развития событий всего два:
1-ый. Как показывает практика - наиболее вероятный. Если пользователь не_в_состоянии/не_хочет запускать тесты из_консоли/ci, редактировать .properties файлы, анализировать резалты и т.д., то вероятность, что он будет пользоваться этим “раннером”, со временем будет стремится к нулю.
2-ой. Если таки пользователю действительно нужен такой “раннер” и тестируемая среда перестанет “вписываться” в 2-ва радиобаттона и 4-ре чекбокса - то новые “хотелки” пользователей будут расти по экспоненте - иерархии/группировки/кастомные сьюты/планировщик/приориты/ре-раны/сортировки/хистори/etc. Тут уже у вас будет два варианта: а) терпеть и “велосипедировать” свою собственную TMS; б) послать лесом и научить пользоваться блокнотом и консолью.


(Sergey Korol) #7

Соглашусь с @vmaximv. Я в свое время прошел через это, и сделал вывод, что проще и быстрее сделать все ручками (настроить xml / конфиги / CI), чем изобретать велосипеды с кастомным GUI, которым по факту никто не будет пользоваться.


(Michael Bodnarchuk) #8

А мне идея GUI очень даже нравится. Если этот GUI можно будет конфигурировать для различных тулов и он будет прсто отображать содержимое консоли - уже будет замечательно. Многим пользователям даже выполнить cmd уже сложная задача. Конечно, эти пользователи не профессиональные тестировщики, но графический интерфейс явно упростит понимание механизмов тестирования, а также предоставит клиентам возможность самим гонять тесты. Клиентам тоже важно видеть, что то что вы делаете, это не вещь в себе, а нечто, что они сами могут погонять, и потрогать руками.

Мне кажется, должен быть достаточно простой и универсальный конфиг (в json/yaml/xml) позволяющий указать:

  • команда консольного runner`а
  • возможные параметры раннера (в виде чекбоксов) и их описание
  • способ запуска одного теста
  • запуск доп. сервисов: того же selenium-server

(5am) #9

а еще можно прикрутить “агентов” аля самописные win (в случае с C# можно юзать WCF) сервисы, поставить их на пул виртуалок и передавать им команды на запуск тестов с “главного запускатора” :slight_smile:
в общем при желании/времени/необходимости можно много чего накрутить

но проще: CI / батники


(vmaximv) #10

А можете сделать эскиз этого GUI, т.к.у меня в голове за пару секунд успело пролететь с десяток параметров, которые могут влиять на конфигурацию запуска. И если клиент в состоянии понимать их предназначение, запустить тесты без UI для него не составит особой проблемы :wink:

Все существующие решения для “гуишного” рана тестов во всех популярных нынче TMS - есть смесь ежа с носорогом, передвигающегося исключительно на костылях, что как-бы намекает на “нетривиальность”.


(Сергей Блохин) #11

Мне не совсем понятная система: «tester with non programming skills».
Что это за тестировщики, которые не могут запустить в консоли скрипт теста?


(Sergey Korol) #12

Наверное они имели ввиду себя, т.е. менеджмент / стейкхолдерс и т.п. :slight_smile:


(Сергей Блохин) #13

Но это не есть задача менеджмента лазить в тесты, имхо. Но это уже оффтопик. Всем сорри.


(Sergey Korol) #14

Помню, встречал таких US менеджеров, которым были нужны всякие однокнопочные GUI солюшены, чтобы потом можно было презентовать все высшему менеджменту самостоятельно. Типа “вы все - рабы, и не достойны показывать это кому-либо, я сама покажу”. :smiley: Такие проекты быстро загибались, ибо автомейшен переставал выполнять свои прямые функции, а все сводилось лишь к феерическим абсурдным реквестам кастомеров.


(Дмитрий Жарий) #15

Это смотря что тестами называть. Я делал утилиту, которая по клику запускает смоук тест приложения:
Открывает браузер на локальной машине, обходит каждую страницу приложения и делает ее скриншот.
В результате создает HTML лог работы со встроенными скриншотами.

Изначально все задумывалось как инструмент, который любой участник нашей команды мог скачать и запустить у себя на машине… Был такой этап на проекте.
Потом, необходимость отпала.

Сейчас же, тестами, которые запускается только на CI сервере интересуются только тестировщики.
HTML логи со скриншотами по прежнему генерируются и ими достаточно часто пользовались на протяжении полугода.


(Evpaty Kolovrat) #16

Поясню. Клиент заказал фреймворк для автотестов. Но у него проект в начальной стадии и нет необходимости (да и возможности) в постоянной штатной единице тестировщика. Но необходимость тестирования уже ясно обозначилась. Он готов отдать создание фреймворка на аутсорс, но само тестирование пока нет :slight_smile: Согласен, что это не лучший подход.

Внедрение CI - это уже глубокая фаза развития проекта. Не все до нее дозревают. Для многих абсолютно достаточно иметь аккаунт на каком-нибудь облачном сервисе типа Crossbrowsertesting или SauceLabs и запускать тесты там. Но с другой стороны хочется минимального удобства, которое можно достичь с gui.

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

P.S. Хотя тот же SauceLabs уже вроде интегрируется с Jenkins…


(sidelnikovmike) #17

А мне кажется нормально. Надо только сделать удобно и чтоб не требовалось переписывать при добавлении/апдейте тестов.
Я на текущем месте писал плагинчик для идеи для облегчения жизни автоматизаторов для запуска тестов в нашей системе запуска(у нас самописная). Удобно, все под рукой


#18

В качестве готового GUI можно посмотреть на http://www.fitnesse.org. Якобы юзеры with non programming skills смогут задавать тестовые данные, запускать тесты, видеть результат и все это в виде wiki страничек. Но я лично от этого инструмента не в восторге, впрочем как и от самой идеи чтобы юзеры with no skills запускали тесты а потом им было облом анализировать результаты.


(vmaximv) #19

Облом там будет задолго до резалтов: обновился FF, не сетнули protected mode/zoom level/popup blocker и еще пару тройку “важных” опций в IE, отключили js, не установили джаву, накатили “ломающий” апдейт от $мелкомягких$, в hosts появилась “ломающая” FirefoxDriver строка
127.0.0.1 some_url, не отключили firewall, залочили рабочую станцию/свернули браузер во время “рана” и еще over9000+ проблем.
И да… гайды можно не писать - их все равно не читают, а если и читают - все что в них написано вылетает из головы после закрытия документа.


(Michael Bodnarchuk) #20

А можете сделать эскиз этого GUI

GUI сам по себе будет таким же простым как на вашей картинке. Но есть файл конфигурации, который заполняется разработчиком. Пользователь может только включать-выключать чекбоксы, на основе тех опций, что включены в файле конфигурации. Например:

{ 
command: "codecept run",
options: {
    "html-report": {
         argument: "--html"
         description: "Создать HTML-отчет"
    }
}}

пользователь увидит чекбокс :ballot_box_with_check: Создать отчет. При его включении в команду запуска добавляется параметр --html. Как-то так