1.2.7. Методика тестирования

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

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

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 студии.