ТОР 5 статей:

Методические подходы к анализу финансового состояния предприятия

Проблема периодизации русской литературы ХХ века. Краткая характеристика второй половины ХХ века

Ценовые и неценовые факторы

Характеристика шлифовальных кругов и ее маркировка

Служебные части речи. Предлог. Союз. Частицы

КАТЕГОРИИ:

Информационные потоки процессов тестирования

12 3 4 5 6 7 8 9 Следующая ⇒

Надежность ПО

Основные понятие и определения

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

Под объектом понимается любая компьютерная система либо ее подсистема.

Надежность является составным свойством и состоит из следующих показателей:

1. Безотказность

2. Ремонтопригодность или восстанавливаемость

3. Долговечность

4. Сохраняемость

Безотказность - это свойство объекта непрерывно сохранять работоспособное состояние в течении некоторого времени или наработки.

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

Долговечность – это свойство объекта сохранять работоспособное состояние до наступления придельного состояния путем технического обслуживания и ремонта.

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

(ГОСТ 17.002)

Наработка – это продолжительность или объем работы объекта.

Выражается через время либо через количества циклов, либо количества решенных задач.

Отказ – событие заключающиеся в нарушении работоспособного состояния объекта.

Отказ почти всегда вызывается физическим разрушением объекта (полного или частичного).

Наработка до отказа – это наработка объекта от начала эксплуатации до возникновения первого отказа.

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

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

Объекты восстанавливаемые и невосстанавливаемые:

Под невосстанавливаемыми объектами понимается объект, для которого в рассматриваемой ситуации не предусмотрено проведение восстановления работоспособного состояния.

Под восстанавливаемыми понимаются объекты, которые могут быть переведены в работоспособное состояние из неработоспособного состояния и это предусмотрено.

Показатели надежности невосстанавливаемых объектов

Показатели надежности являются характеристиками случайной величины T наработки до отказа.

Случайная величина – это величина, принимающая значения которая заранее не известна.

1. Вероятность безотказной работы. P(t) – выражает вероятность того, что невосстанавливаемый объект не откажет к моменту t, т.е. в течении заданной наработке на интервале от 0 до t.

(0, t), где T случайная величина наработки до отказа.

Свойства:

1) P(0) = 1

3) т.е. предполагается что объект после отказа самостоятельно не может восстановится.

2. Вероятность отказа – это вероятность того что объект откажет хотя бы один раз в течении заданной наработке будучи работоспособным в начале момент времени.

Т.о. вероятность отказа в течении заданной наработке от 0 до t будет обратной величиной

Фактически Q(t) представляет собой функцию распределения T.

3. Плотность распределения наработки на отказ

Это производная от функции ненадежности:

есть безусловная вероятность того, что объект откажет на интервале

Любая функция f(x) является функцией плотность если обладает следующими свойствами:

4. Интенсивность отказов

- это условная плотность вероятности возникновения отказа объекта, определяемая при условии, что до рассматриваемого момента отказ не возникал. Поскольку то (2)

Решая дифференциальное уравнение (2) получим связь:

Принимая

5. Средняя наработка до отказа или математическое ожидание фактически это среднее время до 1 отказа

Интегрируя по частям, получим, что

т.е. средняя наработка численно равна площади под кривой P(t) (смотрите график 1).

При математическое ожидание

При среднюю наработку в течении которой объект остается работоспособным с вероятностью

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

Показатели надежности восстанавливаемых объектов

1) Коэффициент готовности

– вероятность того, что объект окажется в работоспособном состоянии в произвольный момент времени, кроме планирования периодов в течении которых применение объекта не предусматривается

, где

– общее число объектов

– количество объектов, находящихся в работоспособном состоянии в момент времени t.

– количество объектов на ремонте.

2) Стационарный коэффициент готовности

, где

- ,

– суммарное время восстановления объекта.

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

ISO₉₁₂₆\IEC

Разработка и тестирование требований к программному продукту

Требование к ПП – это документ, который описывает все то, что должна выносить программа, но без описания разработки.

Разработка происходит по следующим этапам:

1) Интервью с заказчиком.

2) Разработка документа требований к программному продукту.

Свойства требований:

