Методика тестирования. 
Разработка программного модуля "VFS"

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

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

• 1) проведено разбиение равнозначности для диапазона входных значений параметров, на основе логических выкладок;
• 2) определены граничные условия входных параметров;
• 3) проведен поиск утверждений и составлен набор входных значений, проверяющий утверждение;
• 4) проведен анализ алгоритма и составлены наборы входных значений, позволяющие «пройти» по каждой ветке алгоритма.

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

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

Модульные тесты были спланированы заранее с помощью предлагаемых методикой модульного тестирования шаблонов:

• 1) поскольку людские ресурсы были сильно ограничены, тестирование выполнялось разработчиком модуля;
• 2) документирование тестов проводилось в индивидуальном неформализованном порядке без применения автоматических средств и не включалось в официальную отчетность по работам;
• 3) приоритеты, как сказано выше, были отданы операциям с контейнерами и динамической памятью в срезе наиболее частых сценариев использования классов;
• 4) для получения входных данных была организована модельная среда с различными хранилищами по образу системы предыдущего проекта, и её данные использовались в зависимости от тестируемых частей модуля;
• 5) время для тестирования было выделено из расчета примерно половины времени разработки;
• 6) в качестве системы учета времени и баг-трекера использовались сначала Microsoft Outlook, потом Sirid.

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

Формально в рамках тестирования системы были проведены следующие проверки.

• 1) Общий интерфейс VFS:
  • а) Открытие файла на чтение и предоставление входного потока на него стандартной библиотеки С++, согласно относительной системе именования, принятой в структуре данных проекта.
  • б) Открытие файла на запись или его создание с предоставлением исходящего потока стандартной библиотеки С++, согласно той же системе именования.
  • в) Перебор файлов внутри директории безотносительно типу файлового хранилища.
• 2) Ядро VFS:
  • а) Создание системы виртуальных директорий, размещение подсистем в случайном порядке, проверка корректного их перебора.
  • б) Монтирование/демонтирование подсистем различных типов в директории.
  • в) Проверка механизма «сборки мусора» .
• 3) Особенности:
  • а) Проверка на возможность существования нескольких файлов с одинаковым именем в рамках всей VFS.
  • б) Проверка работы критериев сортировки и выбора предпочтительных вариантов файлов.
• 4) Специализированные модули:
  • а) Проверка корректности работы шифрования/дешифрования средствами разработанной библиотеки ml_encrypted_zip при заведомо внедренных ошибках шифрации.
• 5) Надежность:
  • а) Проверка на недопустимые имена файлов.
  • б) Проверка на отсутствие запрашиваемых файлов.
  • в) Проверка на ошибки физического доступа к подсистемам.

Интегральные тесты не проводились, поскольку в них не было необходимости.

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

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

Результаты экспериментальной проверки

Результаты тестирования показали:

• 1) Модуль полностью удовлетворяет функциональным требованиям, перечисленным в ТЗ.
• 2) Некорректного поведения или аварийного завершения работы модуля не удалось добиться ни некорректными действиями пользовательского кода, ни ошибками доступа к хранилищам.
• 3) Модуль защищен от ошибок, связанных с многопоточной средой выполнения.
• 4) Утечек памяти зафиксировано не было, механизм «сборки мусора» функционирует должным образом.