СЕРТИФИКАЦИОННЫЕ ИСПЫТАНИЯ ПРОГРАММНОГО ПРОДУКТА НА СООТВЕТСТВИЕ ТРЕБОВАНИЯМ

ЛЕКЦИЯ 10.4 СЕРТИФИКАЦИОННЫЕ ИСПЫТАНИЯ ПРОГРАММНОГО ПРОДУКТА

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

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

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

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

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

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

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

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

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

Рис. 10.1

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

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

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

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

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

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

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

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

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

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

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

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

Процесс сертификации программных продуктов включает:

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

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

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

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

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

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

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

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

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

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

Заключение по результатам сертификационных испытаний

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

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

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

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

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

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

·         изменения конструкции (состава), комплектности продукции;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Комиссия при испытаниях должна руководствоваться следующими документами (см. рис. 10.1):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Результаты испытаний фиксируются в протоколах (см. стандарт ISO 12119 и рис.10.1), которые обычно содержат следующие разделы:

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

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

·         условия и сценарии проведения тестирования и характерис тики исходных данных при динамическом испытании;

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

·         описание отличий тестовой и реальной эксплуатационной среды;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

·         длительность исполнения заданий при реализации конкрет ных функций;

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

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

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

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

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

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

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

При использовании комплексом программ производительности и памяти реализующей ЭВМ менее чем на 50%, разработчик может практически не учитывать эти ограничения и сопутствующие риски. Закономерным является стремление разработчиков программ применять, особенно для систем реального времени, встроенные объектные ЭВМ с предельным использованием их технических характеристик. Опыт создания ПС реального времени позволяет утверждать, что практически невозможно использовать производительность объектной ЭВМ более чем на 95%, и почти всегда целесообразно ограничиваться на уровне 80 - 90%, так как иначе, затраты на разработку программного продукта могут значительно увеличиться.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

·         исходные требования;

·         процессы измерений;

·         результирующие данные;

·         проверка корректности результатов;

·         расчеты производительности;

·         оценивание достоверности измерений производительности.

Если предварительно в процессе проектирования производи

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

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

КОНТРОЛЬНЫЕ ВОРОСЫ

Раздел 1: Общие положения и порядок сертификационных испытаний

1.       Какова основная цель сертификации программных продуктов?

2.       Что является формальной целью сертификации?

3.       Назовите три фактора, которые учитываются при принятии решения о выдаче сертификата соответствия.

4.       Как международные стандарты определяют сертификацию соответствия?

5.       Кто является первой, второй и третьей стороной в процессе сертификации?

6.       Что такое сертификат соответствия и какой орган его выдает?

7.       Какие объекты, помимо конечного программного продукта, могут сертифицироваться?

8.       Какое преимущество дает поставщику лицензия, выданная по результатам сертификации?

9.       Где проводятся сертификационные испытания?

10.   Какие ресурсы являются определяющими для проведения сертификации?

11.   Кто такой заявитель и какова его роль в процессе сертификации?

12.   Какие документы заявитель может представить в орган по сертификации для сокращения объема испытаний?

13.   Перечислите основные этапы процесса сертификации программных продуктов.

14.   Что должно быть обеспечено для удостоверения качества продукта в рамках Программы испытаний?

15.   Какая информация содержится в протоколах испытаний?

16.   Что такое инспекционный контроль и в каких формах он проводится?

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

18.   При каком условии решение о приостановлении сертификата не принимается?

Раздел 2: Программа и методики испытаний

19.   На что может ориентироваться Программа сертификационных испытаний?

20.   Почему планирование и реализация испытаний описываются как процесс, а не единовременный акт?

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

22.   Какие два основных метода организации тестовых процедур (архитектуры тестирования) представлены в лекции?

23.   Какими документами должна руководствоваться комиссия при проведении испытаний?

24.   Что такое матрица трассирования тестов и для чего она нужна?

25.   Какова основная цель Программы испытаний?

26.   Какие разделы должна содержать четко сформулированная Программа испытаний?

27.   Что должна содержать Методика испытаний?

28.   Какие факторы становятся важнейшими при обработке большого объема данных испытаний?

29.   Какие разделы обычно содержат протоколы испытаний (согласно стандарту ISO 12119)?

30.   В какой документ обобщаются протоколы испытаний и какой итоговый вывод в нем делается?

Раздел 3: Испытания надежности функционирования

31.   Какие характеристики программного продукта имеют особое значение для систем реального времени?

32.   В чем состоит основная особенность тестирования надежности?

33.   Какова задача тестирования при различной интенсивности потоков тестов?