1) Каждое требование должно описывать только 1 функцию.

2) Каждое требование должно иметь уникальный идентификатор.

3) Должно быть измеряемым и контролепригодным.

4) Требования должны быть функциональные или нефункциональные.

Категории требований:

1) Функциональные требования

2) Интерфейсные требования – как программа взаимодействует с окружающей средой.

3) Данные – форматы данных, ограничения.

4) Производительность – количество одновременно вошедших пользователей, количество времени на открытие страницы.

5) Масштабируемость – возможность работы на разных устройствах.

6) Безопасность – как осуществляется доступ в системе, где и как сохраняется, с какой периодичностью.

3) Разработка спецификаций

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

4) Матрица прослеживаемости требований – это такая табличка, цель которой не потерять не одного требования на каждом этапе разработки.

5) Тестирование требований:

ü Полнота (все функции описаны и каждая подробно);

ü Однозначность – требование должно быть составлено на одном языке и запрещает использовать “и т.д., и прочее”;

ü Непротиворечивость;

ü Реализуемость (требование должно быть реализуемо);

ü Контролепригодность (проверяемость);

ü Идентифицируемость (индексы не повторяются).

Основные модели используемые в теории Надежности

Рассматривая зависимость надежности от времени, используются основные законы распределения случайных величин, время между соседними отказами называется непрерывной случайной величиной (СВ), которая характеризуется некоторым законом распределения.

Зависимость надежности от времени описывается с помощью математической модели надежности (ММН), т.е. математического выражения (формулы, выражения, системы выражений или алгоритма) позволяющего определять показатели надежности, в виде формул с эмпирическими коэффициентами. Эти формулы носят название статистических моделей распределения.

Экспоненциальная модель – является самой распространённой статистической моделью. По этой модели определяется безотказность работы через выражение:

– Параметр модели

Функция плотности записывается в виде:

Интенсивность отказов:

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

Модель Пуассона – с экспоненциальной моделью тесно связана модель Пуассона, позволяющая выразить P, но в зависимости t, k. Где k - количество отказов на заданном интервале времени (0, t). Если время между отказами распределено по экспоненциальному закону с параметрами

Равенство математического ожидания и дисперсии используются для проверки степени соответствия исследуемого распределения с распределением Пуассона.

Модель Пуассона основана на представлении о потоке случайных событий и называется Пуассоновским если выполняются условии:

1) Условие стационарности (параметры потока не зависят от t)

2) Условие ординарности (означает, что в один момент времени может произойти 1 событие или 1 отказ).

3) Отсутствие последствий (вероятность наступления данного события не зависит от того, когда произошли предварительные события в том числе отказы и какое количество их было).

Определение Маерса. Надежность ПО – вероятность работы без отказов в течении определенного периода времени, рассчитанная с учетом стоимости каждого отказа для пользователя. Стандарт ISO/IE 9126.

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

В отличии от аппаратуры не происходит износ и старение ПО.

Снижение надежности ПО происходит из-за:

· Ошибок, допущенных на всех этапах разработки ПО;

· Отказов из-за этих ошибок ПО, от способа использования ПО;

· Набора входных данных;

· Контекста используемой среды;

но не зависят от времени работы программы.

Процесс разработки по соответствию ст. ISO/МЭК.

Определяет понятие жизненного цикла.

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

Процесс – набор взаимосвязанных работ, которые преобразуют исходные данные в выходные результаты.

Каждый процесс разделен на набор работ, а каждая работа на набор задач.

Все процессы по этому стандарту делятся на:

· Основные процессы жизненного цикла;

· Вспомогательные процессы ж.ц.;

· Организационные процессы ж.ц.

Стандарт не определяет конкретную модель жизненного цикла или метод разработки программного средств. Пользователи использующие данный стандарт должны использовать действия:

· Выбирать модель жизненного цикла применительно к разрабатываемому ПО;

· Распределить процессы, работы и задачи;

· Выбирать и применять методы разработки программного обеспечения.

Основные процессы жизненного цикла:

· процесс заказа;

· процесс поставки;

· процесс разработки;

· процесс эксплуатации;

· процесс сопровождения.

