Главная » Все файлы » Просмотр файлов из архивов » PDF-файлы » Лекция 12. Проведение Тестирования. Анализ данных об отказах для принятия решений

Лекция 12. Проведение Тестирования. Анализ данных об отказах для принятия решений (Лекции)

PDF-файл Лекция 12. Проведение Тестирования. Анализ данных об отказах для принятия решений (Лекции), который располагается в категории "лекции и семинары" в предмете "надёжность программного обеспечения" изседьмого семестра. Лекция 12. Проведение Тестирования. Анализ данных об отказах для принятия решений (Лекции) - СтудИзба 2019-09-18 СтудИзба

Описание файла

Файл "Лекция 12. Проведение Тестирования. Анализ данных об отказах для принятия решений" внутри архива находится в папке "Лекции". PDF-файл из архива "Лекции", который расположен в категории "лекции и семинары". Всё это находится в предмете "надёжность программного обеспечения" из седьмого семестра, которые можно найти в файловом архиве МГУ им. Ломоносова. Не смотря на прямую связь этого архива с МГУ им. Ломоносова, его также можно найти и в других разделах. .

Просмотр PDF-файла онлайн

Текст из PDF

НАДЁЖНОСТЬ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯЛекция 12:Проведение тестирования.Анализ данных оботказах для принятия решенийВМиК МГУ им. М.В. Ломоносова,Кафедра АСВК, Лаборатория Вычислительных КомплексовАссистент Волканов Д.Ю.План лекцииРаспределение ресурсов притестировании Методы тестирования Диаграмма надёжности Модель RDC Критерии выпуска ПО2SRE: процесс• 5 шагов в SREпроцессе:– Определить необходимыйуровень надежности– Разработатьфункциональный разрез– Подготовить длятестирования– Выполнить тестирование– Проанализировать данныеоб ошибках ииспользовать их дляпринятия решенийDefine NecessaryReliabilityDevelopOperational ProfilePrepare for TestExecute TestApply Failure Datato Guide Decisions3Как распределить время1)2)3)Между тестируемыми системамиМежду функциональным,регрессионным и нагрузочнымтестированием для каждой изподсистемМежду режимами функционированиядля нагрузочных тестов каждой изподсистем41.

Распределение время тестирования вмасштабах системыИнтерфейсВыделяйте время надля сторонних системтестированиесвязанных систем всоответствии сПриобретённые РазработанныерассчитаннымкомпонентыкомпонентырискомРаспределяйтеоставшееся время вОС, системное ПОсоответствии спропорциями,Аппаратное обеспечениеопределёнными длятестовых сценариев52.

Распределение времени ирост надёжностиПри росте надёжности для каждойподсистемы и каждого нового тестовогосценария выделяйте время на:Функциональное тестирование[первая версия программы]Регрессионное тестирование[последующие версии программы]При этом гарантируется проверка всехновых критических операций.Оставшееся время выделяется нанагрузочное тестирование.63. Распределение временинагрузочного тестирования•Выделяйте время нагрузочноготестирования между режимамифункционирования программы всоответствии с числом операций в каждомиз нихПример:РежимПропорцияоперацийПиковаянагрузка0.1Инициализация0.7Часы простоя0.27Запуск тестовых сценариев (1)Последовательность тестирования:1.

Приобретённые компонентыПроверочные тесты2. Разрабатываемая системаСначала функциональные, затем нагрузочные тестыдля первой версии программыСначала функциональные, затем регрессионные тестыдля последующих версий программы3. Интерфейсы других системТолько нагрузочные тестыДопустимо изменение порядка илипараллельное тестирование8Запуск тестовых сценариев (2)При тестах на увеличение надёжности сначалапроводите функциональное, а затем нагрузочноетестирование. Проводите регрессионноетестирование после каждого значительногоизменения программыВыполнение тестов проводится в случайное времяПри функциональном тестировании новые тесты ирегрессионные тесты предыдущей версиипрограммы выполняются в случайном порядкеПри нагрузочном тестировании вызывайте сценариикаждого режима функционирования в соответствиис выделенным для него временемЧисло нагрузочных тестов определяется временем,выделенным для данного режима9функционированияВыбор сценариев (1)Для нагрузочных тестов, сценарии могутвыбираться повторно.

Для функциональныхи регрессионных тестов это не такПри функциональном и регрессионномтестировании результаты прогонов скореевсего будут идентичными, так как влияниекосвенных переменных сведено к минимумуПри нагрузочном тестировании результатынескольких прогонов скорее всего будутотличаться10Выбор сценариев (2)•Зачем повторять одни и те же тесты?Одна операция может содержать в себенесколько ошибок. Если выборпроизводится без перемещения, тооперация может быть вызвана только одинраз, и вероятность обнаружения другихошибок снижается11Определение отказов системыЧтобы определить факт отказа:1)Найдите отклонения от нормы ввыводе программы2)Определите какие из них вызваныотказами3)Определите время возникновенияотказа4)Определите класс тяжести отказа5)Задокументируйте отказ121.

