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

При воспроизведении сценария вместо значения свойства (которое различно для каждой локали) Rational Functional Tester использует переменную, которая одинакова для всех локалей. Поэтому сценарий воспроизводится без помех. Такой подход дает возможность повторно использовать сценарии автоматизации тестирования независимо от измененияю локалей. Он также позволяет сценариям автоматизации выявлять дефекты в глобализованных приложениях, исключая, тем самым, дополнительные затраты труда на ручное тестирование.

Этапы автоматизации тестирования глобализованных приложений

Реализацию  данного подхода начнем с примера  глобализованного приложения JFC-кнопки (Java™ foundation class). Свойства accessibleName и name этой JFC-кнопки локализованы. Это означает, что значение, соответствующее этим свойствам, будет зависеть от локали, в которой запускается приложение.

На  рисунке 4 показано, как скомпоновано и спакетировано глобализованное приложение. В данном случае приложение JFC-кнопки представляет собой исполняемый JAR-файл (Java™ Archive). Это исходный код в виде Java-классов в комбинации с различными локальными файлами ресурсов, которые делают возможным перевод текстов приложения. Таким образом, когда приложение запускается в различных локалях, появляющийся в пользовательском интерфейсе текст читается из соответствующего файла ресурсов для данной локали. Это и делает приложение глобализованным.

 
Рисунок 4. Структура  глобализованного приложения JFC-кнопки  

Запись

Чтобы автоматизировать любое глобализованное приложение, которое записывается только в одной локали и воспроизводится в других (например, Japanese, Chinese или French), выполните следующие действия:

1. Установите переменную Enable Localization в значение True (rational.test.ft.services.enable_localization=true) в файле ivory.properties, который находится в каталоге установки Rational Functional Tester (см. код в листинге 1).

 
Листинг 1. Фрагмент из файла ivory.properties, в котором переменная Enable Localization устанавливается в значение True

### ### Внутренние свойства: не  предназначены для изменений  клиентом ### # Номер версии, применяемый  для плагина enabler.wsw при включении командной # оболочки eclipse rational.test.ft.enabler.plugin.version=7.0.0 # параметры запуска JVM клиента rationsl #rational.test.ft.client.jvm_options=-xj9 # Разрешение данного параметра  позволяет установить каталог  install для локального # TestContext отличным от глобальной настройки # (каталог install первого создаваемого TestContext) rational.test.ft.install_dir.ignore_mismatch=true # Разрешение данного параметра  позволяет запись/воспроизведение  для собственного # UI продукта rational.test.ft.testability.allow_testing=true # Разрешение этого свойства  позволяет искать строку в  локализованной # таблице строк (если  она доступна) rational.test.ft.services.enable_localization=true # Внутреннее. Позволяет подключаться  к проекту .NET для тестирования # интегрированной среды  выполнения #rational.test.ft.testability.allow_vbnet_remote=true

 

На  шаге 2 используются возможности интегрированной  среды IBM® (ранее известной под  названием ITCL) для разработки сценариев  тестирования в Rational Functional Tester. Использование этой интегрированной среды обеспечивает структурный подход к разработке сценариев тестирования, а также дает другие преимущества: уровень абстракции для сценариев автоматизации тестирования путем оформления их в AppObjects, задания (tasks) и уровни контрольных примеров (test case layers); минимальная сложность, повторно используемые обобщенные сценарии тестирования; базовый набор библиотечных файлов, предоставляющих общую функциональность для разработки и распространения сценариев тестирования.

2. С помощью интегрированной среды IBM организуйте сценарии Rational Functional Tester, разработанных для глобализованного приложения JFC-кнопки, в три уровня (показанные на рисунке 5):
• Уровень appObjects: создает класс appJbutton, сохраняющий объекты, с которыми будет взаимодействовать сценарий тестирования.
• Уровень tasks: создает класс taskJbutton, в котором записана реальная логика в виде различных заданий, также называемых функциями.
• Уровень testCases: создает класс testCaseJbutton, в котором различные задания уровня tasks используются для формирования полного сценария тестирования.

 
Рисунок 5. Использование  интегрированной среды IBM для организации  сценариев Rational Functional Tester  

3. Запишите сценарий в любой локали (например, English), используя Rational Functional Tester.
1. Определите все свойства объектов со значениями, различными для различных локалей.
2. Теперь откройте файл определения объектов, известный как карта объектов, в Rational Functional Tester.
3. Выберите свойство объекта, разное для разных локалей. В данном примере приложения отличаются свойства accessibleName и name объекта javax.swing.Jbutton (см. рисунок 6).

 
Рисунок 6. Карта  объектов глобализованного приложения, выбрано свойство объекта с меняющимся значением 

4. Найдите значение свойства объекта в файле ресурсов приложения JFC-кнопки. В данном случае меняющимся значением свойства объекта является текст Remove. Это значение в локали English, а вот эквивалентный текст в других локалях (см. листинги 2 и 3).

 
Листинг 2. Фрагмент из файла ресурсов локали English с парой ключ-значение (значение переменная-свойство)

# NLS_MESSAGEFORMAT_VAR sampleapp.remove = Remove

 
 
Листинг 3. Фрагмент из файла ресурсов локали Japanese с парой ключ-значение (значение переменная-свойство)

# NLS_MESSAGEFORMAT_VAR sampleapp.remove = \u9664\u53bb(E)

 

Улучшение

5. Замените значение в карте объектов Rational Functional Tester соответствующим названием переменной, найденной в файле ресурсов. В данном случае значением свойств accessibleName и name объекта javax.swing.Jbutton был текст Remove. Он заменяется именем переменной sampleapp.remove, поскольку это ключ, соответствующий значению Remove (рисунок 7).

Рисунок 7. Карта  объектов до (со значением свойства) и после (со значением свойства, замененным переменной из файла ресурсов) 

6. Поместите копии всех файлов ресурсов локализованного приложения в каталог resources проекта.
1. Измените имена всех файлов ресурсов так, чтобы они начинались с имени проекта Rational Functional Tester и содержали названия локалей. В данном примере файлы ресурсов переименованы таким образом, чтобы они начинались с BeyondlocaleBarrier (поскольку это имя проекта) и продолжались названиями соответствующих локалей (см. рисунок 8).
2. Таким образом, в нашем примере имя файла для локали Japanese выглядит как BeyondLocaleBarrier_ja.properties. Это гарантирует, что значение, соответствующее переменной, назначенной свойству объекта (см. шаг 5), извлекается сценариями Rational Functional Tester для корректного распознавания объектов во время воспроизведения.

 
Рисунок 8. Файлы  ресурсов локализованного приложения, помещенные в папку ресурсов проекта 

7. Напишите вспомогательную программу National Language Support (NLS) (как показано на рисунке 9), которая:
• Принимает переменную, соответствующую значению свойства объекта.
• Определяет текущую локаль (например, Japanese).
• Ищет файл ресурсов для текущей локали.
• Ищет переменную в файле ресурсов.
• Возвращает локализованное значение:
• Установите его как значение свойства объекта для корректного распознавания с использованием setProperty() API.
• Используйте его для необходимых условных проверок или точек верификации (рисунок 10).

 
Рисунок 9. NLS-программа, написанная для тестирования глобализованного приложения JFC-кнопки  
 
 
 
Рисунок 10. Использование возможностей NLS-программы для реализации условных проверок или точек верификации, гарантирующих соответствие названия кнопки фактической локали 

Воспроизведение

8. Воспроизведите сценарий для различных локалей, например, Japanese, Chinese и French. Сценарий тестирования выполнятся успешно, поскольку он теперь не зависит от локали (см. рисунки 11 и 12).

 
Рисунок 11. Rational Functional Tester воспроизводит сценарий тестирования для приложения, запущенного в локали Japanese, которая отличается от локали, использованной при записи сценария 

Примечание:  
При использовании NLS-программы сценарий тестирования успешно работает в локали Japanese, несмотря на то, что был записан в локали English.

 
Рисунок 12. Журнал регистрации событий при воспроизведении  сценария Rational  

Преимущества подхода

Использование рассмотренного в данной статье подхода  к разработке сценариев автоматизированного  тестирования для глобализованных приложений дает ряд преимуществ. Некоторые из них перечислены ниже:

• Регрессионное тестирование глобализации
• Группы аавтоматизированного тестирования могут использовать преимущества данного подхода для создания инструментов автоматизированного регрессионного тестирования для тестирования глобализованных приложений в пошаговом режиме "сборка за сборкой".
• Записанное один раз работает везде
• Сценарии автоматизации можно разрабатывать в локали English и выполнять в других локалях (Japanese, Chinese, French и т.д.) без каких-либо изменений.
• Разумное использование времени
• Если время работы одного тестировщика по автоматизации тестирования составляло, скажем, X дней, то для девяти локалей оно составит 9*X дней.
• Автоматизация тестирования глобализованных приложений с использованием IBM Rational Functional Tester займет максимум 2*X дней.
• Простота обслуживания
• При изменении текста или метки в тестируемом приложении меняется только один файл ресурсов, а не сценарии автоматизации. Это позволяет обновлять объекты и соответствующие их свойства в одном месте.

 

 

 

 

 

Эффективные методы автоматизации тестирования в Rational Functional Tester

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

В этой статье мы рассмотрим первый шаг, который заключается в понимании того, как эффективно использовать имеющиеся инструменты тестирования. Это шаг можно разделить на несколько тем:

• Объекты и свойства;
• Распространенные проблемы, связанные с браузерами;
• Точки верификации;
• Низкоуровневые команды;
• Вспомогательный суперкласс сценария.

По  каждой из этих тем имеются ссылки на дополнительную информацию, которые  можно найти в разделе Ресурсы в конце этой статьи.

Примечание:  
При написании этой статьи автор использовал следующее программное обеспечение:

• IBM® Rational® Functional Tester версии 7.0.0;
• Microsoft® Internet Explorer® версии 6.0.2900.2180, SP2;
• Операционную систему Microsoft® Windows® XP Professional, SP2;

Альтернативные способы поиска объектов и их свойств

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

Запрос и настройка значений свойств объектов

Возникало ли у вас когда-либо желание динамически  в процессе выполнения программы  сравнить предыдущий вариант значения с текущим значением? А может  быть, вам хотелось добавить в сценарий Rational Functional Tester переход, основанный на текущем значении свойства, содержащегося в каком-либо объекте? Извлечь значение свойства можно программным путем посредством вызова метода getProperty.

В примере  из листинга 1 метод getProperty используется для того, чтобы определить, содержит ли метка сообщение об успешном выполнении. Если содержит, то будет нажата кнопка OK . Если нет, то будет нажата кнопка Cancel .