Процесс заказа – содержит работы и заказы выполнение заказчиком для определения своих потребностей в разработке и выборе поставщика.

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

Процесс разработки – содержит 13 работ:

1) Подготовка процесса (задачи по выбору инструментария, модели жизненного цикла ПО и языки программирования);

2) Разработка требований системы;

3) Проектирование системой архитектуры (общая архитектура системы, обеспеченно все требования между объектами системы, должна быть документально оформлена).

4) Анализ требований к программным средствам, т.е. к каждому программному объекту должна быть разработана спецификация требования.

5) Проектирование программной архитектуры. Т.е. должны быть разработаны и документированы, оформлены в общий проект БД, общий проект внешнего интерфейса.

6) Техническое проектирование программных средств. Здесь должен быть разработан технический проект для каждого компонента. Компоненты должны быть уточнены на уровнен программных модулей.

7) Программирование тестирование программного средства. Должен быть разработан и документально оформлен каждый программный модуль и база данных, а также протестированы на соответствие их требованиям.

8) Сборка программного средства. Все модули должны быть собраны в единый программный объект и протестированы.

9) Квалификационные испытания программного средства. Тестирование ПО на соответствия к программному объекту.

10) Сборка системы. Программные объекты конфигурируются в единую систему вместе с объектами технической конфигурацией и при необходимости с другими системами.

11) Тестирование всей системы.

12) Ввод программного средства в действия.

13) Обеспечения приемки программного средства.

Процесс эксплуатации выделяет следующие работы:

ü Подготовка процесса

ü Эксплуатационные испытания

ü Эксплуатация систем

ü Поддержка пользователя

ü Сопровождение

Процесс сопровождения - выполняется персоналом сопровождения и реализуется при модификации программного средства. Цель процесса – изменение существующего программного средства при сохранении его целостности. В этот же процесс входит снятие программного средства с эксплуатации.

Вспомогательные процессы жизненного цикла:

1) Документирование,

2) Управление конфигурированием,

3) Обеспечение качества, QA – инженер,

4) Верификация (V & V)– это процесс определения того, что программное средство функционирует полно с соответствием с требованием к нему.

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

6) Совместный анализ – процесс оценки состояний и результатов работ по всему проекту

7) Аудит – процесс определения соответствия требования планов и условий договоров любого этапа договора.

8) Решение проблем – процесс анализа и решения проблем, которые были обнаружены в ходе разработки.

Организационные процессы:

· Управление

· Создание инфраструктуры

· Процесс усовершенствования

· Процесс обучения

Модели надежности программного обеспечения

Выделяют 2 класса моделей для оценки надежности ПО:

1) Математические модели

2) Иерархические

Математические модели оценки надежности ПО

Позволяют определить оценки показателей надежности ПО:

· Вероятность безотказной работы (P(t))

· Вероятность отказа Q

· Интенсивность отказов (лямбда)

· Математическое ожидание M

· Количество ошибок в программе до начала тестирование E₀

Математические модели по-разному подходят к оценке надежности ПО, используя для этого разные характеристики:

· Сложность программного обеспечения (модель Холстеда)

· Пространство входных данных (модель Нельсона)

· Искусственно внесенные ошибки в ПО (модель Миллса)

· Интервалы времени между отказами (модели Джилинского-Маранды, Шика-Волвертона, геометрические модели)

Сложность программ является одной из главных причин ненадежности этих программ.

С целью повышения надежности ПО необходимо снижать их сложность.

Критерии (способы) оценки сложности ПО:

· Количество операторов (длина программы)

· Цикломатическое число. Предложено Мак Кейбом. Предложил графическое отображение программного кода в виде ориентированного графа, где узлы графа — это операторы, ребра графа - связи между операторами.

Тогда для линейной последовательности операторов характерна вот такая последовательность:

Для конструкции if-then:

If-then-else:

Конструкция циклов:

Switch-case:

Цикломатическое число высчитывается по формуле – G=R-V+2, где R – количество ребер, а V – количество вершин.

Формула справедлива для замкнутого графа и показывает:

ü Цикломатическую сложность программы (если G>15 модуль считается не надежным и его требуется раздробить)

