Главная » Все файлы » Просмотр файлов из архивов » PDF-файлы » Надёжность ПО (All in one) (2014)

Надёжность ПО (All in one) (2014), страница 13

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

PDF-файл из архива "Надёжность ПО (All in one) (2014)", который расположен в категории "лекции и семинары". Всё это находится в предмете "надёжность программного обеспечения" из седьмого семестра, которые можно найти в файловом архиве МГУ им. Ломоносова. Не смотря на прямую связь этого архива с МГУ им. Ломоносова, его также можно найти и в других разделах. .

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

Текст 13 страницы из PDF

М.В. Ломоносова,Кафедра АСВК, Лаборатория Вычислительных КомплексовАссистент Волканов Д.Ю.План лекцииРаспределение ресурсов притестировании Методы тестирования Диаграмма надёжности Модель 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.

Software Engineering31InstituteТестирование на основеошибокОпределяет классы ошибок и входные данные,способные вызвать эти ошибки, если ониприсутствуютОтправка ошибок - сознательное добавлениеошибок в программу до её тестирования. На основечисла найденных в процессе тестирования ошибокопределяется число реальных ошибок в кодеМутационное тестирование добавляет ошибки вкод, чтобы определить оптимальные для тестовданныеДобавление ошибок позволяет определитьреакцию всей системы на некорректное поведениеотдельных её частей32НефункциональноетестированиеНефункциональные требования описываютотдельные функции системы, а скорее задаютобщие параметры системы(производительность, безопасность,совместимость, удобство использования, …)На тестирование нефункциональныхтребований могут быть затрачены большиеусилияЗадание нефункциональных требованийпозволяет перейти от приложения котороеспособно выполнить требуемые задачи кприложению, которое нужно реальнымпользователям системы33Документированиенефункциональных требованийОбычно нефункциональные требования задаютсядвумя способами одновременно:Создаётся единый документ, в котором описываютсятребования применительно ко всем случаямиспользования системыКаждое требование к системе содержит раздел«нефункциональные требования», где описываютсятребования, отличные от общих спецификаций•34Тестирование нефункциональныхтребований (1)Не откладывайте проверкунефункциональных требованийОбычно рекомендуют проверятьнефункциональные требованияодновременно с соответствующими имфункциональными требованиями35Тестирование нефункциональныхтребований (1)Проводите тестированиепроизводительности в реальномокруженииДля определения производительности СУБДнужно провести тесты на БД размером в 1,100, 500, 1,000, 5,000, 10,000, 50,000, и100,000 записейТакой способ тестированияпроизводительности позволяет определитьверхнюю границу, после которойприложении использовать нецелесообразно36Тестирование нефункциональныхтребований (3)Доверяйте тестирование удобстваработы с приложением егореальным пользователямИспользуйте для полученияинформации сразу несколько методов:Исследуйте существующие средстваНаблюдайте за работой пользователяПредлагайте пользователям несколькопрототипов интерфейса37Тестирование нефункциональныхтребований (3)Исследуйте вопросы безопасности накак на уровне отдельного требования,так и на общесистемном уровнеКаждая функция системы, вероятно, несёт всебе определённые угрозы безопасностиНа основе грамотно составленныхтребований к безопасности можнопостроить набор сценариев для их проверкиЕсли угрозы безопасности критичны, то дляего тестирования стоит использоватьсторонние приложения38SRE: процесс• 5 шагов в SREпроцессе:– Определить необходимыйуровень надежности– Разработатьфункциональный разрез– Подготовить длятестирования– Выполнить тестирование– Проанализировать данныеоб ошибках ииспользовать их дляпринятия решенийDefine NecessaryReliabilityDevelopOperational ProfilePrepare for TestExecute TestApply Failure Datato Guide Decisions39Типы решений• Решения, относящиеся ксертификационным испытаниям– Принять/отклонить приобретенныйкомпонент– Принять/отклонить подсистему,операционную систему, аппаратноеобеспечение и т.п.• Решения, относящиеся к испытаниямповышения надежности– Управление процессом разработки ПО– Выпуск ПО40Обзор: FIO• Интенсивность отказов цели (FIO) (F)– Интенсивность отказов определяется какотказы в некоторых единицах, например:• 3 сигнала за 100 часов функционирования.• 5 отказов за 1000 заданий и т.д.• Средняя наработка до отказа (MTTF)– Ожидаемое время до обнаруженияследующего отказа.A11   tmMTTFMTTF  tmtherefore MTTF 141Диаграмма надежности /2• Эффективный способпроверки выполняетсяFIO (F) или нет• Он основан на сбореданных об отказах вконкретные моментывремени• Вертикальная ось:количество отказов(n)• Горизонтальная ось:нормализованныеданные об отказах (Tn),т.е.

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