«В.В. Липаев ТЕСТИРОВАНИЕ КОМПОНЕНТОВ И КОМПЛЕКСОВ ПРОГРАММ УЧЕБНИК СИНТЕГ® Москва - 2010 УДК 004.41(075.8) ББК 32.973.26-018я73 Л61 Липаев В.В. Тестирование компонентов и комплексов программ. Учебник. – М.: СИНТЕГ, ...»

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

В.В. Липаев. Тестирование компонентов и комплексов программ Ручная пошаговая подготовка сценариев и содержания тестов не может обеспечить достаточно представительный их набор для тестирования крупных комплексов программ реального времени на соответствие требованиям к функциям и характеристикам качества. Для обеспечения высокого качества таких комплексов часто ориентируются на Альфа- и Бета-тестирование коллективами потенциальных пользователей или на тестирование при опытной эксплуатации. Однако эти методы приводят к длительным процессам устранения ошибок и дефектов, сохраняется неопределенность достигнутого качества и возможных рисков. Кроме того, такое тестирование может быть недопустимо для программных комплексов критических систем, где проявление случайных ошибок при эксплуатации может нанести большой ущерб.

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

При наличии реальных планов и разумных предположений использование автоматизированных инструментальных средств и автоматизированных тестовых сценариев представляет собой способ снижеия временных и иных затрат на тестирование программного комплекса. Эффективная Программа тестирования имеет свой собственный жизненный цикл разработки, в который входят плаЛекция 2.4. Подготовка средств тестирования комплексов программ… нирование стратегий и целей, определение требований к тестам, анализ, проектирование и кодирование (рис. 2.15).

Подготовка средств тестирования сложных комплексов программ на соответствие требованиям должна включать:

- методы подготовки тестов для тестирования сложных комплексов программ:

классификацию методов подготовки тестов;

оценки методов автоматизации разработки тестов;

- требования к генерации динамических тестов внешней среды в реальном времени:

подготовки тестов на основе архитектуры системы;

задачи автоматизированного формирования динамических тестов внешней среды;

преимущества программной имитации динамических тестов;

- компоненты генераторов динамических тестов внешней среды в реальном времени:

исходные данные для генерации тестов внешней среды;

набор средств для формирования тестов внешней среды;

- обработку результатов динамического тестирования комплексов программ в реальном времени:

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

средства оценки характеристик комплекса программ и - оценки эффективности динамической генерации тестов в реальном времени:

оценки затрат на программную имитацию тестов;

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

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

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

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

Однако такое решение влечет за собой существенное увеличение расходов на установку соответствующих аппаратных средств и на испытательный стенд.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

определение и формирование динамических тестов реализацию процесса тестирования разработчиком: ввод тестовых наборов;

генерацию тестовых данных; ввод ожидаемых, эталонных результатов;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Программная имитация динамических тестов внешней среды на ЭВМ в реальном времени позволяет:

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

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

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

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

Компоненты генераторов динамических тестов внешней среды в реальном времени Одними из наиболее сложных и дорогих имитаторов внешней среды, применяемых для испытаний крупных программных комплексов, являются модели: полета космических аппаратов; диспетчерских пунктов управления воздушным движением; объектов систем противовоздушной обороны; сложных административных или банковских систем и другие. Применяемые для этого моделирующие испытательные стенды (МИС) проблемно – ориентированы и размеры программ, моделирующих в них динамическую внешнюю среду, могут даже значительно превышать размеры соответствующих испытываемых программных продуктов. Для их реализации должны выделяться достаточно мощные универсальные моделирующие ЭВМ.

Кроме того, для автоматизации разработки программных комплексов могут использоваться отдельные технологические ЭВМ, что в совокупности образует инструментальную базу для обеспечения всего ЖЦ сложных комплексов программ реального времени на объектных реализующих ЭВМ.