ü Минимальное количество тестовых проходов по графу (Если граф разомкнут, то формулой пользоваться нельзя и количество проходов определяют визуально по графу).

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

Можно выделить 3 класса инструментов автоматизации модельного тестирования:

ü Встроенные инструменты в среду разработки (Visual Studio – MS Test)

ü Семейство xUnit (C++ - cppUnit, java- jUnit и т.д.)

ü Универсальные средства тестирования (TestComplete)

Обзор кода – это вид статического тестирования без запуска программы.

Ищем ошибки:

ü Верная реализация алгоритма

ü Верное использование операторов условий и обработка исключительных ситуаций

ü Верное использования индексов массива и указателей

ü Удобочитаемость и структурированность кода

ü Наименование элементов кода, соответствующие нотациям языка стандартам и логическим назначениям

ü Комментируемости кода

ü Оптимальность кода

Виды тестирования ПО по доступу к исходному коду

По доступности исходного кода выделяют 3 вида тестирования:

1. Белый ящик – работа программиста

2. Черный ящик (не известна система доступа к исходному коду) – работа тестировщика.

3. Серый ящик (не полная доступность к программному коду) – наша программа, но использование стороннего компонента, работают программы - инструменты автоматизированного функционального тестирования.

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

Выделяют 2 подхода интеграционном тестировании:

1) Монолитное тестирование

2) Пошаговое тестирование

Монолитное тестирование заключается в том, что каждый модуль тестируются отдельно. Для каждого модуля пишется драйвер (управляющая программа) и 1 или несколько модулей заглушек (мок-объект – имитирует работу другого программного модуля). Когда все модули протестированы, они собираются вмести и программа тестируется целиком.

Недостатки:

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

· Поздно обнаруживаются ошибки межмодульных взаимодействий.

· Труднее проводить отладку программы.

Преимущества:

· Организация параллельных работ на начальном этапе интеграционного тестирования.

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

Существуют 2 стратегии выполнения пошагового тестирования:

1. Восходящее

2. Нисходящее

Нисходящее - начинается с главного модуля. Стратегия подключения новых модулей основывается на критичности модуля и на обеспечения тестового модуля данными. A, A-B, A-B-E.

Недостатки:

· Требуется написания заглушек, но не надо писать драйвера.

· Сложность интерпретации результатов тестов верхних модулей, поскольку не известна работа нижних.

Восходящее – начинается с термальных (ничего не вызывающих) модулей. Стратегия подключения новых модулей основывается на критичности модуля и на обеспечения тестового модуля данными. E, E-B, E-B-A либо E-B-C

Недостатки:

· Требуется написание драйверов

· Рабочая программа не существует до тех пор, пока не добавлен главный модуль.

Преимущества:

· Не требуется писать заглушки

Выбор определятся тем, на модули какого уровня следует обратить внимание в первую очередь.

Объектно-ориентированное тестирование

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

Интеграционное тестирование при объектно-ориентированном подходе не использует структурную схему сверху-вниз поскольку точно не известно какой класс будет вызван пользователем за предыдущим.

Т.о. интеграционные тесты заменяются на:

· Тестирование функциональных возможностей (т.е. тестирует набор классов, которые реагируют на 1 входной сигнал или одно системное событие)

· Заменяется на эксплуатационное тестирование при котором описывается 1 способ применения системы, основанные на тестовых случаях.

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

Лекция 18.03.2016

Модели оценки ПО:

1. Математические модели;

2. Иерархические модели.

Математические модели:

Модель Джелинского-Моранда:

Допущения у этой модели следующие:

· Время до очередного отказа распределено по экспоненциальному закону;

· Все ошибки равновероятны и их появление не зависит друг от друга;

· Частота появления ошибок или интенсивность отказа пропорционально количеству не найденных ошибок:

– количество ошибок в ПО до начала тестирования,

– коэффициент Джелинского-Моранда,

– интервал времени между i-1 и i-той обнаруженными ошибками,

i - количество ошибок, обнаруженных к моменту t_i

· () = const – в случае интерваа времени между 2 смежными моментами появления ошибок.

· Каждая обнаруженная ошибка ПО немедленно устраняется и количество ошибок уменьшается на 1;

