densaface

Коллеги, оцените классную на мой взгляд идею "АвтоКликера следующего поколения"

Сам я работаю в QA, являюсь автором своего уже небезызвестного автокликера AutoClickExtreme. Сейчас нахожусь перед выбором куда развиваться дальше, и хотел бы, чтобы этот процесс происходил не в слепую.

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 скриптования. Последнее больше подходит для автоматизации. Для тестинга была бы интересна с точки зрения подготовки среды тестирования, установки/настройки популярных приложений, которые задействованы в тестировании не как "подопытные", а как вспомогательные.
- Генерация тесткейсов для тестирования приложения будет происходить в полуавтоматическом режиме. Пользователь задает наиболее приоритетные и важные для тестирования контролы, пути, настройки, остальные пути будут предлагаться для тестирования по остаточному принципу (в зависимости от свободных машиноресурсов). Таким образом покрытие тестами, регрессионное тестирование будет решено с меньше долей ручного труда и с большей долей наглядности, обзорности общей картины.
- Еще дополнительной было бы уместно сделать контроль редкоизменяемых параметров как системы, так и тестируемых приложений. Например, какие-то контролы во время успешных прогонов меняют свои параметры, какие-то не меняют. Те которые при успешных прогонах менялись, будут в будущем игнорироваться, а те которые поменялись только при НЕуспешном прогоне теста, тут уместно довести до сведения тестера, что, например, раньше при успешных прогонах фокус был на корневом элементе древовидного списка, а при зафейленном прогоне, нет. Что, например, раньше при успешных прогонах, никогда не было в системном евентлоге события о внезапной остановке службы, а при пофейленном прогоне такое событие возникло.

Буду благодарен за любые комментарии, советы, критику, сравнения с имеющимися решениями. Конечная цель этого письма понять, будет ли это востребовано конечным пользователем, стоит ли реализовывать. Спасибо за уделенное время.