Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Архитектура ПО на практике.doc
Скачиваний:
3
Добавлен:
01.05.2025
Размер:
63 Мб
Скачать
☆

5.6. Тактики реализации контролепригодности

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

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

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

Отправка в тестируемый программный продукт входных и сбор выходных данных обычно осуществляются специальной тестирующей программой (test harness). Вопросы проектирования и генерации таких программ мы не рассматриваем, хотя во многих системах на это уходит много времени и средств.

Мы намерены обратить ваше внимание на две категории тактик тестирования: тактики подачи входных и сбора выходных данных и тактики внутреннего мониторинга.

Входные/выходные данные

Ниже перечислены тактики контроля входных и выходных данных.

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

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

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

Внутренний мониторинг

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

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

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

Схема тактик контролепригодности приводится на рис. 5.11.