· Ошибки корректируются без внесения новых ошибок.

Не бывает отладки, которая бы не повлияла на другие ошибки.

Принимая во внимание допущение 1, вероятность безотказной работы можно вычислить:

Плотность:

Средняя время:

Исходными данными для этой модели является статистика об ошибках, т.е. интервалы времени между отказами. Характеристики модели, которые нужно определить: , , , .

Определение характеристики модели возможно при помощи метода максимального правдоподобия. Метод максимального правдоподобия (Matlab) ориентирован на подбор данных.

Модель Шика-Волвертона:

Модификация модели выше и к указанным допущениям имеет дополнительные допущения.

· Частота появления ошибок пропорциональна времени отладки t_i_, таким образом вероятность обнаружения ошибок стечением времени должна возрастать.

=-

Оценка характеристик модели Шика-Волвертона возможна по методу максимального правдоподобия.

Модель Миллса:

В программу заносятся некоторое количество известных ошибок s случайным образом. Затем делается допущение, что вероятность обнаружения искусственных ошибок и собственных ошибок одинаково и вероятность зависит от их количества. Тестируя программу в течении некоторого времени и отсортировывая искусственно внесенные и собственные ошибки, можно оценить первоначальное количество ошибок E₀:

Где s – количество искусственно внесенных в программу ошибок.

n – Количество найденных (собственных) ошибок.

– количество найденных искусственных ошибок.

Достоинства:

· Модель математически проста и интуитивно понятна;

· Процесс тестирования продолжается до тех пор, пока не найдены все искусственно внесенные ошибки.

Недостаток:

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

Модель Нельсона:

В основе модели Нельсона лежит представление программы в виде некоторой функции F(E_i), где E_i _-набор входных данных, необходимых для выполнения прогона программы.

Прогон программы (выполнение программы) приводит к получению для каждого E_i определенного значения F(E_i).

F(E₁) – результат F от входных данных E.

F(E₂) - ….

В зависимости от набора входных данных E имеются реакции программы F_i.

Наличие ошибок в программе приводит к тому, что ей соответствует некоторая функция , отличающаяся от функции F.

Цель модели – свести к минимуму и F.

Для некоторого E_i отклонение от F^’от F находится в некоторых допустимых пределах , т.е. для получения приемлемого результата необходимо следующие условие:

Тогда множество наборов , не удовлетворяющих этому условию, образуют подмножество (errors) и называются рабочими отказами.

Тогда вероятность отказа Q может быть рассчитана по формуле:

Где N – количество возможных наборов входных данных,

– количество наборов из множества .

В процессе функционирования программы выбор входных данных из множества Е обычно осуществляется не с одинаковыми вероятностями, а диктуется определенными условиями работы. Тогда существует вероятность p_i выбора входных данных Е_i, которые (p_i) образуют множество вероятностей, которые называются функциональным разрезом. Тогда вероятность того, что прогон программы на входных данных Е_i, выбранных в соответствии с распределением вероятностей p_i закончится:

1. Отказом:

Где

2. Правильным выполнением единичного прогона программы:

Вероятность успешного выполнения n прогонов программы при независимом выборе входных данных определяется по формуле:

На практике выбор входных данных для каждого прогона нельзя считать независимым, поэтому функциональный разряд должен быть переопределен в терминах вероятностей P_ji выбора набора Е_i при j-том прогоне программы.

Тогда вероятность отказа j-того прогона будет суммой:

,

j- номер прогона программы.

Тогда надежность всей программы:

Классификация математических моделей надежности ПО

Иерархические модели надежности ПО

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

На территории Беларуси действуют следующие стандарты:

1) Межгосударственный стандарт ГОСТ 28195-99. Оценка качества программных средств. Общее положение.

2) Национальный стандарт РБ СТБ ИСО\МЭК 9126-2003. Информационные технологии, оценка ПП, характеристики качества и руководства по их применению.

3) Международная серия стандартов ISO\IEC 9126-1-4:2001-2004. Программная инженерия качества продукта.

4) Международная серия стандартов ISO\IEC 14598-1-6:1998-2001. Информационная технология. Оценка ПП.

