Если говорить о сохранении окна в репозиторий, то идея, конечно, не нова - возьмите тот же 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. Мы скачиваем из репозитория его карты и скрипт по его установке, запускаем устанавливаем, скачиваем скрипт по настройке из локального репозитория, настраиваем. А если все это сделать еще через командную строку, то почему бы и нет?