Особенности тестирования десктопных приложений. Тестирование Desktop программ — Личный Опыт

• Наличие рекордера, записывающего действия пользователя для автогенерации тестов.
• Поставка «out of the box» для Visual Studio.
• Поддержка от майкрософт, интеграция в TFS.
• Возможность работы на уровне дерева контролов, без привязки к координатам экрана.

Недостатки

В целом, набор недостатков тот же, что и у UI Automation . Отдельно только надо выделить то, что возможность работы есть только в определенных версиях 2010 студии(Ultimate, Premium, Professional). Причем если запуск тестов возможен во всех трех, то создание соответствующего типа item"а в проекте и запуск рекордера возможен только в версиях Ultimate и Premium. И если для своих домашних проектов и можно скачать с торрентов купить Ultimate версию, то для коммерческого проекта, где речь идет о лицензии для десятков разработчиков такой шаг может натолкнуться на непонимание со стороны вышестоящего начальства и бухгалтерии.

Код тестов я приводить не буду, ввиду того, что он является автогенереным и по-этому особого интереса не представляет.

4. Test Complete и ему подобные

Системы, подобные Test Complete можно обобщить в одну группы. Я не стану описывать их подробно, т.к. это тема отдельное статьи, выделю лишь некоторые моменты. Основное их достоинство - широкий спектр применений, отсутствие необходимости в навыках программирования и наличие отдельной, не требующих Visual Studio, системы по создание, хранению и поддержки тестов. Недостатки же повторяют предыдущие решения - платность, отношение к тестируемой системе, как к «черному ящику», без возможности мокирования плюс Test Complete имеет собственную среду для запуска тестов, так что использоваться обычный mstest не получится.

Сделаем что-нибудь свое

Если вы пишите UI своего приложения на WPF, то для его тестирования можно воспользоваться классом VisualTreeHelper . Алгоритм довольно простой - запускаем в тест-методе наше приложение в отдельном потоке, получаем через VisualTreeHelper нужный контрол, эмулируем эвенты и считываем значения для ассертов.

Для более удобного создания тестов, для себя я сделал небольшой утилитный класс, упрощающий выполнение рутинных действий:

Запуск приложения

var application = UI.Run(() =>

Получения свойства контрола. Поясню, т.к. работать с контролами может только тот тред, в котором их создали, приходиться делать такой финт ушами.

var window = application.Get(x => x.MainWindow);

* This source code was highlighted with Source Code Highlighter .

Ну и поиск в дереве

var textBox = _mainWindow.FindChild((TextBox el) => el.Name == "SomeText" );

* This source code was highlighted with Source Code Highlighter .

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

1. private void AssertRender(string expectImageName, FrameworkElement elementForTest)
2. var image = elementForTest.Render();
3. var expectPath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, expectImageName);
4. if (!(File .Exists(expectPath) && File .ReadAllBytes(expectPath).SequenceEqual(image)))
5. File .WriteAllBytes(Path.Combine(AppDomain.CurrentDomain.BaseDirectory,"fail_" + expectImageName), image);
6. throw new AssertFailedException(string .Format("Element {0} not equal to image "{1}"" , elementForTest.Get(x => x.Name), expectImageName));
7. AssertRender("button.png" , button);

* This source code was highlighted with Source Code Highlighter .

Достоинства

• Бесплатность.
• Не требует установки дополнительных библиотек.
• Позволяет мокировать части системы.

Недостатки

• Нет рекордера для тестов. Все пишем руками.
• Поддержка тестов целиком ложится на ваши плечи.

Примеры тестов для поставленной задачи

Изначальный текст в текстовом поле при старте приложения

2. public void TestStartup()
3. var application = UI.Run(() => new App { MainWindow = new MainWindow() });
4. var mainWindow = application.Get(x => x.MainWindow);
5. var textBox = mainWindow.FindChild((TextBox el) => el.Name == "SomeTexBox" );
6. Assert.IsNotNull(textBox);
7. Assert.AreEqual("123123123" , textBox.Get(x=> x.Text));
8. application.Invoke(x => x.Shutdown());

