Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

26.03.2017

Google
WWW CITForum.ru
С Новым годом!
2008 г.

Технология Azov автоматизации массового создания тестов работоспособности

Р. С. Зыбин, В. В. Кулямин, А. В. Пономаренко, В. В. Рубанов, Е. С. Чернов
Труды Института системного программирования РАН

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

Содержание

1. Введение
2. Технология автоматизации создания тестов работоспособности
2.1. Исходные данные и ожидаемые результаты
2.2. Организация работ по технологии Azov
2.3. Методическая основа технологии
2.4. Пример построения тестов по технологии Azov
2.5. Инструментальная поддержка
3. Использование предложенной технологии на практике
4. Сопоставление с другими подходами к автоматизации создания тестов
5. Дальнейшее развитие технологии
6. Заключение
Литература

1. Введение

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

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

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

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

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

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

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

Такая оценка в общем случае верна, но иногда возникают дополнительные факторы, позволяющие по-новому взглянуть на возможность и необходимость автоматизации тестирования работоспособности. Первый такой фактор — размер и сложность тестируемой системы, определяемые на основании общего количества интерфейсных операций и сложности реализуемых ими функций. Если операций очень много, разработка тестов для них всех вручную становится слишком трудоемкой. Например, в стандарте POSIX 2004 года описано 1123 функции [1], многие из которых решают весьма сложные задачи, а в библиотеке Qt для разработки приложений с графическим интерфейсом пользователя [2], входящей в стандарт Linux Standard Base [3], насчитывается около 10000 общедоступных методов классов и глобальных функций.

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

Оба этих фактора — большой размер и наличие базы данных с информацией об интерфейсных операциях — имеются у стандарта Linux Standard Base [3] (LSB), включающего несколько отдельных стандартов (POSIX [1], ISO C [4], Filesystem Hierarchy Standard [5] и пр.) и библиотек (Xlib [6], OpenGL [7], GTK+ [8], Qt [2]). В целом в LSB версии 3.1 входит более 30000 функций и методов. Для автоматизации работ по поддержке в актуальном состоянии текста стандарта и набора инструментов для выполнения различных проверок синтаксическая информация обо всех входящих в стандарт интерфейсах помещена в единую базу данных. Это позволило использовать новый подход для автоматизации создания тестов работоспособности для LSB.

2. Технология автоматизации создания тестов работоспособности

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

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

Технология Azov включает следующие элементы.

  • Методика уточнения данных об интерфейсных операциях.

  • База данных с расширенной информацией о тестируемых операциях.

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

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

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

2.1. Исходные данные и ожидаемые результаты

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

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

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

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

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

2.2. Организация работ по технологии Azov

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

Разработка тестов в рамках технологии Azov организована следующим образом.

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

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


Рисунок 1. Схема выполнения работ по технологии Azov.

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

  • Генерация тестов.
    Итоговый набор тестов работоспособности генерируется при помощи компоновщика тестов на основе информации из пополненной базы данных.

  • Выполнение тестов.
    Сгенерированный набор тестов может представлять собой одну программу или набор программ на языке C или С++. В последнем случае они выполняются в пакетном режиме.

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

Оглавление Вперёд

Размещение рекламы — тел. +7 495 4119920, ICQ 232284597

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

  • Проблемы экономики производства крупных программных продуктов

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

  • Клермонтский отчет об исследованиях в области баз данных

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 4119920, ICQ 232284597 Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2007 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...