Автор работы: Пользователь скрыл имя, 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: Использование метода getProperty
if("SUCCESS".equals(dialog_ getProperty(".text"))) { dialog_htmlDialogButtonOK(). } else { dialog_htmlDialogButtonCancel( } |
Если нужно узнать, какими свойствами обладает некоторый объект, можно открыть карту тестовых объектов 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 для глобального представления тестируемого приложения.
Марк Новацки (Mark Nowacki) и Лиза Нодвелл (Lisa Nodwell) написали статью о правильном понимании и использовании метода TestObject.find (см. второй листинг в разделе Ресурсы). Я не привожу свои примеры кода, чтобы вы могли познакомиться с кодом, написанным этими авторами. Они проделали большую работу, объяснив и проиллюстрировав теоретические принципы на практических примерах.
Время от времени Rational Functional Tester не может различить два объекта, которые вели себя похожим образом при воспроизведении сценария. Чаще всего это происходит в том случае, если одновременно открыты два браузера или два экземпляра одного приложения. Если запущены два Web-браузера, то Rational Functional Tester пытается разрешить неоднозначность, используя якорь для определения целевого объекта. Теперь вы знаете, как использовать поисковый метод, и можете идентифицировать экземпляры браузера или приложения при помощи ссылки на TestObject.
Одновременный
запуск нескольких экземпляров приложения
во время воспроизведения сценария
ведет к неоднозначности
Листинг 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:
Предостережение:
Если вы работаете с TestObjects напрямую, то
использование таких ссылок может вызвать
нестабильность работы вашего приложения.
Старайтесь не медлить с удалением регистрации
тестовых объектов TestObjects.
Способы решения распространенных проблем с браузерами
Ниже
перечислены некоторые
Устранение нежелательного поведения при помощи метода .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. < 4) { sleep(2); } |
Улучшение исполнения теста при помощи метода waitForExistence
Возможно, вы также заметили, что при воспроизведении сценариев тестирования запуск браузера все еще продолжается в то время, как окно воспроизведения сценария ожидает выполнения первой команды. Такое поведение обуславливается тем, что более современные браузеры работают медленнее, возможно, из-за своих дополнительных элементов, например, вкладок, которые необходимо загрузить именно при запуске. Поэтому при запуске браузера рекомендуется использовать метод waitForExistence. Это можно сделать при помощи точки верификации Wait for Selected TestObject:
Однако вам, возможно будет проще самостоятельно добавить вызов после команды startApp. Все, что вам придется сделать - это добавить ссылку на тестовый объект BrowserTestObject и вызов метода waitForExistence.
Обработка незапланированных активных окон
С браузерами (и некоторыми Java-приложениями) связана еще одна распространенная проблема - это многочисленные всплывающие окна. Незапланированные активные окна наиболее часто встречаются, когда сценарии выполняются на разных машинах или с различными браузерами, или если браузеры имеют разные настройки.
Впрочем, в справочной системе Rational Functional Tester описаны два эффективных решения (одно простое, другое посложнее). Одно из решений - воспользоваться классической методикой try-and-catch (Листинг 4) и дождаться появления сообщения. Если сообщение не появится, можно продолжать.
Листинг 4. Ожидание
всплывающего диалогового окна
try { // Dialog_HtmlDialogButtonOK(). Dialog_HtmlDialogButtonOK(). } catch(ObjectNotFoundException e) { } |
Совет:
Если ожидание должно длиться определенное
время, можно удалить из кода строку после
символа комментария.
Еще одно решение, требующее чуть больше усилий - это реализация простой проверки, аналогичной проверке из исключения onObjectNotFound. Включив эту реализацию во вспомогательный суперсценарий, можно обрабатывать события для любого сценария Rational Functional Tester, являющегося расширением этого вспомогательного суперкласса (подробнее об этом далее в этой статье).
Подумайте об использовании нетрадиционных точек верификации
Кроме точек верификации, определяемых во время записи, в сценарий тестирования Rational Functional Tester можно включить и дополнительные точки верификации (и не только с помощью команды Insert at Cursor). Включение в сценарий точек верификации вручную и динамически позволяет определить данные для сравнения по объекту, который не включен в карту тестовых объектов.
Точки верификации, добавляемые вручную
Добавление
точек верификации вручную
Объекты
добавляемых вручную точек
Листинг 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 игнорируется.
Иногда
возникает необходимость в
Если вы передаете сценарию только имя точки верификации, то при следующем воспроизведении этого сценария будет активирован мастер записи точек верификации Recording Verification Point and Action Wizard . С помощью этого мастера можно задать тестовые объекты TestObject и базовые данные для последующих выполнений теста.
Листинг 6. Использование
метода vpDynamic
vpDynamic ("DynamicVP_01").performTest() // или vpDynamic ("DynamicVP_01", TestObjectHere()).performTest( |
Предостережение:
Второй пример из листинга 6 требует передачи
сценарию актуального тестового объекта TestObject. Хотя указанный TestObject не включен в карту
тестовых объектов, он постоянно должен
быть одним и тем же объектом, чтобы результаты
имели смысл. Поэтому еще раз повторяю:
пользуясь методом TestObjects, будьте внимательны.
Распространенной
ошибкой при использовании
В начало
Подробно об использовании низкоуровневых команд
Низкоуровневое
воспроизведение эмулирует
Информация о работе Практическое применение IBM Rational Functional Tester