Имитация конкретных динамических тестов с реальными характеристиками, адекватными объектам внешней среды, является основной частью типовых моделирующих стендов (см. рис. 2.15). В соответствии с полной номенклатурой и реальными характеристикаЛекция 2.4. Подготовка средств тестирования комплексов программ… ми таких объектов создаются их интегральные или дифференциальные модели. Выбор типов моделей зависит от глубины знаний об алгоритмах функционирования внешних объектов, характеристиках их компонентов и обобщенных параметрах работы объекта в целом.

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

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

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

В схеме типового МИС можно выделить ряд базовых компонентов, назначение и функции которых представлены на рис. 2.16. Для каждого эксперимента при динамических испытаниях комплексов программ реального времени следует подготавливать план сценариев тестирования и обобщенные исходные данные.

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

В.В. Липаев. Тестирование компонентов и комплексов программ Лекция 2.4. Подготовка средств тестирования комплексов программ… Эти данные вводятся и преобразуются на моделирующей ЭВМ вне реального масштаба времени и подготавливают старт сеанса функционирования стенда и испытываемых программ в реальном времени. После этого начинают генерироваться тестовые данные.

Аналоги системы и аппаратуры внешней среды используются преимущественно для генерации динамических тестов, представляющих коррелированные логические переменные, которые трудно описать и смоделировать на ЭВМ. Кроме того, они позволяют проверить и аттестовать некоторые программные имитаторы внешней среды, которые впоследствии играют основную роль при испытаниях. В ряде случаев такие аналоги аппаратуры не могут отразить все особенности объектов внешней среды, и имитаторы на ЭВМ остаются единственными источниками соответствующей части данных для проверки качества программного комплекса.

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

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

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

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

Повторяемость сеансов испытаний при автоматической имитации динамических тестов обеспечивается фиксированием всех исходных данных и применением программного формирования псевдослучайных чисел. При надежной работе аналогов реальных объектов и моделирующей ЭВМ, в принципе, можно добиться почти абсолютной повторяемости весьма длительных экспериментов и сцеЛекция 2.4. Подготовка средств тестирования комплексов программ… нариев тестирования. Некоторая не идентичность результатов при повторных экспериментах может быть обусловлена сбоями и частичными отказами аппаратуры. Труднее обеспечивать повторяемость сценариев динамических испытаний, в которых активно участвует оператор-пользователь. В этом случае необходимо регистрировать и сохранять действия оператора в зависимости от времени, а затем повторять их в соответствии с записанным сценарием. При необходимости временная диаграмма может соблюдаться с точностью около 0,5-1 с, однако ошибки в действиях оператора и вводимых им параметрах могут отличаться в каждом сценарии тестирования. Вследствие этого повторяемость тестов реализуется только статистически.

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

генерацию динамических тестовых сценариев или хранения тестов для контроля работоспособности, сохранности и целостности программного комплекса при функционировании и применении;

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

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

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

Средства генерации динамических тестов и имитации внешней среды в составе поставляемого программного комплекса предназначены для оперативной подготовки исходных данных при проверке различных режимов функционирования в процессе применения программного комплекса и при диагностике проявившихся дефектов. Минимальный состав средств генерации тестов должен переВ.В. Липаев. Тестирование компонентов и комплексов программ даваться пользователям для контроля использования рабочих версий в реальном времени и входить в комплект поставки каждой пользовательской версии программного комплекса. Для размещения таких средств мониторинга и контроля качества функционирования крупных комплексов программ необходимы ресурсы памяти, а также дополнительная производительность ЭВМ. Более глубокие испытания функционирования версий и локализации ошибок следует проводить на базе комплекса средств имитации внешней среды высшего уровня в МИС на моделирующей ЭВМ, которые используются специалистами для испытаний и/или сертификации системы. Часть этих средств имитации может применяться как средства нижнего уровня (пользовательские) на объектной ЭВМ для диагностики и обеспечения полного повторения ситуаций, при которых пользователями могут быть обнаружены динамические дефекты функционирования.

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

