GUI Automation testing - вопросы обработки окон

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

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

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

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

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

(EDIT: это также потрясающий инструмент QA во время бета-тестирования, например: просто попросите ваших пользователей записать свои действия, и если произойдет сбой, у вас есть хороший шанс легко воспроизвести проблему, просто воспроизведя сценарий)

Удачи вам!

Карл

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

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

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

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

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

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

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

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

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

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