Выбор методов верификации отраслевого программного обеспечения

Содержание:

  1. Общие сведения о верификации и аттестации ПО
  2. Верификация и аттестация ПО
  3. Проверка системы программного обеспечения
  4. Проверка программы
  5. Процесс проверки
  6. Автоматический статический анализ программ
  7. Метод "Чистая комната"
  8. Тестирование программного обеспечения
  9. Проверка дефектов
  10. Сборочный тест
  11. Тест интерфейса
  12. Тестовый инструмент
  13. Аттестация критических систем
  14. Сертификация надежности
  15. Обеспечение безопасности
  16. Проверка и аутентификация
  17. Заключение
Предмет: Практика
Тип работы: Отчёт
Язык: Русский
Дата добавления: 07.03.2019

 

 

 

 

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

Если вам тяжело разобраться в данной теме напишите мне в whatsapp разберём вашу тему, согласуем сроки и я вам помогу!

 

По этой ссылке вы сможете посмотреть на готовый отчёт по социальной практике:

 

Готовый отчёт по социальной практике

 

Посмотрите похожие темы возможно они вам могут быть полезны:

 

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

Неравномерность регионального развития в России: причины, последствия, пути преодоления

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

Инфляция и ее последствия

 

Введение:

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

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

Последние достижения в технологии разработки программного обеспечения (ПО) значительно увеличили производительность программиста с точки зрения количества кода, создаваемого за единицу времени. Это особенно очевидно, поскольку размер самых сложных программных систем, разрабатываемых в настоящее время, увеличивается до десятков миллионов строк кода. Однако в этом случае качество программы сильно не изменилось. Среднее количество ошибок на 1000 строк кода, которые еще не были проверены, варьируется от 10 до 50. Таким образом, совершенствование методов разработки программного обеспечения и создание все более сложных систем, необходимых современным экономическим, научным и правительственным учреждениям, парадоксальным образом увеличивает количество и связанные с ними риски их недостатков.

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

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

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

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

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

Общие сведения о верификации и аттестации ПО

Обзор проверки и аутентификации

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

Проверка и аутентификация - это совершенно разные понятия, но они часто путаются.

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

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

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

 

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

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

Выбор методов верификации отраслевого программного обеспечения

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

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

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

Цель программного обеспечения. Уровень достоверности соответствия зависит от важности (важности) программных продуктов, разработанных по любому стандарту. Например, программное обеспечение для медицинского устройства «аппарат искусственного кровообращения» является сверхкритическим, поскольку жизнь человека зависит от качества системы. Примером системы с низкой критичностью является: В частности, это прототипы программных систем, разработанных для демонстрации новых идей.

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

Верификация и аттестация ПО

План проверки и сертификации

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

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

 

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

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

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

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

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

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

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

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

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

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

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

Проверка программы

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

Процесс проверки формализован. Участвует небольшая группа (обычно 4 человека или меньше). У каждого в группе есть роль. Должны присутствовать: автор, рецензент, инспектор, координатор. Рецензенты «говорят» программный код, инспекторы проверяют его, а координаторы несут ответственность за организацию процесса. Как показывает опыт тестирования в вашей организации, при распределении ролей в группе могут появиться другие предложения (например, количество участников в группе тестирования, поскольку один человек может играть несколько ролей).

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

Процесс проверки

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

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

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

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

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

Автоматический статический анализ программ

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

Цель автоматического статического анализа - привлечь внимание тестера к аномалиям программы, таким как переменные, используемые без инициализации, или переменные, инициализированные, но не используемые в программе.

Статический анализ состоит из нескольких этапов.

  1. Анализ потока управления. Идентификация и назначение циклов, их вход и выход, идентификация неиспользуемых кодов.
  2. Анализ использования данных. Проверьте переменные в программе. На этом этапе вы также можете определить условные операторы с избыточными условиями.
  3. Интерфейсный анализ. Проверьте целостность различных частей программы, правильное объявление процедур и их использование. Если вы используете язык со строгим контролем типов, этот шаг является избыточным.
  4. Анализ потока данных. Определены зависимости между входными и выходными переменными. Хотя этот анализ не выявил каких-либо конкретных ошибок, он предоставляет полный список значений, используемых в программе. Поэтому некорректный вывод данных легко обнаруживается.
  5. Анализ ветвления программы. На этом этапе семантического анализа определяются все ветви программы и выделяются операторы, выполняемые в каждой ветви. Анализ ветвей программы очень полезен для понимания управления программой, и вы можете анализировать каждую ветку отдельно.

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

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

Метод "Чистая комната"

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

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

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

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

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

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

Тестирование программного обеспечения

План испытаний

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

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

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

В контексте тестирования существует много различий между объектно-ориентированными системами (OOS) и функционально-ориентированными (FOS) системами. В WCF существует четкое различие между основными элементами программы и всеми этими элементами. Это не верно для ООС. Поэтому в OOS нет четкой границы между тестированием компонентов и сборкой. В такой системе процесс тестирования является продолжением процесса разработки.

Проверка дефектов

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

 

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

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

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

Есть несколько способов проверить наличие дефектов.

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

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

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

Сборочный тест

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

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

Нижний и верхний тест. Подходы down (NT) и up test (VT) отражают разные подходы к системной интеграции. Последующая интеграция интегрирует и тестирует высокоуровневые компоненты перед проектированием и реализацией. В вышестоящей интеграции компоненты нижнего уровня сначала интегрируются и тестируются перед разработкой компонентов более высокого уровня.

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

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

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

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

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

Тест интерфейса

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

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

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

Тестовый инструмент

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

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

Аттестация критических систем

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

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

Сертификация надежности

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

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

 

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

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

Обеспечение безопасности

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

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

Проверка и аутентификация

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

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

  1. Анализ правильности функционирования системы.
  2. Анализ возможности изменения и понимания архитектуры системы.
  3. Анализ соответствия между алгоритмами обработки и структурами данных для системных операций системы.
  4. Анализ согласованности программного кода, алгоритмов и структур данных.
  5. Анализ обоснованности тестового сценария для системных требований.

Все доказательства безопасности системы основаны на следующих предположениях: Количество системных ошибок, которые приводят к аварийной ситуации, намного меньше, чем общее количество системных ошибок. Безопасность должна быть направлена ​​на выявление потенциально опасных ошибок. Если эти ошибки не появляются или не имеют серьезных последствий, система считается надежной. Подтверждение правильности программы было предложено более 25 лет назад как метод проверки программного обеспечения. Однако эти методы в основном используются только в лабораториях. Некоторые организации считают, что использование этих методов в процессе разработки традиционных систем неоправданно дорого, поскольку практическая проблема обоснования программного обеспечения является настолько сложной , Однако, как упоминалось ранее, для многих SC более экономно использовать доказательства корректности системы, чем исключать последствия отказов.

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

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

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

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

Заключение

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

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