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

Разработка VFS, кроме решения архитектурных задач, потребовала работы над задачами прикладными, такими как шифрование, архивирование и работа с ресурсами исполняемых фалов win32.

Средства работы с зип-архивами

В качестве базовой библиотеки для работы с зип-архивами была выбрана open-source разработка zlib. Эта библиотека работает на уровне последовательностей байт и реализует наиболее простые и распространенные алгоритмы deflate и inflate. Средства этой библиотеки были использованы при написании специфических потоков, позволяющих «на лету» архивировать и распаковывать данные.

Шифрация по алгоритму CRC32

Шифрация по алгоритму CRC32 была выполнена самостоятельно, поскольку средства, имевшиеся, например, в zlib, в разумные сроки задействовать не удалось. Алгоритм был реализован по описанию в источнике [16] и снабжен известным набором контрольных сумм.

Тестирование

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

Модульное тестирование

Цели тестирования

Мы не можем протестировать программу во всех аспектах, поскольку число их, в том числе из-за сочетаний аппаратно-программных платформ, стремится к бесконечности. Следовательно, тестирование не может показать отсутствие ошибок в программе — для этого есть доказательство корректности. Тестирование может только показать присутствие ошибок.

Время, затраченное на тестирование, стоит достаточно дорого, и необходимо получить от этих затрат наибольшую отдачу. Ниже приведены «золотые правила» тестирования:

• 1) цель: максимизировать количество и важность обнаруженных дефектов на каждый рубль затрат;
• 2) поэтому: нужно начинать тестирование рано;
• 3) ограниченность: тестирование может установить только наличие дефектов и никогда — их отсутствие;
• 4) для доказательства отсутствия дефектов нужно использовать доказательства корректности.

Рис. 2.9. Типы тестирования

Значение модульного тестирования

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

Типичный план модульного тестирования.

Типичный план, основанный на стандарте IEEE 1008−1987, показан на рис. 2.10. Далее поясняются основные шаги:

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

Рис. 2.10. План модульного тестирования

Типы тестов

«Черный ящик», «серый ящик» и «прозрачный ящик»

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

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

Тестирование «серого ящика» подразумевает нечто среднее между перечисленными методами или их комбинацию.

Разбиение равнозначности для «черного ящика»

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

Анализ граничных требований для «черного ящика»

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

Утверждения и решения для тестирования «прозрачного ящика»

Каждое утверждение в программе должно быть проверено хотя бы одним тестом. Анализ каждого утверждения обязателен. Обзор решений гарантирует, что программа выполняет каждую ветвь алгоритма. То есть, необходимо построить такое множество тестов, чтобы каждое «да» и «нет» блок-схемы можно было получить каким-либо тестом из набора.

Тестирование на основе инвариантов

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

Использование случайных величин

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

Планирование модульных тестов

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

• 1) определить принципы модульного тестирования:
  • а) назначить ответственным разработчика;
  • б) поручить тестирование другим;
  • в) поручить другим и проектирование, и проверку;
• 2) определить, что, где и как документировать:
  • а) индивидуальная документация;
  • б) как и где внедрять в другие типы тестирования;
  • в) внедрять ли в формальные документы;
  • г) использовать ли специальный инструментарий;
• 3) определить объемы заранее:
  • а) не тестировать «пока время не кончится»;
  • б) расставить приоритет тестов;
• 4) определить, где и как получить входные данные;
• 5) оценить необходимые ресурсы:
  • а) по возможности, воспользоваться статистикой;
• 6) организовать учет времени и выполнения задач.

Примеры тестирования

Пример теста метода

• 1) проверить работу при допустимых значениях параметров (метод «черного ящика», основанный на требованиях);
• 2) проверить работу на граничных значениях параметров («черный ящик»);
• 3) проверить работу на значениях вне разрешенного диапазона;
• 4) убедиться, что выполняются все инструкции (рассмотрение утверждений);
• 5) проверить все пути, в том числе ветви каждого узла (рассмотрение решений);
• 6) проверить использование всех вызванных объектов;
• 7) проверить обработку всех структур данных;
• 8) проверить обработку всех файлов;
• 9) проверить нормальное завершение всех циклов (часть доказательства корректности);
• 10) проверить аварийное завершение всех циклов;
• 11) проверить нормальное завершение всех рекурсий;
• 12) проверить аварийное завершение всех рекурсий;
• 13) проверить обработку всех условий ошибок;
• 14) проверить синхронизацию и расчет времени;
• 15) проверить аппаратные зависимости.

Пример теста класса

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

Методы «грубой силы» и их применение при отладке программы

Практически все виды тестов — и модульные, и интегральные, и системные — необязательно проводить в отладчике. Для того, чтобы убедиться в результате выполнения функции, достаточно вставить пару строк кода для вывода необходимой информации куда-либо на экран. При отладке VFS использовались вывод в консольное окно тестового приложения и в окно output MSVS. Для вывода в консоль тестового проекта использовался стандартный потока std: cout, для вывода в окно output студии использовались встроенные функции из библиотеки msvcrt. Для более удобного вызова эти библиотечные функции были обернуты в поток.