Тестирование GUI Automation - вопросы о дескрипторе окна

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

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

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

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

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

20.08.2008 20:03:28
5 ОТВЕТОВ
РЕШЕНИЕ

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

1
20.08.2008 20:17:00

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

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

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

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

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

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

Удачи!

деревенщина

2
20.08.2008 20:33:28

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

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

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

0
25.08.2008 16:14:55

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

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

0
12.11.2008 09:23:54

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

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

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

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

1
12.11.2008 09:42:00