Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лекции / лекция2.pptx
Скачиваний:
62
Добавлен:
03.02.2018
Размер:
485.4 Кб
Скачать

Процесс проведения работ

Эффективное тестирование получается тогда, когда ставятся следующие вопросы:

Как можно сломать ПО СОДС «МАРШ!»?

В каких ситуациях это ПО СОДС «МАРШ!» может быть дестабилизировано?

31

Процесс проведения работ

В ходе тестирования проводится практическая и беспристрастная оценка качества ПО СОДС «МАРШ!». При этом следует избегать двух крайностей:

подхода, при котором ПО СОДС «МАРШ!» и его слабые стороны проверяются недостаточно тщательно;

предвзятого отрицательного или деструктивного подхода к ПО СОДС «МАРШ!» - такой подход может привести к возникновению антагонизма между тестированием и разработкой.

32

Процесс проведения работ

Тестирование связано с другими элементами разработки ПО СОДС «МАРШ!» следующим образом:

Управления требованиями охватывает вопросы формулировки и уточнения требований к программному продукту, а требования представляют собой одни из основных источников информации при разработке и отборе тестов.

Анализ и проектирования ПО СОДС «МАРШ!» посвящено созданию проекта программного продукта, от которого также во многом зависит выбор выполняемых тестов.

Реализации ПО СОДС «МАРШ!» охватывает вопросы компоновки тестируемых версий ПО. В ходе итерации могут быть протестированы несколько вариантов сборки ПО (компиляции); как правило, по одной компиляции за один цикл тестирования.

Управления проектом охватывает планирование проекта и действия, выполняемые в рамках каждой итерации. Тесты и планы, описанные в плане итерации, очень важны для разработки адекватной процедуры оценки результатов теста.

Управление конфигурацией и изменениями охватывает вопросы управления изменением ПО СОДС «МАРШ!-3.0» и их частей в ходе реализации проекта. В ходе тестирования проверяется правильность внесения изменений.

33

Возможные операции и потоки операций тестирования ПО СОДС «МАРШ!»

34

Возможные операции и потоки операций тестирования ПО СОДС «МАРШ!»

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

Проверка подхода к тестированию – цель операции заключается в демонстрации того, что технологии, описанные в разделе Подход к тестированию, позволяют провести тестирование в запланированном объеме. Смысл этого действия заключается в демонстрации того, что такой подход будет работоспособен, позволит получить точные результаты и реализуем с имеющимися ресурсами.

Проверка стабильности компиляции – цель операции заключается в проверке того, достаточно ли стабильна компоновка ПО СОДС «МАРШ!» для перехода к детальному тестированию и оценке продукта.

35

Возможные операции и потоки операций тестирования ПО СОДС «МАРШ!»

Тестирование и оценка – цель операция заключается в определении ширины и глубины тестирования, достаточной для адекватной оценки тестируемых объектов, при этом адекватность определяется мотивационными факторами и целью оценки.

Получение приемлемой цели – цель операции в передачи суммарного результата оценки заинтересованным лицам. Результат оценки передается в терминах цели оценки.

Улучшение ресурсов тестирования – цель операции в обслуживании и улучшении ресурсов тестирования.

36

Базовые роли

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

Аналитик - исполнитель этой роли определяет необходимые тесты, отслеживает выполнение тестирования и его результаты и оценивает качество ПО СОДС «МАРШ!» в целом.

Разработчик тестов – исполнитель этой роли определяет общую стратегию тестирования и контролирует успешность ее реализации. Сюда входит выявление методов, инструментов и указаний, подходящих для выполнения выбранных тестов и для обеспечения успешной работы коллектива испытателей.

Испытатель – исполнитель этой роли выполняет тестирование продукта и описывает исход тестирования.

37

Состав рисков для компонент изделия

Риски

Компоненты МАРШ!

Клиент ДСС

 

Нарушение взаимодействия между компонентами изделия

Х

Нарушение взаимодействия с внешними системами

Х

Нарушение режимов функционирования изделия

Х

Отсутствие необходимых возможностей по диагностированию

Х

Нарушение надежности

Х

Несоответствие значений показателей назначения

Х

Неприемлемость эргономики и технической эстетики

Х

Нарушение защиты от НСД

Х

Разрушение информации при авариях

Х

Нарушение сохранности информации

Х

Непрочность изделия при внешних воздействиях

Х

Невыполнение (или некачественная реализация) функции

Х

Нарушение использования методов

Х

Несоответствие информационного обеспечения

Х

Нарушение требований к языкам

Х

Нарушение требований к ПО

Х

Нарушение требований к ТО

Х

Состав рисков для компонент изделия

Недостаточное обеспечение безопасности

Х

Неполадки, обнаруженные в рамках аппаратного обеспечения

Х

Неполадки, обнаруженные в рамках встроенного программного обеспечения

Х

Неполадки, обнаруженные в рамках ФПО, разрабатываемого специально

Х

Неполадки, обнаруженные в рамках ФПО сторонних производителей

Х

Неполадки на этапе разработки

Х

Неполадки на этапе эксплуатации

Х

Ошибки разработчика

Х

Кратковременная остановка функционированияф

Х

Полный выход из строя

Х

Нарушение, выявленное визуально

Х

Нарушение, выявленное при использовании программных средств

Х

Нарушение, выявленное при использовании аппаратных средств

Х

Нарушение, выявленное при использовании программно-аппаратных средств

Х

Нарушение, приводящее к полной замене изделия

Х

Нарушение, приводящее к перепрошивке изделия (возврату к начальным установкам)

Х

Нарушение, приводящее к перезагрузке изделия

Х

Неполадки прошивки

Х

Разработка комплексных тестов

Комплект тестов содержит следующие разделы:

Краткое описание – краткое общее описание комплекта, включая классификационные признаки комплекта, управления ЖЦ комплекта.

Эскиз комплекта тестов - определение общей структуры текущего тестового комплекта. Эскиз может содержать основополагающую информацию о настройке или топологии тестирования частей СОДС «МАРШ!», цели проведение тестирования.

Формальная проверка - список ролей, которые будут утверждающими и проверяющими содержимого комплекта, а также определение самого процесса формальной проверки.

Предварительное условие – описывает объекты/условия, обязательные для начала выполнения комплекта тестов. Например, перед началом выполнения данного комплекта тестов необходимо завершить выполнение другого комплекта тестов.

40

Соседние файлы в папке Лекции