Важнейшее значение для определения качества программных комлексов имеет адекватность имитаторов динамических тестов, которая зависит от степени учета второстепенных факторов, характеризующих функционирование реальных объектов или источников информации, при создании их моделей. Точность моделей на ЭВМ, прежде всего, определяется алгоритмами, на которых они базируются, и полнотой учета в них всех особенностей моделируемых объектов. Кроме того, на адекватность имитации влияет уровень дефектов и ошибок в программах имитации. Каждый, не учитываемый в имитаторе элемент или фактор моделируемой системы, необходимо оценивать путем сопоставления частных имитируемых данных с результатами аналитических исследований или с данными, полученныЛекция 2.4. Подготовка средств тестирования комплексов программ… ми на реальных системах, и определять его возможное влияние на полную требуемую точность модели и генерируемых динамических тестов с учетом других составляющих, отражающихся на достоверности имитации. Перечисленные факторы, влияющие на достоверность генерации тестов в МИС, взаимозависимы, и повышение достоверности имитации за счет одного из факторов при ограниченных ресурсах приводит, как правило, к снижению достоверности вследствие влияния остальных. Поэтому важной задачей при создании имитационных моделей является достижение наибольшей суммарной достоверности имитации и определения значений характеристик качества функционирования программного комплекса, при сбалансированном влиянии каждого из факторов. Поэтому при создании сложных генераторов тестов необходимо достигать, по возможности, равное влияние отмеченных факторов на суммарную достоверность оценки качества программного комплекса при квалификационном тестировании и испытаниях.

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

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

Разрыв динамического исполнения программ для анализа промежуточных данных может производиться методом вставок специальных контрольных программ при подготовке комплекса программ к В.В. Липаев. Тестирование компонентов и комплексов программ конкретному сеансу испытаний. Такие вставки при их небольшом числе почти не искажают реальный масштаб времени. Они обычно размещаются в завершающей части отдельных функциональных групп или компонентов комплекса программ, позволяют контролировать и локализовать причины отказов и дефекты с точностью до достаточно крупных участков комплекса программ. В точках контроля и разрыва естественного процесса исполнения комплекса программ обычно размещаются только операторы ухода на специализированную группу программ регистрации и оперативной обработки промежуточных данных в объектной ЭВМ. Далее эти данные либо накапливаются и предварительно обрабатываются в объектной ЭВМ, либо оперативно передаются в моделирующую ЭВМ для более глубокой обработки.

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

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

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

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

Лекция 2.4. Подготовка средств тестирования комплексов программ… характеристики динамического использования различных ресурсов объектной ЭВМ.

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

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

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

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

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

Зарегистрированные и обработанные результаты испытаний должны использоваться для установления соответствия полученных характеристик качества заданным требованиям. При выявлении их отклонения от требований технического задания заказчика, спецификаций требований или декларируемых в документации, должны разрабатываться корректировки программ для устранения несоответствия. Для этого все этапы тестирования и испытаний программных продуктов должны быть поддержаны системой конфигурационного управления версиями программных компонентов и базой данных документирования тестов, результатов испытаний и выполненных корректировок программ (см. лекцию 2.7 и стандарты ISO 10007 и ISO 15846). Средства накопления сообщений об отказах, ошибках, Лекция 2.4. Подготовка средств тестирования комплексов программ… предложениях на изменения, выполненных корректировках и оцененных характеристиках качества версий являются основой для конфигурационного управления развитием и совершенствованием комплекса программ.

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

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

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

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

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

Экономическую эффективность программной имитации внешней среды на ЭВМ по сравнению с натурными экспериментами целесообразно оценивать при одинаковых объемах динамических тестовых данных для испытаний и определения качества. Показателем экономической эффективности имитации может служить соотношение затрат на проведение натурных экспериментов и затрат на программную имитацию той же совокупности тестовых и эталонных данных. Затраты ресурсов на натурные эксперименты для генерации тестов при проведении разработки, испытаний и определения качества пропорциональны реальному времени функционирования проверяемого программного комплекса и затратам на применение привлекаемых средств реальной внешней среды. Они включают стоимость эксплуатации реального объекта, создающего динамические тесты в единицу времени (например, затраты на функционирование административной системы, прокатного стана или системы управления возЛекция 2.4. Подготовка средств тестирования комплексов программ… душным движением и всех управляемых ею объектов). Таким образом, затраты на натурные эксперименты для оценивания характеристик комплексов программ определяются использованием всей реальной внешней среды, в которой предстоит в дальнейшем функционировать программам, а также затратами на средства измерения характеристик этой среды и проверяемого программного комплекса в процессе разработки, испытаний и определения качества.

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

