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

ЛЕКЦИЯ 10.3 ПОДГОТОВКА СЕРТИФИКАЦИОННЫХ ИСПЫТАНИЙ ПРОГРАММНЫХ ПРОДУКТОВ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лидер должен:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 9.2

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

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

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

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

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

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

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

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

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

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

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

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

Рис.9.3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

·         числа команд в выделенных маршрутах или расчетной дли тельности их реализации (стратегия 1);

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

·         вероятности исполнения маршрутов при реальном функционировании программы (стратегия 3).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сложность тестирования групп программ определяется сложностью модулей и межмодульных связей по управлению и по информации. Каждый модуль тестируется автономно до включения в группу программ и частично в составе группы. Затраты на тестирование модулей в составе группы программ должны учитывать относительные суммарные затраты на тестирование всех входящих моду лей с коэффициентом <1, зависящим от степени проверки соответствующего модуля. Если модули автономно не тестировались (напри мер, при нисходящем тестировании), то коэффициент =1 и затраты на тестирование каждого модуля войдут в затраты при тестировании группы программ в полном объеме. При тщательном автономном тестировании модулей можно полагать коэффициент = 0,1 - 0,01, т.е. в ПС затраты на тестирование модулей составляют несколько процентов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Такая модель должна отражать характеристики:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для их реализации должны выделяться достаточно мощные универсальные моделирующие ЭВМ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Некоторые значения тестов не только трудно создать при натуральных экспериментах, но они являются маловероятными в реальных условиях.

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

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

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

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

- 10⁶ строк текста и должны создаваться с применением современных технологических систем.

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

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

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

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

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

Раздел 1: Требования к квалификации испытателей

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

2.       Как рост сложности ПО повлиял на требования к специалистам по испытаниям?

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

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

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

6.       Почему испытатель должен быть административно независим от программистов?

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

8.       Почему необходимо санкционирование изменений документов на каждом уровне?

9.       При каких условиях специалист по испытаниям высокорисковых продуктов должен быть аттестован?

10.   К чему могут привести недостатки в обосновании ресурсов специалистов?

11.   Почему важно активно привлекать заказчика к управлению испытаниями?

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

13.   Каковы типичные причины многократных изменений в техническом задании?

14.   К чему приводит попытка заказчика форсировать сроки разработки?

15.   На сколько процентов могут увеличиться затраты из-за корректировок ТЗ на поздних этапах?

16.   В чем заключаются различия во взглядах заказчика и разработчика на проект?

17.   Что такое «зоны неоднозначности и взаимного непонимания» и к чему они приводят?

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

19.   Какую роль в коллективе испытателей играют проблемно-ориентированные аналитики и системные архитекторы?

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

Раздел 2: Методы подготовки тестов

21.   Почему ручная пошаговая подготовка тестов неэффективна для крупных комплексов программ реального времени?

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

23.   Чем отличаются два представления комплексов программ (функциональное и событийное)?

24.   От чего зависит выбор типов моделей для генерации тестов?

25.   Дайте определение автоматизации испытаний.

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

27.   Почему автоматизация тестирования остается большим и рискованным мероприятием?

28.   Сравните затраты на поэтапную автоматизацию генерации тестов и на ручное написание тестов.

29.   Что необходимо выстроить для создания удобных для сопровождения автоматизированных тестов?

30.   Какое решение предлагается для ускорения регрессионного тестирования?

31.   Что такое «испытательный стенд» и для каких целей его строят?

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

33.   На основе каких источников могут формироваться правила для генераторов тестов?

34.   Какова роль генераторов тестовых процедур, интегрированных в процесс анализа и проектирования?

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

Раздел 3: Стратегии выбора тестов для модулей и компонентов

36.   Что позволяет детально анализировать относительная простота программных модулей (ПМ)?

37.   Назовите две основные стратегии тестирования программных модулей.

38.   Каким двум методам тестирования соответствуют эти стратегии?

39.   Опишите суть первой стратегии тестирования («от структуры»).

40.   Что рассматривается как ошибка при тестировании по первой стратегии?

41.   Как оценивается достаточность тестирования по первой стратегии?

42.   Какая проблема возникает при первой стратегии из-за противоречивых условий в программе?

43.   Опишите суть второй стратегии тестирования («от данных»).

44.   Какой основной недостаток у второй стратегии?

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

46.   Для каких типов модулей предпочтительнее начинать тестирование с первой стратегии?