* This source code was highlighted with Source Code Highlighter .

Текст после нажатия на первую кнопку

2. public void TestFirstButtonClick()
3. var application = UI.Run(() => new App { MainWindow = new MainWindow() });
4. var mainWindow = application.Get(x => x.MainWindow);
5. var textBox = mainWindow.FindChild((TextBox el) => el.Name == "SomeTexBox" );
6. var button = mainWindow.FindChild((Button el) => el.Content.Equals("Click for test" ));
7. Assert.AreEqual("Habrahabr" , textBox.Get(x => x.Text));
8. application.Invoke(x => x.Shutdown());

* This source code was highlighted with Source Code Highlighter .

Текст после нажатия на вторую кнопку.

3. public void TestSecondButton()
4. var application = UI.Run(() => new App { MainWindow = new MainWindow() });
5. var mainWindow = application.Get(x => x.MainWindow);
6. var dateTimeExpect = new DateTime (2011, 12, 08, 12, 30, 25);
7. MDateTime.NowGet = () => dateTimeExpect;
8. var button = mainWindow.FindChild((Button el) => el.Content.Equals("Click for test 2" ));
9. button.Raise(ButtonBase.ClickEvent);
10. var textBox = mainWindow.FindChilds().First();
11. Assert.AreEqual(dateTimeExpect.ToString(), textBox.Get(x => x.Text));
12. application.Invoke(x => x.Shutdown());

* This source code was highlighted with Source Code Highlighter .

Тут я просто замокировал вызов DateTime.Now с помощью фреймворка Moles , обзор которого можно посмотреть, например, .

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

Добавить метки

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

Такие приложения размещаются на компьютере пользователя. Они не требуют для работы подключение к интернету, взаимодействуют с пользователем посредством стандартного интерфейса, имеют более высокое быстродействие, зависят от используемой операционной системы и требуют установку на каждый компьютер пользователя, желающего работать с данным приложением. Это текстовые редакторы, медиа-плееры, программы расчета, исчисления, изучения – в общем все программы, которые установлены у нас на компьютерах, являются desktop-приложениями. Так как мы имеем доступ к системным файлам программы, данный тип приложений более уязвим, и полностью зависит от действий пользователя.

Основные особенности тестирования десктопных приложений от заключаются в следующем:

Параметр	Desktop приложение	Web приложение
Доступ к сети Internet	не требуется	необходим. исключение: некоторые приложения могут временно работать автономно
Установка/обновление	Должно быть развёрнуто или установлено.	Единовременная настройка. Одна установка для всех пользователей.
Интерфейс взаимодействия	Стандартные интерфейсы, стандартное взаимодействие	Разнообразный интерфейс взаимодействия. Плюсы - разнообразие реализации, минусы, сложности - кроссбраузерная совместимость. Решается применением библиотек на JavaScritp, внедрением стандартов.
Совместимость с устройствами	Зависимость от платформы. Исключение - кроссплатформенные приложения.	В большинстве случаем - платформо-независимое.
Анимация, графика	Быстрая, быстрый отклик	Относительное медленный отклик, связанный с передачей данных по сети.
Медиа	Незначительные проблемы с аудио и видео.	Проблемы. На данный момент всё реализуется через Flash. Но в разработке стандарт HTML5, который подразумевает поддержку аудио и видео на уровне браузера.
Шрифты	Присутствуют только те шрифты, которые установлены у пользователя	Любые шрифты - есть возможность подгрузки необходимого шрифта через Internet
Поиск по контенту	Нет, если только не реализовано на уровне приложения.	Да есть. Причём можно организовать свой поиск, но и воспользоваться сторонними сервисами, к примеру запрашивать данные у Google.
Расшаривание	Если только дополнительно настроить	Изначально веб-приложения(большинство) настроены на совместный доступ
Разработка	Под каждую платформу есть свои инструменты, зачастую под каждую платформу приходиться писать свою версию.	Всё выполняется на сервере, пользователя не волнует как там исполняется всё на сервере. Кроссплатформенно, нужен только браузер. Инструменты, софт на сервере зачастую кроссплатформенный.
	Desktop приложение	Web приложение
