67315

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

Лекция

Информатика, кибернетика и программирование

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

Русский

2014-09-07

247.5 KB

17 чел.

PAGE  8

Глава 14. Интеграция,  квалификационное тестирование и испытания комплексов программ

14.1.  Процессы оценивания характеристик и испытания                           программных средств

      Для оценивания характеристик и испытаний программных средств на различных этапах жизненного цикла в качестве методологической основы целесообразно использовать рекомендации стандарта ISO 14598:1-6 –Оценивание программного продукта. Процесс оценивания ПС в стандарте представлен как совокупность действий, выполняемых в кооперации  заказчиком и оценщиком – испытателем.  Потенциальными заказчиками оценивания ПС могут быть разработчики,  поставщики,  покупатели,  пользователи ПС, производители систем  обработки информации, а также  третейские испытательные лаборатории  программных продуктов. Для получения наибольшего  эффекта от  результатов испытаний  рекомендуется,  чтобы оценивание было насколько возможно:

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

      Общую схему процессов оценивания характеристик комплексов программ составляют (рис. 14.1):

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

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

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

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

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

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

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

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

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

  •  введение  –  постановка задачи и цели оценивания – испытаний;
  •  методология, обеспечения объективности испытаний характеристик ПС;
  •  выделенные для проекта характеристики и атрибуты качества и безопасности ПС по стандарту ISO 9126:1-4 и другим стандартам;
  •  требуемое качество ПС и достоверности процессов испытаний;
  •  расписание выполнения работ по испытаниям характеристик ПС;
  •  распределение обязанностей и ответственности специалистов при  оценивании  характеристик и атрибутов качества;
  •  анализ и использование результатов испытаний;
  •  содержание и оформление отчетов по выполнению испытаний;
  •  дополнительные требования по технике, инструментальным средствам и методам обслуживания испытаний, по соответствию стандартам и организационной поддержке измерений и экспертиз.

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

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

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

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

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

С позиций разных потребителей результатов измерения и оценивания качества ПС построены третья, четвертая и пятая части стандарта ISO 14598:1-6 –  соответственно для:

  •  разработчиков – оценивание внутренних и внешних характеристик  качества (ч.3);
  •  оперативных пользователей – измерение внешних метрик и метрик в использовании (ч.4);
  •  заказчиков и испытателей – определение метрик в использовании (ч.5).

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

     Результаты оценки характеристик предлагается отражать с позиции: процессов жизненного цикла; продуктов и их компонентов; функционирования и применения  ПС.  Требования к процессам оценивания рекомендуется структурировать на главные (функциональные), организационные,  проектные, а также выделять внутренние и внешние метрики качества и их измерение,  ориентируясь на субхарактеристики и их атрибуты в соответствующих частях стандарта ISO 9126:1-4. Реализация процессов испытаний программного продукта по требованиям стандарта должна проводиться квалифицированными и аттестованными специалистами, независимыми от разработчиков проекта, процессов создания ПС и его компонентов, однако, коррелированно  с этапами жизненного цикла конкретного проекта в соответствии с применяемой адаптированной версией стандарта ISO 12207.

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

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

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

         

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

         

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

         

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

       

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

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

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

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

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

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

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

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

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

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

