2.3. Специализированный инструментарий
Разработка VFS, кроме решения архитектурных задач, потребовала работы над задачами прикладными, такими как шифрование, архивирование и работа с ресурсами исполняемых фаловwin32.
2.3.1. Средства работы с зип-архивами
В качестве базовой библиотеки для работы с зип-архивами была выбрана open-source разработка zlib. Эта библиотека работает на уровне последовательностей байт и реализует наиболее простые и распространенные алгоритмы deflate и inflate. Средства этой библиотеки были использованы при написании специфических потоков, позволяющих «на лету» архивировать и распаковывать данные.
2.3.2. Шифрация по алгоритму CRC32
Шифрация по алгоритму CRC32 была выполнена самостоятельно, поскольку средства, имевшиеся, например, в zlib, в разумные сроки задействовать не удалось. Алгоритм был реализован по описанию в источнике [16] и снабжен известным набором контрольных сумм.
2.4. Тестирование
В связи с потенциальным ущербом от каждой программной ошибки и возрастающей сложностью локализации и исправления ошибок по ходу роста программы раннее и частое тестирование становится важной частью процесса разработки. При тестировании VFS широко применялся метод модульного тестирования, описанный в источнике [6], позволивший избежать большого количества ошибок на этапе тестов функционала, затребованного в ТЗ.
2.4.1. Модульное тестирование
Цели тестирования
Мы не можем протестировать программу во всех аспектах, поскольку число их, в том числе из-за сочетаний аппаратно-программных платформ, стремится к бесконечности. Следовательно, тестирование не может показать отсутствие ошибок в программе – для этого есть доказательство корректности. Тестирование может только показать присутствие ошибок.
Время, затраченное на тестирование, стоит достаточно дорого, и необходимо получить от этих затрат наибольшую отдачу. Ниже приведены «золотые правила» тестирования:
1) цель: максимизировать количество и важность обнаруженных дефектов на каждый рубль затрат;
2) поэтому: нужно начинать тестирование рано;
3) ограниченность: тестирование может установить только наличие дефектов и никогда – их отсутствие;
4) для доказательства отсутствия дефектов нужно использовать доказательства корректности.
Рис. 2.9. Типы тестирования
Значение модульного тестирования
Цель модульного тестирования – проверить структуру. Наименьшими частями программы являются функции (методы). Следующим по величине элементом является модуль (класс), иногда комбинация модулей. Модульное тестирование является дополнением к инспектированию и использованию формальных методов проверки корректности.
Типичный план модульного тестирования.
Типичный план, основанный на стандарте IEEE 1008-1987, показан на рис. 2.10. Далее поясняются основные шаги:
1) входными данными для планирования теста являются требования и детальный проект; выходными – модульный план тестирования;
2) следующий шаг – получение входных и выходных данных, ассоциирующихся с каждым тестом; результатом является набор тестов;
3) исполнение тестов.
Рис. 2.10. План модульного тестирования