Имитационные стенды практически всегда являются уникальными. В ряде случаев эти комплексы программ могут иметь объем порядка 106 строк текста и должны создаваться с применением современных технологических систем. Затраты на эксплуатацию программ имитации в основном определяются длительностью проведения динамического тестирования, испытаний и/или измерения характеристик качества. Значения этого времени соответствуют реальному времени генерации тестовых данных и тестирования программ. Затраты на эксплуатацию ЭВМ, используемую в моделирующем имитационном стенде, включают: первичные затраты на закупку и установку оборудования, необходимого для имитации тестовых данных, стоимость имитирующей ЭВМ и устройств сопряжения имитационного стенда с ЭВМ, на которой функционируют тестируемые программы.

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

В.В. Липаев. Тестирование компонентов и комплексов программ Примером сложного испытательного стенда и моделей внешней среды для динамического тестирования и проверки на соответствие требованиям к функциям и характеристикам комплексов программ может рассматриваться система управления полетами воздушных судов и диспетчерских систем в центрах управления воздушным движением. Для комплексной отладки, тестирования, испытаний и сертификации программных продуктов управления воздушным движением (УВД) проводится имитация в реальном времени всей информации, поступающей из внешней среды. Источниками информации для центров УВД являются радиолокационные станции, летный состав на борту воздушных судов, диспетчеры управления воздушным движением и исходные планы полетов.

Лекция 2.5. Тестирование программных комплексов на соответствие…

ТЕСТИРОВАНИЕ ПРОГРАММНЫХ

КОМПЛЕКСОВ НА СООТВЕТСТВИЕ

ТРЕБОВАНИЯМ К ХАРАКТЕРИСТИКАМ И

ДОКУМЕНТАМ

Тестирование надежности функционирования В составе требований к системам и программным комплексам, функционирующим в реальном времени, особое значение имеют динамические функции и характеристики (см. лекцию 1.3). Для обеспечения их высокого качества непригодны отдельные сценарии и процедуры тестов, а необходимо создавать потоки динамических тестов в реальном времени, адекватные соответствующим данным при функционировании внешней среды систем и/или пользователей (рис. 2.17). Эти потоки тестов должны обеспечивать динамическую проверку комплексов программ на соответствие требованиям, выявление дефектов и ошибок при реализации их функций и характеристик в реальном времени. Основная особенность такого тестирования состоит в необходимости создания динамической среды функционирования программного комплекса, максимально приближенной к реальной, при его практическом применении.

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

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

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

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

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

- тестирование характеристик производительности и использования ресурсов ЭВМ программными комплексами:

нарушения временного баланс между длительностью решения задач и производительностью ЭВМ;

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

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

- тестирование документации на соответствие требованиям к программным комплексам:

определение характеристик аудитории пользователей программного комплекса;

подготовка требований и плана эксплуатационной документации программного комплекса;

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

тестирование эксплуатационной документации на практичность.

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

Оценивание надежности программных комплексов включает измерение количественных характеристик: завершенности, устойчивости к дефектам, восстанавливаемости и доступности-готовности (см. лекцию 1.3). При этом предполагается, что в контракте, техническом задании или спецификации требований зафиксированы и утверждены заказчиком определенные значения этих характеристик и их приоритеты. Измерения проводятся при функционировании готового программного комплекса для сопоставления с заданными требованиями и для оценивания рисков соответствия этим требованиям. Тестирование для оценки надежности комплекса программ должно проводиться в тестовом окружении, которое максимально приближено к реальным условиям применения системы. Входные параметры тестов следует задавать на основе вероятностного распределения соответствующих характеристик или их наборов при эксплуатации программного комплекса.

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

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

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

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

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

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

