Автотестирование активно развивается для 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 года.
Немного документации, небольшое комьюнити.
Медленное исполнение элементарных кейсов (“открыть приложение”, “проверить содержимое строки статуса”)
На шесть довольно объемных 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]
Я пришел в тестирование desktop программ после 2-х лет тестирования web и мобильных приложений. В целом многие знания пригодились и я смог их применить в практике.
Принцип тестирования сохранился. Основы одинаковы. Параметры на входе и выходе, ожидаемый результат и актуальный, поиск расхождений, конечно все это применимо и в тестировании desktop приложений.
В тестировании вэб сервисов основной клиент это браузер. Их подразделяют на мобильные/desktop и другие. А в тестировании desktop приложений главным клиентом выступает операционная система.
Для нашего продукта две основные ветки ОС это Windows и Windows Server. Актуальные версии Windows — XP(SP1,SP2,SP3),Windows Vista, Windows 7, Windows 8, Windows 10. Серверные — Windows Server 2003, Windows Sever 2008, Windows Server 2010.
Я начинал со знакомства с HELP — мануалом продукта. Для меня это была новая сфера и мне вдвойне повезло, что был огромный запас документации, доступный для новичка.
Давайте рассмотрим тест-кейсы на примере всем известного Ms Office, также доступного как облачный сервис Office 360.
Системные требования
| Компьютер и процессор | ПК: процессор x86 или x64 с тактовой частотой от 1 ГГЦ и поддержкой набора инструкций SSE2.
Mac: процессор Intel |
| Память | ПК: 2 ГБ ОЗУ |
| Mac: 4 ГБ ОЗУ | |
| Жесткий диск | ПК: 3,0 ГБ свободного пространства на жестком диске
Mac: 6 ГБ свободного пространства на жестком диске формата HFS+ (также известного как Mac OS Extended или HFS Plus) |
| Экран | ПК: разрешение экрана 1280 x 800 |
| Mac: разрешение экрана 1280 x 800 | |
| Графическая подсистема | ПК: чтобы использовать аппаратное ускорение графики, необходима графическая карта с поддержкой DirectX10. |
| Операционная система | ПК: Windows 10, Windows 8.1, Windows 8, Windows 7 с пакетом обновления 1, Windows 10 Server, Windows Server 2012 R2, Windows Server 2012 или Windows Server 2008 R2
Mac: Mac OS X 10.10 Для оптимальной работы используйте последнюю версию любой операционной системы. |
| Браузер | Текущая или предыдущая версия Internet Explorer, текущая версия Microsoft Edge, Safari, Chrome или Firefox. |
Процессор . Минимальный набор инструкций SSE2 . Если ваш процессор не поддерживает эти требования, то программа должна выдать сообщение о невозможности установки. В настоящее время тяжело найти процессоры которые не поддерживают SSE2, есть всего несколько таких типов 2002-2004 года выпуска, по сути это раритет. Сейчас для нашего продукта это не критично, поэтому мы пропускаем такой тест-кейс . Но не забывайте про распространенные процессоры AMD, которые не поддерживают такой тип инструкций. В таких случаях программа будет «крешиться». Если Windows успеет перехватить процесс и выдать ошибку, то есть шанс отловить этот баг.
За мое время работы в компании, был случай когда после релиза стало поступать много жалоб от клиентов. Но отловить баг было очень проблематично, потому что не нашлось подходящей конфигурации железа. Выловить удалось только программистам при помощи тщательного code review . В релиз был включен переход от старой библиотеки к новой, и поэтому минимальные требования к железу повысились. Как следствие, пользователи со старым железом не смогли обновить приложение.
После багфикса, в коде уже учитывались все минимальные требования. Также мы обновили описание продукта, добавив минимальные рекомендуемые характеристики.
Оперативная память компьютера. Проводим положительные и отрицательные тест кейсы. Cмотрим как программа будет действовать при <= 2ГБ ПЗУ, >= 2ГБ ПЗУ. Зачастую я обхожусь виртуальными образами OracleBox.
Мой sanity тест :
Жесткий диск. Аналогично ПЗУ. Можно добавить негативный тест , когда у вас нет места на диске и вы устанавливаете программу и/или уже запускаете. Еще один кейс, когда программа работает и записывает на диск. Приложение должно корректно обрабатывать ситуацию, когда места для записи не хватает.
Дисплей. Основные кейсы это различные разрешения, от минимального до 4К. Такие мониторы стали попадаться намного чаще. Особое внимание также нужно обратить на сохранение окна приложения. Попробуйте свернуть/развернуть/восстановить/ресайзить и закрыть приложение. Рассматривайте ситуацию с 2 дисплеями, таких тоже сейчас не мало. В этих случаях программа должна запоминать размеры и параметры дисплея, на котором была запущена.
Графическая подсистема. Смотрим минимальные требования и запускаем. Современные компьютеры/ноутбуки даже со встроенной видеокартой могут запускать большинство приложений. На моем проекте не требуется больших ресурсов, поэтому мы редко проводим с большим скоупом видеокарт.
Всегда обращайте внимание на разрядность операционки. Она имеет большое значение. Если ваша программа связана с математическими вычислениями, то на ОС с разной разрядностью, результаты могут быть совершенно разными. Всегда тестируйте приложения с учетом обновлений Microsoft. У них принято часто латать дыры. А частые обновления операционки могут навредить вашей программе.
В серверных и обычных версиях Windows есть разграничение прав доступа. Администратор, гость и другие. Важно учитывать все эти роли и иметь возможность установки программы даже в режиме гостя. Хотя гость и не имеет прав записи в programm files, он должен иметь свой каталог temp и устанавливать программу в эту папку.
Негативные тесты тоже возможны. Например, попробуйте установить вашу программу в папку без права на запись или чтение.
Браузер. Здесь ему тоже нашлось место. Очень часто приложения используют движок нативного браузера Windows, в нашем случае IE. Так же как Android приложения могут быть построены на Webview. В Windows 10 используется MS Edge, Windows 8.1 IE 11, в Windows XP SP3 максимальная версия это IE8. Если минимальные требования к вашему продукту это IE9+, то пользователи с Windows XP будут недовольны.
В моем проекте в основном используется blackbox тестирование , у нас нет доступа к коду, а какого-то распространенного дебагера (как firebug) здесь нет. Но не стоит забывать про автоматизацию, про нее расскажу в следующей статье. Буду рад ответить на ваши вопросы!
Здравствуйте, уважаемые хабровчане!
Мы с коллегой готовим для конференции доклад на тему автоматизации тестирования desktop-приложений. Ценность и полезность доклада возрастет, если мы сможем использовать в выступлении результаты опроса профессионального сообщества.
Результатами поделюсь на Хабре.
В основном, вопросы касаются инструментов, используемых в процессе тестирования ПО. Под инструментами тестирования подразумеваются: баг-трекинг система, система виртуализации, система сборки, система контроля версий, автоматизированные тесты.
Есть три дискуссионных вопроса – на них можно ответить здесь, в комментариях.
По ссылке http://www.surveymonkey.com/s/DJTFHFH – 10 вопросов с вариантами ответа. Вам потребуется не более 2,5 минут, чтобы ответить на них.
Мероприятие состоится 20 мая, поэтому просьба ответить на вопросы анкеты до 18 мая включительно.
Спасибо за участие!
А. На ваш взгляд, как это влияет на качество процесса тестирования?
Б. В каких случаях в тестирование предпочтительно использовать свободное ПО?
Если да, с какими основными сложностями пришлось столкнуться?
III. Общие вопросы и тестовый интсрументарий (10 вопросов с вариантами ответов =< 2,5 мин)
http://www.surveymonkey.com/s/DJTFHFH
P.S.
Опрос продолжается, и результаты обещают быть репрезентативными – по состоянию на 12 мая ответили 123 человека. И что самое неожиданное, после того, как количество респлндетов перешагнуло за 100, я получаю такое сообщение при проверке результатов:
Бессовестная Обезьянка для Опросов требует 25 евро, чтобы посмотреть результаты свыше ста респондентов – и это в разгар валютного кризиса в Беларуси!
Продолжайте отвечать, прорвемся:)
Upd. Результаты можно посмотреть в
Но в 2018 году всё ещё нужно разрабатывать десктопные приложения, поддерживать legacy-проекты. Банки, финансовые отделы компаний, производства и лаборатории, сегмент HoReCa применяют Windows Desktop-приложения. Множество бизнесов разных направлений применяют их для учета, организации и автоматизации бизнес-процессов.
Пользовательская машина дает не меньше возможностей, чем web. А иногда и больше. Например, это работа с локальными файлами и устройствами: обработка больших данных, возможность использовать специфичное оборудование, обращаться к различным сервисам. Причин для сохранения десктопных приложения масса:
Всё вышеперечисленное - потребности реальных заказчиков, и достижения web для таких задач неприменимы.
Наш заказчик использует desktop-приложение (.NET) для делопроизводства, организации и сопровождения бизнес-процессов, которое разрабатывается и развивается годами.
Сейчас оно состоит из десятков тысяч строк кода, а это сотни тестов и примерно полтора месяца, которые требуются на первичное ручное тестирование:
Две недели на первичный ручной прогон регресс тестов.
Две недели на повторный прогон.
Время на исправление ошибок и возможные накладки.
По мере исправления ошибок затрачиваемое время растет, могут случаться накладки во время планирования и контроля. Итого - примерно 1,5 месяца работы двоих инженеров , которые обычно задействованы на выполнении регрессионных проверок.
Полквартала для завода, производства или банка, когда нужно срочно доработать функционал, внести правку, добавить модуль, оборачиваются потерей денег.
Заказчику нужны быстрые релизные итерации: запрос, разработка, короткое тестирование и внедрение. Главное - оставить качество на прежнем уровне, а лучше - повысить его по объективным количественным критериям. Именно так появляется необходимость автоматизации тестирования.
Конечно, не все в тестировании можно автоматизировать, и некоторые задачи все еще приходится делать вручную. Но если нужно узнать, насколько автоматизация возможна, полезна и пригодна на конкретном проекте, - команда WaveAccess пользуется manage-паттерном автотестирования “Do Pilot” (“создай пилотную версию”) .
Стратегия Do Pilot заключается в том, чтобы автоматизировать часть работ и оценить их результат: потраченное время, масштабируемость тестов, стоимость их поддержки. То есть, сделать пилотную версию автотеста (АТ), а затем принять решение о том, стоит ли переводить всё тестирование в автоматизацию.
Всегда проще потратить пару недель, чтобы понять: найден полезный инструмент, пригодный для бизнеса, или это потеря времени.
Итак, мы решили реализовать пилотную версию АТ для крупного.NET Windows Desktop приложения нашего клиента. Для этого выбрали стабильную версию приложения и подобрали шесть основных тестовых сценариев, отмеченных тегом Smoke или Regress, прохождение которых даёт гарантию, что основной функционал тестируемого приложения работает в соответствии с техническим заданием.
К результату выдвинули требования:
Оперативность . Имеется возможность “на выходе” просматривать отчеты из CI (Continuous Integration) с ночными прогонами этих 6-ти тестов или получать письмо с описанием “упавших” тестов.
Прозрачность . Команда тестирования понимает, что именно проверяется в каждом шаге теста, а менеджер может читать отчет, написанный в понятной для него форме (например, "на окне n не хватает третьего поля ввода").
Стоимость . Выбранный и нструмент не удорожает проект без необходимости.
Главный вопрос, который встал перед нами, - поиск подходящего инструмента для написания АТ, который отвечал бы всем критериям.
Как мы уже сказали выше: web- и mobile-технологиях автотестирование сейчас преобладает. Рассмотрим, что же, все-таки, можно найти на этом поле для Windows Desktop.
Платные инструменты. TestComplete
Одним из лидеров платных фреймворков является полноценная студия для АТ TestComplete от SmartBear . У решения есть триал-период, есть положительные отзывы пользователей.
Выбираем решение "из коробки" на одного пользователя:
Выбираем кастомизированное решение, убираем "Web" и "Mobile".
Пытаемся максимально снизить цену. За возможность безлимитного тестирования и другие необходимые аддоны все же придется доплатить 1700€ для одной лицензии .
Научить команду тестирования пользоваться студией TestComplete можно, получив сертификаты по 150-700€ за каждый . Возьмём один базовый TestComplete Certification .
Итого:
Итак, 4000€ за студию и один год поддержки на 1 пользователя . Однако заказчику мы хотели предложить такое решение, которое при сохранении качества платных решений “из коробки” не вынуждало бы его платить такую сумму нам, а через год - продолжать платить уже за продление лицензии.
Платные инструменты. Telerik Test Studio
Следующий платный инструмент - Telerik Test Studio. Его цены:
Но за каждую вспомогательную функцию придется платить:
Эта сумма - 2499 + 899 +599 = 4000$ - включает только одного пользователя и год поддержки . Умножив ее на количество пользователей, а на данном проекте команда WaveAccess состояла из двух инженеров, получаем итоговую цену: 8000$ за год . И многие другие платные фреймворки также удивляют ценообразованием.
Мы стремимся к оптимизации ресурсов при сохранении качества. Но главное - мы стремимся к тому, чтобы до конца понять: что именно мы предлагаем клиенту, как используем. Поэтому ПО с открытым программным кодом предпочтительнее, чем коробочное решение - этакий “кот в мешке”.
Автотестирование активно развивается для 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 года.
Немного документации, небольшое комьюнити.
Медленное исполнение элементарных кейсов (“открыть приложение”, “проверить содержимое строки статуса”)
На шесть довольно объемных 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: то есть, автоматизирует участок работ при помощи выбранного фреймворка.
Тем не менее, если использовать в платных “коробочных” решениях для АТ все нужные функции и масштабировать команду хотя бы до двух инженеров - поддержка таких решений удорожает проект. Чтобы на заказчика ПО не ложилась необходимость платить в начале за само решение, а потом - каждый год - за его поддержку, мы рассмотрели несколько фреймворков для АТ с открытым кодом. Из предложений выбрали те, которые нас устраивают. Два найденных решения использовали для работы.
Автоматизация тестирования, хотя и требует подготовки по поиску фреймворка и разработке самих автотестов, оказывается значительно выгоднее ручных “прогонов”.
Десктопные приложения – это полнофункциональные программы, которые работают вне зависимости от других приложений и требуют наличие оператора. Для их работы необходимы достаточные аппаратные ресурсы компьютера, само приложение и набор функций для работы с приложением.
Такие приложения размещаются на компьютере пользователя. Они не требуют для работы подключение к интернету, взаимодействуют с пользователем посредством стандартного интерфейса, имеют более высокое быстродействие, зависят от используемой операционной системы и требуют установку на каждый компьютер пользователя, желающего работать с данным приложением. Это текстовые редакторы, медиа-плееры, программы расчета, исчисления, изучения – в общем все программы, которые установлены у нас на компьютерах, являются desktop-приложениями. Так как мы имеем доступ к системным файлам программы, данный тип приложений более уязвим, и полностью зависит от действий пользователя.
Основные особенности тестирования десктопных приложений от заключаются в следующем:
| Параметр | Desktop приложение | Web приложение |
| Доступ к сети Internet | не требуется | необходим. исключение: некоторые приложения могут временно работать автономно |
| Установка/обновление | Должно быть развёрнуто или установлено. | Единовременная настройка. Одна установка для всех пользователей. |
| Интерфейс взаимодействия | Стандартные интерфейсы, стандартное взаимодействие | Разнообразный интерфейс взаимодействия.
Плюсы - разнообразие реализации, минусы, сложности - кроссбраузерная совместимость. Решается применением библиотек на JavaScritp, внедрением стандартов. |
| Совместимость с устройствами | Зависимость от платформы. Исключение - кроссплатформенные приложения. | В большинстве случаем - платформо-независимое. |
| Анимация, графика | Быстрая, быстрый отклик | Относительное медленный отклик, связанный с передачей данных по сети. |
| Медиа | Незначительные проблемы с аудио и видео. | Проблемы. На данный момент всё реализуется через Flash. Но в разработке стандарт HTML5, который подразумевает поддержку аудио и видео на уровне браузера. |
| Шрифты | Присутствуют только те шрифты, которые установлены у пользователя | Любые шрифты - есть возможность подгрузки необходимого шрифта через Internet |
| Поиск по контенту | Нет, если только не реализовано на уровне приложения. | Да есть. Причём можно организовать свой поиск, но и воспользоваться сторонними сервисами, к примеру запрашивать данные у Google. |
| Расшаривание | Если только дополнительно настроить | Изначально веб-приложения(большинство) настроены на совместный доступ |
| Разработка | Под каждую платформу есть свои инструменты, зачастую под каждую платформу приходиться писать свою версию. | Всё выполняется на сервере, пользователя не волнует как там исполняется всё на сервере. Кроссплатформенно, нужен только браузер. Инструменты, софт на сервере зачастую кроссплатформенный. |
| Desktop приложение | Web приложение | |
| Масштабы | Повсеместно | Пока что web-приложения не столь популярны. Но темпы роста популярности(в куче с «облаками») велики. Уже сейчас многие переходят на хранение документов на Google Docs и прочие сервисы. |
| Тестирование | Производится QA, группой QA.. | По сути всё так же. Только открытость(расположение в сети) данного рода приложений позволяет привлечь бОльшее количество QA. Сотни, тысячи, миллионы. В результате бОльшее покрытие тестами и более быстрое обнаружение уязвимостей и некорректной работы софта. |
При тестировании десктопных приложений необходимо учитывать особенности, перечисленные выше.
Виды тестирования которые необходимо проводить на десктопных приложениях помимо основных (функционального, GUI, юзабилити и т.д) также имеют свои особенности:
Выполняя тестирование установки проверяется:
Для тестирования обновлений специально устанавливают старую версию программы, она сразу же находит обновления и обновляется. Выполняя тестирование обновлений нужно:
Выполняя тестирование удаления проверяем:
