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

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

Список идей тестов. Использование  в RUP для анализа и проектирования Системы Сценариев использования  существенно упрощает задачу разработки необходимого набора тестов. Основной объем тестов строится как проверка различных вариантов выполнения каждого сценария использования. Однако тесты не сводятся к Сценариям  использования, как и задачи тестирования не сводятся только лишь к проверке функциональных требований к системе. Проверка нефункциональных требований может потребовать использования  специальных приемов и подходов. Соответствующие тесты не всегда очевидны. Для таких ситуаций и  создается Список идей тестов. В  него все желающие могут записать Что и/или Как стоит еще проверить. Этот список является внутренним рабочим документом группы тестирования. Наиболее разумная форма его ведения — электронный документ с минимальными формальными требованиями к оформлению.

Модель нагрузки. Сценарии использования, как правило, описывают  взаимодействие с системой одного пользователя. Часто этого бывает мало. При тестировании систем необходимо учитывать возможность  параллельной работы большого числа  пользователей, решающих различные  задачи. Модель реальной нагрузки описывает  характеристики типового «потока заявок», которые должны использоваться для  нагрузочного тестирования, имитирующего работу системы в реальных условиях. Также могут быть созданы стрессовые модели нагрузки для тестирования отказоустойчивости системы.

Дефекты. Основополагающие артефакты процесса тестирования –  описывают обнаруженные факты несоответствия системы предъявляемым требованиям. Являются одним из подтипов запросов на изменение, описывающих найденную ошибку или несоответствие на всех этапах тестирования. Хотя базу данных дефектов можно вести в текстовом файле или Excel таблице, предпочтительным является использования специализированного инструментального средства, которое позволяет передавать информацию об обнаруженных дефектах от тестировщиков к разарботчикам, а в обратную сторону – сведения об устранении дефектов. А также формировать необходимые отчеты о тенденциях изменения количества обнаруживаемых и устраняемых дефектов.

Типы тестирования

Различие задач тестирования приводит, естественным образом, к необходимости  использовать весьма разнообразные  типы тестирования. По объему проверяемого ПО или его части различают автономное или модульное, сборочное и системное тестирование.

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

Метрики тестирования и качества

Как говорят, тестировать  нужно чуть-чуть меньше, чем слишком  много. Как найти эту грань? Ведь недостаток тестирования может вести  к выпуску продукта с существенными  недостатками. А «лишнее» тестирование может стоить достаточно дорого, задерживать  выпуск продукта и отвлекать тестировщиков от других работ.

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

Стратегия тестирования

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

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

Типы тестов

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

Для проверки функциональности ПО используются собственно функциональные тесты, а также тесты безопасности, объема и другие.

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

Приемосдаточные испытания

Приемосдаточные испытания  оформляют процесс передачи продукта от Разработчика Заказчику. В зависимости  от особенностей продукта и от требований Заказчика они могут проводиться  в различной форме. Например, в  виде альфа- или бета-тестирования. Или в виде формальных испытаний, проводимых строго в соответствие с утвержденной программой и методиками.

Тестирование производительности

Тестирование производительности включает оценку временных профилей, времени отклика, операционной надежности и некоторых других. Различные  тесты на производительность разрабатываются  и проводятся на протяжении всего  цикла разработки и во время сопровождения  программного обеспечения. На стадии «Технический проект» (подробнее о стадиях  будет рассказано в следующих  выпусках — следите за обновлениями) разработки, при проектировании, тесты  проводятся для определения и  устранения узких мест в архитектуре  программного обеспечения с точки  зрения производительности.

На последующих стадиях  разработки и в процессе сопровождения  тесты на производительность разрабатываются  и выполняются для:

• оценки соответствия программного обеспечения предъявляемым к нему требованиям производительности, восстанавливаемости после сбоев;
• оценки работоспособности системы в производственных условиях;
• определения оптимальной настройки программно-аппаратного комплекса при различном количестве транзакций, пользователей, объема данных;
• определения сложных ошибок в программном обеспечении, таких как причины неудовлетворительной производительности, проблемы при работе с разделяемыми ресурсами.

Структурное тестирование

Концепция структурного тестирования связана с тестированием внутренней структуры исходного кода программного обеспечения и тестированием  Web-сайтов.

Тесты структуры Web-сайтов разрабатываются и выполняются для проверки всех типов связей/ссылок.

Тестирование удобства использования

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

Рекомендуется предъявлять  прототип пользовательского интерфейса конечным пользователям системы как можно раньше.

 

 

 

 

 

 

 

 

 

Обзор автоматизации  тестирования

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

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

При использовании IBM Rational Functional Tester в качестве инструментария процесс автоматизации тестирования делится на три этапа:

1. Запись. Сценарий тестирования записывается "на лету" по мере работы пользователя с приложением. Можно также вставить точки верификации (verification points) для проверки ответа системы и сделать сценарии тестирования зависящими от данных, чтобы выполнять один и тот же сценарий с различными наборами входных данных.
2. Улучшение. Добавление кода, выполняющего разнообразные функции. Типичные изменения сценариев тестирования - условное ветвление, рефакторинг и обработка исключительных ситуаций.
3. Воспроизведение. Выполнение сценариев, эмулирующих действия, которые выполнял пользователь приложения при записи теста. Расхождения регистрируются, и тестировщик может сделать вывод о том, хорошо ли функционирует приложение или регрессионное тестирование выявило проблемы.

Типичные проблемы глобализованной автоматизации тестирования

Новые тенденции в развертывании программного обеспечения порождают ряд проблем, с которыми сталкиваются инженеры по автоматизации тестирования. В настоящее  время пользователи и организации, разрабатывающие программное обеспечение, рассредоточены географически. Это  означает, что приложения должны быть глобализованы.

Глобализованными называются приложения, в которых все данные (например, сообщения, метки и текст) локализованы, то есть переведены на язык локали, в которой приложения выполняются или из которой запускаются. Например, если приложение запущено в японской локали или операционной системе, вся информация отображается на японском языке. Аналогично, если приложение запущенно во французской локали или операционной системе, вся информация отображается на французском языке и т.д. Термин "глобализованные" относится также к приложениям, которые позволяют вводить и выводить информацию с использованием кодировки символов, отличной от английской.

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

• Автоматизированные сценарии, записанные в одной локали, не воспроизводятся в другой. Это происходит из-за того, что определение объекта, используемое для воспроизведения автоматизированного сценария (например, метка кнопки, с которой должен работать сценарий автоматизации), может быть разным для английской и японской локалей (см. рисунок 1).
• Точки верификации, проверенные в одной локали, не работают в другой. Это происходит из-за того, что ожидаемое или первоначально записанное значение точки верификации не соответствует действительному значению, отображаемому в тестируемом глобализованном приложении, поскольку оно было запущено в другой локали.
• Управляемые данными сценарии тестирования в зависимости от локали, из которой запускается тестируемое приложение, не выбирают и не заполняют набор данных. Это происходит по причине отсутствия встроенной в сценарий автоматизации логики, помогающей определить язык.

Например, на рисунке 1 изображена схема глобализованного приложения, первоначально запускаемого в английской локали для записи сценариев тестирования. Позднее этот же сценарий воспроизводится в японской локали, но он не работает, потому что сообщения тестируемого приложения были записаны на английском. Когда приложение запускается в японской локали, сообщения переводятся в эквивалентный японский текст, что приводит к изменению свойств используемого объекта.

 
Рисунок 1. Сценарий, записанный в одной локали и воспроизводимый в другой, не работает 

Проблема: модель запись/воспроизведение не работает. 
Причина: тестируемое приложение является глобализованным

• Записано в локали 1 (например, English).
• Воспроизведено в локали 2 (например, Japanese).
• Результат: сценарий не работает.
• Причина: определение объекта, используемое для воспроизведения сценария автоматизации, отличается для различных локалей.

Аналогичные проблемы могут возникнуть с точками верификации и сценариями тестирования, управляемыми данными.

Как работает автоматизированное тестирование глобализованных приложений

Глобализованное приложение использует локальный файл ресурсов для отображения сообщений, меток и текста в одном и том же приложении, которое будет запускаться в различных локалях. Рассматриваемый в данной статье подход, основанный на программе IBM Rational Functional Tester, использует локальные файлы ресурсов, которые поставляются вместе с глобализованным приложением. Локальный файл ресурсов один в один отображает значение свойства объекта на переменную, соответствующую этому значению. Это помогает извлечь эквивалентное текстовое значение из файла ресурсов в зависимости от локали, в которой было запущено приложение при воспроизведении.

Если  вы планируете глобализовать свой пакет автоматизации тестирования, вам придется работать с этими картами объектов. Карта объектов – это просто набор всех GUI-объектов в тестируемом приложении с соответствующими значениями свойств. Вы должны выбрать значение свойства (например, метку кнопки) и найти соответствующее значение для нее в файле ресурсов (рисунок 2). После замещения значения данной переменной базовый код извлекает значение переменной, соответствующее текущей локали (рисунок 3).

 
Рисунок 2. Графическое  представление отображения объектов 
 
 
 
Рисунок 3. Базовая утилита, предоставляющая возможность автоматизированного тестирования глобализованных приложений