47.   Почему исчерпывающее тестирование принципиально невозможно?

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

49.   Какова первая задача, решаемая при тестировании структуры программ?

50.   Какие две основные задачи возникают при планировании тестирования структуры?

51.   Назовите три основных критерия выделения маршрутов для тестирования.

52.   Что может приводить к сокращению числа выделяемых по критериям маршрутов?

53.   На основе каких трех характеристик упорядочиваются маршруты при планировании тестирования?

54.   Для каких программ целесообразна стратегия 1 (по числу команд)?

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

Раздел 4: Динамические тесты, имитация внешней среды и обработка результатов

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

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

58.   На что ориентированы методы динамических испытаний с исполнением комплекса программ?

59.   Почему при оценивании качества программ необходимо до начала испытаний определить параметры внешней среды?

60.   Что должна совместно сделать команда заказчика и разработчика перед испытаниями?

61.   Какие характеристики должна отражать модель внешней среды?

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

63.   Назовите четыре ключевых преимущества программной имитации динамических тестов на ЭВМ.

64.   Какие компоненты входят в состав инструментальной базы для обеспечения ЖЦ сложных комплексов ПО?

65.   Что такое «план-сценариев тестирования» и «обобщенные исходные данные»?

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

67.   Какую роль играют данные с рабочих мест операторов-пользователей в МИС?

68.   Каким образом обеспечивается повторяемость сеансов испытаний при автоматической имитации?

69.   На какие две части разделяется обработка результатов испытаний ПО реального времени?

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

ЗАДАНИЯ

Раздел 1: Требования к квалификации испытателей и управление командой

1.        Ситуация: В крупном проекте по разработке АСУ ТП заказчик постоянно меняет техническое задание, ссылаясь на новые рыночные требования. Команда испытателей не успевает адаптировать тестовые сценарии, возникают конфликты с разработчиками.

Вопросы:

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

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

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

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

Вопросы: 

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

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

3. Почему административная независимость тестировщиков жизненно важна?

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

Вопросы: 

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

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

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

Вопросы: 

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

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

5.        Ситуация: Руководитель проекта, не имеющий опыта в тестировании, требует от команды испытателей сократить сроки тестирования на 40% для скорейшего выпуска продукта на рынок.

Вопросы:

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

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

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

Вопросы: Какие действия необходимо срочно предпринять менеджеру проекта?

1. На основе каких документов (согласно лекции) должны быть оформлены

2. требования к квалификации и аттестации?

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

Вопросы:

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

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

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

Вопросы: 

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

2. Какую роль в этом может сыграть руководство?

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

Вопросы: 

1. Какие человеческие факторы и личные качества становятся ключевыми в этой ситуации

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

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

Вопросы:

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

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

Раздел 2: Методы подготовки тестов и автоматизация испытаний

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

Вопросы: 

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

2. В каких случаях автоматизация действительно имеет смысл?

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

Вопросы: 

1. Почему этот метод неэффективен для крупных систем?

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

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

Вопросы: 

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

2. О чем говорит схема на Рис. 9.2?

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

Вопросы: 

1. Какое решение предлагается в лекции для ускорения этого процесса?

2. Что такое «автоматизированная динамическая тестовая среда постоянно действующей конфигурации» и «испытательный стенд»?

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

Вопросы: 

1. Какой тип инструментов может помочь в решении этой проблемы?

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

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

Вопросы: 

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

2. Что такое «динамическая имитация реальной внешней среды» и как она помогает достичь высокого уровня соответствия требованиям?

17.   Ситуация: Генератор тестовых процедур, интегрированный в процесс проектирования, автоматически создает тесты на основе спецификаций системной архитектуры.

Вопросы: 

1. Какое преимущество дает такой подход?

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

18.   Ситуация: Заказчик сомневается в целесообразности инвестиций в дорогостоящую систему автоматизации динамического тестирования.

Вопросы:

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

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

19.   Ситуация: При автоматизации тестирования GUI интерфейса тесты постоянно "ломаются" из-за незначительных изменений в интерфейсе, что сводит на нет всю экономию.

Вопросы: 

1. В чем заключается основная проблема подхода к автоматизации в этом случае?

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

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

Вопросы: 

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

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

Раздел 3: Стратегии выбора тестов для модулей и компонентов

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

Вопросы: 

1. Почему этого оказалось недостаточно?

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

