Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Диплом_Frozen / пояснительная записка / пояснительная записка.doc
Скачиваний:
36
Добавлен:
16.04.2013
Размер:
4.04 Mб
Скачать

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. План модульного тестирования

Соседние файлы в папке пояснительная записка
  • #
    16.04.2013190.46 Кб23UML-диаграмма system.vsd
  • #
    16.04.2013207.87 Кб24UML-диаграмма VFS (общая).vsd
  • #
    16.04.201399.33 Кб22UseCase всей VFS.vsd
  • #
    16.04.2013106.5 Кб22Входные и выходные данные.vsd
  • #
    16.04.2013112.13 Кб23Общая схема работы модуля.vsd
  • #
  • #
    16.04.2013109.57 Кб22Схема алгоритма get_descriptor.vsd
  • #
    16.04.2013106.5 Кб22Схема алгоритма get_files.vsd
  • #
    16.04.2013100.35 Кб22Схема алгоритма mount.vsd
  • #
    16.04.201396.26 Кб23технологическая - Activity.vsd
  • #
    16.04.201379.87 Кб23технологическая - Class.vsd