Тестирование автоматизации графического интерфейса пользователя - вопросы по обработке окон

Question

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

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

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

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

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

Answer 1

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

Answer 2

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

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

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

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

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

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

Удачи вам!

Карл

Answer 3

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

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

NUnitForms и неудачная регистрация DragDrop - проблема MTA против STA

Тестирование скомпилированного exe-интерфейса приложения с помощью NUnitForms

Answer 4

Я, наконец, нашел решение для связи между тестируемым приложением и тестируемым приложением: Управляемый Шпион.По сути, это .NET-приложение, созданное поверх ManagedSpyLib.

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

Спасибо всем, кто помог мне прийти к этому решению!

Answer 5

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

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