Если интенсивное тестирование программ в течение достаточно длительного времени не приводит к обнаружению дефектов или ошибок, то у специалистов, ведущих испытания, создается ощущение бесполезности дальнейшего тестирования программного продукта, и он передается на эксплуатацию. Экспериментальное исследование характеристик сложных ПС позволило оценить темп обнаружения дефектов – риски, при котором крупные программные продукты передаются на регулярную эксплуатацию: 0,0020,005 дефектов в день на человека, т.е. специалисты по испытаниям или все пользователи в совокупности выявляют только около одной ошибки или дефекта каждые два три месяца использования ПС. Интенсивность обнаружения ошибок ниже 0,001 ошибок в день на человека, т.е.

меньше одной ошибки в год на трех-четырех специалистов, непосредственно выполняющих динамическое квалификационное тестирование и/или эксплуатацию комплекса программ, по-видимому, может служить эталоном высокой надежности обработки информации. Если динамическое функционирование программного продукта происходит непрерывно, то эти показатели соответствуют высокой наработке на обнаружение дефекта или отказа порядка 5 10 тысяч часов и коэффициенту готовности выше 0,99.

Форсированные (стрессовые) испытания для оценивания надежности (а также функциональной безопасности и рисков) проВ.В. Липаев. Тестирование компонентов и комплексов программ граммных комплексов значительно отличаются от традиционных методов испытаний аппаратуры. Основными факторами, влияющими на надежность, являются исходные данные и их взаимодействие с дефектами и ошибками программ или сбоями в аппаратуре ЭВМ. Поэтому форсирование испытаний надежности осуществляется повышением интенсивности искажений исходных данных и расширением варьирования их значений, а также специальным увеличением интенсивности потоков информации и загрузки программ на ЭВМ выше нормальной.

При форсированных испытаниях целесообразно выделять следующие режимы тестирования:

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

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

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

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

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

В любых ситуациях функционирования сложных комплексов программ, прежде всего, должны исключаться катастрофические последствия и длительные отказы или в максимальной степени смягЛекция 2.5. Тестирование программных комплексов на соответствие… чаться их негативное влияние на результаты, выдаваемые пользователю. Неизбежность дефектов и ошибок в сложных комплексах программ, искажений исходных данных и аппаратурных сбоев приводит к необходимости регулярного контроля процесса исполнения комплекса программ, и сохранности данных. Предвидеть заранее все ситуации исполнения программ и протестировать при них крупные программные комплексы оказывается невозможным из-за их огромного количества, поэтому применяются методы, которые направлены на оперативное обнаружение последствий дефектов и аномального функционирования программ, а также на автоматическое восстановление (рестарт) нормального вычислительного процесса и искаженных текстов программ и данных. Для обеспечения высокой надежности функционирования необходимо максимально быстро обнаруживать аномалии, достаточно точно классифицировать тип уже имеющихся и возможных последствий искажений, а также осуществлять мероприятия, обеспечивающие быстрое восстановление нормального функционирования программного комплекса и системы.

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

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

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

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

Всегда не полностью, с необходимой детализацией определены и описаны все характеристики, особенности функционирования и безопасности объектов внешней среды. Эти характеристики в той или иной степени обычно находятся под воздействием управляемой системы. Квалификация и субъективные свойства потребителей и пользователей изменяются по мере освоения функциональных возможностей системы и ее работоспособности, что увеличивает неопределенность ее реальной безопасности. Различия свойств персонала, применяющего систему, дополнительно увеличивают неопределенность значений безопасности и трудности ее прогнозирования при тестироЛекция 2.5. Тестирование программных комплексов на соответствие… вании с учетом множества субъективных факторов различных специалистов, участвующих в эксплуатации.

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

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

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

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

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

