- PVSM.RU - https://www.pvsm.ru -
Сразу оговорюсь — я не являюсь профессиональным инженером по автоматизации тестирования. Однако, поскольку на данный момент так вышло, что это мое основное занятие по работе — буду особенно рад комментариям от людей со специализацией в этой области.
В статье — краткое описание CUITe для тех, кто не сталкивался, использование этого фреймворка для тестирования приложения с фронт-эндом на ASP.NET и проблемы, с которыми столкнулись.
Как говорит описание проекта на codeplex [1], это тонкая надстройка над UI Testing фреймворком от Microsoft. В описании приведено много преимуществ, но для меня они сводятся к двум: вместо UIMap — Object repository (более красиво, определения (definitions) UI объектов отдельно от остального кода), и разнообразный синтаксический сахар (все наглядно — берем control в UI объекте и вызываем его метод).
Инсталляция банальна — запускаем инсталлер, Next->Next->Finish, подключаем к проекту CUITe.dll — все. Элементы для интеракции находятся с помощью фирменного CUITe Object Recorder™ или вручную (я предпочитаю последнее). Основы записи тут приводить не буду — статья не об этом, по основам инфы много, чего не скажешь о проблемах, описанных ниже (будет интерес — напишу отдельный пост по основам).
Однако не все так радужно.
Сразу скажу, что приложение на ASP.NET 3.5, все тесты проходили на Интернет Эксплоэ 8. Некоторые проблемы могут быть связаны именно с этим. Коллеги говорят, что в проекте на ASP.NET MVC (и более современным стеком технологий вообще) подобных проблем не было.
Для каждого управляющего элемента (контрола) есть методы для интеракции с ним, к примеру в выпадающем списке (Combo-box) можно выбрать значение. К сожалению, движок иногда промахивается. Происходит это случайно, где-то в 10% случаев — доставляет много радости, когда происходит в конце 40-минутного теста (о длине тестов чуть позже), и надо повторять весь тест заново.
Решение — повышайте значение параметра Playback.PlaybackSettings.DelayBetweenActions. Это время, которое движок ждет, прежде чем сделать очередное действие. По дефолту он равен 100 мс. Я повысил до 120, что в разы снижает вероятность промаха.
Может случаться в тормозных приложениях. Кидается UITestControlNotFoundException().
Решение — используйте Playback.Wait(n), где n — время в мс. Если пользователь приложения согласен ждать по нескольку секунд на некое действие — столько же должен ждать и тест.
По дефолту, CUITe делает скрин приложения во время ошибки — когда не может найти какой-то элемент или не прошел Assert. Полезность сложно переоценить. Но внезапно все скришоты стали не с местом ошибки, а со стартовой страницей приложения. В гугле нашел единственную тему на msdn [2], где жаловались на подобную проблему. Как видно, «решение» — «так и должно быть, он у вас просто пробегает и прикладывает не тот скриншот». Сомневаюсь, что это было решением проблемы в моем случае, так как в папке, где хранятся все сделанные скрины (LastRun) нужных скринов все равно не нашлось (зато было еще больше скринов первой страницы).
Решение — слава богам, есть событие (event) Playback.PlaybackError, на которое вещаем обработчик с методом UITestControl.Desktop.CaptureImage();
. В итоге получаем что-то типа:
string path = @"C:ErrorScreens";
Image pic = UITestControl.Desktop.CaptureImage();
pic.Save(path + "\" + "myerror__" + DateTime.Now.ToString("HH-mm-ss_ddd") + ".bmp");
В итоге получаем папку ErrorScreens со всеми скринами и с кастомным названием, вместо стандартных расфасованых по папкам со случайным названиям, в которых еще одна папка с именем агента. Плюс, в стандартной реализации, скрины переносятся в папки в одно время, так что сортировка по времени не сработает (надо лезть в LastRun).
Замечены проблемы с нахождением выпадающих списков (Combo-box). Для простых списков (CUITe_HtmlList) так вообще нету метода для выбора элемента.
Решение — использовать элементы из Microsoft.VisualStudio.TestTools.UITesting.HtmlControls, надстройкой над которыми и являются все HTML-элементы с префиком CUITe_. Например, устанавливаем значение в выпадающем списке:
public void SetMyComboBoxValue(string value)
{
HtmlComboBox myComboBox = new HtmlComboBox(this);
myComboBox.SearchProperties[HtmlComboBox.PropertyNames.Id]= "my-element-id";
myComboBox.SelectedItem = value;
}
Отладка теста, который падает на 39-ой минуте, без возможности сразу перейти к проблемному месту — еще то занятие.
Решение — Если тестеры привыкли проверять какие-то части приложения только после 40-минутного ввода данных на разных страницах — пытайтесь найти более быстрый способ. Держите наготове тестовые примеры, которые можно использовать. Автоматические тесты, как и юнит-тесты, должны быть короткими.
CUITe в связке с IE 8 — не самый стабильный вариант. Периодически случаются падения с «Window handle is invalid» или вылеты восьмого осла. Последнее обрушает все последующие тесты.
Решения на данный момент не найдено.
Coded UI и CUITe в частности — не серебрянная пуля. Хотя достоинства Coded UI тестирования очевидны, полностью заменить хорошее ручное тестирование вам не удасться. Конечно, это действительно круто — настроить автоматическое тестирование ночных билдов, чтобы точно знать, что мы вчера сломали. Но если ваше окружение нестабильно — берите в команду специалиста по автоматизации, или готовтесь к тому, что доведение тестов до ума — нетривиальная задача.
Источники:
1. http://blogs.msdn.com/b/mathew_aniyan/archive/2009/08/10/configuring-playback-in-vstt-2010.aspx [3] — список настоек Playback.PlaybackSettings.
Автор: Nordvind
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/testirovanie/12381
Ссылки в тексте:
[1] описание проекта на codeplex: http://cuite.codeplex.com/
[2] единственную тему на msdn: http://social.msdn.microsoft.com/Forums/da-DK/vsautotest/thread/a0db3d69-4951-45d3-b954-9790e01a9ec5
[3] http://blogs.msdn.com/b/mathew_aniyan/archive/2009/08/10/configuring-playback-in-vstt-2010.aspx: http://blogs.msdn.com/b/mathew_aniyan/archive/2009/08/10/configuring-playback-in-vstt-2010.aspx
Нажмите здесь для печати.