1. Определяет оценку качества ПС, как совокупность операций по выбору показателей качества оцениваемого продукта, по определению значений этих показателей и сравнение рассчитанных показателей с базовыми. По этому стандарту оценка качества должна проводится на протяжении всех работ Ж.Ц. ПС.

Надежность в этом стандарте 1 из 6 показателей качества ПС.

Основу расчета оценки надежности составляет 4-уровневая иерархическая модель:

1. Факторы качества (надежность является одним из факторов качества). Первый уровень равен термину надежности;

2. Критерий качества (критерий надежности);

3. Метрики;

4. Оценочные элементы (единичные показатели).

Для каждого этапа разработки ПС могут быть выделены эти 4 уровня иерархии.

1) Для этапа разработки требования иерархия будет выглядеть следующим образом:

Фактор Критерий Метрика Оценочные элементы

Надежность à Устойчивость функционированияà · Средства восстановления при ошибках на входе à · Средства восстановления при сбоях оборудованияà См. лаб. раб. №3

2) Фаза проектирования

Фактор Критерий Метрика Оценочные элементы

Надежность à Устойчивость функционированияà · Средства восстановления при ошибках на входе à · Средства восстановления при сбоях оборудованияà · Реализация управления средствами восстановления à См. лаб. раб. №3

3) Модели для этапа реализации, тестирования, сопровождения.

Фактор Критерий Метрика Оценочные элементы

Надежность à 1. Устойчивость функционированияà 2. Работоспособность à 1. · Средства восстановления при ошибках на входе à · Средства восстановления при сбоях оборудованияà · Реализация управления средствами восстановления à 2. ü Функционирования в заданных режимахà ü Обеспечение обработки заданного объема информацииà См. лаб. раб. №3

Оценка надежности производится в следующей последовательности:

1. Выбор показателей и их базовых значений (для показателей надежности принимается шкала от 0 до 1);

2. На каждом уровне оценки производится вычисление 2 величин, абсолютного показателя P_ij и относительного показателя R_ij, где j – это порядковый номер показателя данного уровня для i – того показателя выше стоящего уровня. Относительный показатель R_ij является функцией показателя P_ij и его базового значения (в стандарте имеется таблица содержащая базовые значения для критериев, т.е. для 2 уровня, базовые значения для 3 уровня формируются на основании показателей существующих эталонов либо на основании показателей расчетного эталонного ПС, значения базовых показателей должны соответствовать значениям показателей, отражающих современный уровень качества и прогнозированный мировой уровень)

R_ij =

3. Каждый показатель надежности 2 и 3 уровня характеризуется 2 параметрами:

ü Количественным значением

ü Весовым коэффициентом V_ij

Сумма всех коэффициентов должно быть равно 1. Стандарт который мы рассматриваем содержит перечень весовых коэффициентов для показателей 2 и 3 уровней. Количественные величины весовых коэффициенты зависят от фазы ЖЦ ПС.

4. Определение усредненной оценки математического ожидания m_kq оценочного элемента по нескольким его измерениям:

где k- порядковый номер метрики, q – порядковый номер оценочного элемента, T – количество измерений оценочного элемента, t – номер значения оценочного элемента.

5. Итоговая оценка k – той метрики j-того критерия определяется по формуле:

где – признак метрики, Q – число оценочных элементов, реально используемых при оценке k методов

Абсолютные показатели j – критерия надежности.

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

Абсолютные и относительные значения надежности будут определятся по следующей формуле:

Признак фактора N – количество критериев надежности реально используемых при оценке.

Относительная надежность:

ИСО/МЭК 9126-2003

Это стандарт РБ регламентирует метод оценки качества ПС на основе трехуровневой иерархическая модель качества.

1 уровень – 6 характеристик качества.

2 уровень – подхарактеристики.

3 уровень – метрики качества.

1) Регламентирован 1 уровень модели. Подхарактеристики имеют рекомендательный характер, метрики отсутствуют.

Процесс оценки состоит из 3 стадий:

1. Определения требований к надежности.

2. Требования устанавливаются в терминах подхарактеристик надежности.

3. Требования выражают потребности внешнего окружения ПС, и должны быть определены до начала разработки.

2) Подготовка к оцениванию:

· Выбор метрик надёжности. Поскольку набор рекомендованных метрик отсутствует и может быть выбран каждый количественный признак и каждое количественно оцениваемое взаимодействие программного средства с окружением.

· Определение уровней ранжирования. Измеренные значения метрик отражаются на некоторой шкале. Шкала должна быть разделена на диапазоны, соответствующие различным степеням удовлетворения требований, предусмотренных на стадии 1.

Диапазоны ранжирования можно использовать из стандарта ISO/IEC 14598-1:1999.

В этом стандарте предусмотрено разделение шкал:

I. Неудовлетворительно, удовлетворительно

II. Хорошо, отлично, удовлетворительно, неудовлетворительно.

Эти категории ограничены запланированным уровнем, текущим уровнем и уровне худшего допустимого случая.

· Запланированный уровень определяется как достижимый при доступных ресурсах.

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

· Уровень худшего случая определяет границу принятия пользования, если продукт не удовлетворяет запланированному уровню.

· Для определения надёжности программного средства должна быть учтена вся совокупность результатов оценивания всех метрик.

3) Процедура оценивания

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

· Ранжирование. Устанавливается уровень ранжирования для измеренного значения

· Этап оценки – обобщаются установленные уровни, результат заключения надёжности. (уровень)

ISO/IEC 9126

Регламентирует четырёх уровневую иерархическую модель качества:

ü Характеристики

ü Подхарактеристики

ü Метрики

ü Оценочные элементы

1) Подхарактеристики:

Ø Завершённость – способность программного продукта избегать отказов вследствие ошибок.

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

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

Ø Соответствие надёжности – свойство программного продукта соответствовать стандартам соглашениям и нормативным документам связанных с надёжностью.

2) Метрики – рекомендованы 3 вида метрик:

ü Внутренние метрики

ü Внешние метрики

ü Метрики качества в использовании

Внутренние метрики изменяются в процессе разработки (на основе спецификации, результатов проектирования, обзора исходного кода и модульного тестирования).

Метрики дают возможность оценить промежуточный результат программного продукта и представить качество конечного программного продукта.

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

Описанные в стандарте ISO/IEC 9126 могут быть использованы для оценки надёжности программных средств 14598.

В этом стандарте:

1) Установка требований к оценке надёжности.

1.1 Установка цели (общая цель оценки надёжности программного средства – это поддержка – это поддержка разработки и приобретения программного средства, удовлетворяющего заявленным потребностям. Конечная цель, гарантировать, что ПП обеспечивает требуемый уровень надёжности для промежуточного программного продукта целью надёжности которого, могут быть:

ü Решение о принятии промежуточного программного продукта

ü Предварительная оценка надёжности программного продукта и её прогноз

ü Сбор информации о промежуточном программном продукте для контроля и управления процесса разработки.

1.2 Идентификация типов продукта

Тип оцениваемого промежуточного программного продукта зависит от стадии жизненного цикла. На ранних этапах разработки: технический проект, исходные коды модулей, спецификация, архитектура программного средства.

На последующих этапах разработки могут быть оценены промежуточные сборки и конечный программный продукт.

1.3 Определение модулей надёжности. Основу моделей составляет модель ISO/IEC 9126

2) Стадия определения оценки надёжности.

2.1 Выбор метрик надёжности. Рекомендуется исходя из стандарта ISO/IEC 9126

2.2 Установка уровня ранжирования метрик. Значение, измеренное с помощью метрики, имеет некоторую величину, которая сама по себе не отражает степень удовлетворения результатов измерений, поэтому шкала измерений разделяется на диапазоны, соответствующие различным диапазонам удовлетворяющим требованиям.

2.3 Установка критериев для оценки надёжности. Чтобы оценить надёжность ПО необходимо объединить результаты с этой целью разработана процедура с учётом взвешенных метрик.

3) Проектирование оценки надёжности.

Разработка плана оценки надёжности. В плане описаны методы оценки и график действий по оценке.

4) Выполнение оценки надёжности

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

4.2 Сравнение с уровнями ранжирования

4.3 Оценка результатов (Суммируются оценочные уровни метрик надёжности. Результат степень удовлетворённости программного продукта).