34.   На какие интегральные характеристики влияют экстремальные условия тестирования?

35.   Какие количественные характеристики включает оценивание надежности программных комплексов?

36.   В каком окружении должно проводиться тестирование для оценки надежности?

37.   Как надежность может коррелировать с корректностью программного продукта?

38.   Что может служить ориентиром для прогнозирования потенциальной надежности комплекса программ?

39.   Что необходимо для прямых, количественных измерений надежности?

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

41.   Что такое "отказ" в контексте надежности программного продукта?

42.   В чем состоит сложность диагностики случайных редких отказов?

43.   Какова роль службы регистрации отказов?

44.   Как можно выявить тенденцию изменения показателей надежности?

45.   Как организуются прогоны для достоверного определения надежности на заключительных испытаниях?

46.   Что такое "темп обнаружения дефектов" и какой его уровень считается эталоном высокой надежности?

47.   Чем форсированные (стрессовые) испытания надежности отличаются от традиционных методов?

48.   Как осуществляется форсирование испытаний надежности?

49.   Что должен предусматривать план форсированных испытаний?

50.   Назовите основные режимы тестирования при форсированных испытаниях.

51.   Что такое Бета-тестирование и как оно способствует оценке надежности?

52.   В чем состоит цель тестирования восстанавливаемости?

53.   С какими трудностями сталкиваются при достижении и регистрации наработки на отказ >100 часов?

54.   Какова основная цель применения оперативного контроля и рестарта?

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

56.   Как средства контроля и помехозащиты компенсируют влияние на надежность?

57.   Как повышение затрат на тестирование связано с достижением требуемой надежности?

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

Раздел 4: Испытания функциональной безопасности

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

60.   Назовите основные источники отказовых ситуаций, влияющих на безопасность.

61.   В чем близость понятий функциональной безопасности и надежности?

62.   По какому принципу можно разделить понятия надежности и функциональной безопасности?

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

64.   Какие субъективные факторы увеличивают неопределенность значений безопасности?

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

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

67.   Как рост сложности программ влияет на их потенциальную безопасность?

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

69.   Каким образом достигается требуемая функциональная безопасность систем реального времени?

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

Раздел 5: Испытания производительности и использования ресурсов

71.   В чем состоит оценивание ресурсной эффективности программного продукта?

72.   Какова цель испытаний производительности?

73.   Что такое оценивание перегрузок и для чего оно проводится?

74.   Почему для адекватного тестирования на перегрузки необходимы средства автоматизации?

75.   Какие характеристики должны регистрироваться инструментальными средствами для измерения временной эффективности?

76.   Что может привести к нарушению временного баланса при работе программного продукта?

77.   В чем состоит основная задача испытаний по оценке эффективности использования ресурсов ЭВМ?

78.   Почему разработчикам не рекомендуется использовать производительность объектной ЭВМ более чем на 90-95%?

79.   Какие характеристики должны быть измерены для оценки использования производительности в реальном времени?

80.   Каким образом можно ослабить влияние перегрузки ЭВМ по производительности?

81.   На что должна быть ориентирована модель внешней среды для корректного оценивания ресурсной эффективности?

82.   Какой стандарт полезно применять для определения использования ресурсов ЭВМ?

83.   На какие шесть разделов распределены процедуры измерений в стандарте ISO 14756?

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

85.   К чему приводит "оптимизм" разработчиков при интуитивной оценке длительностей решения задач?

ЗАДАНИЯ

Раздел 1: Общие положения и порядок сертификационных испытаний

1. Ситуация: В ходе инспекционного контроля сертифицированного программного обеспечения для банковской системы обнаружено, что после очередного обновления один из ключевых модулей стал обрабатывать транзакции на 15% медленнее, что нарушает требования ТЗ.

Вопросы: 

1. Каковы вероятные причины возникновения такой ситуации?

2. Какие документы необходимо запросить у разработчика для анализа?

3. Может ли орган по сертификации приостановить действие сертификата и при каких условиях?

4.Какие корректирующие мероприятия следует предложить заявителю?

2. Ситуация: Компания-разработчик представила в аккредитованную лабораторию протоколы внутренних испытаний, утверждая, что они покрывают 90% требований ТЗ, и настаивает на сокращении объема сертификационных испытаний.

Вопросы: 

1. На каком основании орган по сертификации может принять решение о сокращении объема испытаний?

2. Какую экспертизу необходимо провести над представленными протоколами?

3. Какие риски несет орган по сертификации, приняв такое решение?

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

Вопросы: 

1. Что входит в понятие сертификации "технологий и систем качества"?

2. Какие действия должна предпринять компания-разработчик для подготовки к такой сертификации? 3.

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

