- •Техническое задание на разработку по (типы гост, основные разделы гост, принципы разработки технического задания на по)
- •Раздел 1. Общие сведения:
- •Раздел 2. Назначение и цели создания системы.
- •Раздел 3. Характеристики объекта автоматизации
- •Раздел 4 «Требования к системе».
- •Сертификация, стандартизация в области разработки и тестирования по
- •Уровни тестирования по. V-модель разработки и тестирования. Связь V-модели с типами тестирования
- •Модульное тестирование (Unit testing)
- •Интеграционное тестирование (Integration testing)
- •Системное тестирование (System testing)
- •Приемочное тестирование (Acceptance testing)
- •Математические модели оценки качества (надежности) по.
- •Этапы разработки по. Основные задачи, характеристики этапов.
- •Сase-системы (назначение, состав, основные функции)
- •Атрибуты. Показатели качества. Методика расчета и оценка показателей качества по (стандарт 9126)
- •Внедрение и сопровождение по (типы гост, основные этапы, и нормативные документы). Приемочное тестирование. Типы приемочного тестирования.
- •Паттерны, Фреймворки при разработке по. Визуальные средства проектирования (Visual Paradigm и др.).
- •Эскизный проект.
- •Оценка качества разработки по, основные показатели, атрибуты, стандарты, регламентирующие методику и оценки качества по.
- •1. Показатели качества по:
- •2. Атрибуты качества по:
- •3. Стандарты качества по:
- •4. Методики оценки качества по:
- •Модели оценки качества по (модели Муссы, Коркорена, Шумана и др.). Метрики оценки по (Чепина, Джилба и др.).
- •Типы тестирования. Модульное тестирование. Unit – тесты . Использование Unit-тестов при тестировании. Microsoft Test Manager. Динамическое и статическое тестирование.
- •Технический проект. Рабочий проект. Техническая документация разработки программных средств.
- •Uml (диаграммы uml)
Уровни тестирования по. V-модель разработки и тестирования. Связь V-модели с типами тестирования
Уровни тестирования По:
Модульное тестирование (Unit testing)
Модульное тестирование применяется для исследования каждого отдельного элемента или объекта системы. Чтобы найти баги, применяя модульное тестирование, нужно знать, как устроена программа в целом и какой функционал каждого отдельного модуля. Этот уровень тестирования используется больше программистами, нежели тестировщиками. Они создают специальные тест-коды, с помощью которых можно проверить, выполняет ли программное обеспечение свое предназначение.
Интеграционное тестирование (Integration testing)
Если модульное тестирование – это проверка каждого отдельного модуля, то во время интеграционного тестирования QA проверяет, как отдельные модули взаимодействуют вместе, то есть интегрируясь друг с другом. Интеграционное тестирование наиболее подходит для поиска багов в разработке интерфейса системы. И чаще всего в этом уровне тестирования используют подход «сверху вниз», когда систему проверяют по архитектурному строению.
Системное тестирование (System testing)
Название уровня говорит само за себя – проверяется вся система целостно на наличие в ней багов. В системном тестировании тестировщик проверяет взаимосвязь между всеми аппаратными и программными компонентами системы и потом тестирует уже методику работы всей системы.
Приемочное тестирование (Acceptance testing)
Этот уровень тестирования используют уже почти перед непосредственной передачей программного обеспечения заказчику. Его используют, чтобы проверить соответствует ли разработанный продукт тем требованиям, которые выдвигал заказчик. Приемочное тестирование может осуществляться командой разработчиков, его еще называют внутреннее тестирование. Второй вариант или внешнее приемочное тестирование, когда программное обеспечение тестирует сам заказчик.
V-модель:
- Каждый этап требует разработки соответствующих тестов.
- Планирование связано с сопровождением (т.е. цели связаны с результатами , что видно на практике0
- Анализ требований связано с системным тестированием
- Понятие архитектуры позволяет определить механизм взаимосвязей между модулями (т.е. интеграционное тестирование)
- Проектирование подсистем связано с модульным тестированием
- И т.о. окончательно к исправлению кода и наоборот
V-модель — это тип модели SDLC, в которой процесс выполняется последовательно в V-образной форме. Модель основана на объединении фазы тестирования с каждой соответствующей стадией разработки. Разработка каждого шага напрямую связана с этапом тестирования. Следующая фаза начинается только после завершения предыдущей. Каждый этап разработки, напрямую связан с тестированием этого этапа.
Этапы тестирования V-модели:
Модульное тестирование — модульного тестирования разрабатываются на этапе проектирования модуля. Эти планы модульного тестирования выполняются для устранения ошибок на уровне кода или модуля.
Интеграционное тестирование — после завершения модульного тестирования выполняется интеграционное тестирование. При интеграционном тестировании модули интегрируются, и система тестируется. Интеграционное тестирование выполняется на этапе проектирования архитектуры. Этот тест проверяет связь модулей между собой.
Системное тестирование — тестирование тестирует все приложение с его функциональностью, взаимозависимостью и связью. Оно проверяет функциональные и нефункциональные требования разработанного приложения.
Пользовательское приемочное тестирование (UAT): UAT выполняется в пользовательской среде, напоминающей производственную среду. UAT проверяет, что поставленная система соответствует требованиям пользователя и готова к использованию в реальном мире.
Принципы V-модели:
От большого к малому: в V-модели тестирование выполняется в иерархической перспективе, например, требования, определенные командой проекта, создают этапы проекта высокого уровня и детального проектирования. По мере того, как каждый из этих этапов завершается, требования, которые определяются, становятся все более и более уточненными и подробными.
Целостность данных / процессов: этот принцип гласит, что успешное проектирование любого проекта требует интеграции и согласованности как данных, так и процессов. Элементы процесса должны быть идентифицированы для каждого требования.
Масштабируемость: этот принцип гласит, что концепция V-Model обладает гибкостью, позволяющей приспособить любой ИТ-проект независимо от его размера, сложности или продолжительности.
Перекрестные ссылки: прямая корреляция между требованиями и соответствующей деятельностью по тестированию называется перекрестными ссылками.
Материальная документация: этот принцип гласит, что каждый проект должен создавать документ. Эта документация требуется и применяется как группой разработки проекта, так и группой поддержки. Документация используется для поддержки приложения, когда оно становится доступным в производственной среде.