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

Внутрішньобанківська платіжна система.

Внутрішньобанківська платіжна система – це сукупність правил, організаційних заходів, програмно-технічних засобів, засобів захисту, що використовуються банком для виконання внутрішньобанківського переказу. Така система існує для взаємодії з іншими банківськими системами. Згідно інструкції про банківський переказ, вимоги щодо функціонування ВПС – КБ самостійно визначає умови функціонування, але з урахуванням вимог законодавства України, Правила узгоджуються з НБУ, копії яких передаються до НБУ. КБ повинні:

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

2) програмно-технічне забезпечення має багаторівневий захист інформації від санкціонованого доступу, фальсифікації;

3) автоматичне ведення протоколу найкритичних моментів роботи;

4) зберігання архівів електронних документів;

5) надійне резервування для підтримки безперебійного функціонування.

Для оценивания характеристик и испытаний программных средств на различных этапах жизненного цикла в качестве методологической основы целесообразно использовать рекомендации стандарта 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 с, однако ошибки в действиях оператора и вводимых им параметрах могут отличаться в каждом сценарии тестирования. Вследствие этого повторяемость тестов реализуется только статис­тически.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дата добавления: 2014-01-13