4. Ситуация: Срок действия сертификата соответствия истекает через 3 месяца. Заявитель подал заявку на повторную сертификацию, но в продукт были внесены многочисленные изменения и добавлен новый функционал.

Вопросы: 

1. Будет ли процедура повторной сертификации полностью идентичной первичной?

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

3. Какие документы от заявителя являются наиболее важными в этой ситуации?

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

Вопросы: 

1. Сохраняет ли силу сертификат при смене аппаратной платформы?

2. Какие действия должна предпринять компания-заявитель?

3. Нужна ли полная повторная сертификация или достаточно выборочных испытаний?

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

Вопросы: 

1. Является ли это основанием для отказа в выдаче сертификата?

2.  Какие процедуры в лаборатории могли допустить такую ошибку?

3.  Какие корректирующие действия должна предпринять лаборатория?

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

Вопросы: 

1. Какие санкции может применить орган по сертификации?

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

8. Ситуация: Две аккредитованные лаборатории проводят испытания одного и того же продукта по идентичным методикам и получают статистически значимо разные результаты по показателю "время отклика".

Вопросы:

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

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

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

Вопросы: 

1. Должен ли орган по сертификации принимать такие протоколы?

2. Какие процедуры необходимо выполнить для их признания (нотариальный перевод, экспертиза на соответствие стандартам)?

3. Кто несет расходы?

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

Вопросы: 

1. Обязан ли заявитель привести продукт в соответствие с новой версией стандарта?

2. Сохраняет ли силу сертификат, выданный на предыдущую версию?

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

Раздел 2: Программа и методики испытаний (Задачи 11-20)

11. Ситуация: В крупном проекте заказчик постоянно меняет и дополняет требования (эффект "scope creep"). Команда разработки вносит изменения, но документация по тестам устаревает и не соответствует текущей версии продукта.

Вопросы: 

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

2. Что должно произойти с Программой и методиками испытаний при каждом изменении ТЗ?

3. Как обеспечить актуальность матрицы трассировки тестов?

12. Ситуация: Бюджет проекта на сертификацию был сокращен на 30%. Руководство требует провести испытания в полном объеме, но с меньшими затратами.

Вопросы: 

1. Какие этапы или виды испытаний являются наиболее затратными?

2. На чем можно сэкономить с наименьшим риском для качества итоговой оценки?

3. Можно ли сократить объем испытаний за счет анализа рисков?

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

Вопросы: 

1. Правомерны ли действия заказчика?

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

3.  Как регламентировать использование тестовых данных в контракте и Программе испытаний?

14. Ситуация: Требования ТЗ к производительности сформулированы расплывчато: "система должна работать без задержек".

Вопросы: 

1.     Можно ли проводить сертификационные испытания с такими требованиями?

2.     Какие действия должен инициировать орган по сертификации или испытательная лаборатория?

3.     Как формализовать такие требования для проведения измерений?

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

Вопросы: 

1.     Кто несет ответственность за исправление дефектов интеграции?

2.      Как в Программе испытаний должны быть распределены роли и ответственность между субподрядчиками?

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

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

Вопросы: 

1.     Можно ли проводить испытания вручную?

2.     Как это повлияет на трудоемкость, длительность и достоверность результатов?

3.     Какие риски возникают при отказе от автоматизации?

17. Ситуация: При проверке системы качества разработчика обнаружено, что в компании не ведется журнал регистрации дефектов (bug tracker) в едином формате.

Вопросы: 

1.     Является ли это нарушением, критичным для сертификации процессов?

2.     Как отсутствие систематизированных данных о дефектах влияет на оценку надежности и потенциала для улучшения продукта?

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

Вопросы: 

1.     Чья это ответственность — разработчика генератора или испытательной лаборатории?

2.     Как проверить адекватность тестовых данных до начала основных испытаний?

3.     Какие риски это несет для итогового заключения?

19. Ситуация: Проектная документация содержит противоречия: в ТЗ указаны одны значения для времени отклика, а в спецификациях — другие.

Вопросы: 

1.     Каким документом следует руководствоваться при проведении испытаний?

2.     Кто должен инициировать разрешение данного противоречия?

3.     Является ли это основанием для приостановки испытаний до внесения ясности?

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

Вопросы: 

1.     Как планировать испытания, зависящие от внешних факторов?

2.     Следует ли разрабатывать заглушки (stubs/mocks) для внешних сервисов?

3.     Кто должен нести ответственность за срывы сроков по внешним причинам?

Раздел 3: Испытания надежности функционирования (Задачи 21-30)

