Практическое применение IBM Rational Functional Tester

Автор работы: Пользователь скрыл имя, 13 Июня 2012 в 07:07, курсовая работа

Краткое описание

Очень часто при разработке программного обеспечения приходится сталкиваться с одной из двух проблем. Либо качество разработанного продукта много ниже самых минимальных разумных требований, либо затраты на тестирование превосходят все разумные пределы. К сожалению, бывает и так, что обе проблемы существуют одновременно. И денег на тестирование истрачено много, а качества достичь так и не удалось.
Увы, для большинства фирм низкое качество выпускаемого ПО — верный путь если не к полному исчезновению фирмы, то, по крайней мере, к потере клиентов и существенным финансовым потерям.
Кому нужно не оттестированное ПО, которое может подвести в любой самый неподходящий момент!
Одной из причин такой ситуации является объективная сложность процесса тестирования ПО. Ведь под словом Тестирование может скрываться множество самых различных действий, направленных на решение множества разнообразных задач. Тут и запуск и исполнение программы с целью проверки отсутствия ошибок, и оценка производительности, и контроль наличия и полноты документации и даже качества принятых проектных решений.
Как же наладить процесс тестирования? Какими инструментами лучше воспользоваться? Какой подход выбрать?
Надеемся, что предлагаемая читателям серия статей поможет им найти ответы на эти и многие другие вопросы.
В частности, мы планируем уделить большое внимание таким вопросам, как роль тестирования в Rational Unified Process и требования ГОСТ к процессу тестирования.
Первая статья представляет собой краткий обзор содержания серии и знакомит читателей с кругом вопросов, которые будут обсуждаться в последующих статьях

Содержание

Введение в процесс тестирования 3
Предисловие к материалу 3
Введение 3
Что такое тестирование 4
Тестируемость 5
Жизненный цикл продукта и Тестирование 5
Типовой цикл тестирования 6
Тестирование и сценарии использования. 8
Типы тестирования 10
Метрики тестирования и качества 10
Стратегия тестирования 10
Типы тестов 11
Приемосдаточные испытания 11
Тестирование производительности 11
Структурное тестирование 12
Тестирование удобства использования 12
Обзор автоматизации тестирования 13
Как работает автоматизированное тестирование глобализованных приложений 16
Воспроизведение 25
Эффективные методы автоматизации тестирования в Rational Functional Tester 28
Способы поиска тестовых объектов 30
Решение проблемы неточного распознавания объектов 31
Динамические точки верификации 37
Улучшение сценариев при помощи вспомогательного суперкласса 40
IBM Rational Functional Tester: Упрощение автоматизации тестирования графического пользовательского интерфейса 42
Список использованной литературы 55

Вложенные файлы: 1 файл

Курсовой IBM Rational Functional Tester.docx

— 1.22 Мб (Скачать файл)

Листинг 1: Использование  метода getProperty

               

if("SUCCESS".equals(dialog_htmlDialogStatic().

getProperty(".text")))

{

dialog_htmlDialogButtonOK().click();

}

else

{

dialog_htmlDialogButtonCancel().click();

}


 

Если  нужно узнать, какими свойствами обладает некоторый объект, можно открыть  карту тестовых объектов Test Object Map и просмотреть перечисленные в ней свойства. (См. рисунок 1.)

Рисунок 1. Свойства в карте тестовых объектов 

Кроме того, можно просмотреть доступные  свойства, записав временную точку  верификации (verification point, VP) свойств объекта или вставив команду для извлечения значения свойства в переменную при помощи мастера VP and Actions.

Примечание:  
Rational Functional Tester также поддерживает метод setProperty. Однако этот метод не дает гарантии результата: Не пользуйтесь им, если не уверены в результате. Причина заключается в том, что метод setProperty вызывает внутренние методы, которые могут нарушить целостность тестируемого приложения.

Теперь, когда вы знаете, как получить свойства объектов, вы можете задать вопрос: "А  как можно найти сам объект?" Хороший вопрос.

