Тестирование софта - статьи
       

это основной инструмент при создании


Компиляторы[,,] - это основной инструмент при создании программного обеспечения, поэтому их надежность особенно важна. Наряду с другими методами верификации и валидации для компиляторов, тестирование попрежнему остается важным элементом в семье этих методов. Необходимость автоматизации тестирования компиляторов также представляется очевидной, поскольку реальные объемы добротных наборов тестов и сложность анализа результатов весьма велики. Подход UniTesK [] является методологий построения надежного и качественного ПО на основе использования моделей этого ПО. UniTesK использует модельный подход в следующих целях:
  • для построения критериев правильности реализации ПО,
  • для построения критериев полноты и эффективности проверки качества ПО,
  • для построения входных тестовых данных и процедур анализа результатов целевого ПО.
В узком смысле UniTesK предлагает рассматривать модели как инструмент для построения тестов целевого ПО. При этом процесс разработки теста и собственно тестирования распадается на следующие фазы:
  1. Построение абстрактной модели или спецификации поведения целевой системы.
  2. Извлечение тестового оракула (т.е. процедуры анализа результата целевой системы) из спецификации.
  3. Разбиение пространства входных данных целевой системы на домены,
  4. Проектирование критерия тестового покрытия в терминах абстрактной модели.
  5. Интеграция сгенерированных и вручную написанных компонентов тестовой системы.
  6. Пропуск тестов, включающий
    • анализ результатов целевой системы при помощи оракулов;
    • измерение тестового покрытия в терминах модели/спецификации или в терминах реализации.
Основные достоинства этого подхода состоят в следующем:
  • Спецификации и модели обычно строятся на основе функциональных требований к системе, и часто структура спецификаций следует структуре требований, что позволяет явным образом связать требования к системе с результатами тестирования и метриками тестового покрытия.
  • Спецификации и модели, а значит и тесты, могут разрабатываться до завершения реализации целевой системы, что сокращает общее время разработки ПО.
  • Спецификации и модели обычно компактнее и проще реализации, что упрощает ре-юз и сопровождение как самих моделей, так и тестов, которые строятся на их основе.
  • Достижение исчерпывающего покрытия в соответствии с критериями, определенными на спецификациях и моделях, как правило, обеспечивает уровень покрытия реализации, сравнимый с уровнем, достигаемым при традиционном тестировании, но за счет существенно меньших трудозатрат.
Подход UniTesK прошел апробацию в проектах, свзяаннных с тестированием как действующего, так и вновь создаваемого ПО [,,].
Целевое ПО в этих проектах принадлежало к различным классам систем, предоставляющих процедурный интерфейс:
  • ядра операционных систем,
  • телекоммуникационные протоколы,
  • серверы,
  • run-time поддержка компиляторов и отладчиков.
Следуя общей схеме процесса UniTesK, описанной выше, удалось полностью автоматизировать работы фаз 2, 3, 5, 6. Фаза 1 выполняется вручную, фаза 4 - полуавтоматически. Перенос опыта и инструментов UniTesK на тестирование компиляторов вскрыл ряд проблем. В этой статье мы опишем применение этого подхода к тестированию оптимизирующих модулей в компиляторах. Главная проблема здесь заключается в том, что нет эффективного способа создавать для оптимизатора такие спецификации, из которых можно было бы извлекать эффективные оракулы. Поэтому в предлагаемом подходе мы используем лишь следующие фазы процесса UniTesK:
  1. Построение абстрактной модели входных данных целевой системы.
  2. Проектирование критерия тестового покрытия в терминах абстрактной модели.
  3. Интеграция сгенерированных и вручную написанных компонентов тестовой системы.
  4. Пропуск тестов, включающий
    • анализ результатов целевой системы при помощи оракулов;
    • измерение тестового покрытия в терминах модели/спецификации или в терминах реализации.
В рамках предлагаемого подхода оракул проверяет только сохранение семантики программы во время оптимизации. Для этого в качестве тестовых воздействий на оптимизатор берутся такие программы, семантика которых полностью представляется их трассой. Такое свойство тестов позволяет свести задачу проверки сохранения семантики к сравнению трассы с некоторой эталонной трассой. Итак, суть подхода такова:
  • Построить для тестируемого оптимизатора представительное множество тестовых воздействий следующим образом:
    • построить абстрактную модель входных данных оптимизатора;
    • в терминах абстрактной модели сформулировать критерий покрытия этих входных данных;
    • перебрать соответствующие тестовые воздействия;
  • Протестировать оптимизатор следующим образом:
    • пропустить тесты через компилятор при активированном тестируемом оптимизаторе;
    • вынести вердикт относительно сохранения семантики тестов после оптимизации.
В следующих разделах статьи описываются детали процесса тестирования оптимизаторов в соответствии с предлагаемым подходом.В конце приводятся экспериментальные данные по применению методологии, обсуждаются область применимости и ограничения этого подхода и приводится обзор близких работ. Предварительный вариант настоящей статьи был доложен на международном семинаре ``Понимание программ''[].

Содержание раздела