21. Ситуация: При испытаниях комплекса программ управления энергосистемой выявлен дефект, который проявляется только при одновременном поступлении данных с 98% датчиков и в 0,1% случаев приводит к полному отказу системы. Исправление дефекта требует 6 месяцев работы.

Вопросы: 

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

2.     Можно ли выдать сертификат соответствия с данным дефектом?

3.     Какие компенсирующие меры или изменения в документации можно предложить для снижения риска?

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

Вопросы: 

1.     О какой характеристике надежности идет речь (завершенность, восстанавливаемость, устойчивость к дефектам)?

2.     Какие ошибки в процессе тестирования привели к тому, что дефект не был выявлен?

3.     Как необходимо дополнить методики испытаний, чтобы выявлять подобные дефекты в будущем?

23. Ситуация: Заказчик требует обеспечить наработку на отказ в 10 000 часов. Предварительные расчеты и испытания показывают, что достижимый показатель составляет 5 000 часов. Длительность испытаний для подтверждения 10 000 часов превышает разумные сроки проекта.

Вопросы: 

1.     Какие косвенные методы оценки надежности можно применить?

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

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

Вопросы: 

1.     Можно ли по этому результату считать надежность достаточной?

2.     Как классифицировать такой инцидент: сбой или отказ?

3.      Как средства оперативного восстановления влияют на измеряемые показатели надежности?

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

Вопросы: 

1.     Как этот инцидент должен быть отражен в протоколах?

2.     Следует ли начинать испытания заново или можно суммировать данные до и после сбои?

3.     Как обеспечить бесперебойность проведения длительных экспериментов?

26. Ситуация: В ходе испытаний производительности выявлено, что при длительной работе (более 24 часов) происходит утечка памяти, приводящая к постепенному замедлению системы и ее последующему отказу.

Вопросы: 

1.     К какой характеристике качества относится данный дефект?

2.     Какие инструментальные средства необходимы для его обнаружения?

3.     Почему этот дефект мог быть пропущен при модульном тестировании?

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

Вопросы: 

1.     О чем говорит данная тенденция?

2.     Как использовать эти данные для прогнозирования надежности следующей версии?

3.     Следует ли рекомендовать заказчику избегать первых версий крупных обновлений?

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

Вопросы: 

1.     Как можно проверить восстанавливаемость, не нарушая гарантийные условия?

2.     Можно ли использовать эмуляцию аппаратных сбоев?

3.     Будет ли такой тест считаться достоверным?

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

Вопросы: 

1.     Как подойти к тестированию и документированию невоспроизводимых ошибок?

2.     Можно ли считать продукт ненадежным, если дефект проявляется редко?

3.     Какова должна быть позиция испытателей в отчете?

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

Вопросы: 

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

2.     В каком случае орган по сертификации может принять их к сведению?

Раздел 4: Испытания функциональной безопасности (Задачи 31-40)

31. Ситуация: Система управления беспилотным автомобилем демонстрирует высокую надежность в 99,99% тестовых сценариев. Однако в 0,01% случаев в специфических погодных условиях система принимает катастрофически неверное решение.

Вопросы: 

1.     Как оценить риски такого поведения системы?

2.     Можно ли сертифицировать такой продукт?

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

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

Вопросы: 

1.     Является ли недостаток документации основанием для отказа в сертификации?

2.     Как связаны качество документации и функциональная безопасность?

3.     Какие разделы документации должны быть проверены с наибольшим приоритетом?

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

Вопросы: 

1.     Должна ли лаборатория руководствоваться буквой ТЗ (формальное соответствие) или современными представлениями о безопасности (фактическое соответствие)?

2.     Как оформить данное замечание в протоколе?

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

Вопросы:

1.     Может ли уязвимость, не известная на момент сертификации, быть основанием для отмены сертификата?

2.     Какие процедуры должны быть у заявителя для оперативного реагирования на такие инциденты?

3.     Должен ли орган по сертификации участвовать в этом процессе?

35. Ситуация: Эксперты пришли к выводу, что для полной проверки требований безопасности необходимо провести пентест (тестирование на проникновение), но в аккредитации лаборатории данный вид испытаний не указан.

Вопросы: 

1.     Может ли лаборатория проводить такие испытания?

2.     Какие действия необходимо предпринять лаборатории для получения необходимых полномочий?

3.     Как быть заявителю, если сроки поджимают?

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

Вопросы: 

1.     Как в этом случае можно проводить оценку корректности и безопасности?

2.     Какие методы динамического анализа могут стать альтернативой?

3.      Можно ли заключить соглашение о неразглашении (NDA)?