Могут быть учтены время и стоимость.

Информационные потоки процессов тестирования

Тестирование ПО – процесс поиска ошибок в программном продукте.

На входе в процесс имеются потоки:

1) текст программы (выполняемый файл или запрос для web);

2) исходные данные для текста;

3) Ожидаемые результаты.

Планирование функционального тестирования

После появления первой рабочей версии ПП тестировщики приступают к подготовительным работам и начинают разрабатывать тестовые случаи.

Тестовый случай (test case) – это алгоритм проверки некоторой функциональности программы в совокупности с ожиданием программы.

Тестовые случаи формируют логически связанные тестовые комплекты.

Также на этапе подготовительных работ разрабатывается тестовый план.

Тестовый план – это документ согласно которому будут проводится все действия по тестированию программного продукта.

А именно:

ü перечень тестируемых компонентов;

ü перечень не тестированных компонентов;

ü ресурсы тестирования (человеческие с зонами ответственности и материальные);

ü график тестирования;

ü риски тестирования;

ü стратегия тестирования виды используемого тестирования;

Стратегия определяет градацию и последовательность тестов.

Как правило выделяют следующие уровни тестов:

Рассмотрим приемочный тест (smoke test). Это краткая быстрая проверка, основной функциональности программы с целью принять или отклонить новую версию программы для дальнейшего тестирования. Проводится как правило около получаса.

Критический тест (Critical Path Test). Это проверка работы программы в стандартных ситуациях. Т.е. вводятся верные данные в программу, нажимаются нужные кнопки, идет проверка работы положительного пользователя.

Углубленный тест (Extanded Test). Как правило это негативного теста и очень мелких проверок. Проверка работы программы в нестандартных ситуациях. Т.е. вводятся в программу неверные данные нажимаются ненужные кнопки, идет имитация плохого пользователя.

Для разработки тестовых случав необходимо иметь следующую документацию:

ü Требование ПО, Спецификацию

ü Тестовый план

ü График выхода версий ПО

ü Непроектная документация

ü Пожелания заказчика

Этапы разработки тестовых случаев:

ü Ознакомление с требованием и тестовым планом;

ü Проектирование тестовых случаев;

Свойства:

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

o Иерархичность. Отдельные тестовые случаи должны связывать логически связанные тестовые комплекты (разбивка на роли, последовательность действий с базой данных)

o Независимость тестов, особенно в перспективу на автоматизацию.

ü Уточнение тестовых случаев. Не забывая предусматривать тесты на отмену действий. Для каждого поля куда вводятся данные необходимо предусмотреть их оптимальную комбинацию.

ü Проверка.

Принцип эквивалентности – если программа реагирует определённым образом на некоторое входное данное x1, существует довольно большая вероятность что программа отреагирует аналогичным образом на другое входное данное x2, очень близкое к x1. Тогда можно выделить как минимум 2 класса эквивалентности, класс верных значений и класс не верных значений. Данные на границах этих классов будут называться граничные, а внутри классов эквивалентные.

Критический тест верные данные	Углубленный тест неверные данные
Граничные данные	Эквивалентные данные	Граничные данные	Эквивалентные данные
3 символа	4 символов	2 символов	пробел
15 символов	14 символов	16 символов	300 символов
	10 символов		Любые непредусмотренные данные.

Критерии проверки тестовых случаев:

1. Соответствует ли каждый тестовый случай заявленной функциональности;

2. Покрывают ли тестовые случае все требования к программному продукту;

3. Снабжен ли каждый тестовый случай ожидаемыми результатами;

4. Имеются ли среди тестовых избыточные, можно ли устранить эту избыточность;

5. Достаточно ли подробно разработана методика тестирования для ее автоматизации;

6. Организованы ли тестовые случаи эффективно, чтобы обходиться минимальными конфигурациями средств тестирования;

7. Включены ли тесты в систему управления конфигурациями.

12 3 4 5 6 7 8 9 Следующая ⇒

Не нашли, что искали? Воспользуйтесь поиском:

vikidalka.ru - 2015-2024 год. Все права принадлежат их авторам! Нарушение авторских прав | Нарушение персональных данных