4. Определение реальной надежности функционирования программных средств

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

4.1. Экспериментальные методы определения надежности сложных программных средств

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

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

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

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

при полном искажении ключевых параметров каждого типа внешней информации;

при предельных и критических значениях параметров каждого типа информации;

при предельных и критических сочетаниях значений различных взаимодействующих параметров;

при предельно больших и малых интенсивностях суммарного потока внешней информации;

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

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

 

4.2. Организация и этапы тестирования при испытаниях надежности сложных программных средств

 

4.2.1. Цели и этапы испытаний надежности комплексов программ

Основные этапы тестирования и испытаний комплекса программ и его компонент представлены на рис.4.1.

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

Тестирование и испытания программного средства в целом состоит из следующих этапов:

тестирование в реальном времени по данным моделирующего стенда или генераторов тестов, имитирующих отдельные объекты внешней среды;

тестирование в реальном времени с имитаторами отдельных объектов внешней среды и реальнымивоздействиями от операторов—пользователей;

тестирование в полностью адекватной реальной или имитированной внешней среде и с реальными воздействиями от операторов пользователей.

 

Рисунок 4.1 – Этапы тестирования сложных комплексов программ

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

работы по методическому обеспечению тестирования и по созданию сред в автоматической генерации тестов;

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

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

 

4.2.2. Организация завершающих испытаний комплекса программ

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

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

Испытания коммерческих пакетов прикладных программ, создаваемых по инициативе разработчика при отсутствии конкретного заказчика, проводятся в два этапа, которые получили название Альфа— и Бета-тестирование. Об этом говорит сайт https://intellect.icu . Испытания проводятся на соответствие критериям, определенным руководителем проекта. Они заключаются в нормальной и форсированной опытной эксплуатации конечными пользователями программного продукта, в соответствии с сопроводительной документацией.

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

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

При альфа— и бета—тестировании принято разделять прогрессивное и регрессивное тестирование. Под прогрессивным понимается тестирование новых программных компонент для выявления дефектов и ошибок в исходных текстах программ и спецификациях.

Регрессивное тестирование предназначено для контроля качества изменения в программах послепроведения корректировок. Необходимость его определяется тем, что значительная доля изменений после альфа— и бета-тестирования в свою очередь содержит ошибки. Объем тестов и длительность обоих этапов тестирования определяется руководителем проекта в зависимости от сложности комплекса программ и интенсивности потока изменений.

 

4.3. Генерация тестов для определения надежности сложных программных средств

 

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

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

При создании генераторов тестов применяются два принципиально различающихся подхода: интегральный и дифференциальный.

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

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

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

проводить длительное непрерывное генерирование имитируемых данных для определения надежности функционирования ПС, в широком диапазоне изменения условии и параметров, что зачастую невозможно для реальных объектов;

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

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

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

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

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

 

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

 

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

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

данные, характеризующие исходную тестовую информацию и выходные результаты тестирования,

маршруты исполнения программных компонент и их операто­ров при некоторых фиксированных тестовых данных;

аномальные события, сбои, отказы и данные, характеризую­щиеся отклонением результатов тестирования от эталонов за допус­тимые пределы и ограничения;

характеристики использования различных ресурсов ЭВМ.

Для получения этих данных при исполне­нии программ требуются ресурсы памяти и производи­тельности компьютера. В зависимости от объема и сложности программного средства и ресурсовкомпьютера, на котором оно функционирует, выделяется память и производительность на реализацию средств регистрации, обработки и обобщения результатов испытаний. Относительная доля затрат ресурсов на эти средства обычно составляет 5-10% от полных ресурсов на реализацию ПС.

Обработка результатов испытаний должна осуществляться ие­рархически и дифференцировано.

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

данные об отказах, дефектах и ошибках, условиях их про­явления и характеристиках обнаруживающих тестов, а также пред­ложения на изменение программ, подлежащие анализу для выделения тех из них, для которых будут разрабатываться корректировки программ — журнал предлагаемых изменений,

разработанные изменения программ для проведения корректировок в оче­редной версии ПС — журнал утвержденных корректировок,

характеристики базовых версий и набор изменений, выполнен­ных в каждой из них — журнал характеристик базовых версий ПС,

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

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

4.5. Методика тестирования при испытаниях надежности сложных программных средств

Целью методики является организация и регламентирование тестирования и испытаний сложных комплексов прикладных программ и их компонент для достижения соответствия характеристик создаваемых ПС техническим требованиям и спецификациям, согласованным между заказчиком и разработчиком. Методика ориентирована на тестирование крупномасштабных ПС, функционирующих в реальном времени и состоящих из многих программных компонент. Этапы тестирования и испытаний надежности комплекса программ представлены на рис.4.1. Методика тестирования компонент при фиксированных значениях времени изложена выше в п.2.5. В данной методике представлены четыре завершающие этапа тестирования в реальном времени, направленные на достижение высокого качества и надежности комплекса программ, состоящего из нескольких функциональных компонент.

Методика предусматривает следующие этапы тестирования сложных программных средств:

1. Тестирование и отладка программных компонент в реальном времени. На этом этапе нужно выполнить 5 видов работ:

разработка средств имитации внешней среды в реальном времени;

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

подготовка тестов для тестирования функциональной компоненты в реальном времени;

завершение тестирования надежности функциональной компоненты в реальном времени;

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

2. Тестирование и испытания комплекса программ по данным имитаторов внешней среды. Наэтом этапе выполняется 4 вида работ:

2.1. комплексирование всех функциональных компонент в полной версии ПС;

2.2. подготовка тестов для испытаний ПС в реальном времени по данным имитаторов;

2.3. завершение тестирования и испытаний ПС в реальном времени по данным имитаторов;

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

3. Тестирование и испытания надежности комплекса программ при воздействиях от операторов-пользователей. Этап предусматривает выполнение 5 видов работ:

3.1. разработка тренажера и полунатурного имитатора внешней среды для испытаний ПС с участием операторов – пользователей;

3.2. подготовка тестов, имитирующих внешнюю среду, и сценариев воздействий от операторов — пользователей на функционирование ПС в реальном времени;

3.3. завершение испытаний версии ПС в реальном времени по данным имитатора внешней среды при наличии воздействий от операторов – пользователей;

3.4. тестирование комплексов программ, ориентированное на выявление определенных типов дефектов и в экстремальных ситуациях;

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

4. Испытания комплекса программ в реальной внешней среде. На этом этапе выполняется 7 видов работ:

4.1. разработка методики безопасного сопряжения комплекса программ с реальной внешней средой;

4.2. комплексирование испытываемого программного средства с реальной внешней средой;

4.3. подготовка и аттестация измерителей параметров данных от объектов внешней среды, поступающих на комплекс программ;

4.4. завершение испытаний комплекса программ в реальном времени и в реальной внешней среде;

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

4.6. корректировка технологической и эксплутационной документация на версию программного средства по результатам всех стадий испытаний для предъявления заказчику;

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

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