Перед тем как начать писать тест кейсы в SilkTest’е, необходимо записать Тестовый фрэйм (Test frame) приложения. Тестовый фрэйм – это скелет приложения, служащий основной для построения и написания тест кейсов. Все элементы окна (страницы) находятся внутри тестовго фрэйма. Тестовый фрэйм является составным файлом проекта, имеет расширение .inc. Этот файл будет содержать описания главного окна приложения, а так же всех дочерних окон и всевозможных dialogBox’ов.
При создании тестового фрэйма приложения создается иерархическая структура определяющая логику, архитектуру и взаимосвязи элементов окна (страницы).
Допустим, ваше приложение выглядит следующим образом (рис 1):
Рис. 1. Пример приложения.
В данном случае мы имеем окно, внутри которого находится панель, текстовое поле, статическое текствовое поле и две кнопки, в свою очередь на панели находится комбобокс и еще одна кнопка. В таком случае, иерархическая структура окна, будет восприниматся SilkTest’ом следующим образом (Рис.2.)
Рис. 2. Иерархическая структура приложения с позиции SilkTest’а
Есть два способа записать тестовый фрэйм приложения.
- С помощью инстурмента записи тесткейсов (Recording.tool)
- С помощью инструмента записи фрэймов (Window declarations tool)
Первый способ хорош, только в двух случаях: когда вы только начнете работать с проектом, и будутете использовать Recording tool для записи своих шагов, автоматически создастся тестовый фрэйм – т.е. вы будете лишены необходимости собственноручно его создавать. Это удобно. Второй случай – когда использование Recording tool оправдывает себя – когда Вы имеете уже сформированое описание окна, но SilkTest отказывается адекватно воспринимать отдельные его элементы, так как вы недавно получили новую версию тестируемого приложения в которой изменились (добавились, удалились, переименовались) какие-либо элекменты. Такое бывает и очень часто. В таком случае очень удобно выбрать Recording tool и просто прокликать все изменившиеся элементы окна, которые в новом билде тестируемого приложения не распознались SilkTest’ом. В таком случае, после сохранения результатов, SilkTest автомматически обновит описание окна в соответствии с последними изменениями. Опять же, это может съэкономить много времени.
Недостаток создания описания окна с помощью рекордера заключается в том, что при его использовании будут распознаны только те элементы, которые непосредственно были задействованы (кликнуты мышью и пр.) во время записи тест кейса.
К примеру, вот структура Microsoft Notepad если используется Recording tool для создавния фрэйма (Рис..3):
Рис.3. Структура окна Microsoft Notepad созданная с помощью Recording tool
Для того, что бы получить такую структуру, мною были произведены следующие действия:
- При открытом NotePad кликнуть:
- Menu – Open.
Что мы и видим из структуры: записано только окно UntitledNotepad, меню File и пункт меню Open.
Использование инструмента Window Declarations позволяет единовременно описать все элементы окна. Чтобы вызвать этот инструмент, необходимо выполнить команду Record –Window Declarations, затем подвести курсор мыши к тестируемому приложению (Notepad), если все сделано правильно, то получиться такой вот результат:
Рис.4. Описание Notepad с помощью Window Declarations
Нажмите Ctrl+Alt что бы выйти из режима Tracking и вставьте полученную структуру в файл с описанием окна. Как видно из рисунка 5, структура Notepad несколько более сложная нежели представленная выше на рисунке 3.
Рис.5. Структура окна Notepad созданная с помощью иснтрумента Window Declarations
Таким образом, мы имеем целиком окно Notepad вместе со всеми вложенными меню и текстовым полем. С такой структурой можно смело приступать к следующему этапу создания автоматизированного тестирования – созданию автоматических тест кейсов.
SilkTest
Комментарии