- •Раздел 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. Выводы
- •Список литературы
2.4.2. Типы тестов
«Черный ящик», «серый ящик» и «прозрачный ящик»
Тестированием «черного ящика» называется процесс, когда проверяется исключительно соответствие и правильность выходных и выходных данных. Такие тесты могут быть эффективными, если мы можем убедиться, что они охватывают весь диапазон возможных проверок такого рода.
Целью тестирования «прозрачного ящика» является нахождение наиболее ненадежных путей программы. Для этого программа подвергается декомпозиции до получения путей управления и данных.
Тестирование «серого ящика» подразумевает нечто среднее между перечисленными методами или их комбинацию.
Разбиение равнозначности для «черного ящика»
Разбиение равнозначности – это разбиение множества входных данных на подмножества так, чтобы успешное прохождение теста с одним значением гарантировало успешное прохождение с любым другим значением из подмножества.
Анализ граничных требований для «черного ящика»
Граничные условия появляются после разбиения значений параметров по равнозначности. Они так же являются диапазонами, требующими проверки, и условно могут считаться равнозначными.
Утверждения и решения для тестирования «прозрачного ящика»
Каждое утверждение в программе должно быть проверено хотя бы одним тестом. Анализ каждого утверждения обязателен. Обзор решений гарантирует, что программа выполняет каждую ветвь алгоритма. То есть, необходимо построить такое множество тестов, чтобы каждое «да» и «нет» блок-схемы можно было получить каким-либо тестом из набора.
Тестирование на основе инвариантов
Инварианты – это утверждения, связывающие переменные. Это своего рода выражение состояний, которое можно использовать как ограничение множества значений параметров. Это значит, что в некоторых случаях мы можем положить, что некоторые сочетания значений переменных не встретятся в программе никогда.
Использование случайных величин
После того, как выполнены разбиение равнозначности и анализ граничных требований, во избежание предвзятости, наиболее правильным для генерации значения из диапазона будет запустить генератор случайных чисел.
2.4.3. Планирование модульных тестов
Систематический подход к тестированию необходим, поскольку число модулей, нуждающихся в тестировании, может быть очень велико. Один из способов спланировать модульное тестирование:
1) определить принципы модульного тестирования:
а) назначить ответственным разработчика;
б) поручить тестирование другим;
в) поручить другим и проектирование, и проверку;
определить, что, где и как документировать:
а) индивидуальная документация;
б) как и где внедрять в другие типы тестирования;
в) внедрять ли в формальные документы;
г) использовать ли специальный инструментарий;
3) определить объемы заранее:
а) не тестировать «пока время не кончится»;
б) расставить приоритет тестов;
4) определить, где и как получить входные данные;
оценить необходимые ресурсы:
а) по возможности, воспользоваться статистикой;
6) организовать учет времени и выполнения задач.
2.4.4. Примеры тестирования
Пример теста метода
1) проверить работу при допустимых значениях параметров (метод «черного ящика», основанный на требованиях);
2) проверить работу на граничных значениях параметров («черный ящик»);
3) проверить работу на значениях вне разрешенного диапазона;
4) убедиться, что выполняются все инструкции (рассмотрение утверждений);
5) проверить все пути, в том числе ветви каждого узла (рассмотрение решений);
6) проверить использование всех вызванных объектов;
7) проверить обработку всех структур данных;
8) проверить обработку всех файлов;
9) проверить нормальное завершение всех циклов (часть доказательства корректности);
10) проверить аварийное завершение всех циклов;
11) проверить нормальное завершение всех рекурсий;
12) проверить аварийное завершение всех рекурсий;
13) проверить обработку всех условий ошибок;
14) проверить синхронизацию и расчет времени;
15) проверить аппаратные зависимости.
Пример теста класса
1) испытывать комбинации методов:
а) обычно 2-5;
б) сначала выбрать наиболее общие последовательности;
в) учесть последовательности, заведомо приводящие к ошибке;
г) попытаться вручную подсчитать значения результатов;
фокусировать модульные тесты на каждом атрибуте:
а) инициализировать его, а потом запускать последовательности методов, изменяющих его;
3) проверять, что инвариант каждого класса не меняется:
а) проверить истинность инварианта на начальных условиях;
б) выполнить последовательность;
в) ещё раз проверить инвариант;
4) проверить ожидаемость изменения состояний объектов:
а) спланировать последовательность переходов;
б) установить объект в начальное состояние;
в) обеспечить появление первого события и протестировать переход, и так далее.