Программные ошибки модифицированных компонентов

1

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

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

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

В общем случае отказ программного обеспечения можно определить как:

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

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

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

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

Библиографическая ссылка

Дроботун Е.Б. КРИТИЧНОСТЬ ОШИБОК В ПРОГРАММНОМ ОБЕСПЕЧЕНИИ И АНАЛИЗ ИХ ПОСЛЕДСТВИЙ // Фундаментальные исследования. – 2009. – № 4. – С. 73-74;
URL: http://fundamental-research.ru/ru/article/view?id=4467 (дата обращения: 06.04.2019).
Предлагаем вашему вниманию журналы, издающиеся в издательстве «Академия Естествознания»

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

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

Просматривайте свои проекты

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

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

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

Разработчики, которые оставили файл

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

The rules
about bugs is to test from early
stages of development, and to keep a 1:1 or 2:1 ratio of
programmers to testers. Then you can safely assume the
testing-debugging stage will take as long as the time originally
estimated to write the code.

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

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

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

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

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

ций
ПС,

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

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

Изменения
характеристик системы и внешней среды,

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

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

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

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

влияющими
на характеристики обнаруживаемых
ошибок, являются».

методология,
технология и уровень автоматизации
системного и структурного
проектирования ПС, а также непосредственного
программирования
компонентов;

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

класс
ПС, масштаб (размер) и типы компонентов,
в которых обнаруживаются
ошибки;

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

виды
и достоверность эталонов-тестов, которые
используются для обнаружения
ошибок.

Первичные
ошибки в ПС в порядке уменьшения их
влияния на

сложность
обнаружения и масштабы корректировок
можно разделить на следующие
группы (см. рис. 10.2):

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

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

ошибки
планирования и корректности требований
модификаций часто
могут быть наиболее критичным для
общего успеха ЖЦ ПС и системы;

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

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

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

ошибки
реализации спецификаций изменений —
программные дефекты,
возможно, ошибки нарушения требований
или структуры компонентов ПС;

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

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

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

Сложность
проявления, обнаружения и устранения
ошибок

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

сложность
ошибок при создании корректировок

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

сложность
проявления ошибок функционирования

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

К
группе факторов, влияющих на сложность
ошибок

комплексов
программ, относятся:

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

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

трудоемкость
разработки изменений комплекса программ;

длительность
разработки и реализации корректировок;

число
специалистов, участвующих в ЖЦ комплекса
программ.

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

комплексов
программ целесообразно
анализировать на базе трех наиболее
специфических компонентов:

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

определяется
конструктивной сложностью модификации
оформ-

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

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

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

сложность
ошибок изменения структуры данных

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

Масштаб

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

наиболее
сильно влияет на количество ошибок, а
также на требования к качеству

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

Ошибки
корректности формирования и планирования
выполне

ния
требований к ПС

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

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

Ошибки
проектирования и разработки структуры
ПС

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

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

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

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

Системные
ошибки в ПС

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

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

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

бок).
Следует также отметить большое количество
команд, корректируемых при исправлении
каждой такой ошибки (около 20-50 команд
на одну ошибку).

Алгоритмические
ошибки

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

К
алгоритмическим ошибкам следует отнести
также ошибки интерфейса
модулей и функциональных групп программ,
когда информация, необходимая
для функционирования некоторой части
программы, оказывается не полностью
подготовленной программами, предшествующими
по
времени включения, или неправильно
передаются информация и управление
между взаимодействующими модулями.
Этот вид ошибок составляет около 10% от
общего количества, и их можно квалифицировать
как ошибки некорректной постановки
задач. Алгоритмические ошибки проявляются
в неполном учете диапазонов изменения
переменных, в неправильной оценке
точности используемых и получаемых
величин, в неправильном
учете корреляции между различными
переменными, в неадекватном
представлении формализованных условий
решения задачи в виде частных спецификаций
или блок-схем, подлежащих программированию.
Эти
обстоятельства являются причиной того,
что для исправления каждой алгоритмической
ошибки приходится изменять в среднем
около 20 команд (строк
текста), т.е. существенно больше, чем при
программных ошибках.

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

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

Ошибки
реализации спецификаций компонентов

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

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

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

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

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

Программные
ошибки модифицированных компонентов

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

Ошибки
в документации модификаций

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

Неясность
— это когда

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

Технологические
ошибки

документации
и фиксирования программ в памяти ЭВМ
составляют иногда до 10% от общего числа
ошибок, обнаруживаемых
при тестировании. Большинство
технологических ошибок выявляется
автоматически статическими методами.
При ручной подготовке текстов машинных
носителей при однократном фиксировании
исходные данные
имеют вероятность искажения около 10
» 3 —
10~ 4
на символ. Дублированной
подготовкой и логическим контролем
вероятность технологической
ошибки может быть снижена до уровня 10
5
—
10″ 7
на символ. Непосредственное
участие человека в подготовке данных
для ввода в ЭВМ и
при анализе результатов функционирования
программ по данным на дисплеях определяет
в значительной степени их уровень
достоверности и не позволяет полностью
пренебрегать этим типом ошибок в
программах.

В
примере
анализа ошибок конкретного крупного
проекта

было
принято, что завершилась инспекция
начального запрограммированного кода
крупного ПС на предмет его соответствия
рабочей проектной спецификации,
в ходе которой было обнаружено 3,48 ошибки
на тысячу строк кода. Наибольшее
совпадение аппроксимации рэлеевской
кривой распределения
ошибок с фактическими данными установлено
для момента получения этих данных, ему
соответствует значение, равное также
3,48. Значения
числа ошибок на тысячу строк получены
при пересчетах на более ранние
этапы соответственно эскизного — (3,3)
и рабочего — (7,8) проектирования
программ. При прогнозировании в
соответствии с рэлеевской кривой
распределения вероятности проявления
дефектов программ на следующем
этапе квалификационного тестирования
компонентов следовало ожидать
обнаружения около 2,12 ошибки на тысячу
строк исходного кода.

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

В
исследованиях 20 крупных поставляемых
программных продуктов, созданных в 13
различных организациях, коллективы
специалистов добились среднего уровня
0,06 дефекта на тысячу строк нового и
измененного программного
кода. При использовании структурного
метода в пяти проектах достигнуто
0,04-0,075 ошибки на тысячу строк. Таким
образом, уровень
ошибок около 0,05 на тысячу строк кода

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

Другим
примером оценок уровня ошибок критического
ПС особенно высокого
качества может служить программный
продукт бортовых систем «Шаттла»,
созданный NASA.
По оценке авторов, в нем содержится
менее
одной ошибки на 10 000 строк кода. Однако
стоимость программного
продукта достигает 1000 $ за строку кода,
что в среднем в сто раз больше,
чем для административных систем, и в
десять раз больше, чем для ряда
ординарных критических управляющих
систем реального времени.

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

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

быточного
оптимизма

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

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

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

или
слу

чайные
негативные проявления дефектов

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

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

Риски
при случайных, дестабилизирующих
воздействиях

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

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

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

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

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

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

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

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

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

рисков:
функциональной пригодности ПС,
конструктивных характеристик качества
и нарушения ограничений ресурсов при
реализации процессов ЖЦ ПС;

Классификация ошибок программного обеспечения

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

В краткой классификации выделяются следующие ошибки.

Ошибки пользовательского интерфейса.

Ошибки вычислений.

Ошибки управления потоком.

Ошибки передачи или интерпретации данных.

Перегрузки.

Контроль версий.

Ошибка выявлена и забыта.

Ошибки тестирования.

1. Ошибки пользовательского интерфейса.

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

2. Ошибки вычислений.

Выделяют следующие причины возникновения таких ошибок:

Неверная логика (может быть следствием, как ошибок проектирования, так и кодирования);

Неправильно выполняются арифметические операции (как правило — это ошибки кодирования);

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

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

3. Ошибки управления потоком.

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

Выделяются подпункты:

Очевидно неверное поведение программы;

Переход по GOTO;

Логика, основанная на определении вызывающей подпрограммы;

Использование таблиц переходов;

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

4. Ошибки обработки или интерпретации данных.

Выделяются подпункты:

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

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

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

5. Повышенные нагрузки.

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

В этом разделе хотелось бы обратить внимание на следующее:

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

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

6. Контроль версий и идентификаторов.

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

7. Ошибки тестирования.

Являются ошибками сотрудников группы тестирования, а не программы. Выделяются подпункты:

Пропущенные ошибки в программе;

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

Пропуск ошибок на экране;

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

8. Ошибка выявлена и забыта.

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

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

Основные пути борьбы с ошибками

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

· сужение пространства перебора (упрощение создаваемых систем),

· обеспечение требуемого уровня подготовки разработчика (это функции менеджеров коллектива разработчиков),

· обеспечение однозначности интерпретации представления информации,

· контроль правильности перевода (включая и контроль однозначности интерпретации).

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

1. Анализ особенностей программной надежности АСОИУ и методов прогнозирования программных отказов

1.1 Основные понятия надежности программного обеспечения

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

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

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

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

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

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

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

Надежность программного обеспечения АСОИУ определяется его безотказностью, восстанавлиемостью и устойчивостью.

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

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

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

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

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

В с

В с — время восстановления после сбоя.

В о — время восстановления после отказа.

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

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

1.2 Основные причины и признаки выявления ошибок программного обеспечения

Основными причинами ошибок программного обеспечения являются:

Большая сложность программного обеспечения, например, по сравнению с аппаратурой ЭВМ.

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

Источниками ошибок программного обеспечения являются:

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

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

Признаками выявления ошибок являются:

1. Преждевременное окончание программы.

2. Увеличение времени выполнения программы.

3. Нарушение последовательности вызова отдельных подпрограмм.

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

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

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

Неверные действия пользователя:

1. Неправильная интерпретация сообщений.

2. Неправильные действия пользователя в процессе диалога с программным обеспечением.

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

Неисправности аппаратуры установки: приводят к нарушениям нормального хода вычислительного процесса; приводят к искажениям данных и текстов программ в основной и внешней памяти.

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

1.3 Основные параметры и показатели надежности программ АСОИУ

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

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

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

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

Рис. 1.3.1. — время жизни программы.

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

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

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

Методы прогнозирования и тестирования программного обеспечения включают в себя:

1. Методы, позволяющие справиться со сложностью системы.

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

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

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

2. Методы достижения большей точности при переводе информации.

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

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

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

Программная избыточность включает в себя:

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

немедленное обнаружение и регистрацию ошибок;

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

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

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

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

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

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

1. Техническое задание.

2. Описание системы.

3. Руководство пользователя.

4. Исходный текст.

5. Правила построения (стандарты) программ и интерфейсов.

6. Критерии качества тестирования.

7. Эталонные значения исходных и результирующих данных.

8. Выделенные ресурсы, определяемые доступными финансовыми средствами.

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

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

Предлагаемых изменений.

Найденных дефектов.

Утвержденных корректировок.

Реализованных изменений.

Пользовательских версий.

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

2. Анализ моделей оценки программной надежности

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

Эти математические модели предназначены для оценки:

1. Показателей надежности комплекса программ в процессе отладки;

2. Количества ошибок оставшиеся не выявленными;

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

4. Времени, необходимого для выявления всех ошибок с заданной вероятностью.

Существуют ряд математических моделей:

Экспоненциальная модель изменения ошибок в зависимости от времени отладки.

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

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

Модель La Padula. По этой модели выполнение последовательности тестов в m этапов. Каждый этап заканчивается внесением исправлений в программное обеспечение.

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

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

Модель Муса. В процессе тестирования фиксируется время выполнения программы (тестового прогона) до очередного отказа.

Модель переходных вероятностей. Эта модель основана на марковском процессе, протекающем в дискретной системе с непрерывным временем.

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

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

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

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

Модель Нельсона. Данная модель при расчете надежности программного обеспечения учитывает вероятность выбора определенного тестового набора для очередного выполнения программы.

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

2.1 Дискретно-меняющая модель

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

1. Устранение ошибок в программе приводит к увеличению времени наработки на отказ T на одну и ту же величину, равную:

T (1) =T (2) =…=T (i) = const (2.1.1)

T (i) = T (i) — T (i-1) (2.2.2)

2. Время между двумя последовательными отказами:

i = t i — t i -1 (2.1.3)

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

i = i -1 + I (2.1.4)

где i — независимые случайные величины, которые имеют одинаковые математические ожидания M{} и среднеквадратические отклонения.

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

На основании второго предположения величину интервала между i-м (i-1) — м отказами можно определить соотношением:

i = i -1 + i = 0 + j (2.1.5)

из которого можно получить соотношение для определения времени наступления m-го отказа в программе:

t m = i = (0 + j) (2.1.6)

исходя из третьего предположения полученные соотношения примут вид:

i = 0 + j = j (2.1.7)

t m = (0 + j) = i j (2.1.8)

При этих предположениях средняя наработка между (m-1) — м и m-м отказами программы равна:

T 0 (m) = M{ m -1 } = M{ j } = i j = m M{}. (2.1.9)

Средняя наработка до возникновения m-го отказа может быть определена по соотношению:

T m = M{t m } = i jk) = M{}. (2.1.10)

2.2 Экспоненциальное распределение

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

Рассматриваемое распределение характеризуется рядом свойств, такими как:

1. Ошибки в комплексе программ являются независимыми и проявляются в случайные моменты времени. Данное свойство характеризует неизменность во времени интенсивности проявления и обнаружения ошибок (т.е. ош =const) в течение всего времени выполнения программы (=t н -t 0).

2. Интенсивность проявления и обнаружения ошибок ош (интенсивность отказов) пропорционально числу оставшихся в ней ошибок:

()= Kn 0 () (2.2.1)

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

3. В процессе исправления ошибок программы новые ошибки не порождаются. Это означает, что интенсивность исправления ошибок dn/dt будет равна интенсивности их обнаружения:

Тогда n 0 ()= N 0 — n(). (2.2.3)

Основываясь на предположениях, введенных выше, получим:

n()=N 0 (1-e — K); (2.5)

Если принять, что, получим:

2.3 Методика оценки надежности программ по числу исправленных ошибок

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

n() — количество ошибок, устраненных в ходе испытаний (тестирования) программы;

n 0 () — число оставшихся в программе ошибок на момент окончания испытаний.

Тогда n 0 ()= N 0 — n().

Основываясь на предположениях введенных в пункте 2.2.1, а именно: и ()= Kn 0 () то получим:

K — коэффициент, учитывающий быстродействие компьютера.

Решением этого дифференциального уравнения при начальных условиях t=0 и =0 является:

n()=N 0 (1-e -K); (2.3.2)

n 0 ()=N 0 — n()=N 0 e -K . (2.3.3)

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

Если ввести исходное значение среднего времени наработки на отказ перед испытанием, равного, то получим:

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

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

