Тестирование GUI Automation - вопросы о дескрипторе окна - PullRequest
3 голосов
/ 21 августа 2008

Наша компания в настоящее время пишет инструмент для автоматизации графического интерфейса для приложений на компактных платформах. Изначально мы искали много инструментов, но ни один из них нам не подошел.

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

В целом инструмент работает нормально, но поскольку мы используем оконные дескрипторы для имитации пользовательского ввода, вы не можете сделать очень много вещей. Например, мы не можем получить название элемента управления (мы просто получаем заголовок).

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

Есть ли другой (более простой) способ сделать такие вещи (например, очередь сообщений или что-то еще)?

Ответы [ 5 ]

2 голосов
/ 21 августа 2008

Интересная проблема! Я давно не занимался низкоуровневым (думаю, Win32) программированием Windows, но вот что я хотел бы сделать.

Используйте именованный канал и пусть ваше приложение прослушивает его. Используя этот именованный канал в качестве средства связи, реализуйте действительно простой протокол, с помощью которого вы можете запросить у приложения имя элемента управления, учитывая его HWND, или другие вещи, которые вы считаете полезными. Убедитесь, что протокол достаточно богат, чтобы обменяться достаточным количеством информации между вашим приложением и тестовой средой. Убедитесь, что тестовый фреймворк не выдает слишком много «особого поведения» из приложения, потому что тогда вы на самом деле не будете тестировать функции, а скорее свой тестовый фреймворк.

Вероятно, есть более элегантные и более крутые способы реализовать это, но это то, что я помню из головы, используя только простые вызовы Win32 API.

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

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

(РЕДАКТИРОВАТЬ: Это также потрясающий инструмент контроля качества во время бета-тестирования, например: просто пусть ваши пользователи записывают свои действия, и в случае сбоя у вас есть хороший шанс легко воспроизвести проблему, просто воспроизведя сценарий. )

Удачи!

Карл

1 голос
/ 12 ноября 2008

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

Вот несколько сообщений о NUnitForms, которые стоит прочитать

NUnitForms и сбой регистрации DragDrop - проблема MTA против STA

Тестирование GUI скомпилированного приложения exe с NUnitForms

1 голос
/ 21 августа 2008

Если инструмент автоматического тестирования GUI обладает знаниями о платформе, в которой написано приложение, он может использовать эту информацию для создания более совершенных или более сложных сценариев. TestComplete , например, знает о VCL и WinForms Borland. Если вы тестируете сборку приложений с помощью Windows Presentation Foundation, в этой сборке реализована расширенная поддержка .

0 голосов
/ 12 ноября 2008

Управляемый шпион не предоставляет решения для приложений на компактных платформах.

Компания Jamo Solutions (www.jamosolutions.com) отвечает требованиям для автоматизации тестирования на мобильных устройствах, включая приложения .net compact framework.

0 голосов
/ 25 августа 2008

Наконец-то я нашел решение для связи между тестирующим приложением и тестируемым приложением: Управляемый шпион . Это в основном .NET-приложение, созданное поверх ManagedSpyLib.

ManagedSpyLib обеспечивает программный доступ к элементам управления Windows Forms другого процесса. Для этого он использует оконные хуки и файлы отображения памяти.

Спасибо всем, кто помог мне добраться до этого решения!

...