АвтоКликер следующего поколения!

 

Коллеги, оцените классную на мой взгляд идею "АвтоКликера следующего поколения":
1. Основное отличие от существующих - СОСТАВЛЕНИЕ КАРТЫ КОНТРОЛОВ автоматизируемых приложений c привязкой к конкретной версии приложения и затем Воспроизведение действий (кликов/нажатий клавиш/изменение состояния контролов) по ссылкам на пути в этой карте контролов. Опишу подробнее, что это значит и какие бонусы сулит. 
По сравнению с другими автокликерами внешне это нисколько не усложняет запись/воспроизведение. Т.е. пользователь вообще может не задумываться, что такое "карта контролов" и с чем ее едят. А вот новый уровень стабильности/целостный взгляд на происходящее/гибкость будут хорошим дополнением.
 
Теперь от общих слов к детальному описанию.
У нас есть какое-то приложение, которое надо протестировать или автоматизировать. При записи/воспроизведении скрипта, т.е. набора кликов, перехода между различными окнами приложения, будет происходить НЕвидимое для пользователя сканирование каждого окна и состовляться его карта контролов. В итоге у нас получится что-то такое:
 
Total Commander
        - версия 7.05 (crc сумма приложения - 72649е16)
                  - Главное окно:
                             - 2 панели, 8 кнопок, 1 меню, 1 тулбар, 1 статик, 1 поле редактирования, 2 комбо (к каждому контролу сохраняются также его свойства, которые не менялись во время наблюдения за программой + их скриншоты, возможность обозвать привычными именами)
                  - Окно опций, 1-ая закладка
                              - 1 древовидный список, 10 чекбоксов, 3 комбобокса
                  - Окно опций, 2-ая закладка
                              - 1 древовидный список, 6 чекбоксов, 2 комбобокса
                  - и т.д.
                  - Карта путей как попасть из одного окна в любое другое. Допустим, для незарегистрированной версии Total Commander нельзя сразу при запуске в одной действие перейти в окно настроек, надо сначала правильно закрыть окно, предлагающее регистрацию, затем уже переходить в диалог настроек. В других программах пути могут быть длиннее и сложнее. Карта путей между окнами будет представлять собой уменьшенные скриншоты и стрелки между ними. Таким образом, к каждой версии программы будут создаваться карты контролов и карты путей между окнами. Пользователь все это может и не замечать, но у него теперь будет возможность в начале каждого скрипта задать желаемое окно в качестве начального условия и если потом в начале Воспроизведения скрипта запущенное приложение будет в другом состоянии, на другом окне, то Автокликер сможет сам выйти на нужное окно, что обеспечит скрипт большей стабильностью, а от пользователя лишь понадобится согласиться на предлагаемые начальные условия и подтвердить право автокликера самостоятельно находить оптимальный путь между окнами.
- В карте путей какие-то частые маршруты можно будет называть привычными именами, например, "залогинивание"/"вызов настроек" и использовать эти имена в скриптах, не делая заново запись нужного действия или выискивая в предыдущих скриптах в мешанине контролов нужный для копирования участок. Это будет легким путем создания фреймворка, причем с большей обзорностью/целостным представлением картины за счет имеющихся карт контролов и карт путей между окнами.
- Карты контролов и карты путей для разных версий можно будет отправлять в онлайн репозиторий, что будет поощряться продлением пробного периода, и позволит накопить базу фреймворков для разных версий разных приложений. Поиск по этой базе будет сделан оптимально просто: с каким приложением пользователь работает, по crc сумме будет находиться и предлагаться уже готовый фреймворк. А к фреймворку будут также онлайн доступны наиболее часто используемые скрипты, которые будут проходить проверку на воспроизводимость. Т.е. идея своеобразного OpenSource скриптования. Последнее больше подходит для автоматизации. Для тестинга была бы интересна с точки зрения подготовки среды тестирования, установки/настройки популярных приложений, которые задействованы в тестировании не как "подопытные", а как вспомогательные.
- Генерация тесткейсов для тестирования приложения будет происходить в полуавтоматическом режиме. Пользователь задает наиболее приоритетные и важные для тестирования контролы, пути, настройки, остальные пути будут предлагаться для тестирования по остаточному принципу (в зависимости от свободных машиноресурсов). Таким образом покрытие тестами, регрессионное тестирование будет решено с меньше долей ручного труда и с большей долей наглядности, обзорности общей картины.
 