Если обозначить за m — число обнаруженных отказов, а M 0 — число отказов, которое должно произойти, чтобы можно было выявить и устранить n соответствующих ошибок, то есть:

то среднее время наработки на отказ и число обнаруженных отказов определяется следующими соотношениями:

Если принять, что, получим:

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

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

2.4 Методика оценки надежности программ по времени испытания

Дополнительное время испытаний, необходимое для обеспечения увеличения среднего времени наработки на отказ с T 01 до T 02 определяется из соотношений:

где T 01 и T 02 определяются согласно формуле (2.3.9):

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

2.5 Методика оценки безотказности программ по наработке

Наработку между очередными отказами — случайную величину T (i) можно представить в виде суммы двух случайных величин:

T (i) = T (i -1) + T (i) (2.5.1)

Последовательно применяя (3.3.1) ко всем периодам наработки между отказами, получаем:

T (i) = T (0) + T (?) (2.5.2)

Случайная величина Т n — наработка до возникновения n-го отказа программы — равна:

T n = T (i) = (2.5.3)

Введем следующие допущения:

1) все случайные величины T () независимы и имеют одинаковые математические ожидания m ? t и среднеквадратические отклонения? ? t ;

2) случайная величина T (0) пренебрежимо мала по сравнению с суммой T (?)

Основанием для второго допущения могут служить следующие соображения: в самый начальный период эксплуатации программы ошибки возникают очень часто, то есть время T (0) мало. Сумма (2.5.3) быстро растет с увеличением n, и доля T (0) быстро падает. Будем считать что T (0) ? T (0) .
В соответствии со вторым допущением имеем:

T (n) =T (?) . (2.5.4)

При одинаковых T (?) наработка между (n-1) и n отказами — случайная величина T (n) — имеет математическое ожидание:

m t (n) =M=nm ? t (2.5.6)

T (n) = ? ? t ; (2.5.7)

Для случайной величины T n математическое ожидание равно:

M ? t ; (2.5.8)

и среднеквадратическое отклонение:

T ; (2.5.9)

Чтобы вычислить значения, и, необходимо по данным об отказах программы в течение периода наблюдения t н найти статистические оценки числовых характеристик случайной разности T (i) :

n н — число отказов программы за наработку (0, t н).

Учитывая, что при t >t н число отказов n н >> 1, из (2.5.8) и (2.5.9) имеем:

m t (n) ? m ? t , (2.5.12)

T (n) = ? ? t n ; (2.5.13)

Поскольку случайные величины T (n) и T n согласно (2.5.4) и (2.5.5) равны суммам многих случайных величин, T (n) и T n можно считать распределенными нормально с математическими ожиданиями и дисперсиями, определенными по (2.5.6) — (2.5.9), (2.5.12) и (2.5.13). Так как наработка положительна, на практике используется усеченное на интервале (0, ?) нормальное распределение. Обычно нормирующий множитель с?1.

При n>n н плотность распределения наработки между очередными (n-1) и n отказами:

f (n) (?) = , (2.5.14)

где? отсчитывается с момента последнего, (n-1) отказа.

Заключение

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

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

Список литературы

программный безотказность надежность прогнозирование

1. В.В. Липаев Проектирование математического обеспечения АСУ. (системотехника, архитектура, технология). М., «Сов. радио», 1977.

2. Р.С. Захарова Основные вопросы теории и практики надежности.

3. В.А. Благодатских, В.А. Волнин, К.Ф. ПоскакаловСтандартизация разработки программных средств.

4. А.А. ВороновТеоретические основы построения автоматизированных систем управления. Разработка технического задания.-М.: Наука, 1997.

5. Основы прикладной теории надежности АСУ. Учебное пособие, Тверь, ВА ПВО, 1995, н/с 32. 965,0-75. В.М. Ионов и др., инв. №8856.

6. Б.Н. Горевич. Расчет показателей надежности систем вооружения и резервированных элементов. Конспект лекций, ВА ПВО, 1998, н/с 68.501.4, Г68, инв. №9100

Размещено на Allbest.ru

Подобные документы

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

дипломная работа , добавлен 03.11.2013

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

курсовая работа , добавлен 02.07.2013

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

лекция , добавлен 22.03.2014

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

презентация , добавлен 22.03.2014

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

контрольная работа , добавлен 03.12.2010

Особенности аналитической и эмпирической моделей надежности программных средств. Проектирование алгоритма тестирования и разработка программы для определения надежности ПО моделями Шумана, Миллса, Липова, с использованием языка C# и VisualStudio 2013.

курсовая работа , добавлен 29.06.2014

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

курс лекций , добавлен 27.05.2008

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

дипломная работа , добавлен 17.11.2010

Постановка проблемы надежности программного обеспечения и причины ее возникновения. Характеристики надежности аппаратуры. Компьютерная программа как объект исследования, ее надежность и правильность. Модель последовательности испытаний Бернулли.

реферат , добавлен 21.12.2010

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

2.1. Интеллектуальные возможности человека

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

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

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

При разработке ПС не всегда есть
уверенность, что знаешь обо всех связях
между его элементами. Часто невозможно
отследить все связи, а это порождает
поле возможных ошибок. Сложность системы
оценивают числом ее элементов или числом
потенциальных путей взаимодействия
между элементами, т.е. n!
(n-факториалом), где n
 число элементов
системы. Систему называют малой,
12Сли
n<7 (6!=720<1000), систему называют
большой, если n>7. При n=7
имеем промежуточный класс систем. Малая
система всегда проста, а большая может
быть как простой, так и сложной. Задача
технологии программирования 
научиться сводить большие системы к
простым системам.

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

2.2. Неправильный перевод как причина ошибок в пс

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Если предполагать, что в программном обеспечении какие-то ошибки все же будут, то лучшая (после предупреждения ошибок) стратегия — включить средства обнаружения ошибок в само про-граммное обеспечение.

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

{SITELINK-S405}Меры по обнаружению ошибок {/SITELINK}можно разбить на две под-группы: пассивные

попытки обнаружить симптомы ошибки в про-цессе «обычной» работы программного обеспечения и активные

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

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

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

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

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

3. Избыточность.
Все средства обнаружения ошибок основаны на некоторой форме избыточности (явной или неявной).

Когда разрабатываются {SITELINK-S405}меры по обнаружению ошибок{/SITELINK}, важ-но принять согласованную стратегию для всей системы. Действия, предпринимаемые после обнаружения ошибки в программном обеспечении, должны быть единообразными для всех компонен-тов системы. Это ставит вопрос о том, какие именно действия следует предпринять, когда ошибка обнаружена. Наилучшее решение — немедленно завершить выполнение программы или (в случае операционной системы) перевести центральный про-цессор в состояние ожидания. С точки зрения предоставления че-ловеку, отлаживающему программу, например системному про-граммисту, самых благоприятных условий для диагностики оши-бок немедленное завершение представляется наилучшей стратегией. Конечно, во многих системах подобная стратегия бывает нецелесообразной (например, может оказаться, что при-останавливать работу системы нельзя). В таком случае использу-ется метод регистрации ошибок.
Описание симптомов ошибки и «моментальный снимок» состояния системы сохраняются во внеш-нем файле, после чего система может продолжать работу. Этот файл позднее будет изучен обслуживающим персоналом.

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

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

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

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

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

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

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

Просматривайте свои проекты

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

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

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

Разработчики, которые оставили файл

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

The rules
about bugs is to test from early
stages of development, and to keep a 1:1 or 2:1 ratio of
programmers to testers. Then you can safely assume the
testing-debugging stage will take as long as the time originally
estimated to write the code.

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

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

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

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

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

Рис. 1. Стоимость устранения ошибок во встраиваемых системах

На мой взгляд, сроки и затраты на выявление и устранение ошибок для встраиваемых систем приблизительно удваиваются (из-за описанных выше трудностей). В свете таких немыслимых затрат любой метод, который изначально будет препятствовать появлению ошибок, имеет неоценимое значение. К счастью для разработчиков встраиваемых систем, для предотвращения ошибок можно использовать некоторые из новых технологий программной разработки. Наиболее рекомендуемые две из них: стандарты программирования и блочное тестирование.
Правда, оба этих метода сегодня не столько применяются, сколько прославляются. Практически каждый разработчик программного обеспечения согласен с их высокой ценностью, но пользуются ими единицы. Подобная непоследовательность объясняется в большинстве случаев двумя причинами. Прежде всего, многие считают следование стандартам программирования и блочное тестирование весьма утомительным делом. Учитывая, сколько времени и сил эти подходы позволяют сэкономить в будущем, разработчикам следовало бы немножко потерпеть и избежать огромных трудозатрат (и возможного отказа от проекта) впоследствии.
Разработчикам систем реального времени еще труднее они в дополнение ко всему должны решать проблемы, связанные с соблюдением различных временных зависимостей. В конце статьи мы рассмотрим трудности, возникающие при отладке систем реального времени, и познакомимся с некоторыми методами отладки, которые рассчитаны на преодоление этих трудностей и которые также могут быть использованы при разработке любого программного обеспечения.
Способы отладки программ
Отладка программ заключается в проверке правильности работы программы и аппаратуры. Программа, не содержащая синтаксических ошибок тем не менее может содержать логические ошибки, не позволяющие программе выполнять заложенные в ней функции. Логические ошибки могут быть связаны с алгоритмом программы или с неправильным пониманием работы аппаратуры, подключённой к портам микроконтроллера.
Встроенный в состав интегрированной среды программирования отладчик позволяет отладить те участки кода программы, которые не зависят от работы аппаратуры, не входящей в состав микросхемы микроконтроллера. Обычно это относится к вычислению математических выражений или преобразованию форматов представления данных.
Для отладки программ обычно применяют три способа: Пошаговая отладка программ с заходом в подпрограммы; Пошаговая отладка программ с выполнением подпрограммы как одного оператора; Выполнение программы до точки останова.
Пошаговая отладка программ заключается в том, что выполняется один оператор программы и, затем контролируются те переменные, на которые должен был воздействовать данный оператор.
Если в программе имеются уже отлаженные подпрограммы, то подпрограмму можно рассматривать, как один оператор программы и воспользоваться вторым способом отладки программ.
Если в программе существует достаточно большой участок программы, уже отлаженный ранее, то его можно выполнить, не контролируя переменные, на которые он воздействует. Использование точек останова позволяет пропускать уже отлаженную часть программы. Точка останова устанавливается в местах, где необходимо проверить содержимое переменных или просто проконтролировать, передаётся ли управление данному оператору.
Практически во всех отладчиках поддерживается это свойство (а также выполнение программы до курсора и выход из подпрограммы). Затем отладка программы продолжается в пошаговом режиме с контролем локальных и глобальных переменных, а также внутренних регистров микроконтроллера и напряжений на выводах этой микросхемы. Следуйте стандартам программирования!

Самый лучший способ повысить качество ПО это стараться не допускать ошибок в процессе ввода исходного текста.
Первый шаг на пути предотвращения ошибок это осознание того, что ошибки действительно можно предотвратить. Больше всего препятствует контролю над ошибками распространенное убеждение в том, что ошибки неизбежны. Это заблуждение! Ошибки сами по себе не появляются их вносит в текст разработчик. Человеку свойственно ошибаться, так что даже самые лучшие программисты время от времени допускают ошибки, если у них есть такая возможность. Поэтому чтобы уменьшить число ошибок, надо сократить возможности их появления. Один из лучших способов здесь следование стандартам программирования, что ликвидирует благодатную почву для возникновения ошибок на первых этапах.
Стандарты программирования это специфичные для языка «правила», которые, если их соблюдать, значительно снижают вероятность внесения ошибок в процессе разработки приложения. Следовать стандартам программирования нужно на этапе написания программ, до их переноса в целевые платформы, при этом стандартизация должна существовать для всех языков. Поскольку большая часть разработчиков встраиваемых систем пользуется языком С, больше внимания уделим именно стандартам программирования на C, хотя такие же стандарты существуют и для других языков, включая С++ и Java.
Как правило, стандарты программирования делятся на две категории:
отраслевые стандарты программирования: правила, принятые всеми программистами на данном языке (например, запрет входа в цикл не через его заголовок).
специальные стандарты программирования: правила, соблюдаемые конкретной группой разработчиков, в рамках конкретного проекта, или даже единственным программистом. Существует три типа специальных стандартов, которыми может воспользоваться разработчик встраиваемой программной системы: внутренние стандарты, персональные стандарты и стандарты, определяемые целевой платформой.
Внутренние стандарты программирования это правила, которые специфичны для вашей организации или группы разработчиков. Так, уникальные для организации правила присвоения имен это пример внутренних стандартов программирования.
Персональные стандарты это правила, которые помогут вам избежать ваших наиболее частых ошибок. Каждый раз при появлении какой-либо ошибки программист должен проанализировать причину ее появления и выработать собственное правило, препятствующее повторному ее возникновению. Например, если в операторе условия вы часто пишете знак присваивания вместо знака проверки на равенство (т.е. «if (a=b)» вместо «if (a= =b)»), то вам необходимо создать для себя следующий стандарт: «Остерегаться применения знака присваивания в операторе проверки условия».
Стандарты, определяемые целевой платформой, это правила, нарушение которых в данной платформе может привести к появлению определенных проблем. Например, такими стандартами могут быть ограничения на использование памяти или размер переменных, налагаемые целевой платформой.
Чтобы лучше разобраться в том, что такое стандарты программирования и как они работают, познакомимся с ними на конкретных примерах. Рассмотрим следующую запись на языке С:
{
.
.
.
}
Здесь размер одномерного массива декларируется в списке аргументов функции. Это опасная конструкция, поскольку в языке С аргумент-массив передается как указатель на его первый элемент, и в разных обращениях к функции в числе ее фактических аргументов могут указываться массивы с разной размерностью. Создав такую конструкцию, вы предполагаете пользоваться буфером фиксированного размера на 80 элементов, считая, что именно такой буфер и будет передаваться функции, а это может привести к разрушению памяти. Если бы автор этого оператора следовал стандарту программирования «не объявлять размер одномерного массива в числе аргументов функции» (взятому из набора стандартов программирования на языке С одной из ведущих телекоммуникационных компаний), то этот текст выглядел бы следующим образом и проблем с разрушением памяти удалось бы избежать:
char *substring (char string, int start_pos, int length)
{
.
.
.
}
Стандарты программирования позволяют также избегать проблем, которые до момента портирования кода на другую платформу могут не проявляться. Например, следующий кусок кода будет исправно работать на одних платформах и порождать ошибки после переноса его на другие платформы:
#include
void test(char c) {
if(a }
if(islower(c)) {// Правильно
}
while (A }
while (isupper(c)) { // Правильно
}
}
Проблемы портации могут быть связаны с символьными тестами, в которых не используется функции ctype.h (isalnum, isalpha, iscntrl, isdigit, isgraph, islower, isprint, ispunct, isspace, isupper, isxdigit, tolower, toupper). Функции ctype.h для символьной проверки и преобразования прописных букв в строчные и наоборот работают с самыми разными наборами символов, обычно очень эффективны и гарантируют международную применимость программного продукта.
Лучший способ внедрить эти и другие стандарты программирования это обеспечить их автоматическое применение в составе какой-либо технологии программирования, вместе с набором целенаправленных отраслевых стандартов и механизмами создания и поддержки стандартов программирования, ориентированных на конкретную систему. При выборе подобной технологии необходимо сначала найти ответы на вопросы, среди которых следующие:
Применима ли она к данной программе и/или компилятору?
Содержит ли она набор отраслевых стандартов программирования?
Позволяет ли она создавать и поддерживать специальные стандарты программирования (включая стандарты, определяемые целевой платформой)?
Легко ли структурировать отчеты в соответствии с вашими групповыми и проектными приоритетами?
Насколько легко она интегрируется в существующий процесс разработки?
Блочное тестирование