Влияние таких ситуаций перегрузки ЭВМ по производительности, может быть ослаблено путем применения приоритетных дисциплин оперативной диспетчеризации исполнения заданий на решение функциональных задач. В зависимости от характеристик потоков заданий и предполагаемых длительностей их реализации, могут распределяться приоритеты на их решения, и тем самым,  повышаться эффективность использования ограниченной производительности вычислительной системы для определенного комплекса программ.  Быстрый рост количества решаемых задач, их сложности и требуемой производительности вычислительных средств стимулировал поиск путей удовлетворения потребностей заказчиков в ресурсах для решения таких задач.  Значительное внимание было уделено анализу эффективности дисциплин диспетчеризации с относительными и абсолютными приоритетами. Эти дисциплины активно применялись при организации вычислений в специализированных, объектных ЭВМ реального времени.  Они позволяли повышать эквивалентную производительность ЭВМ на 10 – 20% по сравнению с бесприоритетными  дисциплинами диспетчеризации.  Показано, что во многих случаях целесообразно применять при диспетчеризации функциональных задач не более 10 – 15 уровней приоритета, при загрузке ЭВМ на 80 – 95% и при значительном различии длительностей и коэффициентов важности (10 – 100)  приоритетных  задач.  Для практического использования характеристик и методов расчета рационального распределения производительности ВС  созданы методики и типовые модели, позволяющие анализировать и оптимизировать диспетчеризацию в конкретных системах. При ограничениях ресурсов вследствие требований минимизации весов и габаритов  специализированных, объектных ЭВМ в авиационных, ракетных и космических системах,  их экономное использование остается актуальным. Кроме того, в некоторых случаях полезно выделение высоких приоритетов для особо важных или коротких задач, например, для обмена с внешними абонентами.

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

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

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

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

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

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


 

А также другие работы, которые могут Вас заинтересовать

9218. Введение в предмет. Общая патология 25.56 KB
  Введение в предмет. Общая патология. Система представлений об основных закономерностях болезней человека, как о целостных биологических явлениях. Состоит из 3 частей: 1. Пат. Анатомия. 2. Пат. Физиология. 3. Клиническая патология. Вирхов Рудольф (18...
9219. Перекрестная резистентность 29.14 KB
  Перекрестная резистентность При такой резистентности увеличивается устойчивость к другому стрессовому фактору (например: закаливание). Перекрестная сенсибилизация Снижение реакции к другому действующему фактору (например: оклиматизация). Болезни стр...
9220. Патофизиология лейкопоэза 28.04 KB
  Патофизиология лейкопоэза Костный мозг находится во всех плоских костях, головках трубчатых костей. Стволовые клетки. Имеет 3 класса: полипотентная стволовая клетка. Относительно унипотентная - клетки предшественницы лимфопоэза и ми...
9221. Патофизиология эритропоэза 27.36 KB
  Патофизиология эритропоэза ОЦК: у женщин - 6,5-7% от массы тела у мужчин 7-7,5% Гематокрит: 0,36-0,46 - соотношение между клеточной и жидкой частью крови Объем циркулирующей крови: в пределах нормы - нормоволемия, при уменьшении...
9222. Анемии Анемии вследствие нарушения кровообразования 27.46 KB
  Анемии Анемии вследствие нарушения кровообразования Железодефицитные анемии. Причины дефицита железа: менструальные потери, лактации, беременность, растущий ребенок, подросток, поражение желчно-кишечного тракта. Проявления сидеропении Синдром сидеро...
9223. Опухолевый рост типический патологический процесс 27.25 KB
  Опухолевый рост Опухоль (новообразование) - типический патологический процесс. Возникает под действием канцерогена. Проявляется патологическим разрастанием структурных элементов ткани, не связанным с общим обменом веществ. Характеризуется атипизмом ...
9224. Стадии канцерогенеза (патогенез опухолей) 24.15 KB
  Стадии канцерогенеза (патогенез опухолей) Инициация (мутация) - превращение здоровой клетки в опухоль Промоция Опухолевая прогрессия (если опухоль злокачественная) Гемобластозы Правила опухолевой прогрессии Фулдаса-Воробьев...
9225. Воспаление - типический патологический процесс. 28.01 KB
  Воспаление Воспаление - типический патологический процесс. Возникает в ответ на действие патогенных (флогогенных) факторов Проявляется в идее комплекса местных и общих реакций, сформировавшихся в ходе эволюции в качестве защитных ме...
9226. Местные (кардиальные) признаки воспаления 28.84 KB
  Местные (кардиальные) признаки воспаления Жар (calor) - связан с притоком теплой артериальной крови в очаг воспаления, изменение обмена веществ в самом очаге воспаления, в связи с повреждением мембраны разобщается окислительно фосфорилировани и...