Практическое применение IBM Rational Functional Tester
Московский Энергетический Институт
Технический Университет
исследовательский проект
по дисциплине: CASE-технологии разработки программных средств
на тему:
“Практическое применение IBM Rational Functional Tester”
Студент: Чаплинский М.И.
Группа: А–16–07
Преподаватель: Куриленко И. Е.
Москва 2012
Содержание
Оглавление
Содержание 2
Введение в процесс тестирования 3
Предисловие к материалу 3
Введение 3
Что такое тестирование 4
Тестируемость 5
Жизненный цикл продукта и Тестирование 5
Типовой цикл тестирования 6
Тестирование и сценарии использования. 8
Типы тестирования 10
Метрики тестирования и качества 10
Стратегия тестирования 10
Типы тестов 11
Приемосдаточные испытания 11
Тестирование производительности 11
Структурное тестирование 12
Тестирование удобства использования 12
Обзор автоматизации тестирования 13
Как работает автоматизированное тестирование глобализованных приложений 16
Воспроизведение 25
Эффективные методы автоматизации тестирования в Rational Functional Tester 28
Способы поиска тестовых объектов 30
Решение проблемы
неточного распознавания
Динамические точки верификации 37
Улучшение сценариев при помощи вспомогательного суперкласса 40
IBM Rational Functional
Tester: Упрощение автоматизации
Список использованной литературы 55
Введение в процесс тестирования
Предисловие к материалу
Как показывает наша практика построения жизненного цикла разработки ПО и внедрения технологий IBM Rational, в России (последние 1-1,5 года) идет лавинообразный всплеск интереса у разрабатывающих ПО организаций к правильному построению процессов жизненного цикла разработки ПО, и особенно к процессу тестирования.
Руководители и разработчики
начинают понимать важность процесса
тестирования, для повышения качества
программных систем. Становится очевидным,
что чем позже начать тестировать
программную систему, тем выше риски,
тем менее надежной она может
получиться. Нам приятно осознавать,
что тестирование из прикладного
процесса с невысоким приоритетом
переходит в разряд особо важных
процессов, чей жизненный цикл начинается
параллельно с разработкой
Всем, кто хочет поднять свой профессиональный уровень в тестировании, а также всем, кого интересуют технологии IBM Rational, предназначен данный материал.
Представленный Вашему вниманию материал является нашей попыткой объединить все разрозненные материалы по тестированию воедино, а также передать частицу нашего опыта в этой области. Опираясь на методологию IBM Rational и ее программные средства, для поддержки и осуществления процесса тестирования, мы расскажем что, как и когда использовать при тестировании программных систем.
Введение
Очень часто при разработке программного обеспечения приходится сталкиваться с одной из двух проблем. Либо качество разработанного продукта много ниже самых минимальных разумных требований, либо затраты на тестирование превосходят все разумные пределы. К сожалению, бывает и так, что обе проблемы существуют одновременно. И денег на тестирование истрачено много, а качества достичь так и не удалось.
Увы, для большинства фирм низкое качество выпускаемого ПО — верный путь если не к полному исчезновению фирмы, то, по крайней мере, к потере клиентов и существенным финансовым потерям.
Кому нужно не оттестированное ПО, которое может подвести в любой самый неподходящий момент!
Одной из причин такой ситуации является объективная сложность процесса тестирования ПО. Ведь под словом Тестирование может скрываться множество самых различных действий, направленных на решение множества разнообразных задач. Тут и запуск и исполнение программы с целью проверки отсутствия ошибок, и оценка производительности, и контроль наличия и полноты документации и даже качества принятых проектных решений.
Как же наладить процесс тестирования? Какими инструментами лучше воспользоваться? Какой подход выбрать?
Надеемся, что предлагаемая читателям серия статей поможет им найти ответы на эти и многие другие вопросы.
В частности, мы планируем уделить большое внимание таким вопросам, как роль тестирования в Rational Unified Process и требования ГОСТ к процессу тестирования.
Первая статья представляет собой краткий обзор содержания серии и знакомит читателей с кругом вопросов, которые будут обсуждаться в последующих статьях.
Что такое тестирование
Прежде, чем разбираться с деталями, необходимо определить, что же такое тестирование. Даже этот, казалось бы простой вопрос не так прост. Разные источники определяют тестирование его по-разному.
В соответствие с RUP Тестирование — одна из дисциплин RUP. Она ориентирована в первую очередь на оценку качества с помощью следующих методов:
- поиск и документирование дефектов качества;
- общие рекомендации относительно качества;
- проверка выполнения основных предположений и требований на конкретных примерах;
- проверка, что продукт функционирует так, как было запроектировано;
- проверка, что требования выполнены соответствующим образом.
В соответствие с IEEE Std 829-1983 Тестирование — это процесс анализа ПО, направленный на выявление отличий между его реально существующими и требуемыми свойствами (дефект) и на оценку свойств ПО.
По ГОСТ Р ИСО МЭК 12207-99 в жизненном цикле ПО определены среди прочих вспомогательные процессы верификации, аттестации, совместного анализа и аудита. Процесс верификации является процессом определения того, что программные продукты функционируют в полном соответствии с требованиями или условиями, реализованными в предшествующих работах. Данный процесс может включать анализ, проверку и испытание (тестирование). Процесс аттестации является процессом определения полноты соответствия установленных требований, созданной системы или программного продукта их функциональному назначению. Процесс совместного анализа является процессом оценки состояний и, при необходимости, результатов работ (продуктов) по проекту. Процесс аудита является процессом определения соответствия требованиям, планам и условиям договора.
В сумме эти процессы и составляют то, что обычно называют тестированием.
Как не запутаться в этих определениях, на какое из них лучше опираться в ежедневной деятельности — этому будет посвящен следующий выпуск. (следите за обновлениями)
Тестируемость
Далее предполагается рассмотреть
понятие Тестируемости. Почему одни
продукты можно протестировать существенно
быстрее, полнее и надежнее, чем другие?
Какие проектные решения
При выполнении проекта необходимо учитывать, в соответствии с какими стандартами и требованиями будет проводиться тестирование продукта. Какие инструментальные средства будут (если будут) использоваться для поиска и для документирования найденных дефектов. Если помнить о тестировании с самого начала выполнения проекта, тестирование разрабатываемого продукта не доставит неприятных неожиданностей. А значит и качество продукта, скорее всего, будет достаточно высоким.
Жизненный цикл продукта и Тестирование
Все чаще в наше время используются итеративные процессы разработки ПО. Одним из примеров такого подхода является RUP. При использовании такого подхода Тестирование перестает быть процессом «на отшибе», который запускается после того, как программисты написали весь необходимый код. Тестирование оказывается вовлеченным в гущу событий буквально с самого начала работы над проектом. Работа над тестами начинается с самого начального этапа выявления требований к будущему продукту и тесно интегрируется с текущими задачами. И это предъявляет новые требования к тестировщикам. Их роль не сводится просто к выявлению ошибок как можно полнее и как можно раньше. Они должны участвовать в общем процессе выявления и устранения наиболее существенных рисков проекта. Для этого на каждую итерацию определяется цель тестирования и методы ее достижения. А в конце каждой итерации определяется, насколько эта цель достигнута, нужны ли дополнительные испытания, и не нужно ли изменить принципы и инструменты проведения тестов.
В свою очередь, каждый обнаруженный
дефект должен пройти через свой собственный
жизненный цикл. Дефект заносится
в базу дефектов. Аналитик определяет,
не является ли он повтором внесенного
ранее дефекта. Действительно ли
он является дефектом? Руководитель утверждает
исполнителя, который приступает к
устранению дефекта в соответствие
с назначенным дефекту
Типовой цикл тестирования
Тестирование обычно проводится
циклами, каждый из которых имеет
конкретный список задач и целей.
Цикл тестирования может совпадать
с итерацией или
RUP предполагает частую
сборку разрабатываемой
Типовой цикл тестирования приведен на следующем рисунке.
Рисунок 1. Цикл тестирования
Ниже приведены краткие описания задач, входящих в цикл тестирования.
Определить цели тестирования. Включает выбор тестируемых фрагментов и формулирование задач тестирования (например, определить пригодность архитектуры, проверить реализацию основной функциональности конкретного Сценария использования или проверить выполнение требований Заказчика в полном объеме).
Верифицировать метод тестирования. Настройка среды и инструментов тестирования, выполнение отдельных тестов, подтверждение возможности реализовать задачи и цели тестирования.
Подтвердить правильность сборки. Прежде, чем приступить к детальному тестированию выбранной сборки, проводятся ее тесты "на дым". Эти тесты должны показать, что сборка не содержит явных ошибок, делающих ее дальнейшее тестирование просто нецелесообразным. Для "проходных" сборок, в которых не реализован достаточный объем новой функциональности, тестирование может на этом и заканчиваться.
Тестировать и оценивать. Разрабатываются (уточняются) необходимые тесты, после чего тесты выполняются в ручном или автоматическом режиме, и проводится оценка результатов. Достичь приемлемого уровня достижения целей тестирования. Оценивается, с одной стороны, качество и эффективность тестирования, а, с другой стороны, качество тестируемой системы и ее соответствие требованиям, предъявляемым на данном этапе разработки проекта.
Улучшить набор тестов и другие активы для дальнейшего использования. Описать и сохранить тесты, наборы тестовых данных, настройки среды и инструментальных средств, которые можно использовать в последующих тестовых циклах.
Тестирование и сценарии использования.
Выполнение задач жизненного цикла сопровождается разработкой различных артефактов (документов, моделей и других материалов проекта). Как обычно в RUP, разработка артефактов может проводиться в разной форме с разными требованиями к способу выполнения, рецензированию и качеству оформления. Например, вы может посмотреть на описание артефакта и решить, что вам в этом проекте он просто не нужен. Если же он вам необходим, вы можете набросать небольшую схему или несколько предложений на обороте старого документа. Правда, по современным представлениям лучше для этого использовать белую доску и фломастеры. В этом случае проще подключить к работе всех заинтересованных лиц или, по крайней мере, довести результаты до их сведения (прежде, чем их стерли). А можно разработать несколько диаграмм, используя инструменты визуального моделирования. Дополнить их сопроводительным текстом, набранным в мощном текстовом редакторе вроде Word, тщательно отредактированным и отформатированным. А потом все это распечатать и переплести. Но на такое оформление стоит тратить время только тогда, когда вы твердо уверены, что это необходимо. Например, если такое оформление оговорено условиями договора.
Ниже представлены основные
рабочие артефакты
Сценарий тестирования (тест кейс). Это один из основных документов, с которыми имеет дело тестировщик. По сути, упрощенное описание теста. То есть входной информации, условий и последовательности выполнения действий и ожидаемого выходного результата. Учитывая, что даже успешно прошедшие тесты в RUP выполняются неоднократно в ходе регрессионного тестирования, наличие таких описаний необходимо. Однако уровень формальных требований к их оформлению может меняться в очень широких пределах. Одно дело, если вы собираетесь использовать тесты в ходе приемочных испытаний, проводимых Заказчиком, и другое — в ходе внутреннего тестирования коробочного продукта.
Тест скрипт. Обычно говорят о программной реализации теста, хотя скрипт может описывать и ручные действия, необходимые для выполнения конкретного тест кейса.
Набор тестов. Как правило, Сценарии тестирования объединяются в пакеты или наборы. Во-первых, это просто способ группирования тестов со сходными задачами, а, во-вторых, в такой набор можно включать зависимые тесты, которые должны выполняться в определенном порядке (поскольку последующие тесты используют данные, сформированные в ходе выполнения предыдущих).
Список идей тестов. Использование
в RUP для анализа и проектирования
Системы Сценариев
Модель нагрузки. Сценарии использования, как правило, описывают взаимодействие с системой одного пользователя. Часто этого бывает мало. При тестировании систем необходимо учитывать возможность параллельной работы большого числа пользователей, решающих различные задачи. Модель реальной нагрузки описывает характеристики типового «потока заявок», которые должны использоваться для нагрузочного тестирования, имитирующего работу системы в реальных условиях. Также могут быть созданы стрессовые модели нагрузки для тестирования отказоустойчивости системы.
Дефекты. Основополагающие артефакты процесса тестирования – описывают обнаруженные факты несоответствия системы предъявляемым требованиям. Являются одним из подтипов запросов на изменение, описывающих найденную ошибку или несоответствие на всех этапах тестирования. Хотя базу данных дефектов можно вести в текстовом файле или Excel таблице, предпочтительным является использования специализированного инструментального средства, которое позволяет передавать информацию об обнаруженных дефектах от тестировщиков к разарботчикам, а в обратную сторону – сведения об устранении дефектов. А также формировать необходимые отчеты о тенденциях изменения количества обнаруживаемых и устраняемых дефектов.
Типы тестирования
Различие задач тестирования приводит, естественным образом, к необходимости использовать весьма разнообразные типы тестирования. По объему проверяемого ПО или его части различают автономное или модульное, сборочное и системное тестирование.
Важную роль в процессе разработки ПО играет приемосдаточное тестирование. В зависимости от специфики проекта оно может производиться с разной степенью формализма и в различных формах.
Метрики тестирования и качества
Как говорят, тестировать нужно чуть-чуть меньше, чем слишком много. Как найти эту грань? Ведь недостаток тестирования может вести к выпуску продукта с существенными недостатками. А «лишнее» тестирование может стоить достаточно дорого, задерживать выпуск продукта и отвлекать тестировщиков от других работ.
Чтобы принять решение
о прекращении тестирования, чтобы
выбрать оптимальный набор
Стратегия тестирования
Различие задач и целей
тестирования на протяжении жизненного
цикла продукта приводит к необходимости
разрабатывать и реализовывать
различные стратегии
- набор методов и инструментальных средств, необходимых для проведения тестирования и оценки качества;
- критерий успешного завершения тестирования;
- итерации, на которых используются стратегия тестирования и цели тестирования на каждой итерации;
- стадии тестирования для каждой итерации;
- типы используемых тестов;
- критерии оценки тестов.
Типы тестов
Тесты существенно различаются по задачам, которые с их помощью решаются, и по используемой технике. Их можно классифицировать в соответствие с традиционными показателями качества, которые проверяются с их помощью.
Для проверки функциональности ПО используются собственно функциональные тесты, а также тесты безопасности, объема и другие.
Тесты удобства использования (usability) включают тесты на человеческий фактор, эстетику интерфейса и его непротиворечивость, наличие и качество оперативной и контекстной помощи, руководств и учебных материалов. Тестирование надежности ПО производится с помощью интеграционных тестов, тестов структуры и стрессовых тестов и так далее... Различные типы тестов требуют дополнительного рассмотрения.
Приемосдаточные испытания
Приемосдаточные испытания
оформляют процесс передачи продукта
от Разработчика Заказчику. В зависимости
от особенностей продукта и от требований
Заказчика они могут
Тестирование
Тестирование
На последующих стадиях разработки и в процессе сопровождения тесты на производительность разрабатываются и выполняются для:
- оценки соответствия программного обеспечения предъявляемым к нему требованиям производительности, восстанавливаемости после сбоев;
- оценки работоспособности системы в производственных условиях;
- определения оптимальной настройки программно-аппаратного комплекса при различном количестве транзакций, пользователей, объема данных;
- определения сложных ошибок в программном обеспечении, таких как причины неудовлетворительной производительности, проблемы при работе с разделяемыми ресурсами.
Структурное тестирование
Концепция структурного тестирования
связана с тестированием
Тесты структуры Web-сайтов разрабатываются и выполняются для проверки всех типов связей/ссылок.
Тестирование удобства использования
В соответствие с RUP при тестировании удобства использования особое внимание следует уделить тестированию пользовательского интерфейса, то есть учету человеческих факторов. Для оценки пользовательского интерфейса следует привлекать членов проектной команды, экспертов и конечных пользователей.
Рекомендуется предъявлять прототип пользовательского интерфейса конечным пользователям системы как можно раньше.
Обзор автоматизации тестирования
Ручное тестирование является затратным по времени, трудоемким и часто монотонным процессом. Оно приводит к возникновению проблем, особенно при ограниченных ресурсах и жестких сроках. Если вам нужно улучшить тестирование приложений для проверки корректности их работы, важно двигаться в сторону автоматизации всех ручных задач тестирования.
В современных условиях, когда циклы разработки сокращаются, автоматизированное тестирование позволяет как профессионалам, так и новичкам быстро достичь высококачественных результатов тестирования приложений. Инструментальные средства автоматизации записывают взаимодействие пользователей с приложением, а сформированные на этой основе сценарии используются для последующих тестов. В двух словах, автоматизация тестирования позволяет оптимизировать качество сложных приложений эффективным по стоимости способом за приемлемое время. Это помогает быстрее выпустить программное обеспечение более высокого качества.
При использовании IBM Rational Functional Tester в качестве инструментария процесс автоматизации тестирования делится на три этапа:
- Запись. Сценарий тестирования записывается "на лету" по мере работы пользователя с приложением. Можно также вставить точки верификации (verification points) для проверки ответа системы и сделать сценарии тестирования зависящими от данных, чтобы выполнять один и тот же сценарий с различными наборами входных данных.
- Улучшение. Добавление кода, выполняющего разнообразные функции. Типичные изменения сценариев тестирования - условное ветвление, рефакторинг и обработка исключительных ситуаций.
- Воспроизведение. Выполнение сценариев, эмулирующих действия, которые выполнял пользователь приложения при записи теста. Расхождения регистрируются, и тестировщик может сделать вывод о том, хорошо ли функционирует приложение или регрессионное тестирование выявило проблемы.
Типичные проблемы глобализованной автоматизации тестирования
Новые
тенденции в развертывании
Глобализованными называются приложения, в которых все данные (например, сообщения, метки и текст) локализованы, то есть переведены на язык локали, в которой приложения выполняются или из которой запускаются. Например, если приложение запущено в японской локали или операционной системе, вся информация отображается на японском языке. Аналогично, если приложение запущенно во французской локали или операционной системе, вся информация отображается на французском языке и т.д. Термин "глобализованные" относится также к приложениям, которые позволяют вводить и выводить информацию с использованием кодировки символов, отличной от английской.
Даже после успешной автоматизации таких глобализованных приложений вы можете столкнуться со следующими проблемами:
- Автоматизированные сценарии, записанные в одной локали, не воспроизводятся в другой. Это происходит из-за того, что определение объекта, используемое для воспроизведения автоматизированного сценария (например, метка кнопки, с которой должен работать сценарий автоматизации), может быть разным для английской и японской локалей (см. рисунок 1).
- Точки верификации, проверенные в одной локали, не работают в другой. Это происходит из-за того, что ожидаемое или первоначально записанное значение точки верификации не соответствует действительному значению, отображаемому в тестируемом глобализованном приложении, поскольку оно было запущено в другой локали.
- Управляемые данными сценарии тестирования в зависимости от локали, из которой запускается тестируемое приложение, не выбирают и не заполняют набор данных. Это происходит по причине отсутствия встроенной в сценарий автоматизации логики, помогающей определить язык.
Например, на рисунке 1 изображена схема глобализованного приложения, первоначально запускаемого в английской локали для записи сценариев тестирования. Позднее этот же сценарий воспроизводится в японской локали, но он не работает, потому что сообщения тестируемого приложения были записаны на английском. Когда приложение запускается в японской локали, сообщения переводятся в эквивалентный японский текст, что приводит к изменению свойств используемого объекта.
Рисунок 1. Сценарий,
записанный в одной локали и воспроизводимый
в другой, не работает
Проблема:
модель запись/воспроизведение не работает.
Причина: тестируемое
приложение является глобализованным
- Записано в локали 1 (например, English).
- Воспроизведено в локали 2 (например, Japanese).
- Результат: сценарий не работает.
- Причина: определение объекта, используемое для воспроизведения сценария автоматизации, отличается для различных локалей.
Аналогичные проблемы могут возникнуть с точками верификации и сценариями тестирования, управляемыми данными.
Как работает автоматизированное тестирование глобализованных приложений
Глобализованное приложение использует локальный файл ресурсов для отображения сообщений, меток и текста в одном и том же приложении, которое будет запускаться в различных локалях. Рассматриваемый в данной статье подход, основанный на программе IBM Rational Functional Tester, использует локальные файлы ресурсов, которые поставляются вместе с глобализованным приложением. Локальный файл ресурсов один в один отображает значение свойства объекта на переменную, соответствующую этому значению. Это помогает извлечь эквивалентное текстовое значение из файла ресурсов в зависимости от локали, в которой было запущено приложение при воспроизведении.
Если вы планируете глобализовать свой пакет автоматизации тестирования, вам придется работать с этими картами объектов. Карта объектов – это просто набор всех GUI-объектов в тестируемом приложении с соответствующими значениями свойств. Вы должны выбрать значение свойства (например, метку кнопки) и найти соответствующее значение для нее в файле ресурсов (рисунок 2). После замещения значения данной переменной базовый код извлекает значение переменной, соответствующее текущей локали (рисунок 3).
Рисунок 2. Графическое
представление отображения
Рисунок 3. Базовая
утилита, предоставляющая возможность
автоматизированного тестирования глобализованных
приложений