Способы поиска тестовых объектов

Основной  компоновочный блок сценария Rational Functional Tester - это постоянно используемый тестовый объект, TestObject .TestObject представляет собой точку соединения между воспроизводимым сценарием и тестируемым приложением. Каждому TestObject в сгенерированном сценарии тестирования соответствует объект в приложении, на базе которого ведется запись сценария, и этот объект теперь присутствует и в карте тестовых объектов Test Object Map.

Скорее  всего, вы обычно взаимодействуете с  тестовыми объектами TestObject с использованием карты объектов. Однако Rational Functional Tester поддерживает также средства для программного поиска TestObject. Поиск ведется по паре имя-значение, определяющей свойства TestObject или TestObjects, которые нужно найти. Поиск может быть глобальным или ограничиваться потомками родительского узла TestObject.

Rational Functional Tester использует объект с именем RootTestObject для глобального представления тестируемого приложения.

  • Если вы хотите выполнить поиск по всему приложению, вызовите поисковый метод для RootTestObject.
  • Если нужно найти конкретный объект, просто вызовите поиск для этого TestObject. Поиск по конкретному TestObject найдет только дочерние объекты этого TestObject

Марк  Новацки (Mark Nowacki) и Лиза Нодвелл (Lisa Nodwell) написали статью о правильном понимании и использовании метода TestObject.find (см. второй листинг в разделе Ресурсы). Я не привожу свои примеры кода, чтобы вы могли познакомиться с кодом, написанным этими авторами. Они проделали большую работу, объяснив и проиллюстрировав теоретические принципы на практических примерах.

Решение проблемы неточного  распознавания объектов

Время от времени Rational Functional Tester не может различить два объекта, которые вели себя похожим образом при воспроизведении сценария. Чаще всего это происходит в том случае, если одновременно открыты два браузера или два экземпляра одного приложения. Если запущены два Web-браузера, то Rational Functional Tester пытается разрешить неоднозначность, используя якорь для определения целевого объекта. Теперь вы знаете, как использовать поисковый метод, и можете идентифицировать экземпляры браузера или приложения при помощи ссылки на TestObject.

Одновременный запуск нескольких экземпляров приложения во время воспроизведения сценария ведет к неоднозначности определения  цели таких команд, как object() или click(). Чтобы разрешить эту неоднозначность, можно воспользоваться ProcessTestObject при вызове команды startApp. В примере из листинга 2 ProcessTestObject действует как якорь, помогающий найти нужное приложение.

 
Листинг 2: Использование  ProcessTestObject для привязки приложения

               

ProcessTestObject pto1 = startApp("ApplicationOne");

ProcessTestObject pto2 = startApp("ApplicationTwo");

object(pto1, DEFAULT).click();


 

Выполняем уборку-удаление регистрации тестовых объектов

Заключительный  аспект использования метода поиска касается удаления регистрации объектов. Метод TestObject.find возвращает новую ссылку на TestObject (которая иногда называется ограниченной ссылкой, поисковой ссылкой или несопоставленной ссылкой). Такие ссылки удерживают доступ к объекту до тех пор, пока вы явно не отмените их регистрацию, а это значит, что они могут вызвать проблемы, если оставить их без внимания.

Rational Functional Tester удаляет регистрацию ограниченных ссылок только после завершения выполнения всего теста, а не одного конкретного сценария. Пока существует ограниченная ссылка на объект, Rational Functional Tester может не допустить полного освобождения объекта в приложении. Например, пока вы сохраняете ограниченную ссылку на Java™-объект, этот Java-объект не считается потерявшим актуальность и подлежащим удалению. Поэтому мы рекомендуем явно удалить регистрацию всех созданных поисковых ссылок сразу после того, как они станут ненужными.

Класс RationalTestScript содержит несколько методов, удаляющих ссылки на тестовые объекты TestObjects:

  • com.rational.test.ft.script;
  • RationalTestScript.unregister;
  • unregisterAll.

