Практическое применение 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

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

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

Улучшение сценариев  при помощи вспомогательного суперкласса 40

IBM Rational Functional Tester: Упрощение автоматизации тестирования  графического пользовательского  интерфейса 42

Список использованной литературы 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 выполняются неоднократно в ходе регрессионного тестирования, наличие таких описаний необходимо. Однако уровень формальных требований к их оформлению может меняться в очень широких пределах. Одно дело, если вы собираетесь использовать тесты в ходе приемочных испытаний, проводимых Заказчиком, и другое — в ходе внутреннего тестирования коробочного продукта.

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