37. Ситуация: ИИ-система для подбора лекарств демонстрирует высочайшую точность, но ее решения невозможно логически объяснить ("black box"). Регулятор требует объяснимость для сертификации в медицинской сфере.

Вопросы: 

1.     Является ли "объяснимость" (explainability) нефункциональным требованием, которое можно добавить в ТЗ?

2.     Как тестировать и доказывать соответствие требованию к объяснимости?

3.     Может ли это стать непреодолимым барьером для сертификации подобных систем?

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

Вопросы: 

1.     Как проводить сертификационные испытания недетерминированной системы?

2.     Какие новые методики и критерии оценки необходимо разработать?

3.     Как доказать "необходимую уверенность" в соответствии требованиям?

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

Вопросы: 

1.     Как в данном случае можно проводить оценку надежности и безопасности?

2.     Какие дополнительные документы или гарантии можно запросить у поставщика библиотеки?

3.     Как этот факт должен быть отражен в документации и сертификате?

40. Ситуация: Разработчик хочет сертифицировать свою систему управления, но она построена на основе свободно распространяемых компонентов (open source) с разными лицензиями.

Вопросы: 

1.     Влияет ли природа компонентов (проприетарные/open source) на возможность и процедуру сертификации?

2.     Какие дополнительные юридические и технические риски необходимо оценить?

Раздел 5: Испытания производительности и использования ресурсов (Задачи 41-50)

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

Вопросы:

1.     В чем может заключаться причина расхождения между испытательной и реальной средой?

2.     Какие разделы Программы испытаний могли быть выполнены неудовлетворительно?

3.      Кто несет ответственность за данное несоответствие: разработчик, испытательная лаборатория или заказчик?

42. Ситуация: 

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

Вопросы: 

1.     Кто имеет право на "расширение условий испытаний в пределах требований"?

2.     Как аргументировать необходимость проведения форсированных испытаний?

3.     Какие риски возникают, если пойти навстречу разработчикам и исключить тест?

43. Ситуация: При испытаниях в реальном времени система должна обрабатывать 1000 транзакций в секунду. На испытательном стенде достигается показатель в 950 транзакций. Заказчик настаивает на выполнении контрактного значения.

Вопросы: 

1.     Можно ли считать испытания проваленными?

2.     Какие факторы могут объяснить расхождение?

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

44. Ситуация: Адекватное проведение динамического испытания на перегрузки при использовании ручных методов подготовки тестов — дорого и трудоемко.

Вопросы: 

1.     Какие средства автоматизированного тестирования необходимы?

2.     Какие характеристики они должны позволять оценивать? К

3.     акова экономическая целесообразность их приобретения/разработки?

45. Ситуация: В процессе сертификации выяснилось, что ключевой специалист-сертификатор, отвечающий за данный тип продуктов, уволился из лаборатории.

Вопросы: 

1.     Может ли это повлиять на ход и результаты испытаний?

2.     Какие требования к квалификации "коллектива специалистов-сертификаторов" предъявляются в лекции?

3.     Должна ли лаборатория уведомлять заявителя о таких кадровых изменениях?

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

Вопросы: 

1.     Что должен сделать заявитель для сохранения действия сертификата?

2.     Нужно ли проводить полный цикл испытаний при миграции на новую платформу?

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

Вопросы: 

1.     Какие законные варианты решения проблемы существуют?

2.     Можно ли изменить схему сертификации?

3.     Кто должен нести дополнительные расходы?

48. Ситуация: 

Заказчик требует 100% покрытия тестами всех строк кода (code coverage).

Разработчик демонстрирует показатель в 98%, утверждая, что оставшиеся 2% — это код обработки исключительных ситуаций, которые невозможно смоделировать на стенде.

Вопросы: 

1.     Является ли 100% coverage гарантией высокого качества?

2.     Как можно протестировать код обработки исключений?

3.     Является ли невыполнение требования заказчика основанием для отказа в сертификации?

49. Ситуация: По результатам испытаний продукт в целом соответствует требованиям, но комиссия заказчика отказывается подписывать акт сдачи-приемки, ссылаясь на неудобный пользовательский интерфейс, хотя требований к UI в ТЗ нет.

Вопросы: 

1.     Правомерен ли отказ заказчика?

2.     Как формализовать "удобство использования" для того, чтобы включить его в перечень проверяемых характеристик?

3.     Можно ли считать испытания проваленными по субъективной причине?

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

Вопросы: 

1. Будет ли действовать предыдущий сертификат?

2. Можно ли провести сравнительный анализ стандартов и выполнить только дополнительные испытания?

3.Какова типичная процедура признания иностранного сертификата?