Зачастую, слыша о блочном тестировании, разработчики воспринимают его как синоним модульного тестирования. Другими словами, проверяя отдельный модуль или подпрограмму более крупной программной единицы, разработчики считают, что выполняют блочное тестирование. Конечно, модульное тестирование имеет очень большое значение и, безусловно, должно проводиться, но это не тот метод, на котором я бы хотел остановиться. Говоря о «блочном тестировании», я имею в виду тестирование на еще более низком уровне: тестирование самых минимально возможных программных единиц, из которых состоит прикладная программа, всё ещё находясь в инструментальной среде (хост-системе) в случае языка С, это будут функции, которые проверяются сразу же после их компиляции.
Блочное тестирование значительно повышает качество программного обеспечения и эффективность процесса разработки. При тестировании на уровне объектов вы гораздо ближе к этой методике и обладаете гораздо большими возможностями построения входных наборов, выявляющих ошибки со стопроцентным покрытием (рис. 2). Кроме того, тестируя блок кода сразу после того, как он был написан, вы тем самым избегаете необходимости «продираться» через наслоения ошибок, чтобы найти и исправить единственную исходную в данном случае вы сразу ее устраняете, и вся проблема решена. Это существенно ускоряет и облегчает процесс разработки, поскольку на поиск и устранение ошибок тратится значительно меньше материальных и временных ресурсов.

Рис. 2. Простота нахождения ошибок при блочном тестировании

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

Рис. 3. Тестирование «черного ящика»

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

Рис. 4. Тестирование «белого ящика»

Оба вышеописанных процесса могут служить основой третьего, регрессивного тестирования. Сохранив тестовые наборы для «черного» и «белого» ящиков, можно использовать их для регрессивного тестирования на уровне блоков и контролировать целостность кода по мере того, как вы его модифицируете. Концепция регрессивного тестирования на этом уровне является новым оригинальным подходом. При выполнении регрессивного тестирования на уровне блоков можно сразу же после изменения вами текста определять, не появились ли новые проблемы, и устранять их немедленно после возникновения, тем самым препятствуя распространению ошибки по вышележащим уровням.
Главная проблема, связанная с блочным тестированием, заключается в том, что если не пользоваться технологиями автоматического блочного тестирования, проводить его трудно, утомительно и слишком долго. Рассмотрим вкратце причины, по которым включать неавтоматизированное блочное тестирование в сегодняшние процессы разработки трудно (если вообще возможно).
Первый этап блочного тестирования ПО встраиваемых систем заключается в создании такой среды, которая позволит запускать и тестировать интересующую функцию в хост-системе. Это требует выполнения следующих двух действий:
разработка программного текста, который будет запускать функцию,
написание фиктивных модулей, которые будут возвращать результаты вместо внешних ресурсов, к которым обращается функция и которые в текущий момент отсутствуют или недоступны.
Второй этап разработка тестовых наборов. Для полноты охвата конструктивных и функциональных особенностей функции необходимо создавать тестовые наборы двух типов: для «черного ящика» и для «белого ящика».
Основой разработки тестовых наборов для «черного ящика» должна стать спецификация функции. В частности, для каждой записи в спецификации должен быть создан хотя бы один тестовый набор, при этом желательно, чтобы эти наборы учитывали указанные в спецификации граничные условия. Проверять того, что некоторые входные параметры приводят к ожидаемым результатам, недостаточно; необходимо определить диапазон взаимосвязей входов и выходов, который позволит сделать вывод о корректной реализации указанных функциональных характеристик, и затем создавать тестовые наборы, полностью покрывающие данный диапазон. Можно также тестировать не указанные в спецификации и ошибочные условия.
Цель тестовых наборов для «белого ящика» обнаружить все скрытые дефекты путем всестороннего тестирования функции разнообразными входными параметрами. Эти наборы должны обладать следующими возможностями:
обеспечивать максимально возможное (100%) покрытие функции: как уже говорилось, такая степень покрытия на уровне блоков возможна, поскольку создавать наборы для тестирования каждой характеристики функции вне приложения гораздо проще (стопроцентное покрытие во всех случаях невозможно, но это цель, к которой надо стремиться);
выявлять условия краха функции.
Следует заметить, что самостоятельно создание подобных наборов, не владея технологиями их построения, невероятно тяжелое занятие. Чтобы создать эффективные тестовые наборы для «белого ящика», необходимо сначала получить полное представление о внутренней структуре функции, написать наборы, обеспечивающие максимальное покрытие функции, и найти совокупность входов, приводящих к отказу функции. Получить спектр покрытия, необходимый для высокоэффективного тестирования «белого ящика», возможно лишь при исследовании значительного числа путей прохода по функции. Например, в обычной программе, состоящей из 10000 операторов, имеется приблизительно сто миллионов возможных путей прохода; вручную создать тестовые наборы для проверки всех этих путей невозможно.
После создания тестовых наборов необходимо провести тестирование функции в полном объеме и проанализировать результаты с целью выявления причин ошибок, крахов и слабых мест. Необходимо иметь способ прогона всех тестовых наборов и быстрого определения, какие из них приводят к возникновению проблем. Необходимо также иметь инструмент измерения степени покрытия для оценки полноты тестирования функции и определения необходимости в дополнительных тестовых наборах.
При любых изменениях функции следует проводить регрессивное тестирование, чтобы убедиться в отсутствии новых и/или устранении предыдущих ошибок. Включение блочного регрессивного тестирования в процесс разработки позволит защититься от многих ошибок они будут обнаружены сразу же после возникновения и не смогут стать причинами распространения ошибок в приложении.
Регрессивное тестирование можно проводить двумя способами. Первый заключается в том, что разработчик или испытатель анализирует каждый тестовый набор и определяет, на работе которого из них может сказаться измененный код. Этот подход характеризуется экономией машинного времени за счет работы, проводимой человеком. Второй, более эффективный, заключается в автоматическом прогоне на компьютере всех тестовых наборов после каждого изменения текста. Данный подход гарантирует большую эффективность труда разработчика, поскольку он не должен тратить время на анализ всей совокупности тестовых наборов, для того чтобы определить, какие наборы следует прогонять, а какие нет.
Если вы сможете автоматизировать процесс блочного тестирования, то не только повысите качество тестирования, но и высвободите для себя значительно больше временных и материальных ресурсов, чем уйдёт на этот процесс. Если вы пишете программы на языке С, то для автоматизации блочного тестирования можете воспользоваться существующими технологиями. Чем больше процессов вы сможете автоматизировать, тем больше пользы вы получите.
При выборе технологии блочного тестирования сначала следует ответить на следующие вопросы:
Подходит ли эта технология для вашего текста и/или компилятора?
Может ли она автоматически создавать тестовые схемы?
Может ли она автоматически генерировать тестовые наборы?
Позволяет ли она вводить создаваемые пользователем тестовые наборы и фиктивные модули?
Автоматизировано ли регрессивное тестирование?
Имеется ли в ее составе технология или связь с технологией автоматического распознавания ошибки в процессе прогона?
Средства отладки, не меняющие режим работы программ

Из-за того, что операционные системы реального времени должны выполнять определенные задачи в условиях заранее определенных временных ограничений, временные соотношения превращаются в важнейший параметр, который разработчики должны учитывать при установке тестового ПО. Обычно в процессе исполнения программ возникает множество различных прерываний, и чрезвычайно необходимо, чтобы в момент возникновения прерывания приложение реагировало корректно. Ситуация еще более усложняется, когда несколько прерываний возникает сразу или когда в системе исполняется несколько приложений с несколькими взаимодействующими друг с другом тредами. По сути, это приложения с несколькими одновременными путями исполнения различные кодовые последовательности как бы исполняются в одно и то же время, даже если в системе всего один центральный процессор. Интересно заметить, что если бы эти приложения исполнялись в нескольких процессорах, то различные треды на практике были бы загружены в разные процессоры.
Если возникающие в приложениях реального времени ошибки проявляются во взаимодействиях между программой и прерываниями, то они будут в значительной мере чувствительны ко времени. В этом случае критически важно регистрировать порядок возникновения ошибок, поскольку это позволит разобраться в причинах и следствиях каждой ошибки. В этом как раз и кроется главная проблема отладки систем реального времени: существует достаточное количество трудновыявляемых ошибок, которые проявляются только при определенных временных соотношениях.
Эта проблема осложняется тем, что подобные ошибки не так-то просто воспроизводятся. Очень трудно воссоздать ситуацию с такими же временными соотношениями, что и приведшие к возникновению ошибки в реальной программе. Механизм отладки таких приложений должен быть максимально возможно щадящим. Любое вмешательство в ход исполнения программ может привести к изменению ее временных характеристик и отсутствию условий возникновения ошибок. Конечно, создание условий, при которых ошибки не возникают, это хорошо, но в данном случае это является препятствием отладке программы.
Теоретической основой проблемы отладки систем реального времени может послужить известный всем из курса физики принцип неопределенности немецкого физика Вернера Гейзенберга, согласно которому одновременно определить скорость и местоположение движущейся частицы невозможно. Гейзенберг считал, что, определяя координаты частицы, экспериментатор тем самым изменяет её местоположение, что не позволяет определить её координаты точно. Операция измерения влияет на измеряемый объект и искажает результаты измерения. Принцип неопределенности это одна из аксиом квантовой механики.
Применительно же к нашей теме, этот принцип означает, что отладка системы требует сбора информации о ее состоянии. Однако сбор информации о состоянии системы меняет ее временные характеристики и существенно затрудняет надежное воспроизведение условий возникновения ошибки.
Таким образом, суть этой проблемы в том, что нужно найти способ обнаружения ошибок реального времени и анализа поведения программы без влияния на существующие временные соотношения. Наверное, вашим первым порывом было бы обращение к отладчику, но отладчики, как правило, прерывают исполнение программы и, соответственно, изменяют ее временные характеристики. Малопригодны и системы моделирования, поскольку они не могут воссоздать временные характеристики реальных технических средств. Еще никто не создал такую систему моделирования, которая могла бы смоделировать режим реального времени; временные параметры можно определить, только загрузив программу в само железо.
Последнее требует наличия специального механизма для упрощенной регистрации состояния системы. Один из возможных и подходящих механизмов запись информации в оперативную память, поскольку такая операция выполняется чрезвычайно быстро. Один из способов применения этого механизма организация где-нибудь в памяти специального буфера и использование в вашей программе указателя на этот буфер. Указатель всегда ссылается на начало буфера. В программу вставляются операции записи в ячейку, определяемую указателем. После каждой операции записи значение указателя меняется соответствующим образом. Иногда полезно пользоваться кольцевым буфером (т.е. когда после записи в последнюю ячейку буфера указатель начинает показывать на начало буфера), что позволяет отслеживать ситуации, приводящие к возникновению проблемы. Необходимо при этом предусмотреть способ сохранения содержимого буфера после нормального или аварийного завершения программы, чтобы впоследствии иметь к нему доступ и проводить так называемую «посмертную отладку». Способ реализации зависит от аппаратных средств, обычно это можно сделать, если не выполнять повторную инициализацию (reset) оборудования.
Теперь вам нужен механизм чтения этой памяти. Здесь можно использовать и отладчик, и другие средства извлечения информации из оперативной памяти. В частности, можно написать простенькую программу, которая будет пересылать эти данные в файл или на принтер. Каким бы средством вы не пользовались, конечным этапом, вероятнее всего, будет ручной анализ содержимого буфера. Если ваш буфер кольцевой, то вам необходимо иметь точные сведения о значении указателя; события, которые стали началом последовательности, будут непосредственно перед указателем, события, которые возникли непосредственно перед крахом, будут сразу же после указателя.

Рис. 5. Последовательность событий в кольцевом буфере

Теперь ваша главная задача попытаться разобраться в последовательности данных, записанных в буфере. Эта задача аналогична исследованию причин катастрофы самолета по показаниям приборов, зарегистрированных «черным ящиком» самолета. Анализ характеристик программы в этом случае проводится после свершившегося события, что, естественно, гораздо меньше влияет на ее исполнение, чем контроль в течение работы.
Иногда бывает очень трудно восстановить приведшие к краху события, и четкого понятия о моменте возникновения ошибки нет. Только на выяснение причины ошибки могут уходить многие месяцы. В таких случаях для поиска ошибочного оператора можно воспользоваться логарифмическим методом отладки. В разных местах отлаживаемого кода расставляются маркеры (например, операторы типа exit), а перед ними операторы записи в память. Затем запускаете программу и ожидаете момента краха. В случае краха вы знаете, между какими маркерами он произошел. Этот метод позволяет выявлять и проблемы согласования по времени, поскольку он позволяет находить сегменты кода, в которых возникают нарушения временных соотношений.
Ещё одно решение это применение в качестве технологии отладки так называемых брандмауэров. Брандмауэр это точка в логическом потоке программы, в которой доказывается справедливость предположений, на которые опирается последующий код. Проверка этих предположений отличается от обычного контроля ошибок. Срабатывание брандмауэра представляет собой сигнал разработчику о том, что внутреннее состояние системы неустойчиво. Это может произойти, например, если ожидающая строго положительного аргумента функция получает нулевую или отрицательную величину. Неискушённым разработчикам большинство брандмауэров кажутся тривиальными и ненужными. Однако опыт разработки крупных проектов показывает, что по мере развития и совершенствования программных систем неявные предположения в отношении среды исполнения нарушаются все чаще и чаще. Во многих случаях даже сам автор затрудняется сформулировать, что представляют собой надлежащие условия исполнения того или иного участка кода.
Реализуемые внутри встраиваемых систем брандмауэры нуждаются в специальных средствах связи для передачи сообщений во внешний мир; обсуждение способа установления таких каналов передачи выходит за рамки настоящей статьи.
Заключение

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