Масштабы	Повсеместно	Пока что web-приложения не столь популярны. Но темпы роста популярности(в куче с «облаками») велики. Уже сейчас многие переходят на хранение документов на Google Docs и прочие сервисы.
Тестирование	Производится QA, группой QA..	По сути всё так же. Только открытость(расположение в сети) данного рода приложений позволяет привлечь бОльшее количество QA. Сотни, тысячи, миллионы. В результате бОльшее покрытие тестами и более быстрое обнаружение уязвимостей и некорректной работы софта.

При тестировании десктопных приложений необходимо учитывать особенности, перечисленные выше.

Виды тестирования которые необходимо проводить на десктопных приложениях помимо основных (функционального, GUI, юзабилити и т.д) также имеют свои особенности:

• тестирование инсталляции
• тестирование обновления
• тестирование деинсталляции

Выполняя тестирование установки проверяется:

1. Запускается ли программа после установки
2. Расположение программы в файловой системе по-умолчанию
3. Расположение программы в файловой системе если путь сохранения изменен пользователем
4. Наличие ярлыков на рабочем столе
5. Есть ли установленный компонент в меню Пуск > Программы
6. При установке обратить внимание на издателя
7. Установка программы для текущего пользователя/для всех пользователей компьютера
8. Установка пользователем с правами админа
9. Установка пользователем без прав админа

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

1. Проверить что после установки обновлений данные пользователя не были повреждены
2. Проверить что все созданные ранее пользователем файлы остались доступными

Выполняя тестирование удаления проверяем:

1. Файлы должны удалиться
2. Ярлык с рабочего стола исчез
3. Удалена ли запись из меню Пуск > Все программы
4. Выполняем команду %userprofile% через командную строку, чтобы открыть личную папку текущего пользователя. Убеждаемся, что нет папок с названием программы

Автотестирование активно развивается для web- и mobile-проектов. Но десктопные приложения приходится тестировать до сих пор: их по-прежнему используют финансовые компании, производства, сегмент HoReCa. Зайдите в ближайший банк, кафе, ресторан - всюду вы увидите Windows Desktop. При этом тестирование таких приложений почти не развивается, информации о нем мало.

Эта статья написана по опыту одного из наших проектов: необходимо было тестирование Windows Desktop приложения с десятками тысяч строк кода. Ручная проверка подобного решения заняла бы слишком много времени, поэтому мы решили разработать пилотную версию автотестов для выполнения проекта.

Подбирая инструмент для этой задачи, мы столкнулись с тем, что функции коммерческих студий ориентированы, в основном, на web- и mobile-, сами решения неоправданно удорожают проект, и не до конца понятно, что у них "под капотом". Мы стремимся к тому, чтобы до конца понять: что именно мы предлагаем клиенту, как используем, поэтому обратились к поиску инструментов с открытым кодом и выбрали оптимальный.

Итак, нашей задачей было создать пилотную версию АТ (автотестов). Конечной целью - автоматизация тестирования сложного.NET desktop приложения. При подборе инструмента выдвигали следующие требования:

Оперативность . Возможность "на выходе" просматривать отчеты из CI с ночными прогонами этих шести тестов (или получать письмо с описанием “упавших” тестов).

Прозрачность . Нужно, чтобы команда тестирования понимала, что именно проверяется в каждом шаге теста, а менеджер мог читать отчет в понятной для него форме (например: "на окне n не хватает третьего поля ввода").

Стоимость . Необходим инструмент, который не удорожает проект без необходимости.

Сравнение бесплатных фреймворков

Первым решением, опробованным для наших задач, стал Visual Studio Coded UI .

Плюсы :

Те же технологии в тестировании, что и в разработке продукта.

Есть test recorder.

Работа с WinForms.