Тестирование характеристик производительности и использования ресурсов ЭВМ программными Оценивание ресурсной эффективности состоит в измерении количественных характеристик: временной эффективности и используемости динамических ресурсов ЭВМ комплексом программ (см.

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

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

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

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

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

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

загрузку вычислительной системы функционирующими программами;

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

В.В. Липаев. Тестирование компонентов и комплексов программ длительность исполнения типовых заданий при реализации конкретных функций;

характеристики функционирования устройств ввода/вывода;

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

заполнение памяти обмена с внешними абонентами в различных режимах применения программного комплекса.

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

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

При использовании комплексом программ производительности и памяти реализующей ЭВМ менее чем на 50%, разработчик может практически не учитывать эти ограничения и сопутствующие риски.

Закономерным является стремление разработчиков программ применять, особенно для систем реального времени, встроенные объектные ЭВМ с предельным использованием их технических характеристик. Опыт создания программ реального времени позволяет утверЛекция 2.5. Тестирование программных комплексов на соответствие… ждать, что практически невозможно использовать производительность объектной ЭВМ более чем на 95%, и почти всегда целесообразно ограничиваться на уровне 80 90%, так как иначе, затраты на разработку программного комплекса могут значительно увеличиться.

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

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

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

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

загрузка ЭВМ в нормальном режиме поступления сообщений и заданий, а также вероятность перегрузки заданиями различных типов и возможные распределения длительностей перегрузки в реальных условиях;

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

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

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

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

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

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

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

Для определения использования комплексами программ временных ресурсов ЭВМ полезно применять рекомендации стандарта ISO 14756. Стандарт ориентирован на динамическое оценивание: программных комплексов, операционных систем и вычислительных комплексов, включающих аппаратные и программные средства.

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

По результатам квалификационного тестирования и испытаний могут быть решены задачи динамического оценивания ресурсной эффективности программного комплекса, что позволяет анализировать факторы, определяющие необходимую пропускную способность ЭВМ, и разрабатывать меры для приведения ее в соответствие с поЛекция 2.5. Тестирование программных комплексов на соответствие… требностями. Если предварительно в процессе проектирования производительность системы не оценивалась или определялась слишком грубо, то велик риск, что доработки будут большими или может понадобиться заменить ЭВМ на более быстродействующую. Это обусловлено, как правило, «оптимизмом» разработчиков, что приводит к занижению интуитивных оценок длительностей решения функциональных задач и возможных предельных интенсивностей потоков внешней информации. Длительная регистрация и накопление значений ресурсной эффективности способствуют выявлению ситуаций, при которых проявляются некоторые дефекты функциональной пригодности.

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

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

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

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

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

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

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

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

Стандарты ISO 15910 и ISO 18019 являются наиболее современными нормативными документами, регламентирующими процессы создания эксплуатационной документации для пользователей сложных программных комплексов. В них изложены детальные структуры планов документирования, ориентированных на разработчиков документов, соответствующих требованиям на программные комплексы, и процедуры контроля реализации плана. Эксплуатационная документация должна проходить тестирование и испытания на достоверность, которые должны быть спланированы и реализованы на базе требований к функциям и характеристикам, а также к применению эксплуатационных процедур реального программного комплекса. Изложены требования и правила оформления твердой копии документов и правила структурирования и представления схем компонентов, окружения, иллюстраций и основного текста документов.

Стандарты представляют разработчикам документации метод определения и применения процесса документирования при создании конкретного программного комплекса. Для соответствия стандартам план должен включать спецификацию требований к стилю оформления документов. Стандарты также определяют виды информации, представляемой заказчиком разработчику документации для тестирования, проверки и распространения документации. Стандарты определяют реализацию процесса документирования, описанного в ISO 12207, и могут быть адаптированы к условиям и требованиям конкретного проекта (см. рис. 2.17). Минимальный состав документации определяВ.В. Липаев. Тестирование компонентов и комплексов программ ется заказчиком (например, с использованием ISO 12207 или ISO 6592), что должно быть учтено при разработке плана документирования.

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

конкретной эксплуатационной среды и ее характеристики;

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

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

возможностей, функций и характеристик программного комплекса и системы;

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

форм регистрации обнаруженных дефектов и ошибок;

соглашений о внесении изменений, возникающих в процессе сопровождения версии программного комплекса;

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

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

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