1. M. Aivazis and W. Hicken. «C++ Defensive Programming: Firewalls and Debugging Information.» C++ Report (July-August 1999): 34 40.

1

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

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

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

В общем случае отказ программного обеспечения можно определить как:

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

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

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

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

Библиографическая ссылка

Дроботун Е.Б. КРИТИЧНОСТЬ ОШИБОК В ПРОГРАММНОМ ОБЕСПЕЧЕНИИ И АНАЛИЗ ИХ ПОСЛЕДСТВИЙ // Фундаментальные исследования. – 2009. – № 4. – С. 73-74;
URL: http://fundamental-research.ru/ru/article/view?id=4467 (дата обращения: 06.04.2019).
Предлагаем вашему вниманию журналы, издающиеся в издательстве «Академия Естествознания»

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

ций
ПС,

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

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

Изменения
характеристик системы и внешней среды,

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

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

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

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

влияющими
на характеристики обнаруживаемых
ошибок, являются».

методология,
технология и уровень автоматизации
системного и структурного
проектирования ПС, а также непосредственного
программирования
компонентов;

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

класс
ПС, масштаб (размер) и типы компонентов,
в которых обнаруживаются
ошибки;

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

виды
и достоверность эталонов-тестов, которые
используются для обнаружения
ошибок.

Первичные
ошибки в ПС в порядке уменьшения их
влияния на

сложность
обнаружения и масштабы корректировок
можно разделить на следующие
группы (см. рис. 10.2):

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

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

ошибки
планирования и корректности требований
модификаций часто
могут быть наиболее критичным для
общего успеха ЖЦ ПС и системы;

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

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

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

ошибки
реализации спецификаций изменений —
программные дефекты,
возможно, ошибки нарушения требований
или структуры компонентов ПС;

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

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

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

Сложность
проявления, обнаружения и устранения
ошибок

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

сложность
ошибок при создании корректировок

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

сложность
проявления ошибок функционирования

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

К
группе факторов, влияющих на сложность
ошибок

комплексов
программ, относятся:

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

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

трудоемкость
разработки изменений комплекса программ;

длительность
разработки и реализации корректировок;

число
специалистов, участвующих в ЖЦ комплекса
программ.

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

комплексов
программ целесообразно
анализировать на базе трех наиболее
специфических компонентов:

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

определяется
конструктивной сложностью модификации
оформ-

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

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

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

сложность
ошибок изменения структуры данных

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

Масштаб

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

наиболее
сильно влияет на количество ошибок, а
также на требования к качеству

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

Ошибки
корректности формирования и планирования
выполне

ния
требований к ПС

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

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

Ошибки
проектирования и разработки структуры
ПС

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

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

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

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

Системные
ошибки в ПС

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

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

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

бок).
Следует также отметить большое количество
команд, корректируемых при исправлении
каждой такой ошибки (около 20-50 команд
на одну ошибку).

Алгоритмические
ошибки

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

К
алгоритмическим ошибкам следует отнести
также ошибки интерфейса
модулей и функциональных групп программ,
когда информация, необходимая
для функционирования некоторой части
программы, оказывается не полностью
подготовленной программами, предшествующими
по
времени включения, или неправильно
передаются информация и управление
между взаимодействующими модулями.
Этот вид ошибок составляет около 10% от
общего количества, и их можно квалифицировать
как ошибки некорректной постановки
задач. Алгоритмические ошибки проявляются
в неполном учете диапазонов изменения
переменных, в неправильной оценке
точности используемых и получаемых
величин, в неправильном
учете корреляции между различными
переменными, в неадекватном
представлении формализованных условий
решения задачи в виде частных спецификаций
или блок-схем, подлежащих программированию.
Эти
обстоятельства являются причиной того,
что для исправления каждой алгоритмической
ошибки приходится изменять в среднем
около 20 команд (строк
текста), т.е. существенно больше, чем при
программных ошибках.

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

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

Ошибки
реализации спецификаций компонентов

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

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

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

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

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

Программные
ошибки модифицированных компонентов

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

Ошибки
в документации модификаций

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

Неясность
— это когда

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

Технологические
ошибки

документации
и фиксирования программ в памяти ЭВМ
составляют иногда до 10% от общего числа
ошибок, обнаруживаемых
при тестировании. Большинство
технологических ошибок выявляется
автоматически статическими методами.
При ручной подготовке текстов машинных
носителей при однократном фиксировании
исходные данные
имеют вероятность искажения около 10
» 3 —
10~ 4
на символ. Дублированной
подготовкой и логическим контролем
вероятность технологической
ошибки может быть снижена до уровня 10
5
—
10″ 7
на символ. Непосредственное
участие человека в подготовке данных
для ввода в ЭВМ и
при анализе результатов функционирования
программ по данным на дисплеях определяет
в значительной степени их уровень
достоверности и не позволяет полностью
пренебрегать этим типом ошибок в
программах.

В
примере
анализа ошибок конкретного крупного
проекта

было
принято, что завершилась инспекция
начального запрограммированного кода
крупного ПС на предмет его соответствия
рабочей проектной спецификации,
в ходе которой было обнаружено 3,48 ошибки
на тысячу строк кода. Наибольшее
совпадение аппроксимации рэлеевской
кривой распределения
ошибок с фактическими данными установлено
для момента получения этих данных, ему
соответствует значение, равное также
3,48. Значения
числа ошибок на тысячу строк получены
при пересчетах на более ранние
этапы соответственно эскизного — (3,3)
и рабочего — (7,8) проектирования
программ. При прогнозировании в
соответствии с рэлеевской кривой
распределения вероятности проявления
дефектов программ на следующем
этапе квалификационного тестирования
компонентов следовало ожидать
обнаружения около 2,12 ошибки на тысячу
строк исходного кода.

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

В
исследованиях 20 крупных поставляемых
программных продуктов, созданных в 13
различных организациях, коллективы
специалистов добились среднего уровня
0,06 дефекта на тысячу строк нового и
измененного программного
кода. При использовании структурного
метода в пяти проектах достигнуто
0,04-0,075 ошибки на тысячу строк. Таким
образом, уровень
ошибок около 0,05 на тысячу строк кода

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

Другим
примером оценок уровня ошибок критического
ПС особенно высокого
качества может служить программный
продукт бортовых систем «Шаттла»,
созданный NASA.
По оценке авторов, в нем содержится
менее
одной ошибки на 10 000 строк кода. Однако
стоимость программного
продукта достигает 1000 $ за строку кода,
что в среднем в сто раз больше,
чем для административных систем, и в
десять раз больше, чем для ряда
ординарных критических управляющих
систем реального времени.

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

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

быточного
оптимизма

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

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

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

или
слу

чайные
негативные проявления дефектов

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

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

Риски
при случайных, дестабилизирующих
воздействиях

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

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

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

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

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

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

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

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

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

рисков:
функциональной пригодности ПС,
конструктивных характеристик качества
и нарушения ограничений ресурсов при
реализации процессов ЖЦ ПС;

19

Ñîäåðæàíèå

Ââåäåíèå

1. Ôèëîñîôèÿ òåñòèðîâàíèÿ

2. Èíòåãðàöèÿ ìîäóëÿ

2.1 Âîñõîäÿùåå òåñòèðîâàíèå

2.2 Íèñõîäÿùåå òåñòèðîâàíèå

3. Ðàñïðîñòðàíåííûå ìåòîäû òåñòèðîâàíèÿ

3.1 Ìåòîä áîëüøîãî ñêà÷êà

3.2 Ìåòîä ñàíäâè÷à

4. Ñèñòåìíîå òåñòèðîâàíèå

4.1 àâòîìàòèçàöèÿ òåñòèðîâàíèå

Çàêëþ÷åíèå

Ñïèñîê ëèòåðàòóðû

Ââåäåíèå

Ìíîãèå îðãàíèçàöèè, çàíèìàþùèåñÿ ñîçäàíèåì ïðîãðàììíîãî îáåñïå÷åíèÿ, äî 50% ñðåäñòâ, âûäåëåííûõ íà ðàçðàáîòêó ïðîãðàìì, òðàòÿò íà òåñòèðîâàíèå, ÷òî ñîñòàâëÿåò ìèëëèàðäû äîëëàðîâ ïî âñåìó ìèðó â öåëîì. È âñå æå, íåñìîòðÿ íà ãðîìàäíûå êàïèòàëîâëîæåíèÿ, çíàíèé î ñóòè òåñòèðîâàíèÿ ÿâíî íå õâàòàåò è áîëüøèíñòâî ïðîãðàììíûõ ïðîäóêòîâ íåïðèåìëåìî íåíàäåæíî äàæå ïîñëå “îñíîâàòåëüíîãî òåñòèðîâàíèÿ”.

Î ñîñòîÿíèè äåë ëó÷øå âñåãî ñâèäåòåëüñòâóåò òîò ôàêò, ÷òî áîëüøèíñòâî ëþäåé, ðàáîòàþùèõ â îáëàñòè îáðàáîòêè äàííûõ, äàæå íå ìîæåò ïðàâèëüíî îïðåäåëèòü ñëîâî “òåñòèðîâàíèå”, è ýòî íà ñàìîì äåëå ãëàâíàÿ ïðè÷èíà íåóäà÷.

«Òåñòèðîâàíèå — ïðîöåññ, ïîäòâåðæäàþùèé ïðàâèëüíîñòü ïðîãðàììû è äåìîíñòðèðóþùèé, ÷òî îøèáîê â ïðîãðàììå íåò». Îñíîâíîé íåäîñòàòîê ïîäîáíîãî îïðåäåëåíèÿ çàêëþ÷àåòñÿ â òîì, ÷òî îíî ñîâåðøåííî íåïðàâèëüíî; ôàêòè÷åñêè ýòî ïî÷òè îïðåäåëåíèå àíòîíèìà ñëîâà “òåñòèðîâàíèå”. Îïðåäåëåíèå îïèñûâàåò íåâûïîëíèìóþ çàäà÷ó, à òàê êàê òåñòèðîâàíèå çà÷àñòóþ âñå æå âûïîëíÿåòñÿ ñ óñïåõîì, ïî êðàéíåé ìåðå, ñ íåêîòîðûì óñïåõîì, òî òàêîå îïðåäåëåíèå ëîãè÷åñêè íåêîððåêòíî. Ïðàâèëüíîå îïðåäåëåíèå òåñòèðîâàíèÿ òàêîâî: Òåñòèðîâàíèå — ïðîöåññ âûïîëíåíèÿ ïðîãðàììû ñ íàìåðåíèåì íàéòè îøèáêè.

Äàííàÿ òåìà äîñòàòî÷íà, àêòóàëüíà íà ñåãîäíÿøíèé äåíü, âåäü îäíèì èç íàèáîëåå óñòîÿâøèõñÿ ìåòîäîâ îöåíêè êà÷åñòâà ïðîãðàììíîãî ïðîäóêòà ÿâëÿåòñÿ åãî òåñòèðîâàíèå, êîòîðîå âõîäèò â íàáîð ýôôåêòèâíûõ ñðåäñòâ ñîâðåìåííîé ñèñòåìû îáåñïå÷åíèÿ êà÷åñòâà ïðîãðàììíîãî ïðîäóêòà. Òåñòèðîâàíèå íå ïîçèöèîíèðóåòñÿ â êà÷åñòâå åäèíñòâåííîãî ñïîñîáà îáåñïå÷åíèÿ êà÷åñòâà. Îíî ÿâëÿåòñÿ ÷àñòüþ îáùåé ñèñòåìû îáåñïå÷åíèÿ êà÷åñòâà ïðîäóêòà, ýëåìåíòû êîòîðîé âûáèðàþòñÿ ïî êðèòåðèþ íàèáîëüøåé ýôôåêòèâíîñòè ïðèìåíåíèÿ â êîíêðåòíîì ïðîåêòå.

Öåëü ðàáîòû òåñòèðîâàíèå ïðîãðàììíûõ ñðåäñòâ çàêëþ÷àåòñÿ â òîì, ÷òîáû íàéòè êàê ìîæíî áîëüøå îøèáîê. Íàèëó÷øåå ðåøåíèå ïðîáëåìû íàäåæíîñòè — ñ ñàìîãî íà÷àëà íå äîïóñêàòü îøèáîê â ïðîãðàììå. Îäíàêî âåðîÿòíîñòü òîãî, ÷òî óäàñòñÿ áåçóïðå÷íî ñïðîåêòèðîâàòü áîëüøóþ ïðîãðàììó, áåñêîíå÷íî ìàëà. Ðîëü òåñòèðîâàíèÿ ñîñòîèò êàê ðàç â òîì, ÷òîáû îïðåäåëèòü ìåñòîíàõîæäåíèå íåìíîãî÷èñëåííûõ îøèáîê, îñòàâøèõñÿ â õîðîøî ñïðîåêòèðîâàííîé ïðîãðàììå.

Ñòðóêòóðíî ðàáîòó ìîæíî ïðåäñòàâèòü â âèäå 4 ãëàâ.  ïåðâûõ â äâóõ ãëàâàõ òåîðåòè÷åñêèå àñïåêòû ôèëîñîôèè òåñòèðîâàíèå ïðîãðàììíûõ ñðåäñòâ è èíòåãðàöèè ìîäóëåé. Ðàññìàòðèâàþòñÿ òàêèå ñïîñîáû êàê âîñõîäÿùåãî è íèñõîäÿùåãî òåñòèðîâàíèÿ.

Òðåòåé è ÷åòâåðòîé ãëàâå ðàññìàòðèâàþòñÿ ðàñïðîñòðàíåííûå ìåòîäû òåñòèðîâàíèÿ. Ìåòîä áîëüøîãî ñêà÷êà è ìåòîä ñàíäâè÷à, êîòîðûå ñëóæàò äëÿ áîëåå ñåðüåçíûõ âûÿâëåíèÿ îøèáîê è áåñïåðåáîéíîé ðàáîòû ïðîãðàììû, à òàê æå îïèñàíèå ñèñòåìíîãî òåñòèðîâàíèÿ.

Ïðè íàïèñàíèå ðåôåðàòà áûëè èñïîëüçîâàíû ñëåäóþùèå èñòî÷íèêè: ó÷åáíûå ïîñîáèÿ, ó÷åáíèêè ïî äèñöèïëèíå «Èíôîðìàòèêà â ïðîãðàììèðîâàíèè », à òàêæå Èíòåðíåò.

1. Ôèëîñîôèÿ òåñòèðîâàíèå

Òåñòèðîâàíèå ïðîãðàììíîãî îáåñïå÷åíèÿ îõâàòûâàåò öåëûé ðÿä âèäîâ äåÿòåëüíîñòè, âåñüìà àíàëîãè÷íûé ïîñëåäîâàòåëüíîñòè ïðîöåññîâ ðàçðàáîòêè ïðîãðàììíîãî îáåñïå÷åíèÿ. Ñþäà âõîäÿò ïîñòàíîâêà çàäà÷è äëÿ òåñòà, ïðîåêòèðîâàíèå, íàïèñàíèå òåñòîâ, òåñòèðîâàíèå òåñòîâ è, íàêîíåö, âûïîëíåíèå òåñòîâ è èçó÷åíèå ðåçóëüòàòîâ òåñòèðîâàíèÿ. Ðåøàþùóþ ðîëü èãðàåò ïðîåêòèðîâàíèå òåñòà. Âîçìîæåí öåëûé ñïåêòð ïîäõîäîâ ê âûðàáîòêå ôèëîñîôèè, èëè ñòðàòåãèè ïðîåêòèðîâàíèÿ òåñòîâ. ×òîáû îðèåíòèðîâàòüñÿ â ñòðàòåãèÿõ ïðîåêòèðîâàíèÿ òåñòîâ, ñòîèò ðàññìîòðåòü äâà êðàéíèõ ïîäõîäà, íàõîäÿùèõñÿ íà ãðàíèöàõ ñïåêòðà. Ñëåäóåò îòìåòèòü òàêæå, ÷òî ìíîãèå èç òåõ, êòî ðàáîòàåò â ýòîé îáëàñòè, ÷àñòî áðîñàþòñÿ â îäíó èëè äðóãóþ êðàéíîñòü.

Ñòîðîííèê (èëè ñòîðîííèöà) ïîäõîäà, ñîîòâåòñòâóþùåãî ëåâîé ãðàíèöå ñïåêòðà, ïðîåêòèðóåò ñâîè òåñòû, èññëåäóÿ âíåøíèå ñïåöèôèêàöèè èëè ñïåöèôèêàöèè ñîïðÿæåíèÿ ïðîãðàììû èëè ìîäóëÿ, êîòîðûå îí òåñòèðóåò. Ïðîãðàììó îí ðàññìàòðèâàåò êàê ÷åðíûé ÿùèê. Ïîçèöèÿ åãî òàêîâà: “Ìåíÿ íå èíòåðåñóåò, êàê âûãëÿäèò ýòà ïðîãðàììà è âûïîëíèë ëè ÿ âñå êîìàíäû èëè âñå ïóòè. ß áóäó óäîâëåòâîðåí, åñëè ïðîãðàììà áóäåò âåñòè ñåáÿ òàê, êàê óêàçàíî â ñïåöèôèêàöèÿõ”. Åãî èäåàë — ïðîâåðèòü âñå âîçìîæíûå êîìáèíàöèè è çíà÷åíèÿ íà âõîäå.

Ïðèâåðæåíåö ïîäõîäà, ñîîòâåòñòâóþùåãî äðóãîìó êîíöó ñïåêòðà, ïðîåêòèðóåò ñâîè òåñòû, èçó÷àÿ ëîãèêó ïðîãðàììû. Îí íà÷èíàåò ñ òîãî, ÷òî ñòðåìèòñÿ ïîäãîòîâèòü äîñòàòî÷íîå ÷èñëî òåñòîâ äëÿ òîãî, ÷òîáû êàæäàÿ êîìàíäà áûëà âûïîëíåíà, ïî êðàéíåé ìåðå, îäèí ðàç. Åñëè îí íåìíîãî áîëåå èñêóøåí, òî ïðîåêòèðóåò òåñòû òàê, ÷òîáû êàæäàÿ êîìàíäà óñëîâíîãî ïåðåõîäà âûïîëíÿëàñü â êàæäîì íàïðàâëåíèè õîòÿ áû ðàç. Åãî èäåàë — ïðîâåðèòü êàæäûé ïóòü, êàæäóþ âåòâü àëãîðèòìà. Ïðè ýòîì åãî ñîâñåì (èëè ïî÷òè ñîâñåì) íå èíòåðåñóþò ñïåöèôèêàöèè.

Íè îäíà èç ýòèõ êðàéíîñòåé íå ÿâëÿåòñÿ õîðîøåé ñòðàòåãèåé. Îäíàêî, óæå, âåðîÿòíî, çàìåòèë, ÷òî ïåðâàÿ èç íèõ, à èìåííî òà, â ñîîòâåòñòâèè ñ êîòîðîé ïðîãðàììà ðàññìàòðèâàåòñÿ êàê ÷åðíûé ÿùèê, ïðåäïî÷òèòåëüíåé. Ê ñîæàëåíèþ, îíà ñòðàäàåò òåì íåäîñòàòêîì, ÷òî ñîâåðøåííî íåîñóùåñòâèìà. Ðàññìîòðèì ïîïûòêó òåñòèðîâàíèÿ òðèâèàëüíîé ïðîãðàììû, ïîëó÷àþùåé íà âõîäå òðè ÷èñëà è âû÷èñëÿþùåé èõ ñðåäíåå àðèôìåòè÷åñêîå. Òåñòèðîâàíèå ýòîé ïðîãðàììû äëÿ âñåõ çíà÷åíèé âõîäíûõ äàííûõ íåâîçìîæíî. Äàæå äëÿ ìàøèíû ñ îòíîñèòåëüíî íèçêîé òî÷íîñòüþ âû÷èñëåíèé êîëè÷åñòâî òåñòîâ èñ÷èñëÿëîñü áû ìèëëèàðäàìè. Äàæå èìåé ìû âû÷èñëèòåëüíóþ ìîùíîñòü, äîñòàòî÷íóþ äëÿ âûïîëíåíèÿ âñåõ òåñòîâ â ðàçóìíîå âðåìÿ, ìû ïîòðàòèëè áû íà íåñêîëüêî ïîðÿäêîâ áîëüøå âðåìåíè äëÿ òîãî, ÷òîáû ýòè òåñòû ïîäãîòîâèòü, à çàòåì ïðîâåðèòü. Òàêèå ïðîãðàììû, êàê ñèñòåìû ðåàëüíîãî âðåìåíè, îïåðàöèîííûå ñèñòåìû è ïðîãðàììû óïðàâëåíèÿ äàííûìè, êîòîðûå ñîõðàíÿþò “ïàìÿòü” î ïðåäûäóùèõ âõîäíûõ äàííûõ, åùå õóæå. Íàì ïîòðåáîâàëîñü áû òåñòèðîâàòü ïðîãðàììó íå òîëüêî äëÿ êàæäîãî âõîäíîãî çíà÷åíèÿ, íî è äëÿ êàæäîé ïîñëåäîâàòåëüíîñòè, êàæäîé êîìáèíàöèè âõîäíûõ äàííûõ. Ïîýòîìó èñ÷åðïûâàþùåå òåñòèðîâàíèå äëÿ âñåõ âõîäíûõ äàííûõ ëþáîé ðàçóìíîé ïðîãðàììû íåîñóùåñòâèìî.

Ýòè ðàññóæäåíèÿ ïðèâîäÿò êî âòîðîìó ôóíäàìåíòàëüíîìó ïðèíöèïó òåñòèðîâàíèÿ: òåñòèðîâàíèå — ïðîáëåìà â çíà÷èòåëüíîé ñòåïåíè ýêîíîìè÷åñêàÿ. Ïîñêîëüêó èñ÷åðïûâàþùåå òåñòèðîâàíèå íåâîçìîæíî, ìû äîëæíû îãðàíè÷èòüñÿ ÷åì-òî ìåíüøèì. Êàæäûé òåñò äîëæåí äàâàòü ìàêñèìàëüíóþ îòäà÷ó ïî ñðàâíåíèþ ñ íàøèìè çàòðàòàìè. Ýòà îòäà÷à èçìåðÿåòñÿ âåðîÿòíîñòüþ òîþ, ÷òî òåñò âûÿâèò íå îáíàðóæåííóþ ïðåæäå îøèáêó. Çàòðàòû èçìåðÿþòñÿ âðåìåíåì è ñòîèìîñòüþ ïîäãîòîâêè, âûïîëíåíèÿ è ïðîâåðêè ðåçóëüòàòîâ òåñòà. Ñ÷èòàÿ, ÷òî çàòðàòû îãðàíè÷åíû áþäæåòîì è ãðàôèêîì, ìîæíî óòâåðæäàòü, ÷òî èñêóññòâî òåñòèðîâàíèÿ, ïî ñóùåñòâó, ïðåäñòàâëÿåò ñîáîé èñêóññòâî îòáîðà òåñòîâ ñ ìàêñèìàëüíîé îòäà÷åé. Áîëåå òîãî, êàæäûé òåñò äîëæåí áûòü ïðåäñòàâèòåëåì íåêîòîðîãî êëàññà âõîäíûõ çíà÷åíèé, òàê ÷òîáû åãî ïðàâèëüíîå âûïîëíåíèå ñîçäàâàëî ó íàñ íåêîòîðóþ óáåæäåííîñòü â òîì, ÷òî äëÿ îïðåäåëåííîãî êëàññà âõîäíûõ äàííûõ ïðîãðàììà áóäåò âûïîëíÿòüñÿ ïðàâèëüíî. Ýòî îáû÷íî òðåáóåò íåêîòîðîãî çíàíèÿ àëãîðèòìà è ñòðóêòóðû ïðîãðàììû, è ìû, òàêèì îáðàçîì, ñìåùàåìñÿ ê ïðàâîìó êîíöó ñïåêòðà.

Âòîðûì ïî âàæíîñòè àñïåêòîì òåñòèðîâàíèÿ (ïîñëå ïðîåêòèðîâàíèÿ òåñòîâ) ÿâëÿåòñÿ ïîñëåäîâàòåëüíîñòü ñëèÿíèÿ âñåõ ìîäóëåé â ñèñòåìó èëè ïðîãðàììó. Ýòà ñòîðîíà âîïðîñà îáû÷íî íå ïîëó÷àåò äîñòàòî÷íîãî âíèìàíèÿ è ÷àñòî ðàññìàòðèâàåòñÿ ñëèøêîì ïîçäíî. Âûáîð ýòîé ïîñëåäîâàòåëüíîñòè, îäíàêî, ÿâëÿåòñÿ îäíèì èç ñàìûõ æèçíåííî âàæíûõ ðåøåíèè, ïðèíèìàåìûõ íà ýòàïå òåñòèðîâàíèÿ, ïîñêîëüêó îí îïðåäåëÿåò ôîðìó, â êîòîðîé çàïèñûâàþòñÿ òåñòû, òèïû íåîáõîäèìûõ èíñòðóìåíòîâ òåñòèðîâàíèÿ, ïîñëåäîâàòåëüíîñòü ïðîãðàììèðîâàíèÿ ìîäóëåé, à òàêæå òùàòåëüíîñòü è ýêîíîìè÷íîñòü âñåãî ýòàïà òåñòèðîâàíèÿ. Ïî ýòîé ïðè÷èíå òàêîå ðåøåíèå äîëæíî ïðèíèìàòüñÿ íà óðîâíå ïðîåêòà â öåëîì è íà äîñòàòî÷íî ðàííåé åãî ñòàäèè.

Èìååòñÿ áîëüøîé âûáîð âîçìîæíûõ ïîäõîäîâ, êîòîðûå ìîãóò áûòü èñïîëüçîâàíû äëÿ ñëèÿíèÿ ìîäóëåé â áîëåå êðóïíûå åäèíèöû.  áîëüøèíñòâå ñâîåì îíè ìîãóò ðàññìàòðèâàòüñÿ êàê âàðèàíòû øåñòè îñíîâíûõ ïîäõîäîâ, îïèñàííûõ â ñëåäóþùèõ øåñòè ðàçäåëàõ. Ñðàçó æå çà íèìè èäåò ðàçäåë, ãäå ïðåäëîæåííûå ïîäõîäû ñðàâíèâàþòñÿ ïî èõ âëèÿíèþ íà íàäåæíîñòü ïðîãðàììíîãî îáåñïå÷åíèÿ.

2. Èíòåãðàöèÿ ìîäóëåé

2.1. Âîñõîäÿùåå òåñòèðîâàíèå

Ïðè âîñõîäÿùåì ïîäõîäå ïðîãðàììà ñîáèðàåòñÿ è òåñòèðóåòñÿ ñíèçó ââåðõ. Òîëüêî ìîäóëè ñàìîãî íèæíåãî óðîâíÿ (“òåðìèíàëüíûå” ìîäóëè; ìîäóëè, íå âûçûâàþùèå äðóãèõ ìîäóëåé) òåñòèðóþòñÿ èçîëèðîâàííî, àâòîíîìíî. Ïîñëå òîãî êàê òåñòèðîâàíèå ýòèõ ìîäóëåé çàâåðøåíî, âûçîâ èõ äîëæåí áûòü òàê æå íàäåæåí, êàê âûçîâ âñòðîåííîé ôóíêöèè ÿçûêà èëè îïåðàòîð ïðèñâàèâàíèÿ. Çàòåì òåñòèðóþòñÿ ìîäóëè, íåïîñðåäñòâåííî âûçûâàþùèå óæå ïðîâåðåííûå. Ýòè ìîäóëè áîëåå âûñîêîãî óðîâíÿ òåñòèðóþòñÿ íå àâòîíîìíî, à âìåñòå ñ óæå ïðîâåðåííûìè ìîäóëÿìè áîëåå íèçêîãî óðîâíÿ. Ïðîöåññ ïîâòîðÿåòñÿ äî òåõ ïîð, ïîêà íå áóäåò äîñòèãíóòà âåðøèíà. Çäåñü çàâåðøàþòñÿ è òåñòèðîâàíèå ìîäóëåé, è òåñòèðîâàíèå ñîïðÿæåíèè ïðîãðàììû.

Ïðè âîñõîäÿùåì òåñòèðîâàíèè äëÿ êàæäîãî ìîäóëÿ íåîáõîäèì äðàéâåð: íóæíî ïîäàâàòü òåñòû â ñîîòâåòñòâèè ñ ñîïðÿæåíèåì òåñòèðóåìîãî ìîäóëÿ. Îäíî èç âîçìîæíûõ ðåøåíèè — íàïèñàòü äëÿ êàæäîãî ìîäóëÿ íåáîëüøóþ âåäóùóþ ïðîãðàììó. Òåñòîâûå äàííûå ïðåäñòàâëÿþòñÿ êàê “âñòðîåííûå” íåïîñðåäñòâåííî â ýòó ïðîãðàììó ïåðåìåííûå è ñòðóêòóðû äàííûõ, è îíà ìíîãîêðàòíî âûçûâàåò òåñòèðóåìûé ìîäóëü, ñ êàæäûì âûçîâîì ïåðåäàâàÿ åìó íîâûå òåñòîâûå äàííûå. Èìååòñÿ è ëó÷øåå ðåøåíèå: âîñïîëüçîâàòüñÿ ïðîãðàììîé òåñòèðîâàíèÿ ìîäóëåé — ýòî èíñòðóìåíò òåñòèðîâàíèÿ, ïîçâîëÿþùèé îïèñûâàòü òåñòû íà ñïåöèàëüíîì ÿçûêå è èçáàâëÿþùèé îò íåîáõîäèìîñòè ïèñàòü äðàéâåðû.

2.2 Íèñõîäÿùåå òåñòèðîâàíèå

Íèñõîäÿùåå òåñòèðîâàíèå (íàçûâàåìîå òàêæå íèñõîäÿùåé ðàçðàáîòêîé íå ÿâëÿåòñÿ ïîëíîé ïðîòèâîïîëîæíîñòüþ âîñõîäÿùåìó, íî â ïåðâîì ïðèáëèæåíèè ìîæåò ðàññìàòðèâàòüñÿ êàê òàêîâîå, Ïðè íèñõîäÿùåì ïîäõîäå ïðîãðàììà ñîáèðàåòñÿ è òåñòèðóåòñÿ ñâåðõó âíèç. Èçîëèðîâàíî òåñòèðóåòñÿ òîëüêî ãîëîâíîé ìîäóëü. Ïîñëå òîãî êàê òåñòèðîâàíèå ýòîãî ìîäóëÿ çàâåðøåíî, ñ íèì ñîåäèíÿþòñÿ (íàïðèìåð, ðåäàêòîðîì ñâÿçåé) îäèí çà äðóãèì ìîäóëè, íåïîñðåäñòâåííî âûçûâàåìûå èì, è òåñòèðóåòñÿ ïîëó÷åííàÿ êîìáèíàöèÿ. Ïðîöåññ ïîâòîðÿåòñÿ äî òåõ ïîð, ïîêà íå áóäóò ñîáðàíû è ïðîâåðåíû âñå ìîäóëè.

Ïðè ýòîì ïîäõîäå íåìåäëåííî âîçíèêàåò äâà âîïðîñà: ÷òî äåëàòü, êîãäà òåñòèðóåìûé ìîäóëü âûçûâàåò ìîäóëü áîëåå íèçêîãî óðîâíÿ (êîòîðîãî â äàííûé ìîìåíò åùå íå ñóùåñòâóåò), è êàê ïîäàþòñÿ òåñòîâûå äàííûå. Îòâåò íà ïåðâûé âîïðîñ ñîñòîèò â òîì, ÷òî äëÿ èìèòàöèè ôóíêöèé íåäîñòàþùèõ ìîäóëåé ïðîãðàììèðóþòñÿ ìîäóëè-çàãëóøêè”, êîòîðûå ìîäåëèðóþò ôóíêöèè îòñóòñòâóþùèõ ìîäóëåé. Ôðàçà “ïðîñòî íàïèøèòå çàãëóøêó” ÷àñòî âñòðå÷àåòñÿ â îïèñàíèè ýòîãî ïîäõîäà, íî îíà ñïîñîáíà ââåñòè â çàáëóæäåíèå, ïîñêîëüêó çàäà÷à íàïèñàíèÿ çàãëóøêè” ìîæåò îêàçàòüñÿ òðóäíîé. Âåäü çàãëóøêà ðåäêî ñâîäèòñÿ ïðîñòî ê îïåðàòîðó RETURN, ïîñêîëüêó âûçûâàþùèé ìîäóëü îáû÷íî îæèäàåò îò íåå âûõîäíûõ ïàðàìåòðîâ.  òàêèõ ñëó÷àÿõ â çàãëóøêó âñòðàèâàþò ôèêñèðîâàííûå âûõîäíûå äàííûå, êîòîðûå îíà âñåãäà è âîçâðàùàåò. Ýòî èíîãäà îêàçûâàåòñÿ íåïðèåìëåìûì, òàê êàê âûçûâàþùèé ìîäóëü ìîæåò ðàññ÷èòûâàòü, ÷òî ðåçóëüòàò âûçîâà çàâèñèò îò âõîäíûõ äàííûõ. Ïîýòîìó â íåêîòîðûõ ñëó÷àÿõ çàãëóøêà äîëæíà áûòü äîâîëüíî èçîùðåííîé, ïðèáëèæàÿñü ïî ñëîæíîñòè ê ìîäóëþ, êîòîðûé îíà ïûòàåòñÿ ìîäåëèðîâàòü.

Èíòåðåñåí è âòîðîé âîïðîñ: â êàêîé ôîðìå ãîòîâÿòñÿ òåñòîâûå äàííûå è êàê îíè ïåðåäàþòñÿ ïðîãðàììå? Åñëè áû ãîëîâíîé ìîäóëü ñîäåðæàë âñå íóæíûå îïåðàöèè ââîäà è âûâîäà, îòâåò áûë áû ïðîñò:

Òåñòû ïèøóòñÿ â âèäå îáû÷íûõ äëÿ ïîëüçîâàòåëåé âíåøíèõ äàííûõ è ïåðåäàþòñÿ ïðîãðàììå ÷åðåç âûäåëåííûå åé óñòðîéñòâà ââîäà. Òàê, îäíàêî, ñëó÷àåòñÿ ðåäêî.  õîðîøî ñïðîåêòèðîâàííîé ïðîãðàììå ôèçè÷åñêèå îïåðàöèè ââîäà-âûâîäà âûïîëíÿþòñÿ íà íèæíèõ óðîâíÿõ ñòðóêòóðû, ïîñêîëüêó ôèçè÷åñêèé ââîä-âûâîä — àáñòðàêöèÿ äîâîëüíî íèçêîãî óðîâíÿ. Ïîýòîìó äëÿ òîãî, ÷òîáû ðåøèòü ïðîáëåìó ýêîíîìè÷åñêè ýôôåêòèâíî, ìîäóëè äîáàâëÿþòñÿ íå â ñòðîãî íèñõîäÿùåé ïîñëåäîâàòåëüíîñòè (âñå ìîäóëè îäíîãî ãîðèçîíòàëüíîãî óðîâíÿ, çàòåì ìîäóëè ñëåäóþùåãî óðîâíÿ), à òàêèì îáðàçîì, ÷òîáû îáåñïå÷èòü ôóíêöèîíèðîâàíèå îïåðàöèé ôèçè÷åñêîãî ââîäà-âûâîäà êàê ìîæíî áûñòðåå. Êîãäà ýòà öåëü äîñòèãíóòà, íèñõîäÿùåå òåñòèðîâàíèå ïîëó÷àåò çíà÷èòåëüíîå ïðåèìóùåñòâî: âñå äàëüíåéøèå òåñòû ãîòîâÿòñÿ â òîé æå ôîðìå, êîòîðàÿ ðàññ÷èòàíà íà ïîëüçîâàòåëÿ.

Îñòàåòñÿ åùå îäèí âîïðîñ: â êàêîé ôîðìå ïèøóòñÿ òåñòû äî òåõ ïîð, ïîêà íå áóäåò äîñòèãíóòà ýòà öåëü? Îòâåò: îíè âêëþ÷àþòñÿ â íåêîòîðûå èç çàãëóøåê.

Íèñõîäÿùèé ìåòîä èìååò êàê äîñòîèíñòâà, òàê è íåäîñòàòêè ïî ñðàâíåíèþ ñ âîñõîäÿùèì. Ñàìîå çíà÷èòåëüíîå äîñòîèíñòâî — â òîì, ÷òî ýòîò ìåòîä ñîâìåùàåò òåñòèðîâàíèå ìîäóëÿ, òåñòèðîâàíèå ñîïðÿæåíèè è ÷àñòè÷íî òåñòèðîâàíèå âíåøíèõ ôóíêöèé. Ñ ýòèì æå ñâÿçàíî äðóãîå åãî äîñòîèíñòâî — êîãäà ìîäóëè ââîäà-âûâîäà óæå ïîäêëþ÷åíû, òåñòû ìîæíî ãîòîâèòü â óäîáíîì âèäå. Íèñõîäÿùèé ïîäõîä âûãîäåí òàêæå â òîì ñëó÷àå, êîãäà åñòü ñîìíåíèÿ îòíîñèòåëüíî îñóùåñòâèìîñòè ïðîãðàììû â öåëîì èëè åñëè â ïðîåêòå ïðîãðàììû ìîãóò îêàçàòüñÿ ñåðüåçíûå äåôåêòû.

Ïðåèìóùåñòâîì íèñõîäÿùåãî ïîäõîäà î÷åíü ÷àñòî ñ÷èòàþò îòñóòñòâèå íåîáõîäèìîñòè â äðàéâåðàõ; âìåñòî äðàéâåðîâ âàì ïðîñòî ñëåäóåò íàïèñàòü “çàãëóøêè”. Êàê ÷èòàòåëü ñåé÷àñ óæå, âåðîÿòíî, ïîíèìàåò, ýòî ïðåèìóùåñòâî ñïîðíî.

Íèñõîäÿùèé ìåòîä òåñòèðîâàíèÿ èìååò, ê ñîæàëåíèþ, íåêîòîðûå íåäîñòàòêè. Îñíîâíûì èç íèõ ÿâëÿåòñÿ òîò, ÷òî ìîäóëü ðåäêî òåñòèðóåòñÿ äîñêîíàëüíî ñðàçó ïîñëå åãî ïîäêëþ÷åíèÿ. Äåëî â òîì, ÷òî îñíîâàòåëüíîå òåñòèðîâàíèå íåêîòîðûõ ìîäóëåé ìîæåò ïîòðåáîâàòü êðàéíå èçîùðåííûõ çàãëóøåê. Ïðîãðàììèñò ÷àñòî ðåøàåò íå òðàòèòü ìàññó âðåìåíè íà èõ ïðîãðàììèðîâàíèå, à âìåñòî ýòîãî ïèøåò ïðîñòûå çàãëóøêè è ïðîâåðÿåò ëèøü ÷àñòü óñëîâèé â ìîäóëå. Îí, êîíå÷íî, ñîáèðàåòñÿ âåðíóòüñÿ è çàêîí÷èòü òåñòèðîâàíèå ðàññìàòðèâàåìîãî ìîäóëÿ ïîçæå, êîãäà óáåðåò çàãëóøêè. Òàêîé ïëàí òåñòèðîâàíèÿ îïðåäåëåííî íå ëó÷øåå ðåøåíèå, ïîñêîëüêó îá îòëîæåííûõ óñëîâèÿõ ÷àñòî çàáûâàþò.

Âòîðîé òîíêèé íåäîñòàòîê íèñõîäÿùåãî ïîäõîäà ñîñòîèò â òîì, ÷òî îí ìîæåò ïîðîäèòü âåðó â âîçìîæíîñòü íà÷àòü ïðîãðàììèðîâàíèå è òåñòèðîâàíèå âåðõíåãî óðîâíÿ ïðîãðàììû äî òîãî, êàê âñÿ ïðîãðàììà áóäåò ïîëíîñòüþ ñïðîåêòèðîâàíà. Ýòà èäåÿ íà ïåðâûé âçãëÿä êàæåòñÿ ýêîíîìè÷íîé, íî îáû÷íî äåëî îáñòîèò ñîâñåì íàîáîðîò. Áîëüøèíñòâî îïûòíûõ ïðîåêòèðîâùèêîâ ïðèçíàåò, ÷òî ïðîåêòèðîâàíèå ïðîãðàììû — ïðîöåññ èòåðàòèâíûé. Ðåäêî ïåðâûé ïðîåêò îêàçûâàåòñÿ ñîâåðøåííûì. Íîðìàëüíûé ñòèëü ïðîåêòèðîâàíèÿ ñòðóêòóðû ïðîãðàììû ïðåäïîëàãàåò ïî îêîí÷àíèè ïðîåêòèðîâàíèÿ íèæíèõ óðîâíåé âåðíóòüñÿ íàçàä è ïîäïðàâèòü âåðõíèé óðîâåíü, âíåñÿ â íåãî íåêîòîðûå óñîâåðøåíñòâîâàíèÿ èëè èñïðàâëÿÿ îøèáêè, ëèáî èíîãäà äàæå âûáðîñèòü ïðîåêò è íà÷àòü âñå ñíà÷àëà, ïîòîìó ÷òî ðàçðàáîò÷èê âíåçàïíî óâèäåë ëó÷øèé ïîäõîä. Åñëè æå ãîëîâíàÿ ÷àñòü ïðîãðàììû óæå çàïðîãðàììèðîâàíà è îòòåñòèðîâàíà, òî âîçíèêàåò ñåðüåçíîå ñîïðîòèâëåíèå ëþáûì óëó÷øåíèÿì åå ñòðóêòóðû.  êîíå÷íîì èòîãå çà ñ÷åò òàêèõ óëó÷øåíèé îáû÷íî ìîæíî ñýêîíîìèòü áîëüøå, ÷åì òå íåñêîëüêî äíåé èëè íåäåëü, êîòîðûå ðàññ÷èòûâàåò âûèãðàòü ïðîåêòèðîâùèê, ïðèñòóïàÿ ê ïðîãðàììèðîâàíèþ ñëèøêîì ðàíî.

3. Ðàñïðîñòðàíåííûå ìåòîäû òåñòèðîâàíèå

Ïðè ïðîåêòèðîâàíèè è ïðîãðàììèðîâàíèè ìîäóëÿ ñ òàêîé ôóíêöèåé âñåãäà ñëåäóåò ïîíèìàòü, ÷òî êâàäðàòíîå óðàâíåíèå ìîæåò èìåòü êàê äåéñòâèòåëüíûå, òàê è êîìïëåêñíûå êîðíè. Äëÿ ïîëíîé ðåàëèçàöèè ýòîé ôóíêöèè íåîáõîäèìî, ÷òîáû ðåçóëüòàòû ìîãëè áûòü äåéñòâèòåëüíûìè èëè êîìïëåêñíûìè ÷èñëàìè (èëè, åñëè äîïîëíèòåëüíûå çàòðàòû íà íàõîæäåíèå êîìïëåêñíûõ êîðíåé íå îïðàâäàíû, ìîäóëü äîëæåí ïî êðàéíåé ìåðå âîçâðàùàòü êîä îøèáêè â ñëó÷àå, êîãäà âõîäíûå êîýôôèöèåíòû çàäàþò óðàâíåíèå ñ êîìïëåêñíûìè êîðíÿìè). Ïðåäïîëîæèì, ÷òî êîíêðåòíûé êîíòåêñò, â êîòîðîì èñïîëüçóåòñÿ ìîäóëü, èñêëþ÷àåò êîìïëåêñíûå êîðíè (ò. å. âûçûâàþùèå ìîäóëè íèêîãäà íå çàäàþò âõîäíûõ ïàðàìåòðîâ, êîòîðûå ïðèâåëè áû ê êîìïëåêñíûì êîðíÿì). Ïðè ñòðîãî íèñõîäÿùåì ìåòîäå èíîãäà áûâàåò íåâîçìîæíî òåñòèðîâàòü ìîäóëü äëÿ ñëó÷àÿ êîìïëåêñíûõ êîðíåé (èëè òåñòèðîâàòü îøèáî÷íûå óñëîâèÿ). Ìîæíî ïîïûòàòüñÿ îïðàâäûâàòü ýòî òåì, ÷òî, ïîñêîëüêó òàêîå óðàâíåíèå íèêîãäà íå áóäåò äàíî ìîäóëþ, íèêîãî íå äîëæíî çàáîòèòü, ðàáîòàåò ëè îí è â ýòèõ ñëó÷àÿõ. Äà, ýòî áåçðàçëè÷íî ñåé÷àñ, íî îêàæåòñÿ âàæíûì â áóäóùåì, êîãäà êòî-òî ïîïûòàåòñÿ èñïîëüçîâàòü ìîäóëü â íîâîé ïðîãðàììå èëè ìîäèôèöèðîâàòü ñòàðóþ ïðîãðàììó òàê, ÷òî ñòàíóò âîçìîæíûìè è êîìïëåêñíûå êîðíè.

Ýòà ïðîáëåìà ïðîÿâëÿåòñÿ â ðàçíîîáðàçíûõ ôîðìàõ. Ïðèìåíÿÿ íèñõîäÿùåå òåñòèðîâàíèå â òî÷íîì ñîîòâåòñòâèè ñ ïðåäûäóùèì ðàçäåëîì, ÷àñòî íåâîçìîæíî òåñòèðîâàòü îïðåäåëåííûå ëîãè÷åñêèå óñëîâèÿ, íàïðèìåð îøèáî÷íûå ñèòóàöèè èëè çàùèòíûå ïðîâåðêè. Íèñõîäÿùèé ìåòîä, êðîìå òîãî, äåëàåò ñëîæíîé èëè âîîáùå íåâîçìîæíîé ïðîâåðêó èñêëþ÷èòåëüíûõ ñèòóàöèé â íåêîòîðîì ìîäóëå, åñëè ïðîãðàììà ðàáîòàåò ñ íèì ëèøü â îãðàíè÷åííîì êîíòåêñòå (ýòî îçíà÷àåò, ÷òî ìîäóëü íèêîãäà íå ïîëó÷èò äîñòàòî÷íî ïîëíûé íàáîð âõîäíûõ çíà÷åíèé). Äàæå åñëè òåñòèðîâàíèå òàêîé ñèòóàöèè â ïðèíöèïå îñóùåñòâèìî, ÷àñòî áûâàåò òðóäíî îïðåäåëèòü, êàêèå èìåííî íóæíû òåñòû, åñëè îíè ââîäÿòñÿ â òî÷êå ïðîãðàììû, óäàëåííîé îò ìåñòà ïðîâåðêè ñîîòâåòñòâóþùåãî óñëîâèÿ.

Ìåòîä, íàçûâàåìûé ìîäèôèöèðîâàííûì íèñõîäÿùèì ïîäõîäîì, ðåøàåò ýòè ïðîáëåìû: òðåáóåòñÿ, ÷òîáû êàæäûé ìîäóëü ïðîøåë àâòîíîìíîå òåñòèðîâàíèå ïåðåä ïîäêëþ÷åíèåì ê ïðîãðàììå. Õîòÿ ýòî äåéñòâèòåëüíî ðåøàåò âñå ïåðå÷èñëåííûå ïðîáëåìû, çäåñü òðåáóþòñÿ è äðàéâåðû, è çàãëóøêè äëÿ êàæäîãî ìîäóëÿ.

3.1 Ìåòîä áîëüøîãî ñêà÷êà

Âåðîÿòíî, ñàìûé ðàñïðîñòðàíåííûé ïîäõîä ê èíòåãðàöèè ìîäóëåé — ìåòîä “áîëüøîãî ñêà÷êà”.  ñîîòâåòñòâèè ñ ýòèì ìåòîäîì êàæäûé ìîäóëü òåñòèðóåòñÿ àâòîíîìíî. Ïî îêîí÷àíèè òåñòèðîâàíèÿ ìîäóëåé îíè èíòåãðèðóþòñÿ â ñèñòåìó âñå ñðàçó.

Ìåòîä áîëüøîãî ñêà÷êà ïî ñðàâíåíèþ ñ äðóãèìè ïîäõîäàìè èìååò ìíîãî íåäîñòàòêîâ è ìàëî äîñòîèíñòâ. Çàãëóøêè è äðàéâåðû íåîáõîäèìû äëÿ êàæäîãî ìîäóëÿ. Ìîäóëè íå èíòåãðèðóþòñÿ äî ñàìîãî ïîñëåäíåãî ìîìåíòà, à ýòî îçíà÷àåò, ÷òî â òå÷åíèå äîëãîãî âðåìåíè ñåðüåçíûå îøèáêè â ñîïðÿæåíèÿõ ìîãóò îñòàòüñÿ íåîáíàðóæåííûìè. Ìåòîä áîëüøîãî ñêà÷êà çíà÷èòåëüíî óñëîæíÿåò îòëàäêó.

È âñå æå áîëüøîé ñêà÷îê íå âñåãäà íåæåëàòåëåí. Åñëè ïðîãðàììà ìàëà è õîðîøî ñïðîåêòèðîâàíà, îí ìîæåò îêàçàòüñÿ ïðèåìëåìûì. Îäíàêî äëÿ êðóïíûõ ïðîãðàìì ìåòîä áîëüøîãî ñêà÷êà îáû÷íî ãóáèòåëåí.

3.2 Ìåòîä ñàíäâè÷à

Òåñòèðîâàíèå ìåòîäîì ñàíäâè÷à ïðåäñòàâëÿåò ñîáîé êîìïðîìèññ ìåæäó âîñõîäÿùèì è íèñõîäÿùèì ïîäõîäàìè. Çäåñü äåëàåòñÿ ïîïûòêà âîñïîëüçîâàòüñÿ äîñòîèíñòâàìè îáîèõ ìåòîäîâ, èçáåæàâ èõ íåäîñòàòêîâ.

Ïðè èñïîëüçîâàíèè ýòîãî ìåòîäà îäíîâðåìåííî íà÷èíàþò âîñõîäÿùåå è íèñõîäÿùåå òåñòèðîâàíèå, ñîáèðàÿ ïðîãðàììó êàê ñíèçó, òàê è ñâåðõó è âñòðå÷àÿñü â êîíöå êîíöîâ ãäå-òî â ñåðåäèíå. Òî÷êà âñòðå÷è çàâèñèò îò êîíêðåòíîé òåñòèðóåìîé ïðîãðàììû è äîëæíà áûòü çàðàíåå îïðåäåëåíà ïðè èçó÷åíèè åå ñòðóêòóðû. Íàïðèìåð, åñëè ðàçðàáîò÷èê ìîæåò ïðåäñòàâèòü ñâîþ ñèñòåìó â âèäå óðîâíÿ ïðèêëàäíûõ ìîäóëåé, çàòåì óðîâíÿ ìîäóëåé îáðàáîòêè çàïðîñîâ, çàòåì óðîâíÿ ïðèìèòèâíûõ ôóíêöèé, òî îí ìîæåò ðåøèòü ïðèìåíÿòü íèñõîäÿùèé ìåòîä íà óðîâíå ïðèêëàäíûõ ìîäóëåé (ïðîãðàììèðóÿ çàãëóøêè âìåñòî ìîäóëåé îáðàáîòêè çàïðîñîâ), à íà îñòàëüíûõ óðîâíÿõ ïðèìåíèòü âîñõîäÿùèé ìåòîä.

Ïðèìåíåíèå ìåòîäà ñàíäâè÷à — ýòî ðàçóìíûé ïîäõîä ê èíòåãðàöèè áîëüøèõ ïðîãðàìì, òàêèõ, êàê îïåðàöèîííàÿ ñèñòåìà èëè ïàêåò ïðèêëàäíûõ ïðîãðàìì.

Ìåòîä ñàíäâè÷à ñîõðàíÿåò òàêîå äîñòîèíñòâî íèñõîäÿùåãî è âîñõîäÿùåãî ïîäõîäîâ, êàê íà÷àëî èíòåãðàöèè ñèñòåìû íà ñàìîì ðàííåì ýòàïå. Ïîñêîëüêó âåðøèíà ïðîãðàììû âñòóïàåò â ñòðîé ðàíî, ìû, êàê â íèñõîäÿùåì ìåòîäå, óæå íà ðàííåì ýòàïå ïîëó÷àåì ðàáîòàþùèé êàðêàñ ïðîãðàììû. Ïîñêîëüêó íèæíèå óðîâíè ïðîãðàììû ñîçäàþòñÿ âîñõîäÿùèì ìåòîäîì, ñíèìàþòñÿ òå ïðîáëåìû íèñõîäÿùåãî ìåòîäà, êîòîðûå áûëè ñâÿçàíû ñ íåâîçìîæíîñòüþ òåñòèðîâàòü íåêîòîðûå óñëîâèÿ â ãëóáèíå ïðîãðàììû.

Ïðè òåñòèðîâàíèè ìåòîäîì ñàíäâè÷à âîçíèêàåò òà æå ïðîáëåìà, ÷òî è ïðè íèñõîäÿùåì ïîäõîäå, õîòÿ çäåñü îíà ñòîèò íå òàê îñòðî. Ïðîáëåìà ýòà â òîì, ÷òî íåâîçìîæíî äîñêîíàëüíî òåñòèðîâàòü îòäåëüíûå ìîäóëè. Âîñõîäÿùèé ýòàï òåñòèðîâàíèÿ ïî ìåòîäó ñàíäâè÷à ðåøàåò ýòó ïðîáëåìó äëÿ ìîäóëåé íèæíèõ óðîâíåé, íî îíà ìîæåò ïî-ïðåæíåìó îñòàâàòüñÿ îòêðûòîé äëÿ íèæíåé ïîëîâèíû âåðõíåé ÷àñòè ïðîãðàììû.  ìîäèôèöèðîâàííîì ìåòîäå ñàíäâè÷à íèæíèå óðîâíè òàêæå òåñòèðóþòñÿ ñòðîãî ñíèçó ââåðõ. À ìîäóëè âåðõíèõ óðîâíåé ñíà÷àëà òåñòèðóþòñÿ èçîëèðîâàííî, à çàòåì ñîáèðàþòñÿ íèñõîäÿùèì ìåòîäîì. Òàêèì îáðàçîì, ìîäèôèöèðîâàííûé ìåòîä ñàíäâè÷à òàêæå ïðåäñòàâëÿåò ñîáîé êîìïðîìèññ ìåæäó âîñõîäÿùèì è íèñõîäÿùèì ïîäõîäàìè.

4. Ñèñòåìíîå òåñòèðîâàíèå

Ñèñòåìíîå òåñòèðîâàíèå ðàññìàòðèâàåò òåñòèðóåìóþ ñèñòåìó â öåëîì è îïåðèðóåò íà óðîâíå ïîëüçîâàòåëüñêèõ èíòåðôåéñîâ.

Íà óðîâíå ñèñòåìû ÷àñòî ñëîæíî è ìàëîýôôåêòèâíî àíàëèçèðîâàòü ïðîõîæäåíèå òåñòîâûõ òðàåêòîðèé âíóòðè ïðîãðàììû èëè îòñëåæèâàòü ïðàâèëüíîñòü ðàáîòû êîíêðåòíûõ ôóíêöèé. Îñíîâíàÿ çàäà÷à ñèñòåìíîãî òåñòèðîâàíèÿ — â âûÿâëåíèè äåôåêòîâ, ñâÿçàííûõ ñ ðàáîòîé ñèñòåìû â öåëîì, òàêèõ êàê íåâåðíîå èñïîëüçîâàíèå ðåñóðñîâ ñèñòåìû, íåïðåäóñìîòðåííûå êîìáèíàöèè äàííûõ ïîëüçîâàòåëüñêîãî óðîâíÿ, íåñîâìåñòèìîñòü ñ îêðóæåíèåì, íåïðåäóñìîòðåííûå ñöåíàðèè èñïîëüçîâàíèÿ, îòñóòñòâóþùàÿ èëè íåâåðíàÿ ôóíêöèîíàëüíîñòü, íåóäîáñòâî â ïðèìåíåíèè è òîìó ïîäîáíîå.

Ñèñòåìíîå òåñòèðîâàíèå ïðîèçâîäèòñÿ íàä ïðîåêòîì â öåëîì ñ ïîìîùüþ ìåòîäà «÷åðíîãî ÿùèêà». Ñòðóêòóðà ïðîãðàììû íå èìååò íèêàêîãî çíà÷åíèÿ, äëÿ ïðîâåðêè äîñòóïíû òîëüêî âõîäû è âûõîäû, âèäèìûå ïîëüçîâàòåëþ. Òåñòèðîâàíèþ ïîäëåæàò êîäû è ïîëüçîâàòåëüñêàÿ äîêóìåíòàöèÿ.

Êàòåãîðèè òåñòîâ ñèñòåìíîãî òåñòèðîâàíèÿ;

1. Ïîëíîòà ðåøåíèÿ ôóíêöèîíàëüíûõ çàäà÷.

2. Ñòðåññîâîå òåñòèðîâàíèå — íà ïðåäåëüíûõ îáúåìàõ íàãðóçêè âõîäíîãî ïîòîêà.

3. Êîððåêòíîñòü èñïîëüçîâàíèÿ ðåñóðñîâ (óòå÷êà ïàìÿòè, âîçâðàò ðåñóðñîâ).

4. Îöåíêà ïðîèçâîäèòåëüíîñòè.

5. Ýôôåêòèâíîñòü çàùèòû îò èñêàæåíèÿ äàííûõ è íåêîððåêòíûõ äåéñòâèé.

6. Ïðîâåðêà èíñòàëëÿöèè è êîíôèãóðàöèè íà ðàçíûõ ïëàòôîðìàõ.

7. Êîððåêòíîñòü äîêóìåíòàöèè

Ïîñêîëüêó ñèñòåìíîå òåñòèðîâàíèå ïðîâîäèòñÿ íà ïîëüçîâàòåëüñêèõ èíòåðôåéñàõ, ñîçäàåòñÿ èëëþçèÿ òîãî, ÷òî ïîñòðîåíèå ñïåöèàëüíîé ñèñòåìû àâòîìàòèçàöèè òåñòèðîâàíèÿ íå âñåãäà íåîáõîäèìî. Îäíàêî îáúåìû äàííûõ íà ýòîì óðîâíå òàêîâû, ÷òî îáû÷íî áîëåå ýôôåêòèâíûì ïîäõîäîì ÿâëÿåòñÿ ïîëíàÿ èëè ÷àñòè÷íàÿ àâòîìàòèçàöèÿ òåñòèðîâàíèÿ, ÷òî ïðèâîäèò ê ñîçäàíèþ òåñòîâîé ñèñòåìû ãîðàçäî áîëåå ñëîæíîé, ÷åì ñèñòåìà òåñòèðîâàíèÿ, ïðèìåíÿåìàÿ íà óðîâíå òåñòèðîâàíèÿ ìîäóëåé èëè èõ êîìáèíàöèé.

4.1 Àâòîìàòèçàöèÿ òåñòèðîâàíèÿ

Èñïîëüçîâàíèå ðàçëè÷íûõ ïîäõîäîâ ê òåñòèðîâàíèþ îïðåäåëÿåòñÿ èõ ýôôåêòèâíîñòüþ ïðèìåíèòåëüíî ê óñëîâèÿì, îïðåäåëÿåìûì ïðîìûøëåííûì ïðîåêòîì.  ðåàëüíûõ ñëó÷àÿõ ðàáîòà ãðóïïû òåñòèðîâàíèÿ ïëàíèðóåòñÿ òàê, ÷òîáû ðàçðàáîòêà òåñòîâ íà÷èíàëàñü ñ ìîìåíòà ñîãëàñîâàíèÿ òðåáîâàíèé ê ïðîãðàììíîìó ïðîäóêòó (âûïóñê Requirement Book, ñîäåðæàùåé âûñîêîóðîâíåâûå òðåáîâàíèÿ ê ïðîäóêòó) è ïðîäîëæàëàñü ïàðàëëåëüíî ñ ðàçðàáîòêîé äèçàéíà è êîäà ïðîäóêòà.  ðåçóëüòàòå, ê íà÷àëó ñèñòåìíîãî òåñòèðîâàíèÿ ñîçäàþòñÿ òåñòîâûå íàáîðû, ñîäåðæàùèå òûñÿ÷è òåñòîâ. Áîëüøîé íàáîð òåñòîâ îáåñïå÷èâàåò âñåñòîðîííþþ ïðîâåðêó ôóíêöèîíàëüíîñòè ïðîäóêòà è ãàðàíòèðóåò êà÷åñòâî ïðîäóêòà, íî ïðîïóñê òàêîãî êîëè÷åñòâà òåñòîâ íà ýòàïå ñèñòåìíîãî òåñòèðîâàíèÿ ïðåäñòàâëÿåò ïðîáëåìó. Åå ðåøåíèå ëåæèò â îáëàñòè àâòîìàòèçàöèè òåñòèðîâàíèÿ, ò.å. â àâòîìàòèçàöèè ðàçðàáîòêè.

Ñîáñòâåííî èñïîëüçîâàíèå ýôôåêòèâíîé ñèñòåìû àâòîìàòèçàöèè òåñòèðîâàíèÿ ñîêðàùàåò äî ìèíèìóìà âðåìÿ ïðîïóñêà òåñòîâ, áåç êîòîðîãî íåâîçìîæíî ïîäòâåðäèòü ôàêò ðîñòà êà÷åñòâà (óìåíüøåíèÿ ÷èñëà îñòàâøèõñÿ îøèáîê) ïðîäóêòà. Ñèñòåìíîå òåñòèðîâàíèå îñóùåñòâëÿåòñÿ â ðàìêàõ öèêëîâ òåñòèðîâàíèÿ (ïåðèîäîâ ïðîïóñêà ðàçðàáîòàííîãî òåñòîâîãî íàáîðà íàä ñîçäàíèåì ðàçðàáàòûâàåìîãî ïðèëîæåíèÿ). Ïåðåä êàæäûì öèêëîì ôèêñèðóåòñÿ ðàçðàáîòàííûé èëè èñïðàâëåííûé build, íà êîòîðûé çàíîñÿòñÿ îáíàðóæåííûå â ðåçóëüòàòå òåñòîâîãî ïðîãîíà îøèáêè. Çàòåì îøèáêè èñïðàâëÿþòñÿ, è íà î÷åðåäíîé öèêë òåñòèðîâàíèÿ ïðåäúÿâëÿåòñÿ íîâûé build. Îêîí÷àíèå òåñòèðîâàíèÿ ñîâïàäàåò ñ ýêñïåðèìåíòàëüíî ïîäòâåðæäåííûì çàêëþ÷åíèåì î äîñòèãíóòîì óðîâíå êà÷åñòâà îòíîñèòåëüíî âûáðàííîãî êðèòåðèÿ òåñòèðîâàíèÿ èëè î ñíèæåíèè ïëîòíîñòè íå îáíàðóæåííûõ îøèáîê äî íåêîòîðîé çàðàíåå îãîâîðåííîé âåëè÷èíû. Âîçìîæíîñòü îãðàíè÷èòü öèêë òåñòèðîâàíèÿ ïðåäåëîì â îäíè ñóòêè èëè íåñêîëüêî ÷àñîâ ïîääåðæèâàåòñÿ èñêëþ÷èòåëüíî çà ñ÷åò ñðåäñòâ àâòîìàòèçàöèè òåñòèðîâàíèÿ.

Ñòàòèñòèêà òåñòîâîãî öèêëà, ñîäåðæàùàÿ: 1) ðåçóëüòàòû ïðîïóñêà êàæäîãî òåñòà èç òåñòîâîãî íàáîðà è èõ ñðàâíåíèÿ ñ ýòàëîííûìè âåëè÷èíàìè; 2) ôàêòû, ïîñëóæèâøèå îñíîâàíèåì äëÿ ïðèíÿòèÿ ðåøåíèÿ î ïðîäîëæåíèè èëè îêîí÷àíèè òåñòèðîâàíèÿ; 3) êðèòåðèé ïîêðûòèÿ è ñòåïåíü åãî óäîâëåòâîðåíèÿ, äîñòèãíóòàÿ â öèêëå òåñòèðîâàíèÿ.

Ðåçóëüòàòîì àíàëèçà êàæäîãî öèêëà òåñòèðîâàíèÿ ÿâëÿåòñÿ ñïèñîê ïðîáëåì, â âèäå îøèáîê è äåôåêòîâ, êîòîðûé çàíîñèòñÿ â áàçó ðàçâèòèÿ ïðîåêòà.

Çàêëþ÷åíèå

Èòàê, â äàííîé ðàáîòå áûëè ðàññìîòðåíû ìåòîäû òåñòèðîâàíèå, èíòåãðàöèÿ ìîäóëåé âîñõîäÿùåãî è íèñõîäÿùåãî òåñòèðîâàíèÿ.

Òåõíîëîãèÿ òåñòèðîâàíèÿ áàçèðóåòñÿ íà òåñòîâûõ ïðîöåäóðàõ ñ îïðåäåëåííûìè äàííûìè íà âõîäå, íà÷àëüíûìè óñëîâèÿìè è îæèäàåìûì ðåçóëüòàòîì. Äàííûå ïðîöåäóðû ðàçðàáàòûâàþòñÿ äëÿ ïðîâåðêè îòäåëüíîé ïðîãðàììû èëè äëÿ íàõîæäåíèÿ ñîîòâåòñòâèÿ íà îïðåäåëåííîå òðåáîâàíèå. Òåñòîâûå ïðîöåäóðû ìîãóò ïðîâåðÿòü ðàçëè÷íûå àñïåêòû ôóíêöèîíèðîâàíèÿ ïðîãðàììû — îò ïðàâèëüíîé ðàáîòû îòäåëüíîé ôóíêöèè äî àäåêâàòíîãî âûïîëíåíèÿ áèçíåñ-òðåáîâàíèé.

Ïðè âûïîëíåíèè òåñòèðîâàíèÿ òîé èëè èíîé ïðîãðàììû íåîáõîäèìî ó÷èòûâàòü, â ñîîòâåòñòâèè ñ êàêèìè ñòàíäàðòàìè è òðåáîâàíèÿìè áóäåò ïðîâîäèòüñÿ ýòà ïðîöåäóðà. Íåîáõîäèìî òàêæå îáîçíà÷èòü êàêèå ìåòîäû áóäóò èñïîëüçîâàòüñÿ äëÿ ïîèñêà óñòðàíåíèÿ îøèáîê. Åñëè ïîìíèòü î òåñòèðîâàíèè ñ ñàìîãî íà÷àëà âûïîëíåíèÿ ïðîåêòà, òåñòèðîâàíèå ðàçðàáàòûâàåìûõ ñðåäñòâ íå äîñòàâèò íåïðèÿòíûõ íåîæèäàííîñòåé. À çíà÷èò è êà÷åñòâî ïðîäóêòà, ñêîðåå âñåãî, áóäåò äîñòàòî÷íî âûñîêèì.

Ïðè íàïèñàíèè ðåôåðàòà ìîæíî ñäåëàòü ñëåäóþùèå âûâîäû: ÷àñòîòà îáíàðóæåíèÿ îøèáîê íà åäèíèöó çàòðàò è íàäåæíîñòü òåñíî ïåðåñåêàþòñÿ ñî âðåìåíåì òåñòèðîâàíèÿ è, ñëåäîâàòåëüíî, ñ ãàðàíòèåé êà÷åñòâà ïðîäóêòà. ×åì áîëüøå òðóäîçàòðàò âêëàäûâàåòñÿ â òåñòèðîâàíèå ïðîãðàììíîãî ïðîäóêòà, òåì ìåíüøå îøèáîê â ïðîäóêòå îñòàåòñÿ íåçàìå÷åííûìè.

Ñòðåìëåíèå ê óìåíüøåíèþ ÷èñëà îñòàâøèõñÿ îøèáîê èëè ê óâåëè÷åíèþ êà÷åñòâà ïðîäóêòà ïðèâîäèò ê ïðèìåíåíèþ ðàçëè÷íûõ ìåòîäîâ îòëàäêè è òåñòèðîâàíèÿ â ïðîöåññå ñîçäàíèÿ ïðîãðàììíûõ ñðåäñòâ.

Ñïèñîê ëèòåðàòóðû

1. Îñíîâû ñîâðåìåííîãî òåñòèðîâàíèÿ ïðîãðàììíîãî îáåñïå÷åíèÿ. Ïîä ðåäàêöèåé ïðîô. Â.Ï. Êîòëÿðîâà. 204 ñ.

2. «Çàïóñê è àíàëèç òåñòîâ ïðîãðàììíûõ ïðîäóêòîâ ïðè ïîìîùè èíñòðóìåíòà óïðàâëåíèÿ òåñòèðîâàíèåì»

3. Îïèñàíèå òèïîâ òåñòèðîâàíèÿ// http://www.a1qa.ru/service/software_testing/description_testing_type/

4. Åâãåíèé Áàëûêîâ. Âëàäèìèð Öàðåâ. Òåñòèðîâàíèå ïðîãðàììíûõ ñðåäñòâ// http://www.rsdn.ru/article/testing/SoftwareTesting.xml

5. Áàðàíöåâ. À.Ñ. «Ñèñòåìíîå òåñòèðîâàíèå» Ñ34-78

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

1. ^

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

1)способность к перебору,

2)способность к абстракции,

3)способность к математической индукции.

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

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

При разработке программного средства мы не всегда можем уверенно знать обо всех связях между ее элементами из-за возможных ошибок. Поэтому полезно уметь оценивать сложность системы по числу ее элементов: числом потенциальных путей взаимодействия между ее элементами, т.е. n! , где n — число ее элементов. Систему назовем малой, если n 7. При n=7 имеем промежуточный класс систем. Малая система всегда проста, а большая может быть как простой, так и сложной. Задача технологии программирования — научиться делать большие системы простыми.

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

1. ^

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

Рис. 2.1. Грубая схема разработки и применения ПС.

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

1. ^

Пример модели ошибок при переводе изображен на рис.2.2. На нём человек осуществляет перевод информации из представления A в представление B. При этом он совершает четыре основных шага перевода:

Рис.2.2. Модель перевода.

1. он получает информацию, содержащуюся в представлении A, с помощью своего читающего механизма R;
2. он запоминает полученную информацию в своей памяти M;
3. он выбирает из своей памяти преобразуемую информацию и информацию, описывающую процесс преобразования, выполняет перевод и посылает результат своему пишущему механизму W;
4. с помощью этого механизма он фиксирует представление B.

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

1. Основные пути борьбы с ошибками.

Учитывая рассмотренные особенности действий человека при переводе можно указать следующие пути борьбы с ошибками:⁶

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

1. ^

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

1) статический просмотр,

2) смежный контроль,

3) пользовательский контроль,

4) ручная имитация.

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

^

1. Большой психологический словарь / Сост. и общ. ред. Б. Мещеряков, В. Зинченко. – СПб.: ПРАЙМ-ЕВРОЗНАК, 2004.
2. Е.А. Жоголев. Технологические основы модульного программирования. // Программирование, 1980, #2. — С. 44-49.
3. Майерс Г. Искусство тестирования программ. — М.: «Финансы и статистика», 1982.
4. Дж. Фокс. Программное обеспечение и его разработка. — М.: Мир, 1985. — С. 53-67, 125-130.
5. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений: Пер. с англ./ С. Канер, Дж. Фолк, Е.К. Нгуен. – К.: Издательство «ДиаСофт», 2001.
6. К. Браун, Р. Калбертсон, Г. Кобб. Быстрое тестирование. – СПб: «Вильямс», 2002.
7. И.В. Поттосин. О добротности программ // Системная информатика: Сб. науч. тр. – Новосибирск: Наука. Сибирское отделение РАН, 1998.
8.  И.С. Березин, Н.П. Жидков. Методы вычислений, т.т. 1 и 2. — М.: Физматгиз, 1959.
9. К. Зиглер. Методы проектирования программных систем. — М.: Мир, 1985. — С. 15-23.
10. Н.С. Бахвалов, Н.П. Жидков, Г.М.Кобельков. Численные методы. — М.: Наука, 1987.
11. А.Н. Лебедев. Защита банковской информации и современная криптография.
12. Е.А. Жоголев. Введение в технологию программирования (конспект лекций). — М.: «ДИАЛОГ-МГУ», 1994.
13. М. Зелковец, А. Шоу, Дж. Гэннон. Принципы разработки программного обеспечения. — М.: Мир, 1982. — С. 11.
14. Э. Дейкстра. Заметки по структурному программированию / У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование. — М.: Мир, 1975. — С. 7-19.