Сразу оговорюсь — я не являюсь профессиональным инженером по автоматизации тестирования. Однако, поскольку на данный момент так вышло, что это мое основное занятие по работе — буду особенно рад комментариям от людей со специализацией в этой области.
В статье — краткое описание CUITe для тех, кто не сталкивался, использование этого фреймворка для тестирования приложения с фронт-эндом на ASP.NET и проблемы, с которыми столкнулись.
Что есть CUITe
Как говорит описание проекта на codeplex, это тонкая надстройка над 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, где жаловались на подобную проблему. Как видно, «решение» — «так и должно быть, он у вас просто пробегает и прикладывает не тот скриншот». Сомневаюсь, что это было решением проблемы в моем случае, так как в папке, где хранятся все сделанные скрины (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 — список настоек Playback.PlaybackSettings.
Автор: Nordvind
