'

Основные принципы построения автоматического теста при помощи QTP

Понравилась презентация – покажи это...





Слайд 0

Основные принципы построения автоматического теста при помощи QTP


Слайд 1

Введение Целью данного документа является изложение подхода к автоматизации тестирования с использованием QTP, а также некоторых хороших практик построения тестов. Данный подход не претендует на какую-то уникальность или на какую-то особенную эффективность и удобство реализации равно как и на истину в последней инстанции. Это один из способов организации тестов для приложений сложнее калькулятора или блокнота. Преимуществами данного подхода являются гибкость и относительная универсальность (независимость от типа тестируемого приложения).


Слайд 2

Структура теста Структурно тест состоит из следующих компонентов: Suite file – excel файлы, содержащий ссылки на файлы с тестовыми сценариями Test script file – excel файлы, содержащие описание тестовых сценариев Test driver – модуль, отвечающий за взаимодействие с внешними файлами, содержащими тестовые данные, вызов необходимых test actions и подготовку данных для отчета о тестировании Test actions – модули, реализующие взаимодействие с AUT. Reporter – модуль реализующий формирование отчета о тестировании Test report – отчет о тестировании


Слайд 3

Взаимосвязь компонентов Взаимосвязь компонентов отражена на рисунке


Слайд 4

Компоненты теста: Описание Данный файл предназначен для группировки тестовых сценариев по каким-либо признакам. Он определяет последовательность исполнения тестов и является входной точкой для автоматического скрипта. Место расположения файла - TestData\<file name> на одном уровне с папкой автоматического теста. Порядок следования колонок в файле не регламентируется Suite file


Слайд 5

Структура Suite файла:


Слайд 6

Test script file Данные файлы содержат последовательность вызова test actions и данные для них. Кроме перечисленных в таблице колонок в файле могут содержаться любые другие колонки, в зависимости от параметров вызываемых действий.


Слайд 7

Структура Test script файла:


Слайд 8

Test driver file Данный модуль реализуется в виде Action. Он является единственным action в test flow qtp. Все остальные действия вызываются из данного action. Входными данными для данного action является имя Suite file. Модуль считывает данные из test script file, формирует объект Dictionary с параметрами и организует последовательный вызов действий, описанных в Test script file, и передает результаты вызовов в reporter для генерации отчета о тестировании. Передача данных в actions организуется через параметр “data” объекта Environment.


Слайд 9

Алгоритм работы:


Слайд 10

Test actions Данные модули реализуются в виде Action qtp и обеспечивают выполнение тестовых действий. Данные передаются в action через параметр data объекта Environment. Отдельный test action реализует законченный шаг теста (открыть форму, создать элемент, проверить элемент). Каждый test actionв начале работы должен проверить состояние UI и привести его к исходному для данного test action (например, открыть необходимую форму, если она не открыта). На выходе каждый test action должен сгенерировать объект Dictionary. Каждый test action должен заканчиваться инструкцией ExitAction Test Actions должны взаимодействовать с AUT посредствам объектов в Object Repository(OR). Допускается обращение к UI c использование descriptive programming, но предпочтение должно отдаваться использованию OR.


Слайд 11

Элементы объекта Dictionary


Слайд 12

Хорошие практики проектирования тестовых действий (test actions)


Слайд 13

Атомарность Тестовое дейсnвие должно проектироваться таким образом, чтобы по возможности выполнять атомарное действие (т.е. если есть возможность разделить код на два тестовых действия - лучше делить). При этом под действием понимается не клик мышкой по объекту, а законченное действие с т.з. бизнес-процесса (например: создание заказа, проверка данных заказа, отмена заказа).


Слайд 14

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


Слайд 15

Формирование результата При выводе результата проверки в отчет необходимо ограничиваться не только констатацией (pass/fail) но и выводить ожидаемый и фактический результат.


Слайд 16

Описание объектов UI При описании объектов UI в OR необходимо придерживаться следующих принципов: Если можно обойтись без использования Smart Identification, то лучше обходиться без него. Если можно сгруппировать объекты внутри иерархии (По умолчанию QTP записывает все объекты страницы плоским списком), то лучше группировать. Если есть элементы, повторяющиеся на всех (или большинстве) страницах, то лучше вынести такие объекты на generic страницу.


Слайд 17

Работа со сложными объектами UI Для работы со сложными объектами UI (таблицы, меню, комбобоксы) желательно создавать отдельные классы (в отдельной functional library) и всю внутреннюю логику работы реализовывать именно там.


Слайд 18

Стабильность теста При разработке авто теста следует помнить, что авто тест – это программа предназначенная для тестирования другой программы (AUT). Т.е. при разработке авто теста следует учитывать вероятность ошибок в AUT. Это означает, что при выполнении авто тест должен быть стабильнее AUT и «падать» он должен только в крайнем случае (желательно перед этим записав причину в отчет).


Слайд 19

Список полезной литературы VB Script: http://www.w3schools.com/Vbscript/default.asp http://www.askit.ru/custom/progr_admin/progr_admin_plan.htm (c п.2 по п.4) VB Script Reference из хелпа по QTP QTP: Quick Test Professional Tutorial QuickTest User’s Guide Для ознакомления с DOM структурой http://www.w3.org/DOM/ http://msdn.microsoft.com/en-us/library/ms764730(VS.85).aspx


Слайд 20

Ваши вопросы


×

HTML:





Ссылка: