Любая из ошибок программирования, которая не обнаруживается на этапах компиляции и компоновки программы, в конечном счете может проявиться тремя способами: привести к выдаче системного сообщения об ошибке, «зависанию» компьютера и получению неверных результатов.
Однако до того, как результат работы программы становится фатальным, ошибки обычно много раз проявляются в виде неверных промежуточных результатов, неверных управляющих переменных, неверных типах данных, индексах структур данных и т. п. (рис. 2.10). А это значит, что часть ошибок можно попытаться обнаружить и нейтрализовать, пока они еще не привели к тяжелым последствиям.
Программирование, при котором применяют специальные приемы раннего обнаружения и нейтрализации ошибок, было названо защитным или программированием с защитой от ошибок.
При его использовании существенно уменьшается вероятность получения неверных результатов. Детальный анализ ошибок и их возможных ранних проявлений показывает, что целесообразно
проверять:
•правильность выполнения операций ввода-вывода;
•допустимость промежуточных результатов (значений управляющих переменных, значений индексов, типов данных, значений числовых аргументов и т. д.).
Проверки правильности выполнения операций ввода-вывода. Причинами неверного определения исходных данных могут являться, как внутренние ошибки-ошибки устройств вводавывода или программного обеспечения, так и внешние ошибки — ошибки пользователя. При этом принято различать:
•ошибки передачи — аппаратные средства, например, вследствие неисправности, искажают данные;
ошибки преобразования — программа неверно преобразует исходные данные из входного формата во внутренний;
•ошибки перезаписи — пользователь ошибается при вводе данных, например, вводит лишний или другой символ;
•ошибки данных — пользователь вводит неверные данные. Ошибки передачи обычно контролируются аппаратно.
Для защиты от ошибок преобразования данные после ввода обычно сразу демонстрируют пользователю («эхо»). При этом выполняют сначала преобразование во внутренний формат, а затем обратно. Однако предотвратить все ошибки преобразования на данном этапе обычно крайне сложно, поэтому соответствующие фрагменты программы тщательно тестируют [31], используя
методы эквивалентного разбиения и граничных значений (см. § 9.4).
Обнаружить и устранить ошибки перезаписи можно только, если пользователь вводит избыточные данные, например контрольные суммы. Если ввод избыточных данных по каким-либо причинам нежелателен, то следует по возможности проверять вводимые данные, хотя бы контролировать интервалы возможных значений, которые обычно определены в техническом задании, и выводить введенные данные для проверки пользователю.
Неверные данные обычно может обнаружить только пользователь.
Проверка допустимости промежуточных результатов. Проверки промежуточных результатов позволяют снизить вероятность позднего проявления не только ошибок неверного определения данных, но и некоторых ошибок кодирования и проектирования. Для того чтобы такая проверка была возможной, необходимо, чтобы в программе использовались переменные, для которых существуют ограничения любого происхождения, например, связанные с сущностью моделируемых процессов.
Однако следует также иметь в виду, что любые дополнительные операции в программе требуют использования дополнительных ресурсов (времени, памяти и т. п.) и могут также содержать ошибки. Поэтому имеет смысл проверять не все промежуточные результаты, а только те, проверка которых целесообразна, т. е. возможно позволит обнаружить ошибку, и не сложна. Например:
•если каким-либо образом вычисляется индекс элемента массива, то следует проверить, что этот индекс является допустимым;
•если строится цикл, количество повторений которого определяется значением переменной, то целесообразно убедиться, что значение этой переменной не отрицательно;
•если определяется вероятность какого-либо события, то целесообразно проверить, что полученное значение не более 1. а сумма вероятностей всех возможных независимых событий равна 1 и т. д.
Предотвращение накопления погрешностей. Чтобы снизить погрешности результатов вычислений, необходимо соблюдать следующие рекомендации:
•избегать вычитания близких чисел (машинный ноль);
•избегать деления больших чисел на малые;
•сложение длинной последовательности чисел начинать с меньших по абсолютной величине;
•стремиться по возможности уменьшать количество операций;
•использовать методы с известными оценками погрешностей;
•не использовать условие равенства вещественных чисел;
•вычисления производить с двойной точностью, а результат выдавать с одинарной. Обработка исключений. Поскольку полный контроль данных на входе и в процессе
вычислений, как правило, невозможен, следует предусматривать перехват обработки аварийных ситуаций.
Для перехвата и обработки аппаратно и программно фиксируемых oшибок в некоторых языках программирования, например, Delphi Pascal, C++ Java, предусмотрены средства обработки исключений. Использование эти средств позволяет не допустить выдачи пользователю сообщения об аварийном завершении программы, ничего ему не говорящего. Вместо этого программист получает возможность предусмотреть действия, которые позволяют исправить эту ошибку или, если это невозможно, выдать пользователю сообщение с точным описанием ситуации и продолжить работу.
2.8. Сквозной структурный контроль
Сквозной структурный контроль представляет собой совокупность технологических операций контроля, позволяющих обеспечить как можно более раннее обнаружение ошибок в процессе разработки. Термин «сквозной в названии отражает выполнение контроля на всех этапах разработки. Термин «структурный» означает наличие четких рекомендаций по выполнена контролирующих операций на каждом этапе.
Сквозной структурный контроль должен выполняться на специальных контрольных сессиях, в которых, помимо разработчиков, могут участвовал специально приглашенные эксперты. Время между сессиями определяет объем материала, который выносится на сессию: при частых сессиях матер! ал рассматривают небольшими порциями, при редких — существенным фрагментами. Материалы для очередной сессии должны выдаваться участникам заранее, чтобы они могли их обдумать.
Одна из первых сессий должна быть организована на этапе определения спецификаций. На этой сессии проверяют полноту и точность спецификаций, при этом целесообразно присутствие заказчика или специалиста по предметной области, которые смогут определить, насколько правильно полно определены спецификации программного обеспечения.
На этапе проектирования вручную по частям проверяют алгоритмы разрабатываемого программного обеспечения на конкретных наборах данных и сверяют полученные результаты с соответствующими спецификациями. Основная задача — убедиться в правильности понимания спецификаций и проанализировать достоинства и недостатки концептуальных решений, закладываемых в проект.
На этапе реализации проверяют план (последовательность) реализации модулей, набор тестов, а также тексты отдельных модулей.
Для всех этапов целесообразно иметь списки наиболее часто встречающихся ошибок, которые формируют по литературным источникам и исходя из опыта предыдущих разработок. Такие списки позволяют сконцентрировать усилия на конкретных моментах, а не проверять все подряд. При этом все найденные ошибки фиксируют в специальном документе, но не исправляют их (более подробно см. § 9.2).
Помимо раннего обнаружения ошибок, сквозной структурный контроль обеспечивает своевременную подготовку качественной документации по проекту.
Контрольные вопросы и задания
1.Что понимают под технологичностью программного обеспечения? Почему?
2.Дайте определение модуля. Чем вызвано изменение этого понятия? Как изменились требования к модулям в настоящее время и почему?
3.Что понимают под связностью и сцеплением модулей? Какие типы связности и сцепления считаются допустимыми и почему? В чем особенность библиотек ресурсов?
4.Чем нисходящий подход к разработке отличается от восходящего? Перечислите достоинства и недостатки этих подходов?
5.Что называют структурным программированием и почему? Назовите основные и дополнительные структуры. Объясните, в чем сложность использования схем алгоритмов при проектировании структурных программ? Какие способы описания структурных алгоритмов существуют?
6. Предложите структурный алгоритм перевода чисел в 16-ричную систему счисления. Опишите его с использованием схемы алгоритма, псевдокода, диаграмм Насси-Шнейдермана и flow-форм. В чем, по вашему, основной недостаток двух последних нотаций, который препятствует их широкому применению?
7.Что называют «хорошим стилем» оформления программ и почему? Реализуйте решение предыдущего задания на любом языке программирования. Подумайте, как следует назвать переменные, и какие комментарии необходимы.
8.От каких ошибок защищает «программирование с защитой от ошибок» и почему? Что понимают под термином «исключение»? В каких случаях «исключения» используют?
9.Почему «сквозной структурный контроль» так назван? Что значит «сквозной» контроль? В чем заключается его «структурность»?
3. ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ И ИСХОДНЫХ ДАННЫХ
ДЛЯ ЕГО ПРОЕКТИРОВАНИЯ
Этап постановки задачи — один из наиболее ответственных этапов создания программного продукта. На этом этапе формулируют основные требования к разрабатываемому программному обеспечению. Оттого, насколько полно определены функции и эксплуатационные требования, насколько правильно приняты принципиальные решения, определяющие процесс проектирования, во многом зависит стоимость разработки и ее качество.
3.1. Классификация программных продуктов по функциональному признаку
Каждый программный продукт предназначен для выполнения определенных функций. По назначению все программные продукты можно разделить натри группы: системные, прикладные и гибридные (рис. 3.1).
К с и с т е м н ы м обычно относят программные продукты, обеспечивающие функционирование вычислительных систем (как отдельных компьютеров, так и сетей). Это — операционные системы, оболочки и другие служебные программы (утилиты).
Операционные системы, как правило, управляют ресурсами (процессором и памятью), процессами (задачами и потоками) и устройствами. Сложность организации операционных систем обуславливается степенью автоматизации и достигаемой эффективности процессов управления. Так мультипрограммные операционные системы существенно сложнее однопрограммных, что хорошо видно на примере MS DOS и WINDOWS.
Оболочки (например, NORTON COMMANDER) в свое время появились для организации более удобного интерфейса пользователя с файловой системой MS DOS. Современные оболочки,
такие, как FAR, используют для обеспечения пользователю привычной среды при работе с файловой системой.
К утилитам принято относить программы и системы, непосредственно не входящие в состав операционной системы, но обеспечивающие выполнение определенных функций, таких как архивация файлов, проверка компьютера на заражение вирусами, осуществление удаленного доступа к информации и др.
П р и к л а д н ы е программы и системы ориентированы на решение конкретных пользовательских задач.
Различают пользователей:
• разработчиков программ;
•непрограммистов, использующих компьютерные системы для достижения своих целей. Разработчики программ используют специальные инструментальные средства, такие как
компиляторы, компоновщики, отладчики, которые последнее время обычно интегрируют в
системы программирования и среды разработки. Современные среды программирования,
например, Delphi, Visual C++, реализуют визуальную технологию разработки программных продуктов и предоставляют программистам огромные библиотеки компонентов, которые можно включать в свою разработку. К этой же группе относят инструментальные комплексы создания баз данных, такие как Access, FoxPro, Oracle, средства создания интеллектуальных систем, например, экспертных, обучающих, систем контроля знаний и т. д. Последнее достижение в этом направлении — CASE-средства разработки программного обеспечения, такие как ERwin, BPwin, Paradigm Plus, Rational Rose и др.
Пользователи-непрограммисты в соответствии с современными требованиями не должны быть профессионалами в проблемах создания программных продуктов и специфике их взаимодействия с операционной системой, Для них разрабатывают специальные программные продукты, ориентированные на определенную предметную область. Такие продукты условно можно разделить па продукты общего назначения, профессиональные среды или пакеты, обучающие системы, развлекающие программы и т. д.
Продукты общего назначения используют разные группы пользователей. К ним можно отнести текстовые редакторы, например, WinWord, электронные таблицы типа Excel, графические редакторы, информационные системы общего назначения, например, карта Москвы, программыпереводчики, и т. п.
Профессиональные продукты предназначены для специалистов в различных областях, например, к ним можно отнести:
•системы автоматизации проектирования, ориентированные на различные технические области;
•системы-тренажеры, например, тренажер для отработки действий пилотов в аварийной ситуации;
•бухгалтерские системы, например. 1C;
•издательские системы, например, PageMaker, QuarkXpress;
•профессиональные графические системы, например, Adobe Illustrator, PhotoShop, CorelDraw и
т. п.;
•экспертные системы и т. д.
Системы автоматизации производственных процессов отличаются от профессиональных тем,
что они ориентированы на пользователей разных профессий, связанных единым производственным процессом.
Обучающие программы и системы в соответствии со своим названием предназначены для обучения, например, иностранным языкам, правилам дорожного движения и т. п.
К развлекающим относят игровые программы, музыкальные программы, опять же информационные системы, но с тестами развлекающего характера, например гороскопы и т. п.
Г и б р и д н ы е системы сочетают в себе признаки системного и прикладного программного обеспечения. Как правило, это большие, но узкоспециализированные системы, предназначенные для управления технологическими процессами различных типов в режиме реального времени. Для
повышения надежности и снижения времени обработки в такие системы обычно включают программы, обеспечивающие выполнение функций операционных систем.
К каждому из перечисленных выше типов программного обеспечения при разработке, помимо функциональных, обычно предъявляют еще и определенные эксплуатационные требования.
3.2.Основные эксплуатационные требования
кпрограммным продуктам
Как уже упоминалось в § 1.4, эксплуатационные требования определяют некоторые характеристики разрабатываемого программного обеспечения, проявляемые в процессе его функционирования. К таким характеристикам относят:
•правильность — функционирование в соответствии с техническим заданием;
•универсальность — обеспечение правильной работы при любых допустимых данных и защиты от неправильных данных;
•надежность (помехозащищенность) — обеспечение полной повторяемости результатов, т. е. обеспечение их правильности при наличии различного рода сбоев;
•проверяем ость — возможность проверки получаемых результатов;
•точность результатов — обеспечение погрешности результатов не выше заданной;
•защищенность — обеспечение конфиденциальности информации;
•программная совместимость — возможность совместного функционирования с другим программным обеспечением;
•аппаратная совместимость — возможность совместного функционирования с некоторым оборудованием;
•эффективность — использование минимально возможного количества ресурсов технических средств, например, времени микропроцессора или объема оперативной памяти;
•адаптируемость — возможность быстрой модификации с целью приспособления к изменяющимся условиям функционирования;
•повторная входимость — возможность повторного выполнения без перезагрузки с диска;
•реентерабельность — возможность «параллельного» использования несколькими процессами. Правильность является обязательным требованием для любого программного обеспечения:
все, что указано в техническом задании, непременно должно быть реализовано. Однако следует понимать, что ни тестирование (см. гл. 9), ни верификация не доказывают правильности созданного программного продукта. В этой связи обычно говорят об определенной вероятности наличия ошибок. Естественно, чем большая ответственность перекладывается на компьютерную систему, тем меньше должна быть вероятность как программного, так и аппаратного сбоя. Например, очевидно, что вероятность неправильной работы для системы управления атомной электростанцией должна быть близка к нулю.
Требование универсальности также обычно входит в группу обязательных. Ничего хорошего нет в том, что разработанная система выдает результат для некорректных данных или аварийно завершает свою работу на некоторых наборах данных. Однако, как уже упоминалось выше, доказать универсальность сравнительно сложной программы, так же, как ее правильность, невозможно, поэтому имеет смысл говорить о степени универсальности программы.
Практически, чем выше требования к правильности и универсальности программного обеспечения, тем выше и требования к его надежности. Источниками помех могут являться все участники вычислительного процесса: технические средства, программные средства и люди. Технические средства подвержены сбоям, например, из-за резких скачков напряжения питания или помех при передаче информации по сетям. Программное обеспечение может содержать ошибки. А люди могут ошибаться при вводе исходных данных.
Современные вычислительные устройства уже достаточно надежны. Сбои технических средств, как правило, регистрируются аппаратно, соответственно результаты вычислений в этом случае восстанавливаются. В случае длительных вычислений, как правило, промежуточные результаты сохраняют (прием получил название «создание контрольных точек»), что позволяет
при возникновении сбоя продолжить вычисления с данными, записанными в последней контрольной точке.
Передача информации по сетям также аппаратно контролируется, кроме того, обычно применяется специальное помехозащитное кодирование, которое позволяет находить и исправлять ошибки передачи данных. Однако полностью исключить ошибки технических средств невозможно, поэтому в тех случаях, когда требования к надежности высоки, обычно используют дублирование систем, при котором две системы решают одну и ту же задачу параллельно, периодически сверяя полученные результаты.
Часто самым «ненадежным элементом» современных систем являются люди. Уже хорошо известно, что в условиях монотонной работы за пультом вычислительной установки операторы допускают большое количество ошибок. Известны и средства, позволяющие снизить количество ошибок в конкретных ситуациях. Так, там, где это возможно, используют ввод избыточной информации, позволяющий выполнять проверки правильности вводимых данных (ввод контрольных сумм и т. п., см. § 2.7). Кроме этого, широко используют всякого рода подсказки, когда информацию необходимо не вводить, а выбирать из некоторого списка и т. п.
Повышенные требования к надежности предъявляют при разработке систем управления, функционирующих в режиме реального времени, когда вычисления выполняются параллельно с технологическими процессами. Существенно это требование и для научно-технических систем и баз данных.
Для обеспечения проверяемости следует документально фиксировать исходные данные, установленные режимы и прочую информацию, которая влияет на получаемые результаты. Особенно это существенно в случаях, когда данные поступают непосредственно от датчиков. Если такие данные не выводить вместе с результатами, то последние нельзя будет проверить.
Точность или величина погрешности результатов зависит от точности исходных данных, степени адекватности используемой модели, точности выбранного метода и погрешности выполнения операций в компьютере. Требования к точности результатов обычно наиболее жесткие для систем управления технологическими процессами (например, химическими) и систем навигации (например, система управления стыковкой космических аппаратов).
Обеспечение защищенности (конфиденциальности) информации, используемой проектируемой системой, отдельная и в условиях наличия сетей достаточно сложная задача. Помимо чисто программных средств защиты, таких как кодирование информации и идентификация пользователя, для обеспечения защищенности используют также специальные организационные приемы. Наиболее жесткие требования предъявляются к системам, в которых хранится информация, связанная с государственной и коммерческой тайной.
Требование программной совместимости может варьироваться от возможности совместной установки с указанным программным обеспечением до обеспечения взаимодействия с ним, например обмена данными и т. п. Чаще всего приходится обеспечивать функционирование программного обеспечения под управлением заданной операционной системы. Однако может потребоваться предусмотреть получение данных из какой-то программы или передачу некоторых данных ей. В этом случае необходимо точно оговорить форматы передаваемых данных.
Требование аппаратной совместимости в основном формулируют в виде минимально возможной конфигурации оборудования, на котором будет работать программное обеспечение. Если предполагается использование нестандартного оборудования, то для него должны быть указаны интерфейсы или протоколы обмена информацией. При этом для операционных систем класса Windows нестандартными считают устройства, для которых в системе отсутствуют драйверы — программы, обеспечивающие взаимодействие устройства с операционной системой.
Эффективность системы обычно оценивается отдельно по каждому ресурсу вычислительной установки. Часто используют следующие критерии:
•время ответа системы (обычно отнесенное к быстродействию используемого оборудования) — для систем, взаимодействующих с пользователем в интерактивном режиме, и систем реального времени;
•объем оперативной памяти — для продуктов, работающих в системах с ограниченным
ЛЕКЦИЯ 30
Тема 3.8 Защитное программирование
1. Способы проявления ошибок.
2. Принципы защитного программирования.
3. Рекомендации по защитному программированию.
1. Способы проявления ошибок
Любая из ошибок программирования,
которая не обнаруживается на этапах компиляции и компоновки программ, в
конечном счете может проявиться тремя способами: привести к выдаче системного
сообщения об ошибке, «зависанию» компьютера и получению неверных результатов.
 |
