Принципы использования каркаса FITNESS

FITNESSE – это в первую очередь инструмент для совместной разработки программного обеспечения. FITNESSE позволяет клиентам, тестерам, и программистам изучить то, что должно сделать их программное обеспечение, и автоматически сравнить это с тем, что программное обеспечение фактически делает. FITNESSE позволяет сравнить ожидания заказчиков с полученным результатом. FITNESSE – это инструмент для тестирования программного обеспечения. FITNESSE – это wiki. FIT (“Framework for Integrated Testing”) является ядром, которое в действительности обрабатывает каждую таблицу FITNESSE, используя FixtureCode, относящийся к этой таблице. Оно парсит HTML страничку, полученную из вики кода и встречая там табличку находит в соответствующий ей java класс наследник Fixture, который и запускает специальным образом. С помощью FITNESSE можно создавать наборы для тестирования, что значительно упрощает проведение приёмочного тестирования программного обеспечения. Кроме того, поскольку FITNESSE – это wiki, то в одной среде можно хранить и поддерживать в актуальном состоянии всю документацию по проекту с привязкой к выполненным тестам, как модульным, так и приёмочным.

6. Основные принципы стратегии «Чистой комнаты»

Разработка по принципу «Чистой комнаты» -это процесс разработки программного обеспечения, направленный на производство программного продукта с сертифицируемым уровнем надежности. Данный подход фокусируется на предотвращении дефектов, а не на их устранении. Также, это интеграция моделирования, формальной верификации, статистического анализа. Верификация выполняется с использованием математических критериев корректности. Статистический анализ используется для анализа тестового покрытия. Преимущества: 1) Ни одной ошибки, 2) Короткий цикл разработки, 3) Длиннее жизнь продукта. Основные принципы: 1) Маленькие команды (Независимые команды для разработки спецификаций, разработки и сертификации), 2) Инкрементная разработка с статистическим контролем качества (Эффективность оценивается на каждом шаге инкрементной разработки с использованием числа ошибок на KLOC, скоростью увеличения MTTF или числом последовательно выполненных безошибочных тестов), 3) Разработка базируется на математических принципах (Для составления спецификации и разработки используется принцип «ящика», Формальная верификация используется для подтверждения корректности реализации спецификации, Корректность проверяется путем рецензирования), 4) Тестирование базируется на статистических принципах (Тестовые наборы случайным образом генерируются на основе модели использования). Виды команд: 1) Specification team (Разрабатывает спецификации), 2) 2) Development team (Разрабатывает и верифицирует продукт, Продукт не компилируется и не выполняется в процессе верификации) 3) Certification team (Разрабатывает множество статистических тестов, Оценивает надежность продукта). Стратегия “Чистой комнаты”: 1) Increment planning (Планирование строится вокруг инкрементной стратегии), 2) Requirements gathering (Сбор и улучшение требований осуществляется классическими методами), 3) Box structure specification («Ящик» - это изоляция поведения и данных на каждом уровне разработки), 4) Формальный дизайн (Спецификация (черный ящик) итерационно улучшается до уровня архитектурного дизайна (устойчивый ящик) и дизайна уровня системы или компонента (чистый ящик)), 5) Верификация корректности (Используются математические подходы к подтверждению корректности спецификации и кода), 6) Генерация кода, инспекции («Ящик» спецификации транслируется в код на языке программирования, инспекции подтверждают соответствие кода и «ящика», синтаксическую корректность кода и т.п.), 7) Статистическое планирование тестов (Тестовые наборы генерируются в автоматическом режиме, случайно, на основе распределения вероятностей шаблонов использования продукта).