Предостережение:  
Если вы работаете с TestObjects напрямую, то использование таких ссылок может вызвать нестабильность работы вашего приложения. Старайтесь не медлить с удалением регистрации тестовых объектов TestObjects.

Способы решения распространенных проблем с браузерами

Ниже  перечислены некоторые распространенные проблемы, с которыми можно встретиться  при тестировании HTML-приложений

Устранение нежелательного поведения при помощи метода .readystate

Если  состояние вашего браузера или объектов в браузере не соответствует ожидаемому, можно столкнуться с нежелательным (странным, непредсказуемым) поведением при попытке взаимодействия с браузером или объектами, особенно если много взаимодействий выполняется не в рамках вспомогательных методов. Именно поэтому проверка состояния готовности readyState Web-браузера или какого-либо из объектов должна стать привычным делом.

 
Значения readyState в Rational Functional Tester

Значение

Состояние

Описание

0

uninitializedObject

Объект не инициализирован  данными

1

loadingObject

Объект в состоянии  загрузки данных

2

loadedObject

Объект завершил загрузку данных

3

interactiveUser

Пользователь может взаимодействовать  с объектом, даже если он загружен не полностью

4

completeObject

Инициализация объекта завершена


 

Если  вы знаете, что предстоит взаимодействие с большой таблицей, деревом (каталогом  файлов) или HTML-документом, стоит проверить  состояние этих объектов (Листинг 3) до начала взаимодействий.

 
Листинг 3. Проверка состояния готовности readyState

               

  while

  (Integer.parseInt(object.getProperty(".readyState").toString())

  < 4)

  {

  sleep(2);

  }


 

Улучшение исполнения теста при помощи метода waitForExistence

Возможно, вы также заметили, что при воспроизведении  сценариев тестирования запуск браузера все еще продолжается в то время, как окно воспроизведения сценария ожидает выполнения первой команды. Такое поведение обуславливается тем, что более современные браузеры работают медленнее, возможно, из-за своих дополнительных элементов, например, вкладок, которые необходимо загрузить именно при запуске. Поэтому при запуске браузера рекомендуется использовать метод waitForExistence. Это можно сделать при помощи точки верификации Wait for Selected TestObject:

  1. В процессе записи сценария запустите приложение;
  2. Нажмите кнопку Insert Verification Point or Action Command на панели инструментов Recording;
  3. На странице выбора объектов Select an Object мастера Verification Point and Action Wizard нажмите левой кнопкой мыши на значке Object Finder и перетащите его на HTML-страницу (не просто в область окна браузера, а именно на страницу);
  4. Нажмите кнопку Next;
  5. На странице выбора действий Select an Action мастера Verification Point and Action Wizard установите флажок Wait for Selected TestObject;
  6. Если нужно, снимите флажок для Use the defaults, чтобы изменить параметры максимального времени ожидания Maximum Wait Time и интервала проверок Check Interval, которые равны соответственно 2 минутам и 2 секундам;
  7. Нажмите кнопку Finish.

Однако  вам, возможно будет проще самостоятельно добавить вызов после команды startApp. Все, что вам придется сделать - это добавить ссылку на тестовый объект BrowserTestObject и вызов метода waitForExistence.

Обработка незапланированных активных окон

С браузерами (и некоторыми Java-приложениями) связана еще одна распространенная проблема - это многочисленные всплывающие окна. Незапланированные активные окна наиболее часто встречаются, когда сценарии выполняются на разных машинах или с различными браузерами, или если браузеры имеют разные настройки.

Впрочем, в справочной системе Rational Functional Tester описаны два эффективных решения (одно простое, другое посложнее). Одно из решений - воспользоваться классической методикой try-and-catch (Листинг 4) и дождаться появления сообщения. Если сообщение не появится, можно продолжать.

 
Листинг 4. Ожидание всплывающего диалогового окна

               

  try

  {

  // Dialog_HtmlDialogButtonOK().waitForExistence(5,1);

  Dialog_HtmlDialogButtonOK().click();

  }

  catch(ObjectNotFoundException e)

  {

  }


 

