- •Раздел 1. Специальный раздел
- •1.1. Исследовательская часть
- •1.1.1. Постановка задачи
- •1.1.2. Предварительные нир
- •1.3. Информационные потребности пользователя
- •1.1.4. Требования, предъявляемые системе
- •1.2. Конструкторская часть
- •1.2.1. Структура входных и выходных данных
- •1.2.2. Общая схема работы модуля
- •1.2.3. Выбор платформы проектирования и его обоснование
- •1.2.4. Проектирование архитектуры модуля
- •1.2.5. Конфигурация технических средств
- •1.2.6. Алгоритмы работы модуля
- •1.2.7. Методика тестирования
- •1.2.8. Результаты экспериментальной проверки
- •2.1. Проектирование на языке uml
- •2.1.1. Концепция Unified Modeling Language
- •2.1.2. Виды диаграмм uml
- •2.1.3. Связь с объектно-ориентированными языками
- •2.2. Идеология stl в применении к архитектуре модуля
- •2.2.2. Контейнеры stl
- •2.2.3. Алгоритмы stl
- •2.2.4. Потоки
- •2.4.1. Умные указатели
- •2.3. Специализированный инструментарий
- •2.4.2. Типы тестов
- •2.4.3. Планирование модульных тестов
- •2.4.4. Примеры тестирования
- •2.4.5. Методы “грубой силы” и их применение при отладке программы
- •3.1. Цели определения себестоимости и цены модуля
- •3.2. Методы определения себестоимости
- •3.3. Расчет себестоимости vfs
- •3.4. Методы расчета цены
- •3.4.1. Расчет цены по стоимости изготовления
- •3.4.2. Расчет цены на основе роялти
- •3.4.3. Расчет цены на тиражируемый продукт
- •3.5. Расчет цены vfs
- •3.6. Выводы
- •4.2.1. Психофизиологические факторы
- •4.2.2. Электромагнитные излучения
- •4.2.3. Освещение рабочего места
- •4.2.4 Электробезопасность
- •4.2.5 Микроклимат
- •4.2.6. Зашумленность
- •4.3. Инженерный расчет освещенности машинного зала
- •4.4. Экологическая безопасность
- •4.5. Пожарная безопасность
- •4.6. Выводы
- •Список литературы
1.2.7. Методика тестирования
Во время реализации модуля широко применялся подход так называемого модульного тестирования, при котором формальному тестированию подвергается каждый модуль и класс в целом.
Согласно методике модульного тестирования, для каждого метода был выполнен следующий анализ:
1) проведено разбиение равнозначности для диапазона входных значений параметров, на основе логических выкладок;
2) определены граничные условия входных параметров;
3) проведен поиск утверждений и составлен набор входных значений, проверяющий утверждение;
4) проведен анализ алгоритма и составлены наборы входных значений, позволяющие «пройти» по каждой ветке алгоритма.
При тестировании выбор значений из диапазонов равнозначности производился с помощью генератора псевдослучайных последовательностей.
Каждый класс после реализации подвергался тестированию на основе переходов по состояниям (там, где такие можно было вычленить) и на основе инвариантов внешних данных. При этом прежде всего тестировались связки методов, работающих с внутренними контейнерами и динамической памятью, как потенциально наиболее подверженные ошибкам. В целом, тестирование классов проводилось по сходной с тестированием методов методике, с той особенностью, что проверяемый алгоритм был более высокого уровня и реализовывался уже не в методе, а во внешнем коде, в роли которого и выступало тестовое приложение.
Модульные тесты были спланированы заранее с помощью предлагаемых методикой модульного тестирования шаблонов:
1) поскольку людские ресурсы были сильно ограничены, тестирование выполнялось разработчиком модуля;
2) документирование тестов проводилось в индивидуальном неформализованном порядке без применения автоматических средств и не включалось в официальную отчетность по работам;
3) приоритеты, как сказано выше, были отданы операциям с контейнерами и динамической памятью в срезе наиболее частых сценариев использования классов;
4) для получения входных данных была организована модельная среда с различными хранилищами по образу системы предыдущего проекта, и её данные использовались в зависимости от тестируемых частей модуля;
5) время для тестирования было выделено из расчета примерно половины времени разработки;
6) в качестве системы учета времени и баг-трекера использовались сначала Microsoft Outlook, потом Sirid.
Высокоуровневое тестирование проводилось при помощи полного воссоздания среды работы VFS, то есть окружения, в котором работает модуль. Поэтому для тестирования был собран каркас приложения, к нему был подключен модуль (так же, как и планировалось подключать к проектам – статически присоединенной dll), и было проверен каждый прецедент использования в соответствии с предоставленным программным интерфейсом. Для проверки работоспособности в многопоточной среде запускалось большое количество потоков, одновременно выполняющих различные комбинации действий. Каждое действие выполнялось как в указанных в требованиях условиях, так и с нарушениями – проверялась передача заведомо неверных параметров, специально организовывались ошибки доступа к данным в хранилищах. Проводился контроль утечек памяти.
Формально в рамках тестирования системы были проведены следующие проверки.
1) Общий интерфейс VFS:
а) Открытие файла на чтение и предоставление входного потока на него стандартной библиотеки С++, согласно относительной системе именования, принятой в структуре данных проекта.
б) Открытие файла на запись или его создание с предоставлением исходящего потока стандартной библиотеки С++, согласно той же системе именования.
в) Перебор файлов внутри директории безотносительно типу файлового хранилища.
Ядро VFS:
а) Создание системы виртуальных директорий, размещение подсистем в случайном порядке, проверка корректного их перебора.
б) Монтирование/демонтирование подсистем различных типов в директории.
в) Проверка механизма "сборки мусора".
3) Особенности:
а) Проверка на возможность существования нескольких файлов с одинаковым именем в рамках всей VFS.
б) Проверка работы критериев сортировки и выбора предпочтительных вариантов файлов.
4) Специализированные модули:
а) Проверка корректности работы шифрования/дешифрования средствами разработанной библиотеки ml_encrypted_zip при заведомо внедренных ошибках шифрации.
Надежность:
а) Проверка на недопустимые имена файлов.
б) Проверка на отсутствие запрашиваемых файлов.
в) Проверка на ошибки физического доступа к подсистемам.
Интегральные тесты не проводились, поскольку в них не было необходимости.
Системные тесты были выполнены в ограниченном объеме, поскольку в команде системным тестированием специально занимались отдельные люди. Из системных были выполнены тесты на использование ресурсов компьютера, на надежность (с вычислением средней наработки на отказ) и стресс-тесты.
Тестирование проводилось как при помощи встроенного отладчика Visual Studio, так и при помощи методов «грубой силы», заключавшихся в выводе интересующей информации на консоль окна тестового приложения или в окно output студии.