Рисунок 1 — Способы проявления ошибок
Однако до того как результат работы
программы становится фатальным, ошибки обычно много раз проявляются в виде
неверных промежуточных результатов, неверных управляющих переменных, неверных
типах данных, индексах структур данных и т.д. (рисунок 3.1). А это значит, что
часть ошибок можно попытаться обнаружить и нейтрализовать, пока они еще не
привели к тяжелым последствиям. Для этого используется защитное
программирование. При его использовании существенно уменьшается вероятность
получения неверных результатов.
Защитное программирование – это такой стиль написания программ, при котором появляющиеся ошибки
легко обнаруживаются и идентифицируются программистом.
Детальный анализ ошибок и их возможных
ранних проявлений показывает, что целесообразно проверять:
—
правильность выполнения операций ввода-вывода;
—
допустимость промежуточных результатов (значений
управляющих переменных, значений индексов, типов данных, значений числовых
аргументов и т.д.).
Проверка
правильности операций ввода-вывода.
Причины неверного определения исходных
данных:
—
внутренние ошибки – ошибки устройств ввода-вывода
или программного обеспечения;
—
внешние ошибки – ошибки пользователя.
Различают:
—
ошибки передачи (аппаратные средства, например,
вследствие неисправности, искажают данные);
—
ошибки преобразования (программа неверно
преобразует исходные данные из входного формата во внутренний);
—
ошибки перезаписи (пользователь ошибается при вводе
данных, например, вводит лишний или другой символ);
—
ошибки данных (пользователь вводит неверные
данные).
Ошибки передачи обычно контролируются
аппаратно.
Для защиты от ошибок преобразования
данные после ввода обычно сразу демонстрируют пользователю. При этом выполняют
сначала преобразование во внутренний формат, а затем обратно. Предотвратить все
ошибки на данном этапе сложно, поэтому соответствующие фрагменты программы
тщательно тестируют.
Обнаружить и устранить ошибки
перезаписи можно только, если пользователь вводит избыточные данные, например
контрольные суммы. Если ввод избыточных данных нежелателен, то следует проверять
вводимые данные, хотя бы контролировать интервалы возможных значений, которые
обычно определены в техническом задании, и выводить введенные данные для
проверки пользователю.
Неверные данные может обнаружить
только пользователь.
Проверка
допустимости промежуточных результатов.
Эта проверка позволяет снизить
вероятность позднего проявления не только ошибок неверного определения данных,
но и некоторых ошибок кодирования и проектирования. Для этого используют в
программе переменные, для которых существуют ограничения, например, связанные с
сущность моделируемых процессов.
Предотвращение
накопления погрешностей.
Чтобы снизить погрешность результатов
вычислений, необходимо соблюдать следующие рекомендации:
—
избегать вычитания близких чисел (машинный ноль);
—
избегать деления больших чисел на малые;
—
сложение длинной последовательности чисел начинать
с меньших по абсолютной величине;
—
стремиться по возможности уменьшать количество
операций;
—
использовать методы с известными оценками
погрешностей;
—
не использовать условие равенства вещественных
чисел;
—
вычисления производить с двойной точность, а
результат выдавать – с одинарной.
Обработка
исключений.
Поскольку полный контроль данных на
входе и в процессе вычислений не возможен, следует предусмотреть перехват
обработки аварийных ситуаций.
Для перехвата и обработки аппаратно и
программно фиксируемых ошибок в некоторых языках программирования предусмотрены
средства обработки исключений. Использование их позволяет
пользователю не допустить выдачи пользователю сообщения об аварийном завершении
программы, ничего ему не говорящего. Вместо этого программист получает
возможность предусмотреть действия, которые позволят исправить эту ошибку или
выдать пользователю сообщение с точным описанием ситуации и продолжить работу.
2. Принципы защитного программирования
Существуют три основных принципа
защитного программирования:
1.
Общее недоверие. Для каждого модуля входные данные должны
тщательно анализироваться в предположении, что они могут быть ошибочными.
2.
Немедленное
обнаружение. Каждая
ошибка должна быть выявлена как можно раньше, это упрощает установление ее
причины.
3.
Изолирование ошибки. Ошибки в одном модуле должны быть изолированы
так, чтобы не допустить их влияние на другие модули.
3. Рекомендации по защитному программированию
Рекомендации по защитному
программированию:
— Делайте проверку области значений переменных.
— Выполняйте контроль правдоподобности значений
переменных, которые не должны превышать некоторых констант или значений других
переменных
— Контролируйте итоги вычислений.
— Включайте автоматические проверки (например,
контроль переполнения или потери точности).
— Проверяйте длину элементов информации.
— Проверяйте коды возврата функций.
Тема: «Программирование с «защитой от ошибок. Сквозной структурный контроль» Разработала Топоркова Ирина Александровна
Вопросы лекции 1. Программирование с «защитой от ошибок» . 2. Сквозной структурный контроль.
1. Программирование с «защитой от ошибок»
Способы проявления ошибок
Проверка правильности выполнения операций ввода-вывода
Проверка допустимости промежуточных результатов
ПРИМЕР.
Предотвращение накопления погрешности
Обработка исключений
2. Сквозной структурный контроль
Контрольные вопросы 1. От каких ошибок защищает «программирование с защитой от ошибок» и почему? 2. Что понимают под термином «исключение» ? 3. В каких случаях «исключения» используют? 4. Почему «сквозной структурный контроль» так назван? 5. Что значит «сквозной» контроль? 6. В чем заключается его «структурность» ?
Презентация на тему Программирование с защитой от ошибок. Сквозной структурный контроль
Содержание
-
1.
Программирование с защитой от ошибок. Сквозной структурный контроль -
2.
Программирование с «защитой от ошибок». Сквозной структурный контроль. Вопросы лекции -
3.
1. Программирование с «защитой от ошибок» -
4.
Способы проявления ошибок -
7.
Проверка правильности выполнения операций ввода-вывода -
8.
Проверка допустимости промежуточных результатов -
9.
ПРИМЕР. -
10.
Предотвращение накопления погрешности -
11.
Обработка исключений -
12.
2. Сквозной структурный контроль -
14.
Контрольные вопросы От каких ошибок защищает «программирование -
15.
Скачать презентацию -
16.
Похожие презентации
Программирование с «защитой от ошибок». Сквозной структурный контроль. Вопросы лекции
Слайды презентации
Слайд 1
Тема: «Программирование с «защитой от ошибок. Сквозной структурный
контроль»
Разработала
Топоркова Ирина Александровна
Слайд 2
Программирование с «защитой от ошибок».
Сквозной структурный контроль.
Вопросы лекции
Слайд 3
1. Программирование
с «защитой от ошибок»
Слайд 7
Проверка правильности выполнения операций ввода-вывода
Слайд 8
Проверка допустимости промежуточных результатов
Слайд 10
Предотвращение накопления погрешности
Слайд 12
2. Сквозной структурный контроль
Слайд 14
Контрольные вопросы
От каких ошибок защищает «программирование с
защитой от ошибок» и почему?
Что понимают под термином
«исключение»?
В каких случаях «исключения» используют?
Почему «сквозной структурный контроль» так назван?
Что значит «сквозной» контроль?
В чем заключается его «структурность»?
Окончательная проверка корректности программ (т. е. проверка соответствия их внешним спецификациям), проверка на отсутствие алгоритмических ошибок и ошибок в организации программы осуществляется тестированием. Программы проверяются на функционирование с различными исходными данными. Результаты функционирования программ сравниваются с эталонными значениями. Программу условно можно считать правильной, если её запуск для выбранной системы тестовых исходных данных во всех случаях дает правильные результаты.
Тестирование программ является одним из самых длительных и ответственных этапов разработки.
Процесс разработки программного обеспечения предполагает три стадии тестирования: автономное, комплексное и системное, каждая из которых соответствует завершению соответствующей части системы.
При тестировании самыми важными являются два вопроса: в каком порядке тестировать модули и как готовить и задавать тестовые данные.
При тестировании модулей программного обеспечения, так же, как при проектировании и кодировании возможно применение как восходящего, так и нисходящего подходов.
Различают два подхода к формированию тестов: структурный и функциональный. Каждый из указанных подходов имеет свои особенности и области применения.
Структурный подход базируется на том, что известка структура тестируемого программного обеспечения, в том числе его алгоритмы («стеклянный ящик»). В этом случае тесты строят так, чтобы проверить правильность реализации заданной логики в коде программы.
Структурное тестирование называюттакже тестированием по «маршрутам», так как в этом случае тестовые наборы формируют путем анализа маршрутов, предусмотренных алгоритмом. Под маршрутамипри этом понимают последовательности операторов программы, которые выполняются при конкретном варианте исходных данных.
В основе структурного тестирования лежит концепция максимально полного тестирования всех маршрутов программы. Так, если алгоритм программы включает ветвление, то при одном наборе исходных данных может быть выполнена последовательность операторов, реализующая действия, которые предусматривает одна ветвь, а при втором – другая. Соответственно, для программы будут существовать маршруты, различающиеся выбранным при ветвлении вариантом.
Считают, что программа проверена полностью, если с помощью тестов удается осуществить выполнение программы по всем возможным маршрутам передач управления. Однако нетрудно видеть, что даже в программе среднего уровня сложности число неповторяющихся маршрутов может быть очень велико, и, следовательно, полное или исчерпывающеетестирование маршрутов, как правило, невозможно.
Функциональный подход основывается на том, что структура программного обеспечения не известна («черный ящик»). В этом случае тесты строят, опираясь на функциональные спецификации. Этот подход называют также подходом, управляемым данными, так как при его использовании тесты строят на базе различных способов декомпозиции множества данных.
Наборы тестов, полученные в соответствии с методами этих подходов, обычно объединяют, обеспечивая всестороннее тестирование программного обеспечения.
Процесс тестирования можно разделить на три этапа.
1. Проверка в нормальных условиях. Предполагает тестирование на основе данных, которые характерны для реальных условий функционирования программы.
2. Проверка в экстремальных условиях. Тестовые данные включают граничные значения области изменения входных переменных, которые должны восприниматься программой как правильные данные. Типичными примерами таких значений являются очень маленькие или очень большие числа и отсутствие данных. Еще один тип экстремальных условий – это граничные объемы данных, когда массивы состоят из слишком малого или слишком большого числа элементов.
3. Проверка в исключительных ситуациях. Проводится с использованием данных, значения которых лежат за пределами допустимой области изменений. Известно, что все программы разрабатываются в расчете на обработку какого-то ограниченного набора данных. Поэтому важно получить ответ на следующие вопросы:
· что произойдет, если программе, не рассчитанной на обработку отрицательных и нулевых значений переменных, в результате какой–либо ошибки придется иметь дело как раз с такими данными?
· как будет вести себя программа, работающая с массивами, если количество их элементов превысит величину, указанную в объявлении массива?
· что произойдет, если числа будут слишком малыми или слишком большими?
Наихудшая ситуация складывается тогда, когда программа воспринимает неверные данные как правильные и выдает неверный, но правдоподобный результат. Программа должна сама отвергать любые данные, которые она не в состоянии обрабатывать правильно. Не нужно считать причиной ошибок машину, так как современные машины и трансляторы обладают чрезвычайно высокой надежностью.
При конструировании программы необходимо определить адекватный задаче способ задания исходных данных. Отметим несколько различных способов задания исходных данных, которые рекомендуется применять при тестировании программ:
· ввод с клавиатуры в текстовом режиме (в ответ на программный запрос, указывающий, как правило, содержательное название данного и множество допустимых значений):
· генерация в программе случайных чисел, задающих, как правило, элементы составных данных (массивов, файлов):
· генерация данных определенной структуры или с определенными свойствами (например, двоичные деревья) с помощью специальных процедур (генераторов тестов);
· тестовые файлы (как правило, небольшого размера), содержащие специально подобранную последовательность элементов, на которых наглядно демоне фи русте я исполнение алгоритма;
· тестовые файлы большого размера (с произвольными или обладающими определенными свойствами данными) для получения количественных оценок алгоритма (например, для сравнения трудоемкости алгоритмов сортировки);
· произвольные пользовательские файлы, имена которых запрашиваются программой:
· графические объекты, вводимые с помощью графического курсора и клавиш.
В зависимости от целей программы исходные данные могут отображаться на экране программой или оставаться скрытыми от пользователя. В одной и той же программе можно предусмотреть несколько способов задания исходных данных. Важно, чтобы способ задания исходных данных был адекватен задаче, естествен для нее.
При тестировании можно планировать проверку всех возможных маршрутов исполнения программы при всех значениях исходных переменных. Однако это реализуемо только для очень простых программ небольшого объема при малых диапазонах изменения исходных данных. Поэтому при планировании отладки программ применяются критерии полноты тестирования, которые, однако, не гарантируют полной проверки программ. Выбор критерия для конкретного применения зависит от наличия ресурсов для тестирования и структурной сложности отлаживаемой программы. Критерии характеризуются глубиной контроля программ и объемом проверок. В процессе отладки основная часть неисправностей в программах обнаруживается и затем устраняется. Однако всегда есть риск пропуска нескольких неисправностей.
Требования к тестированию программ сформулированы в виде аксиом тестирования в известной книге Г. Майерса «Искусство тестирования программ».
Аксиома 1.Считайте тестирование ключевой задачей Вашей разработки.
Эта аксиома, сформулированная в основном для больших, сложно структурированных программ, имеет важное значение и для небольших, учебных программ. Ее утверждение исходит не только из того, что процесс тестирования при надлежащем его выполнении является довольно длительным по времени. Тестирование – очень ответственный этап разработки, так как именно от его выполнения зависит правильность и надежность получаемой в итоге программы Кроме того, как правило, в процессе тестирования учебных программ выясняется необходимость выполнения ряда доработок программы, связанных с оценкой
· интерфейса (удобства ввода данных и их контроля, точности и полноты выдаваемых сообщений);
· приемлемости времени исполнения программы;
· отслеживания программой всех возможных вариантов решения задачи;
· необходимого представления (типа) данных и точности вычислений.
Вывод, который должен сделать для себя разработчик программы на основе ной аксиомы, состоит в том, что при планировании разработки программы нужно отводить больше времени и внимания данному этапу и очень ответственно выполнять его.
Аксиома 2.Тестирование, кон почти всякая другая деятельность. отмена начинается с постановки целей.
Цели тестирования для учебных программ весьма скромны – показать, что программа при ее исполнении ведет себя правильно, в соответствии с решаемой задачей, т.е. выдает правильные результаты для допустимых исходных данных и сообщает о невозможности их обработки (желательно на ранней стадии обработки) для неверных данных или их недопустимой комбинации. Осознание этих целей должно побудить разработчика спланировать достаточно полный пакет тестов, а также сроки разработки с учетом сложности тестирования программы.
Аксиома 3.Необходимая часть всякого теста – описание ожидаемых выходных данных.
Эта аксиома основана на определении теста как двух наборов данных –исходных данных и ожидаемых результатов работы программы. Даже если тестирование не документируется (например, если исходные данные теста вводятся с клавиатуры, арезультаты выдаются на экран), то перед тем, как вводить данные или в процессе их ввода, нужно обязательно предсказать ожидаемые результаты работ программы.
Аксиома 4.Подготовка тестов, как для правильных, так и для неправильных входных данных.
Под правильными данными здесь понимаются данные таких типов, диапазонов, форм задания размеров, которые допускает программа. Однако, программа будет правильной (надежной), если она будет адекватно воспринимать и недопустимые данные, т.е. контролировать правильность задания данных как в отдельности, так и в совокупности (возможные наборы значений), и в случае неправильного задания данных, выдавать об этом вразумительные сообщения или выполнять некоторые действия.
Аксиома 5. Проектирование тестов требует даже большего творчества, чем разработка программ.
Известно, что никакое, даже очень тщательное тестирование программы, не может гарантировать отсутствия в ней ошибок. Тем не менее тщательная подготовка пакета тестов в значительной мере обеспечит ее правильность и надежность. Пакет тестов представляет собой совокупность тестов (исходные данные и ожидаемые результаты), по возможности охватывающих все случаи задания исходных данных задачи. Это в частности, означает, что в пакете тестов должны быть тесты, задающие как допустимые, гак и недопустимые программой значения исходных данных, находящиеся
· внутри допустимого интервала (множества),
· на каждой из границ интервала.
· вне допустимого интервала.
Кроме того, должны быть рассмотрены все «вырожденные» случаи задания исходных данных:
· пустые строки, множества и файлы.
· последовательности (представляемые массивами) нулевой длины и длины, превышающей допустимую программой (по каждому из измерений массива).
При создании тестов для программ вычислительного характера следует обратить особое внимание на подготовку тестов, проверяющих достижение точности вычислений гарантируемой выбранным численным методом.
Важно также включать в тесты такие максимальные значения исходных данных, которые контролируются программой и указываются в формулировке задачи.
При создании тестов для программ, реализующих алгоритмы поиска, сортировки и других алгоритмов комбинаторного характера следует обратить особое внимание на подготовку тестов, с помощью которых можно определить максимальное (или близкое к нему) время выполнения программы. Для этого можно генерировать последовательности (файлы) большою объема или специальным образом организованные последовательности (для которых проверяемый алгоритм выполняется «неэффективно»).
Аксиома 6.Нужно избегать невоспроизводимых тестов, не тестировать «с лету».
Когда исходные данные теста задаются для того, чтобы посмотреть, «что получится» – это неряшливая и бессмысленная работа. Даже если прогон тестa не документируется. ввод его исходных данных с клавиатуры должен быть осмысленным: это должны быть данные, которые можно воспроизвести еще pазт.е. представления данных (числовые, строковые) должны быть короткими. Однообразными, подчиненными каким–либо правилам, одним словом, запоминающимися.
Аксиома 7. В пакете тестов не должно быть случайных или несущественных тестов. Хорош тот тест, для которого высока вероятность обнаружить ошибку, а не тот, который демонстрирует правильную работу программы.
Эта аксиома выражает суть тестирования как процесса обнаружения ошибок. Процесс тестирования учебной программы можно считать относительно завершенным не тогда, когда «прошел» первый (или второй или десятый) тест, акогда Вы исчерпали все приводящие Вам в голову варианты задания исходных данных и на всех этих вариантах программа выдала ожидаемые (т. е. правильные) результаты.
Аксиома 8.Детально изучите результаты каждого теста. Самые и ширенные тесты ничего не стоят, если их результаты удостаиваются лишь беглого вклада.
Лучшим средством анализа результатов тестирования является документирование результатов (запись их в файл) и последующее их сравнение с ожидаемыми (тоже задокументированными) результатами. Это сравнение нетрудно выполнять автоматически некоторой программой, даже если сравниваемые данные могут совпадать не в точности, а с некоторой прогнозируемой погрешностью (например, вещественные числа). Но если делается даже простои визуальный анализ выдаваемых на экран значений, он должен быть тщательным и исчерпывающим. Непременным требованием при этом должно быть сохранение на экране исходных данных теста(а иногда и формулировки задачи) для того, чтобы можно было воспроизвести ожидаемые результаты.
Аксиома 9. Никогда не изменяйте программу, чтобы облегчить ее тестирование
Изменение программы при тестировании должно быть следствием глубокого анализа того, почему программа выполнилась так, а не иначе.
Должно быть найдено объяснение всех результатов. И только после этого, поняв, как нужно исправить программу (не ухудшая ее экономичности и надежности), можно приступать к ее изменению. Изменения должны быть по возможности локальными, не менять общую логику программы и те ее части, которые уже отлажены. Радикальное изменение программы означает ее перепроектирование, т.е. возвращение на более раннюю стадию разработки. В любом случае, после каждого (даже сугубо локального) изменения программы должен быть повторен прогон всех использованных ранее тестов.
Анонима 10По мере того, как растет число обнаруженных ошибок одновременно растет также относительная вероятность существования в ней необнаруженных ошибок
Возрастание числа обнаруживаемых ошибок в программе при ее тестировании обычно обуславливается следующими обстоятельствами.
Если программа изначально составлена (спроектирована) очень плохо, так что никакие ее локальные исправления, выполняемые при тестировании и отладке, не могут ее скорректировать. В этом случае необходимо вернуться к ее перепроектированию, отбросив, возможно полностью, старый вариант программы. Неправильные изменения программы в процессе ее тестирования могут все более отдалять Вас от правильного варианта. Выход из этой ситуации – вернуться к одному из предыдущих вариантов программы. Для этого рекомендуется при тестировании и отладке время от времени (перед существенным се изменением) сохранять вариант текста программы, как-то идентифицируя (например, номером) разные его варианты.
13.4. Программирование «с защитой от ошибок»
Любая из ошибок программирования, которая не обнаруживается на этапах компиляции и компоновки программы, в конечном счете может проявиться тремя способами: привести к выдаче системного сообщения об ошибке, «зависанию» компьютера и получению неверных результатов.
Однако до того, как результат работы программы становится фатальным, ошибки обычно много раз проявляются в виде неверных промежуточных результатов, неверных управляющих переменных, неверных типах данных, индексах структур данных и т. п. А это значит, что часть ошибок можно попытаться обнаружить и нейтрализовать, пока они еще не привели к тяжелым последствиям.
Программирование, при котором применяют специальные приемы раннего обнаружения и нейтрализации ошибок, было названо защитным или программированием с защитой от ошибок.
При его использовании существенно уменьшается вероятность получения неверных результатов.
Можно дать некоторые рекомендации по составлению программы, которые облегчат ее отладку и дальнейшее использование.
· Программа должна быть универсальной, т. е. не зависящей от конкретного набора данных.
· При использовании массива его размер следует задавать константой и указывать ее отдельно, используя далее эту константу во всей программе.
· Универсальная программа должна обрабатывать вырожденные случаи (например, число элементов вектора равно 0 или 1), выдавать сообщение об ошибке в тех случаях, когда размер массива превысит допустимое значение (использованное в описании массива), когда результат вычислений выходит за рамки разрядной сетки и т. п.
· В программе следует предусмотреть защиту от неправильного ввода (она не должна выполняться, если данные выходят за пределы допустимого диапазона).
· В качестве параметров вместо констант необходимо применять переменные. Если в программе используются константы, то при их изменении в исходной программе нужно менять каждый оператор, содержащий прежнюю константу. Эта процедура отнимает много времени и часто вызывает ошибки.
· Программа должна содержать комментарии, позволяющие легко проследить за логической взаимосвязью и функциями отдельных ее частей.
· Выбирайте такой способ представления данных, который упрощает программу.
· Убедитесь, что входные данные соответствуют принятым ограничениям.
· Обеспечьте распознавание неверно заданных входных данных.
· Стремитесь в первую очередь к получению правильной программы и только потом к сокращению времени ее выполнения.
· Стремитесь к простой, а не к сложной программе.
· Четко и ясно выражайте свои мысли в комментариях.
· Не бойтесь переписывать неудачные участки ПО.
Используя некоторые простые приемы, можно повысить эффективность программы (т. е. уменьшить количество выполняемых операций и время ее работы). Например, к таким приемам относятся следующие:
· арифметическое выражение, которое несколько раз вычисляется в программе, лучше вычислить один раз и присвоить его значение переменной, которую и можно везде использовать вместо арифметического выражения;
· при организации циклов в качестве границ индексов рекомендуется применять переменные, а не выражения, которые вычислялись бы при каждом прохождении цикла;
· особое внимание следует обратить на организацию циклов: убрать из них все повторяющиеся с одинаковыми данными вычисления, выполнив их до входа в цикл.
Детальный анализ ошибок и их возможных ранних проявлений показывает, что целесообразно проверять:
• правильность выполнения операций ввода–вывода;
• допустимость промежуточных результатов (значений управляющих переменных, значений индексов, типов данных, значений числовых аргументов и т. д.).
Проверки правильности выполнения операций ввода–вывода.Причинами неверного определения исходных данных могут являться, как внутренние ошибки – ошибки устройств ввода–вывода или программного обеспечения, так и внешние ошибки – ошибки пользователя. При этом принято различать:
· ошибки передачи – аппаратные средства, например, вследствие неисправности, искажают данные;
· ошибки преобразования – программа неверно преобразует исходные данные из входного формата во внутренний;
· ошибки перезаписи – пользователь ошибается при вводе данных, например, вводит лишний или другой символ;
· ошибки данных – пользователь вводит неверные данные. Ошибки передачи обычно контролируются аппаратно.
Для защиты от ошибок преобразования данные после ввода обычно сразу демонстрируют пользователю («эхо»). При этом выполняют сначала преобразование во внутренний формат, а затем обратно. Однако предотвратить все ошибки преобразования на данном этапе обычно крайне сложно, поэтому соответствующие фрагменты программы тщательно тестируют , используя методы эквивалентного разбиения и граничных значений.
Обнаружить и устранить ошибки перезаписи можно только, если пользователь вводит избыточные данные, например контрольные суммы. Если ввод избыточных данных по каким–либо причинам нежелателен, то следует по возможности проверять вводимые данные, хотя бы контролировать интервалы возможных значений, которые обычно определены в техническом задании, и выводить введенные данные для проверки пользователю.
Неверные данные обычно может обнаружить только пользователь.
Проверка допустимости промежуточных результатов.Проверки промежуточных результатов позволяют снизить вероятность позднего проявления не только ошибок неверного определения данных, но и некоторых ошибок кодирования и проектирования. Для того чтобы такая проверка была возможной, необходимо, чтобы в программе использовались переменные, для которых существуют ограничения любого происхождения, например, связанные с сущностью моделируемых процессов.
Однако следует также иметь в виду, что любые дополнительные операции в программе требуют использования дополнительных ресурсов (времени, памяти и т. п.) и могут также содержать ошибки. Поэтому имеет смысл проверять не все промежуточные результаты, а только те, проверка которых целесообразна, т. е. возможно позволит обнаружить ошибку, и не сложна.
Например:
• если каким–либо образом вычисляется индекс элемента массива, то следует проверить, что этот индекс является допустимым;
• если строится цикл, количество повторений которого определяется значением переменной, то целесообразно убедиться, что значение этой переменной не отрицательно;
• если определяется вероятность какого–либо события, то целесообразно проверить, что полученное значение не более 1, а сумма вероятностей всех возможных независимых событий равна 1 и т. д.
Предотвращение накопления погрешностей. Чтобы снизить погрешности результатов вычислений, необходимо соблюдать следующие рекомендации:
• избегать вычитания близких чисел (машинный ноль);
• избегать деления больших чисел на малые;
• сложение длинной последовательности чисел начинать с меньших по абсолютной величине;
• стремиться по возможности уменьшать количество операций;
• использовать методы с известными оценками погрешностей;
• не использовать условие равенства вещественных чисел;
• вычисления производить с двойной точностью, а результат выдавать с одинарной.
Обработка исключений.Поскольку полный контроль данных на входе и в процессе вычислений, как правило, невозможен, следует предусматривать перехват обработки аварийных ситуаций.
Помощь в ✍️ написании работы
Поиск по сайту:
Ограничений сверх описанных в настоящем документе требований на проведение испытаний не налагается.
Требования к техническому обслуживанию системы
Для проведения испытаний системы должно быть обеспечено бесперебойное питание ПЭВМ. Во время испытаний система должна быть обеспечена соответствующая стандартам хранения носителей и эксплуатации ПЭВМ температура и влажность воздуха.
Помещения, в которых размещаются программно-технические средства, должны обеспечивать требуемый уровень защиты АС ХОД от несанкционированного доступа.
Размещение помещений и их оборудование должны исключать возможность бесконтрольного проникновения в них посторонних лиц и обеспечивать сохранность находящихся в этих помещениях конфиденциальных документов и технических средств.
Размещение оборудования, технических средств, предназначенных для обработки конфиденциальной информации, должно соответствовать требованиям техники безопасности, санитарным нормам и требованиям пожарной безопасности.
Входные двери режимных помещений должны быть оборудованы замками, обеспечивающими надежное закрытие помещений в нерабочее время.
Окна и двери должны быть оборудованы охранной сигнализацией, связанной с пультом централизованного наблюдения за сигнализацией.
Все пользователи системы должны соблюдать правила эксплуатации электронной вычислительной техники.
Меры по обеспечению безопасности испытаний
Все технические решения, использованные при создании АС ХОД, а также при определении требований к аппаратному обеспечению, должны соответствовать действующим нормам и правилам техники безопасности, пожарной безопасности и взрывобезопасности, а также охраны окружающей среды при эксплуатации.
Порядок взаимодействия организаций
В испытаниях принимают участие две организации: Заказчик (предоставляет помещение и комплекс технических средств) и Исполнитель (проводит испытания). С каждой стороны назначаются ответственные для оперативного разрешения возникающих вопросов.
Порядок привлечения экспертов
Присутствие экспертов со стороны Заказчика необходимо на всех этапах испытаний.
Требования к персоналу
Проводящий испытания сотрудник должен обладать следующими навыками:
— пользовательские навыки в работе с ПЭВМ;
— пользовательские навыки в работе с графическим интерфейсом целевой ОС.
Также необходимо знание предметной области и знакомство с Руководством пользователя АС ХОД.
МАТЕРИАЛЬНО-ТЕХНИЧЕСКОЕ ОБЕСПЕЧЕНИЕ ИСПЫТАНИЙ
Требования к техническому обеспечению системы
Для проведения испытаний необходимо предоставить ПК, выполненный в защищенном исполнении, именно тот, который будет использоваться при эксплуатации системы.
Требования к техническому обеспечению АС ХОД
| Параметр/Характеристика | Рекомендуемое значение |
| Платформа | Intel |
| Процессор | Intel Core 2 Duo |
| — Число процессоров | 1 |
| — Тактовая частота | 1800 МГц |
| Оперативная память | 1024 Мб |
| Объем жесткого диска | 120 Гб |
| Сетевое оборудование | — |
| Видеосистема и монитор (разрешающая способность) | 1024×768 точек |
Требования к программному обеспечению АС ХОД
|
Программное обеспечение |
|
| Операционная система | ОС Linux (Ubuntu 10.04) |
| Офисный пакет | Open Office 2.3 |
|
СЗИ |
|
| Антивирус | Dr.Web 6.0 Enterprise Security Suite |
| Средство защиты от НСД | Secret Net 6.0 (автономный вариант) |
| АМДЗ | Secret Net Touch Memory Card |
МЕТРОЛОГИЧЕСКОЕ ОБЕСПЕЧЕНИЕ ИСПЫТАНИЙ
Требования к метрологическому обеспечению системы не предъявляются.
ОТЧЕТНОСТЬ
По результатам выполнения указанных в таблице 1 этапов испытаний оформляются Протоколы испытаний АС ХОД, а по результатам испытаний в целом – Акт испытаний АС ХОД.
ПРИЛОЖЕНИЕ А
(справочное)
1. Проверка соответствия рабочих эксплуатационных документов и дополнительных рабочих материалов на АС ХОД требованиям к документации.
Данная проверка проводится путем последовательного выполнения (в указанном порядке) следующих частных проверок:
— проверка комплектности представленных на испытания рабочих эксплуатационных документов и дополнительных рабочих материалов;
— проверка содержания и оформления представленных на испытания рабочих эксплуатационных документов.
2. Проверка соответствия требованиям к структуре и функционированию системы.
Данная проверка проводится путем последовательного выполнения (в указанном порядке) следующих частных проверок:
— проверка комплектности представленных на испытания рабочих эксплуатационных документов и дополнительных рабочих материалов;
— проверка содержания и оформления представленных на испытания рабочих эксплуатационных документов.
Затем проводится опытная эксплуатация объекта и делается вывод о соответствии системы заявленным характеристикам.
3. Проверка соответствия требованиям к численности и квалификации персонала системы и режиму его работы.
При проведении проверки исследуется уровень знаний персонала и его квалификация методом опроса и проверки знаний путем опытной эксплуатации системы.
4. Проверка соответствия требованиям к показателям назначения.
Проверяется состав АС и его техническое обеспечение путем проверки документации на предоставленное оборудование.
5. Проверка соответствия требованиям к надежности.
Проверка осуществляется методом пробного пуска системы и продолжительного ее функционирования в течении 24 ч. Также имитируется отключение электроэнергии для проверки надежности источника бесперебойного питания.
6. Проверка соответствия требованиям к безопасности.
Проводится проверка соответствия требований к аппаратному обеспечению. Технические средства должны соответствовать действующим нормам и правилам техники безопасности, пожаробезопасности и взрывобезопасности, а также охраны окружающей среды при эксплуатации
7. Проверка соответствия требованиям к эргономике и технической эстетике.
Проверка соответствия регламентирующим документам.
8. Проверка соответствия требованиям к эргономике и технической эстетике.
Требования к транспортабельности не предъявляются.
9. Проверка соответствия требованиям к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы.
Проверка ИБП, документации регламентирующей техническое обслуживание, ремонт и хранение компонентов системы.
10. Проверка соответствия требованиям по защите информации от НСД.
Проверка с использованием специальных тест-программ, имитирующих НСД. Проверка настроек СЗИ.
11. Проверка соответствия требованиям по защите информации от утечки по техническим каналам.
Проверка документации по специсследованиям и спецпроверке оборудования.
12. Проверка соответствия требованиям по сохранности информации при авариях.
Имитация отключения питания и проверка сохранности документов.
13. Проверка соответствия требованиям по защите от влияния внешних воздействий.
Проверка условий, в которых будет функционировать АС.
14. Проверка соответствия требованиям к патентной чистоте.
Требования к патентной чистоте не предъявляются.
15. Проверка соответствия требованиям по стандартизации и унификации.
Проверка соответствия оформления документов на выходе из системы документации.
16. Проверка соответствия требованиям к функциям редактора документов.
Пробное тестирование выполнение указанной функции.
17. Проверка соответствия требованиям к математическому обеспечению системы.
Требования к математическому обеспечению АС ХОД не предъявляются.
18. Проверка соответствия требованиям к информационному обеспечению.
Проверка документации и реальных условий.
19. Проверка соответствия требованиям к лингвистическому обеспечению системы.
Проверка АС на наличие постороннего ПО и т.п.
20. Проверка соответствия требованиям к программному обеспечению.
Проверка опытным путем работы ПО.
21. Проверка соответствия требованиям к техническому обеспечению системы.
Проверка соответствия предоставленных технических средств документации.
22. Проверка соответствия требованиям к метрологическому обеспечению системы.
Требования к метрологическому обеспечению подсистемы не предъявляются.
24. Проверка соответствия требованиям к организационному обеспечению системы.
Проверка документации.
25. Проверка соответствия требованиям к методическому обеспечению системы.
Проверка документации.
Тестирование программного обеспечения не может гарантировать полную безошибочность системы из-за того, что невозможно реалистично смоделировать бесконечное количество входных значений и впоследствии проверить бесконечное количество выходных значений. Даже проверить все возможные пути через программу обычно нереально. Таким образом, тестирование — очень эффективный способ показать наличие ошибок, но доказать их отсутствие невозможно. Отсутствие ошибок может быть продемонстрировано только формальным доказательством, которое не является практическим методом из-за его сложности.
Другие вопросы тестирования, которые следует рассмотреть и решить, включают:
- Невозможно полностью протестировать все возможные варианты ввода
- Очень сложно выявить, что в спецификации что-то забыли
- Спецификация не всегда четкая или даже отсутствует
- Тестирование часто недооценивают или неправильно понимают
- На результаты тестирования может повлиять плохая коммуникация в команде или с заказчиком
- Тестирование должно быть адаптировано к тестируемому продукту, невозможно тестировать разные программы одинаково
- Во время тестирования некоторые тесты могут стать неэффективными. Тесты должны постоянно адаптироваться к меняющимся обстоятельствам
- Две разные ошибки могут быть одинаковыми снаружи, или одна ошибка может отличаться снаружи
- Тестирование чувствительно к входным данным, оно должно быть реалистичным. Создание монотонных данных не идеально
Позитивистская спецификация
Клиент определяет точку интереса, из которой затем расширяется область, от которой он зависит: для нее затем говорится, как приложение должно или не должно вести себя. Но поскольку пространство кейсов определяется только таким образом изнутри, пространство всех потенциальных кейсов и, следовательно, количество кейсов, подлежащих проверке, может увеличиваться до бесконечности. FS может охватывать только основные функции и их случаи, с той лишь разницей, что она анализирует их: вы всегда можете найти случай, который FS не охватывает, просто достаточно далеко зайти в сочетании различных возможных влияний.
Поэтому необходимо определить порог, на который более сложные случаи больше не должны распространяться в приложении. Это «ограничение сверху» не определяется клиентом, для которого желательно наиболее комплексное решение, охватывающее максимальное количество случаев (за ту же цену). Объем разработки должен быть определен трейдером во время переговоров или, по крайней мере, впоследствии командой проекта при разработке заказа, и предоставить это решение всем заинтересованным сторонам : прежде всего, программистам и тестерам. Однако на практике это обычно не так, поэтому каждый должен сам определить глубину своей работы: поэтому тестировщик определяет, какой из возможных и, хотя и не обязательных, потенциально опасных сценариев не будет посещать вообще и не будет тестировать на практике.
Невозможность полной спецификации
Однако, помимо явных вариантов использования, могут быть и другие случаи, которые необходимы для работы системы и которые также должны быть посещены и проверены тестировщиком. Но сначала их нужно вообще найти: это тоже обязанность тестировщика. Все такие другие необходимые случаи также становятся необходимыми для фактического объявления приложения как «функционального».
Этот поиск, хотя и неявный, но все еще необходимых случаев, часто выполняется аналитической группой проекта, но в конечном итоге тестировщик часто находит их снова и даже более подробно (возможно, также потому, что у него нет доступа к аналитикам). Степень, в которой аспекты взаимодействия с отдельными функциями, которые хочет охватить тестировщик, определяется им самим, в соответствии с его опытом и способностями: можно определить слишком мелкие рамки функциональные возможности в одном корпусе. Глубину резкости следует контролировать в соответствии с оставшимся временем, отведенным на этап проекта.
Функциональное ПО не требуется для определения плана постепенного тестирования, это просто вопрос работы над документацией, поэтому сценарии тестирования могут быть подготовлены еще до начала реализации. Текущие подробные сведения о проблеме и две разные точки зрения будут хорошо работать при проверке функций в отделе разработки: некоторые потенциальные дефекты могут быть обнаружены до того, как они возникнут или находятся в зачаточном состоянии, что сэкономит затраты на дополнительный ремонт. Решение случаев, по которым программист и тестировщик соглашаются таким образом, снова становится обязательными требованиями к конечному продукту.
Неформальный вход
Клиенты обычно описывают свои требования с помощью правил : Если A, то X. Но если B, то Y. С одной стороны, такой метод кажется интуитивно понятным, с другой стороны, он может быть хорошо формализован с использованием производственных правил , теории множеств и логики предикатов . На практике ни клиенты, ни трейдеры не формализуют свои назначения, результирующие требования затем предполагают невысказанное поведение или, что еще хуже, они не определяют выходы для некоторых возможных входов или не определяют все входные данные, хотя они возможны.
Практическим следствием могут быть случаи, когда:
- хотя поведение для выбранных параметров ввода указано, возможные входы, для которых поведение не описано, также остаются
- или описание входов даже охватывает все возможные значения, но уже не ситуацию, когда входные данные вообще не заданы
Неустановленный результат
Это случай, когда FS определяет поведение только для части всех теоретически возможных ситуаций (декартова, поддерево ). Таким образом, в приведенном ниже примере явно указано требование для ситуаций A и D. Однако оно не указывает напрямую другие возможности. В этом случае анализ (тестирование документации) может привести к нескольким результатам.
Пример показывает, что из другого контекста FS был сделан вывод, что опция E + F исключена из-за других контекстов. Вероятно, это было также причиной, по которой Ф.С. не осмелился прямо упомянуть этот случай. Поскольку это состояние не может быть достигнуто, а результат наблюдается, этот случай, таким образом, выпадает из тестирования.
Случай G более требователен, что опять же может быть связано с контекстом функциональности. Хотя это не обязательно указывать непосредственно в FS, это необходимое требование для функциональности системы, и поэтому его следует тестировать отдельно.
Иногда для этих требований из другого контекста может также следовать, что они не являются независимыми, а тавтологически перенимают (копируют) значение из другого случая, уже протестированного: эта априорная информация известна (белое поле), но контекст может измениться по мере развития событий в будущем.
Наихудшая возможность снова может быть связана с ситуацией G из примера: если такой случай можно идентифицировать как достижимый, он должен быть протестирован, то есть наблюдаться, а затем оцениваться. Но если FS не указывает эту ситуацию (не говорит, что правильно), это ошибка FS. Обнаружить такую ошибку до начала реализации всегда дешевле, чем найти ее, например, во время функционального тестирования. Решение затем предоставляется либо менеджером проекта, либо консультантом клиента, либо, в худшем случае, самим клиентом, например, путем внесения поправок в контракт.