Совет:  
Если ожидание должно длиться определенное время, можно удалить из кода строку после символа комментария.

Еще одно решение, требующее чуть больше усилий - это реализация простой  проверки, аналогичной проверке из исключения onObjectNotFound. Включив эту реализацию во вспомогательный суперсценарий, можно обрабатывать события для любого сценария Rational Functional Tester, являющегося расширением этого вспомогательного суперкласса (подробнее об этом далее в этой статье).

Подумайте об использовании нетрадиционных точек верификации

Кроме точек верификации, определяемых во время записи, в сценарий тестирования Rational Functional Tester можно включить и дополнительные точки верификации (и не только с помощью команды Insert at Cursor). Включение в сценарий точек верификации вручную и динамически позволяет определить данные для сравнения по объекту, который не включен в карту тестовых объектов.

Точки верификации, добавляемые вручную

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

Объекты добавляемых вручную точек верификации  создаются при помощи метода vpManual, как показано в листинге 5.

 
Листинг 5. Использование  метода vpManual

               

  vpManual

  ("ManualVP_01", "Check something manually.").performTest();

  // или

  vpManual

  ("ManualVP_01", "Check something manually.",

  "Check something manually.").performTest();


 

При первом выполнении точки верификации, добавленной вручную, если объект точки  верификации еще не существует, будет  передано базовое значение (которое  затем можно просмотреть и  изменить в Rational Functional Tester, как и значение любой другой точки верификации). В файле журнала будет написано: Created verification point baseline.

Начиная с этого момента, все последующие  вызовы метода vpManual для этой точки верификации будут сравнивать актуальную точку с базовой. Как видно из листинга 5, метод vpManual можно вызвать, передав ему оба результата - базовый и актуальный. В этом случае объект точки верификации в Rational Functional Tester игнорируется.

Динамические точки  верификации

Иногда  возникает необходимость в выполнении точки верификации в тестовых объектах, не включенных в карту  объектов. С этой целью можно использовать динамические точки верификации  при помощи метода vpDynamic (листинг 6). Динамические точки верификации воспроизводят соответствующий пользовательский интерфейс при следующем прогоне сценария. Можно вставить данные точки верификации, протестированные для объекта, указанного сценарием. В этом случае вам не придется вручную воспроизводить тест до соответствующего состояния, прежде чем вы сможете записать точку верификации.

Если  вы передаете сценарию только имя  точки верификации, то при следующем  воспроизведении этого сценария будет активирован мастер записи точек верификации Recording Verification Point and Action Wizard . С помощью этого мастера можно задать тестовые объекты TestObject и базовые данные для последующих выполнений теста.

 
Листинг 6. Использование  метода vpDynamic

             

  vpDynamic

  ("DynamicVP_01").performTest();

  // или

  vpDynamic

  ("DynamicVP_01", TestObjectHere()).performTest();


 

Предостережение:  
Второй пример из листинга 6 требует передачи сценарию актуального тестового объекта TestObject. Хотя указанный TestObject не включен в карту тестовых объектов, он постоянно должен быть одним и тем же объектом, чтобы результаты имели смысл. Поэтому еще раз повторяю: пользуясь методом TestObjects, будьте внимательны.

Распространенной  ошибкой при использовании этого  метода является неиспользование метода performTest. Это допустимо и выполняется без предупреждений, но при исполнении сценария интересующее нас действие не выполняется.

В начало

Подробно об использовании низкоуровневых команд

Низкоуровневое  воспроизведение эмулирует точные перемещения мыши и манипуляции  с клавиатурой, выполняемые пользователем. Такое воспроизведение сценариев  позволяет более точно управлять  отдельными действиями пользователей, например, в программах для векторного рисования (черчения), эмуляторах PDA и  других нетрадиционных инструментах, учитывающих свойства объектов, которые  совсем не похожи на обычные команды click и input.

Информация о работе Практическое применение IBM Rational Functional Tester