3.  Как совместить обе стратегии?

22.   Ситуация: При тестировании ПМ по первой стратегии (от структуры) выявлены маршруты, которые являются принципиально нереализуемыми из-за противоречивых условий.

Вопросы:

1. Чем это грозит процессу тестирования?

2. Как можно выявить такие маршруты на этапе планирования тестирования?

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

23.   Ситуация: Испытатель столкнулся с проблемой: при тестировании по второй стратегии (от данных) трудно оценить, все ли маршруты исполнения программы были проверены.

Вопросы: 

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

2. Почему без структурного графа программы эта задача сложна?

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

Вопросы:

1. На основе каких критериев и метрик (покрытие графа, затраты ресурсов) можно принять это решение?

2.  Почему исчерпывающее тестирование невозможно в принципе?

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

Вопросы: 

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

2. Что такое цикломатическое число и как оно помогает?

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

Вопросы: 

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

27.   Ситуация: Профилирование программы показало, что 3% операторов потребляют 50% времени исполнения. Ресурсы на тестирование ограничены.

Вопросы: 

1. Как следует скорректировать стратегию тестирования на основе этой информации?

2. На проверке каких маршрутов и компонентов следует сосредоточиться в первую очередь?

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

Вопросы: 

1. Как должен работать этот процесс?

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

29.   Ситуация: Сложность программного модуля определяется не 1000 строк кода, а 200 возможными путями исполнения. Один из модулей имеет аномально высокую сложность.

Вопросы:

1. Почему число маршрутов является ключевым фактором сложности?

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

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

Вопросы: 

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

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

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

Раздел 4: Динамические тесты, имитация внешней среды и обработка результатов

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

Вопросы: 

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

2. Какова структура моделирующего испытательного стенда (МИС)?

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

Вопросы: 

1. В чем принципиальная разница между этими подходами?

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

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

Вопросы: 

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

2. Что необходимо сделать, если в сценарии активно участвует оператор-пользователь?

34.   Ситуация: Заказчик требует, чтобы в составе поставляемого программного продукта были средства для оперативного контроля его работоспособности после развертывания.

Вопросы: 

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

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

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

Вопросы: 

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

2. Как органически вписать процесс тренировки операторов в общий процесс испытаний?

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

Вопросы: 

1. Какие две стратегии селекции результатов («снизу вверх» и «сверху вниз») можно применить?

2.  В чем их преимущества и недостатки? Как найти компромисс между полнотой и удобством анализа?

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

Вопросы: 

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

2. Какие задачи решает каждая из них?

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

Вопросы: 

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

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

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

Вопросы: 

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

2. Что такое «аналоги системы и аппаратуры внешней среды» и какова их роль?

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

Вопросы: 

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

Раздел 5: Оценка эффективности и комплексные кейсы

41.   Ситуация: Затраты на создание комплекса программной имитации внешней среды для тестирования системы УВД сопоставимы с затратами на разработку самого тестируемого ПО.

Вопросы: 

1. Как обосновать такие значительные инвестиции?

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

42.   Ситуация: Стоит выбор: проводить натурные эксперименты с реальными объектами или инвестировать в создание программного имитатора. Необходимо провести сравнительный анализ эффективности.

Вопросы: 

1. На какие две части разделяется анализ эффективности программной имитации?

2. Каким показателем можно оценить экономическую эффективность?

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

Вопросы: 

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

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

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

Вопросы: 

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

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

45.   Ситуация: При комплексной отладке программного продукта центра УВД невозможно достоверно автоматически имитировать реакцию диспетчеров на нестандартные ситуации.

Вопросы: 

1. Как решается эта проблема в рамках моделирующего стенда?

2.  Почему человеческий фактор диспетчера является одновременно и элементом системы, и источником неопределенности?

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

Вопросы:

1.  Разработайте комплексный план действий для менеджера проекта на ближайшие 3 месяца, основанный на принципах из лекции. Расставьте приоритеты.

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

Вопросы:

 1. Проведите ретроспективный анализ: какие ошибки, скорее всего, были допущены в организации процесса испытаний?

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

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

Вопросы: 

1. Какие именно средства генерации тестов и имитации среды, согласно лекции, должны были быть включены в комплект поставки?

2.  Кто несет ответственность за это упущение?

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

Вопросы: 

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

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

Вопросы: 

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

2.Обоснуйте каждый шаг.