Буду благодарен за любые комментарии, советы, критику, сравнения с имеющимися решениями. Конечная цель этого письма понять, будет ли это востребовано конечным пользователем, стоит ли реализовывать. Спасибо за уделенное время.

Если говорить о сохранении окна в репозиторий, то идея, конечно, не нова - возьмите тот же Coded UI (слышал, что и силктест поступает аналогично: превращает окно в класс. Ещё такое можно проделывать из дотнета с wpf-приложениями).

Что касается записи и переходов между окнами - надо отточить концепцию, потому что это очень близко к модульному програмированию, от которого (любого программирвания) на вашем сайте заявлен уход.

Автоматизация куска прохода - это где-то между вызовами макросов и воркфлоу. Для массового джуниор-тестировщика это, наверное, перспективно. Для человека где-то со средним опытом уже потребуется создание чего-то гибкого. Попробуйте рассмотреть продукты, которые предоставляют воркфлоу (т.е. написаны поверх WWF): я знаю только из области пауэршелл: PowerWF ("только мышкой"), PowerShell ISE 3.0 (тут уже думать надо), но есть и поверх других языков (видел пару самоделок в инете).

Автоматизация переходов без программирования, "одной мышкой" - гуглите по слову workflow, эту концепцию юзеры осиливают.

 

Хотите логически потестить вашу концепцию?

1) Вот наше приложение: остнастка mmc, т.е. дерево слева, остальное справа (кстати, не все элементы имеют хэндлы, если вы юзаете хэндлы). Но наш продукт ни фига не compmgmt.msc :) Вам не получится сидеть в одной точке и направлять оттуда свои тесты! :) Нет, наш продукт достаточно сценариен: сначала идёте в корень дерева и создаёте связку домен-облако (не менее одной) - это визард, потом создаёте коллекцию (тоже визард), визард запускает визард установки агента. Потом уже, открыв окошко в окошке в окошке, можете добавлять юзеров или другие объекты. Потом с ними можете проводить действия (их много). Да на каждом шагу ещё немало вариантов выбора, порой до десятка контролов на шаге визарда.

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

2) Сегодня смотрел одно приложение, давно хотел посмотреть: QlikView personal edition. Рекомендую взять его на отработку концепции: посмотрите там сеттинги, посмотрите добавление в отчёты источников данных - оно слегка перегружено контролами, вам будет интересно поиграться. :)

 

А вот идея с онлайн репозиторием мне совсем не нравится:

1) через корпоративный прокси это обычно кошмар. Вам надо будет хорошо оттестировать приложение, ведь даже продукты известных вендоров могут не работать со всеми видами прокси. (К примеру, у нас виртуальным машинкам по дивайсайди запрещается доступ в инет, но это только по DHCP. По статическим адресам админы ограничение не сделали, но всё равно это отличается от работы с инетом машинок в корпоративном домене. И последние тоже не так работают, как свой персональный прокси с запомненным паролем...).

2) онлайн репозиторий больше годится для демок или обучения: ну вот зачем нам онлайн-репозиторий, если продукт ещё не релизился, а беты выдаются ограниченному числу кастомеров из числа наших полевых инженеров. Возможно, это интересно для ежедневно билдящихся опенсорсных продуктов, но люди, которые их пишут, скоре запрограммируют тесты, чем будут их накликивать...

Спасибо за подробный комментарий, попробую защититься

"Что касается записи и переходов между окнами - надо отточить концепцию, потому что это очень близко к модульному програмированию, от которого (любого программирвания) на вашем сайте заявлен уход."   Уйти от программирования полностью - это иллюзия, не удастся, но максимально облегчить этот процесс и сделать доступным для чайников, без увеличения рутины - это достойная, на мой взгляд, цель.