Работа с UI-контролами DevExpress.

Минусы :

Небольшой объем документации.

Платная VS.

Test recorder генерирует плохо поддерживаемый код: тесты после записи и запуска сразу “падают” (возможно, не воспроизводится на “простых” интерфейсах).

BDD-написание тест-кейсов (с использованием, например, одного из самых популярных фреймворков на языке C# - Specflow) несовместимо “из коробки” с Coded UI.

Ограничения поиска и работы с элементами пользовательского интерфейса, накладываемые UIA API v.1 - MSAA.

Плюсы :

Инструмент для полноценного написания тестов на языке С#.

Совместим с фреймворками BDD.

Минусы :

Нет возможности нормально идентифицировать все элементы UI. Не подходит к DevExpress элементам.

Апдейт Nuget-пакета не происходил с 2016 года.

Немного документации, небольшое комьюнити.

Медленное исполнение элементарных кейсов (“открыть приложение”, “проверить содержимое строки статуса”)

Сроки разработки тестов. Поддержка, стабильность UI-тестов

На шесть довольно объемных Regress-сценариев из примера было заложено три месяца разработки с “нуля”, включая ознакомление проектом, исследование доступных, описанных выше, фреймворков, создание скелета проекта АТ, настройка CI (continuous integration), менеджмент и коммуникации, сопроводительную документацию. Проект выполнен и сдан в срок.

При продолжении покрытия тестовых сценариев автотестами подготовительные операции, разумеется, будут занимать меньше времени, так как были реализованы на стадии пилота.

Помещаем тесты в Continuous Integration

Оба фреймворка поддерживают запуск тестов с использованием систем непрерывной интеграции. В нашей команде использовали TC и TFS.

При использовании фреймворка FLAUI, фреймворка SpecFlow и тестов, написанных на языке C#, в создании сборки нет ничего особенного (svc - build - run), кроме соблюдения некоторых условий на агенте исполнения тестов:

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

Automatic logon setup (Use SysInternals Autologon for Windows as it encrypts your password in the registry).

Отключить screensaver.

Отключить Windows Error Reporting. Справка на Gist: DisableWER.reg

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

RDC. Но часто можно встретить и совет пользоваться VNC (с аргументацией что: при подключении через Удаленный рабочий стол и последующем отключении, десктоп будет заблокирован When you connect using Remote desktop, then disconnect, the desktop will be locked, and UI Automation will fail)

BDD-фреймворк Specflow имеет интеграцию “на лету” c TC и TFS. Т.е. непосредственно в прогоне тестов отображается отчет об успешных и проваленных тестах.

Пример ROI автотестов

Перед внедрением автоматизации подсчитать ROI сложно, поскольку существует огромное количество неизвестных факторов и коэффициентов. (И лучше не верить калькуляции ROI в разделе прайсинга Test Complete).

Но после реализации пилотного проекта автоматизации можно привести некоторые цифры. Возьмем самую простую формулу ROI:

ROI = (Gain of Investment - Cost of Investment) / Cost of Investment

Стоимость проекта автоматизации за первый год (без поддержки):

3 месяца на покрытие автотестом Regress-прогона при работе одного инженера-разработчика в тестировании: получается, 500 часов * Dev-ставка в час . Допустим, стоимость решения (Cost of investment) оплачивается заказчиком полностью в первый год (не делится по частям, и на покупку решения не берется кредит).

Выгода:

В первой статье мы подсчитали, что чистый “прогон” регресс-тестов вручную занимает 1 месяц: 2 недели первичный прогон + 2 недели вторичный прогон (без проверки новых тестов и сопутствующих расходов).

После разработки АТ-регресса (3 месяца), 9 месяцев в году прогоны регресс-теста руками не исполняются. Будем считать, что высвободившиеся ресурсы подключили к другим проектам в компании. Сохранили: 1500 часов * QAставка в час * 2 человека в команде .

ROI = (1500*QA*2 - 500*Dev) / 500 * Dev = (6*QA - 1*Dev) / Dev

При взятии по рынку средних значений QA ставка = n, Dev ставка = 1,5n получаем:

ROI = (6n - 1,5n) / 1,5n = 3.

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

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

Результат

Разработанные автотесты заменяют ручные силы команды QA и высвобождают команду из двух человек для более важных проектных задач. При этом оптимально расходуются ресурсы проекта.

Да, мануальное тестирование - необходимая часть разработки. Но если ПО состоит из десятков тысяч строк кода и требует двух-трех недель от разработки новой функции до релиза, автоматизация очень важна. Чтобы понять, выгодно ли покрытие всех работ автотестами и возможно ли оно, наша команда применяет стратегию Do Pilot: то есть, автоматизирует участок работ при помощи выбранного фреймворка.

Тем не менее, если использовать в платных “коробочных” решениях для АТ все нужные функции и масштабировать команду хотя бы до двух инженеров - поддержка таких решений удорожает проект. Чтобы на заказчика ПО не ложилась необходимость платить в начале за само решение, а потом - каждый год - за его поддержку, мы рассмотрели несколько фреймворков для АТ с открытым кодом. Из предложений выбрали те, которые нас устраивают. Два найденных решения использовали для работы.

Автоматизация тестирования, хотя и требует подготовки по поиску фреймворка и разработке самих автотестов, оказывается значительно выгоднее ручных “прогонов”.

Если вам нужно произвести тестирование ваших приложений в оптимальные сроки и не увеличивая затраты без необходимости, мы с радостью ответим на ваши вопросы:

Телефон: +7 812 407 2350

E-mail: [email protected]

• Appium
• FlaUI
• Quality Assurance
• TestStack.White
• Visual Studio Coded UI
• WinAppDriver
• Windows Desktop
• Winium.Desktop
• автоматизация тестирования

Здравствуйте, уважаемые хабровчане!
Мы с коллегой готовим для конференции доклад на тему автоматизации тестирования desktop-приложений. Ценность и полезность доклада возрастет, если мы сможем использовать в выступлении результаты опроса профессионального сообщества.
Результатами поделюсь на Хабре.

В основном, вопросы касаются инструментов, используемых в процессе тестирования ПО. Под инструментами тестирования подразумеваются: баг-трекинг система, система виртуализации, система сборки, система контроля версий, автоматизированные тесты.

Есть три дискуссионных вопроса – на них можно ответить здесь, в комментариях.
По ссылке http://www.surveymonkey.com/s/DJTFHFH – 10 вопросов с вариантами ответа. Вам потребуется не более 2,5 минут, чтобы ответить на них.

Мероприятие состоится 20 мая, поэтому просьба ответить на вопросы анкеты до 18 мая включительно.
Спасибо за участие!

I. Свободное vs. Коммерческое (лицензионное) ПО

Использование свободного ПО при тестировании (например, Bugzilla, VMware Server, SVN и т.д.) позволяет минимизировать инвестиции в используемые инструменты.

А. На ваш взгляд, как это влияет на качество процесса тестирования?
Б. В каких случаях в тестирование предпочтительно использовать свободное ПО?

II. Тестирование desktop-приложений

А. Приходилось ли вам автоматизировать тестирование desktop-приложений?

Если да, с какими основными сложностями пришлось столкнуться?

III. Общие вопросы и тестовый интсрументарий (10 вопросов с вариантами ответов =< 2,5 мин)
http://www.surveymonkey.com/s/DJTFHFH

P.S.
Опрос продолжается, и результаты обещают быть репрезентативными – по состоянию на 12 мая ответили 123 человека. И что самое неожиданное, после того, как количество респлндетов перешагнуло за 100, я получаю такое сообщение при проверке результатов:

Бессовестная Обезьянка для Опросов требует 25 евро, чтобы посмотреть результаты свыше ста респондентов – и это в разгар валютного кризиса в Беларуси!
Продолжайте отвечать, прорвемся:)

Upd. Результаты можно посмотреть в