Анализ вывода программы1.Некоторые отклонения отнормального поведения можно найтис помощью средств отладки (GDB,…)Примеры:Неверное обращение к памятиВзаимная блокировка процессовЗависаниеetc.132. Отклонения и ошибкиС помощью ручного анализаотклонения можно сделать вывод, чтонарушаются требования к программе,следовательно произошёл отказОтказы наибольшей тяжести можноопределить без анализа выводапрограммы:Аварийное завершение программыНеполное выполнение поставленнойзадачи143. Время возникновенияотказаДля определения времени отказаиспользуйте ту же меру, что и призадании желаемой целевойинтенсивности отказовДля тестов функциональностиизмеряйте время, когда произошёлотказДля тестов надёжности системыиспользуйте интервальную оценку.[5 отказов за 1000 операций]–154. Определение классатяжести отказаВыберете один из описанных ранееклассов тяжести отказов, который бысоответствовал найденной ошибкеЗадокументируйте отказы и их классытяжестиНачинайте исправлять ошибки сотказов, имеющих больший класстяжести16Терминология (1)Статический анализРучная проверка кодаМетоды нахождения отклонений и ошибокВзаимопроверкаФормальная проверкаАудит исходного кодаПроверка интерфейсовПоблочное тестированиеАнализ потоков данныхСтруктурный анализ17Терминология (2)Динамический анализИнструментализацияСтруктурный анализИзмерение производительности: временивыполнения и объёма потребляемых ресурсовИзмерение производительности: анализсложности алгоритма работыВставка динамических проверок (assert)Интерактивное тестирование и отладкаСлучайное тестирование18Терминология (3)Динамический анализФункциональное тестированиеМутационное тестированиеНа основе спецификацииПостроение причинно-следственных связейМутационный анализПодсев ошибокТестирование в реальном времениФормальное тестирование19Простейшие технологиитестированияДва широко известных метода:Метод прозрачного ящикаОбнаруживает ошибки на основеанализа внутренней структурыпрограммыМетод чёрного ящикаОценивает насколько хорошопрограмма выполняет предъявляемые кней требования201.

Метод прозрачного ящикаТребует детального знанияреализации программыЦель – обеспечить полное покрытиекодаКак много путей выполнения программыпроверены на самом деле?Эффективность теста часто измеряетсяразмером покрытого им кода212. Метод чёрного ящикаПредполагает, что требования уже прошливалидациюПоиск нереализованной или неправильнореализованной функциональностиЗадаёт входные данные, заранее зная какойрезультат должен быть полученСуществует много методов:Тестирование производительностиСтресс-тестированиеТестирование надёжностиТестирование безопасностиetc.22Уровни тестированияТестированиесвязано с цикломразработкипрограмм:БлочноеИнтеграционноеПользователямиУстановкиРегрессионноеОценкаресурсовРазвёрткасистемыОписаниепрограммыТестированиепользователямиАбстрактнаяархитектураИнтеграционноетестированиеДетальнаяархитектураБлочноетестированиеРеализация231. Блочное тестированиеТестирование одного модуляпрограммы методом белого ящика вконтролируемом окружении инезависимо от других модулейМодуль – функция или небольшой ихнабор, который может быть полностьюпокрыт тестовыми сценариями242.

ИнтеграционноетестированиеТестируется комбинация модулейФокус на их взаимодействииМетоды белого и чёрного ящикаСуществует три основных подхода:Сверху-внизСнизу вверхБольшого взрыва253. Внешнее тестированиеМетод чёрного ящикаПроверяет, что система корректнореализует требуемый функционалИногда известно как альфатестированиеТестирование имитируетиспользование системы конечнымипользователями264.

Системное тестированиеБолее робастная версия внешнеготестированияРазличие в тестовой платформеОкружение идентично реальномуУчитывается «железо», размеры БД, …Позволяет лучше оценитьнефункциональные требования(производительность, безопасность,…)275. ТестированиепользователямиТакже известно как бета-тестированиеСистема тестируется конечнымипользователямиЕщё более реалистичное тестированиепо сравнению системнымВалидация на основепользовательских представленийОпределяет степень готовности дляразвёртывания286.

Тестирование установкиПроверка полной, частичнойустановки/удаления программы и еёобновленияРасплывчато описывается влитературе297. РегрессионноетестированиеТестирование модифицированнойпрограммыПроверяет, что внесённые изменения неповлияли на работу остальных подсистемДля тестирования выбираются сценарии, наработу которых могут повлиять внесённыеправкиИсправление ошибки может добавить новуюошибку, нарушить структуру иликорректность интеграции с другимикомпонентами30Стоимость ошибкиТребованиеПроектированиеКодирование50 %ФункциональноетестированиеСистемноетестированиеПолевыеиспытанияПричиныотказов40 %10 %3%5%7%25 %Найденныеотказы50 %10 %20 KDM12 KDM1 KDM1 KDM1 KDMСтоимостьошибки6 KDM1 KDM = 1,000 Немецких марокCMU.

Свежие статьи
Популярно сейчас