Отдельное спасибо за воркфлоу, QlikView  - буду гуглить.

"Вам не получится сидеть в одной точке и направлять оттуда свои тесты! :) Нет, наш продукт достаточно сценариен" Я как раз и хотел сказать, что сидеть в одной точке вовсе будет не обязательно. Если по сценарию начальным условием должно быть нахождение в корне дерева, и контрол распознался как древовидный список, то автокликер с помощью контроля редкоизменяемых параметров контролов сам предложит начальным условием обозначить нахождение в корне и разрешение переходить в него, если не в корне. Контроль редко изменяемых параметров - это такая штука, которая будет анализировать состояние контролов перед началом движения по сценарию. Т.е. если у нас в 10 случаях Воспроизведений - 9 случаев имели выделенный элемент в корне, а 10й нет и пофейлился, то автокликер ворнингом уведомит пользователя об этом и предложит включить это в начальное условие скрипта. Если какие-то параметры меняются и это не приводит к фейлу, то эти параметры исключаются из дальнейшего контроля и их изменение не будет приводить ни к какому оповещению пользователя. Собственно, это же контролирует и сам тестер, т.е. он помнит, что раньше какая-то опция всегда имела одно значение и тест всегда заканчивался удачно, но если по каким-то причинам эта опция изменилась и тест упал, то это как минимум повод обратить на это внимание и проверить корелляцию между падением теста и изменением значея опции.

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

"А когда приложение пишется, логика приложения не ясна, юзер интерфейс постоянно переделывается - готова ли ваша концепция к тому, что постоянно надо будет накликивать, задавать одни и те же названия для путей и т.д.?"

Для этого и задумана идея таким образом. Представьте, подсчет crc суммы показал, что у нас другая версия тестируемого продукта, автокликер берет карты из последней версии и считает их условноНЕподтвержденными. При новом сканировании контролов, какие-то вдруг не обнаружены, вынесены в другие диалоги или добавлены новые. В таком случае автокликер запрашивает пользователя, что делать в скриптах с недостающими/лишними контролами. Пользователь выбирает, что либо действия связанные с этими контролами удалить/пропускать, либо для этих контролов какие-то важные параметры/действия задаются и применяются к фиксированному количествую ранее написанных тесткейсов. Ведь тесткейсов к предыдущим продуктам может быть несколько тысяч и в каждом заменить работу одного контрола на работу другого - задача не тривиальная. Подход с инвентаризацией контролов позволит с минимальными времеными потерями исправить это.

"1) через корпоративный прокси это обычно кошмар. Вам надо будет хорошо оттестировать приложение, ведь даже продукты известных вендоров могут не работать со всеми видами прокси. (К примеру, у нас виртуальным машинкам по дивайсайди запрещается доступ в инет, но это только по DHCP. По статическим адресам админы ограничение не сделали, но всё равно это отличается от работы с инетом машинок в корпоративном домене. И последние тоже не так работают, как свой персональный прокси с запомненным паролем...)."

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

"2) онлайн репозиторий больше годится для демок или обучения: ну вот зачем нам онлайн-репозиторий, если продукт ещё не релизился, а беты выдаются ограниченному числу кастомеров из числа наших полевых инженеров. Возможно, это интересно для ежедневно билдящихся опенсорсных продуктов, но люди, которые их пишут, скоре запрограммируют тесты, чем будут их накликивать..."

Опишу чуть подробнее, что я подразумевал под фразой "Последнее больше подходит для автоматизации. Для тестинга была бы интересна с точки зрения подготовки среды тестирования, установки/настройки популярных приложений, которые задействованы в тестировании не как "подопытные", а как вспомогательные." Допустим, у нас в тесте используется ssh. Мы скачиваем из репозитория его карты и скрипт по его установке, запускаем устанавливаем, скачиваем скрипт по настройке из локального репозитория, настраиваем. А если все это сделать еще через командную строку, то почему бы и нет?