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

         

Большая сложность используемых сегодня программных


Большая сложность используемых сегодня программных систем и важность решаемых ими задач требуют аккуратной и систематической проверки их корректности в смысле соответствия требованиям и стандартам. Для такой проверки чаще всего используется тестирование — наблюдение за работой системы в ряде специально создаваемых ситуаций и анализ правильности ее работы в каждой такой ситуации с учетом всех существенных аспектов ее поведения.
Большинство имеющихся на сегодняшний день методов тестирования требует серьезных затрат для обеспечения некоторых гарантий адекватности или полноты проводимой проверки. То есть, важно, чтобы оценка корректности системы, вынесенная на основе небольшого количества тестовых экспериментов, была верна и по отношению к ее работе во всех возможных ситуациях, которых для практически важных систем бесконечно много. Обычно для этого проводится классификация ситуаций, которые могут возникнуть при работе системы, и организуются тесты на каждый выделенный вид ситуаций, в ходе которых выполняются все необходимые проверки.
При автоматизации тестирования чаще всего автоматизируется лишь выполнение тестов. Автоматизация их создания связана с необходимостью формализации как критериев правильности работы тестируемой системы, так и правил классификации тестовых ситуаций и техник формирования входных данных как представителей получаемых классов ситуаций. Поскольку для подавляющего большинства систем все эти критерии и правила заданы неформально, такая автоматизация может потребовать существенных дополнительных затрат на их полную формализацию.
В ряде ситуаций такие затраты неоправданны, так как результаты тестирования не должны демонстрировать высокую надежность и полноту проверки выделенных видов тестовых ситуаций. Таково, например, тестирование работоспособности, при котором проверяется только, что основные функции системы выполняются более-менее правильно, т.е. система не разрушается и возвращает результаты, проходящие простейшие проверки на корректность (полная проверка при этом не выполняется).
При тестировании работоспособности библиотек проверяют каждую библиотечную операцию (каждый общедоступный метод каждого класса) на наиболее простом сценарии ее использования, проверяя выполнение базовых ограничений на результат работы. Скажем, при тестировании работоспособности реализации функции 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.

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