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

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),т.е.

время отказа  FFigure from Musa’s Book42Параметры /1• Отношение различимости (): Приемлемаяошибка в оценке интенсивности отказов• Риск заказчика() : Вероятность того, чторазработчик готов принять ложное заявление,что целевая интенсивность отказоввыполняется (т.е.

принятие), когда это не так• Риск разработчика() : Вероятность того,что разработчик готов принять ложно заявив,что целевая интенсивность отказов невыполняется (т.е. отклонение), когда это таки есть43Параметры /2Для  =10% и = 10% и  =2– Существует риск в 10% () ошибочногопринятия ПО, когда его целевая интенсивностьотказов на самом деле равна или больше чем в2 раза ( =2) превышает целевуюинтенсивность отказов– Существует риск в 10% () ошибочногоотклонения ПО, когда его целеваяинтенсивность отказов на самом деле равнаили менее чем 2 раза ( =2) меньше целевойинтенсивности44Диаграмма надежности /2A  ln1B  ln1 • A изменяется быстро с риском заказчика, ноочень незначительно с риском разработчикаи это определяет отрезок границыпринятия с горизонтальной линией n=0• B изменяется быстро с риском разработчика,но очень незначительно с риском заказчикаи это определяет отрезок границыотклонения с вертикальной линиейTn=045Диаграмма надежности /3• Граница между областями принятия andи продолженияAln Tn n1  1 Граница между областями отклоненияи продолженияBln Tn n1  1 46Диаграмма надежности /4Значения отрезков границ сразличными горизонтальными ивертикальными осями47Диаграмма надежности /5Значения A и B для различных уровнейрисков заказчика и разработчикаTable from Musa’s Book48Диаграмма надежности /6• Когда уровни риска ( и ) уменьшаются,система потребует проведения больше испытанийпрежде чем достигнуть областей принятия илиотклонения, т.е.

необходимо продолжитьрасширение областей• Когда отношение различимости () уменьшается,система потребует проведения больше испытанийпрежде чем достигнуть областей принятия илиотклонения, т.е. необходимо продолжитьрасширение областей49RDC:Когда и как• Когда использовать RDC?– Когда данные об отказах ограниченынесколькими отказами и требуется определитьтенденцию в надежности системы• Как использовать RDC?– Собрать данные об отказах (количествоотказов и моменты времени)– Определить MTTF и ожидаемые уровни доверия– Нарисовать точки отказов на графике ипроанализировать тенденцию надежности50RDC: Пример/1• Риск потребителя = 5%• Риск поставщика = 5%• Отношениеразличимости=2Figure from Musa’s Book51RDC: Пример /2• Риск потребителя = 1%• Риск поставщика = 1%• Отношениеразличимости=2Figure from Musa’s Book52RDC: Пример /3• Риск потребителя = 0,1%• Риск поставщика = 0,1%• Отношениеразличимости=253Figure from Musa’s BookRDC: Пример /4• Риск потребителя = 10%• Риск поставщика = 10%• Отношениеразличимости = 1.254Figure from Musa’s BookПример 1FailurenumberMeasure(milliontransactions)NormalizedMeasure(MTTF)10.18750.7520.31251.2531.255F  4 failures/million transactions  %10  %10 255Пример 2FailurenumberMeasure(CPU hour)NormalizedMeasure(MTTF)180.82191.93606F  0.1 failures/CPU hour  0.05  0.05 256Пример 3 /1• Мы собрались купить новый цветной лазерныйпринтер для лаборатории.

Мы имеем принтердля проведения тестовых сертификационныхиспытаний на нем. Инструкция показывает,что необходимо заменить тонер каждые 10000страниц. Мы хотим, чтобы система работалабезотказно между двумя последовательнымиизменениями тонера или в худшем случае –один отказa) Какая должна быть наша целеваяинтенсивность отказов для системы?F = 1/10000 pages57Пример 3 /2b) Мы наблюдаем, что отказыпроисходят на 4000 страниц, 6000страниц, 10000 страниц, 11000страниц, 12000 страниц и 15000страниц. Используядемонстрационные диаграммынадежности, какое заключениеможно сделать об этом принтере?58Пример 3 /3• Из-за провала сертификационных испытаний мыотказываемся от этого принтера59RDC: Достоинства иограничения• RDC анализ это очень эффективный с точкизрения времени и стоимости способ анализанадежности системы. Он может использоватьсядля демонстрации надежности системы припринятии решений• Недостатком RDC анализа является то, что RDC непозволяет дать количественную оценкунадежности (или доступность) изучаемойсистемы.

Он может лишь показать тенденцииизменений и их влияние на надежность системы• Другой недостаток: экспериментировать сразличными уровнями достоверности и MTTFвозможно, но довольно утомительно60Типы решений• Решения, относящиеся ксертификационным испытаниям– Принять/отклонить приобретенныйкомпонент– Принять/отклонить подсистему,операционную систему, аппаратноеобеспечение и т.п.• Решения, относящиеся к испытаниямповышения надежности– Управление процессом разработки ПО– Выпуск ПО61Критерий выпуска• Следующие показатели должны рассматриватьсясовместно для получения адекватной картиныкачества продукта:– Стабильность, надежность и доступностьсистемы– Дефект объёма– Выдающиеся критические проблемы– Обратная связь с пользователями раннихверсий программ– Другие атрибуты качества, которые имеютособое значение для конкретного продукта,заказчика и рынка(например, простотаиспользования, производительность,безопасность, мобильность)From Dr.

Kan’s Book62Подход:модели• Использование средств таких как CASRE дляпостроения соотношения / F во времени, чтобыпроанализировать тенденции• CASRE использует базовую экспоненциальную илогарифмическую пуассоновскую и некоторыедругие модели• Базовая экспоненциальная модель предполагаетконечное количество отказов за бесконечное время;логарифмическая пуассоновская модельпредполагают бесконечное количество отказов• При оценке соотношения / F , базоваяэкспоненциальная модель имеет «оптимистическую»тенденцию; логарифмическая пуассоновская модельимеет «пессимистическую» тенденцию63Критерий выпуска /1• Оценка нормализованной интенсивностиотказов имеет степень неопределенности.Она определяется «доверительныминтервалом»• Например, если доверительный интервал90%, то можно ожидать, что системадостигнет своей целевой интенсивноститолько с вероятностью 90%• CASRE 2.0 не позволяет вычислять«доверительные интервалы64Критерий выпуска /2• Как включить доверительный интервал воценку?• Можно использовать следующийприближенный подход:– Рассмотрим завершение тестирования длясистемы, когда нормированная интенсивностьотказов снижается до 0,5 или ниже– Предположим, что 90% - доверительныйинтервал для интенсивности отказов вблизирелиза и таким образом интенсивность отказоврасширяется от 0.5 до 1.5 раз65Критерий выпуска /3Рассмотрим вопрос о выпуске продукта1.