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

В соответствии с ограничениями, налагаемыми средой тестирования, определите требования.

Полезно также исследовать группу Интерфейсы системы, особенно те, которые относятся к субъектам, внешним по отношению к границам системы. С помощью Моделей проекта и реализации найдите элементы, имеющие стереотип <<interface>>. Также рассмотрите модели на предмет наличия классов стереотипа <<boundary>>.

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

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

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

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

Подразделы:

• Создание общих сценариев тестов
• Создание взаимозависимости тестовых данных
• Создание взаимозависимости состояний тестов
• Создание производных значений тестовых данных
• Создание общих путей навигации теста

Создание общих сценариев тестов

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

Создание взаимозависимости тестовых данных

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

Создание взаимозависимости состояний тестов

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

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

Создание производных значений тестовых данных

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

Создание общих путей навигации теста

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

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

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

Подразделы:

• Определение интерфейсов теста
• Определение встроенных функций теста
• Определение ограничений проекта теста

Определение интерфейсов теста

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

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

Определение встроенных функций теста

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

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

Определение ограничений проекта теста

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

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

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

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

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

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

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

• Фиктивные заглушки и драйвера, которые не имеют другой функциональности, кроме предоставления заданного значения (или значений) или в качестве входа, или в качестве возврата.
• Более развитые заглушки и драйвера, которые могут имитировать некоторое поведение.

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

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

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

Помните, что вы определяете компоненты реализации инфраструктуры. Главная цель - это определить различные части решения, которое ее реализует.

Подразделы:

• Элементы автоматического тестирования
• Элементы тестирования вручную

Элементы автоматического тестирования

Ключевыми требованиями или компонентами инфраструктуры автоматического тестирования являются:

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

Запишите свои решения в виде определений в разделах реализации Архитектуры автоматического тестирования, в указании к процессу одной или нескольких Рекомендаций по тестированию или в Сценариях тестирования, Наборах тестов или вспомогательных процедурах тестовой библиотеки. Более подробная информация находится в разделе Рабочий продукт: Архитектура автоматического тестирования.

Элементы тестирования вручную

Ключевыми требованиями или компонентами инфраструктуры тестирования вручную являются:

• Хранилище тестовых данных: общее хранилище для определения тестовых данных.
• Восстановление: метод восстановления известного состояния конфигурации среды тестирования.
• Необходимость отделить целевые элементы теста от остальной разрабатываемой системы.

Запишите свои решения в виде указаний к процессу в одном или нескольких Рабочий продукт: Рекомендации, относящиеся к проекту.

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

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

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