Первичные ошибки вторичные ошибки и их проявления презентация

1. Причины и типы ошибок

ПРИЧИНЫ И ТИПЫ ОШИБОК

2. Классификация ошибок по причине возникновения

• синтаксические ошибки;
• семантические ошибки;
• логические ошибки.

3. Синтаксические ошибки

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

4. Семантические ошибки

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

5. Логические ошибки

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

6. Классификация ошибок по этапу обработки программы

Ошибки, которые могут быть в программе,
принято делить на три группы:
• ошибки компиляции;
• ошибки компоновки;
• ошибки выполнения.

7.

Ошибки компиляции
Ошибки компиляции (Compile-time error) – ошибки,
фиксируемые компилятором (транслятором, интерпретатором)
при выполнении синтаксического и частично семантического
анализа программы;
Наиболее легко устранимы.
Их обнаруживает компилятор, а программисту остается только
внести изменения в текст программы и выполнить повторную
компиляцию.
Компилятор просматривает программу от начала. Если
обнаруживается
ошибка,
то
процесс
компиляции
приостанавливается и в окне редактора кода выделяется строка,
которая, по мнению компилятора, содержит ошибочную
конструкцию.

8.

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

9. Наиболее типичные ошибки компиляции

Сообщения компилятора
Undeclared identifier
(Необъявленный
идентификатор)
Вероятная причина
Используется переменная, не объявленная в
разделе var программы;
Ошибка при написании имени переменной;
Ошибка при написании имени инструкции
(оператора).
Unterminated string
При записи строковой константы не
(Незавершенная строка)
поставлена завершающая кавычка.
Incompaible types … and В операторе присваивания тип выражения
…
не соответствует или не может быть
(Несовместимые типы)
приведен к типу переменной, получающей
значение выражения.
Missing operator or
Не поставлена точка с запятой после
semicolon
инструкции программы.
(Отсутствует оператор или точка
с запятой)

10. Ошибки компоновки

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

11. Ошибки выполнения

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

12. Ошибки выполнения

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

13. Причины ошибок выполнения

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

14. Причины ошибок выполнения

15. Предотвращение и обработка исключений

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

16. Предотвращение и обработка исключений

Инструкция обработки исключения в общем виде:
try // инструкции, выполнение которых может вызвать
исключение
except // начало секции обработки исключений
on ТипИсключения1 do Обработка1;
on ТипИсключения2 do Обработка2;
…;
else // инструкции обработки остальных исключений
end;

17. Предотвращение и обработка исключений

где:
• try — ключевое слово, обозначающее, что далее следуют
инструкции, при выполнении которых возможно
возникновение исключений, и что обработку этих
исключений берет на себя программа;
• except — ключевое слово, обозначающее начало секции
обработки исключений. Инструкции этой секции будут
выполнены, если в программе возникнет ошибка;
• on — ключевое слово, за которым следует тип
исключения, обработку которого выполняет инструкция,
следующая за do;
• else — ключевое слово, за которым следуют инструкции,
обеспечивающие обработку исключений, тип которых не
указаны в секции except.

18. Типичные исключения

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

19. Пример: Обработка исключения типа EZeroDivide

procedure TForm1.Button1Click(Sender: TObject);
Var u, r, i: real; // напряжение , сопротивление, ток
begin
Labels.Caption := ‘ ‘;
try // инструкции, которые могут вызвать исключение (ошибку)
u := StrToFloat(Edit1.Text);
r := StrToFloat(Edit2.Text);
i := u/r;
except // секция обработки исключений
onEZeroDivide do // деление на ноль
begin
ShowMessage(‘Сопротивление не может быть равно нулю!’);
exit;
end;
on EConvertError do // ошибка преобразования строки в число
begin
ShowMessage(‘Напряжение и сопротивление должны быть заданы числом. ‘ );
exit;
end; end;

20. Отладка и тестирование

ОТЛАДКА И ТЕСТИРОВАНИЕ

21.

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

22.

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

23.

Немного истории
Статистика:
Даже
однострочное
изменение
в
программе
с
вероятностью 55 % либо не исправляет старую ошибку,
либо вносит новую. Если же учитывать изменения любого
объема, то в среднем менее 20 % изменений корректны с
первого раза.

24.

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

25. Зависимость вероятности правильного исправления ошибок и стоимости исправления ошибок от этапа разработки

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

26.

Основные понятия, связанные с
тестированием и отладкой
Отладка программного средства – это деятельность,
направленная на обнаружение и исправление ошибок в ПС с
использованием процессов выполнения его программ.
Тестирование программного средства — процесс выполнения
программ на некотором наборе данных, для которого заранее
известен результат применения или известны правила поведения
этих программ.
Отладка = Тестирование + Поиск ошибок + Редактирование

27.

Основные понятия, связанные с
тестированием и отладкой
Процесс отладки включает:
• действия, направленные на выявление ошибок
(тестирование);
• диагностику и локализацию ошибок (определение
характера ошибок и их местонахождение);
• внесение исправлений в программу с целью устранения
ошибок (редактирование).
Отладка = Тестирование + Поиск ошибок + Редактирование
Самым трудоемким и дорогим является тестирование,
затраты на которое приближаются к 45% общих затрат на
разработку ПС и от 30 до 60% общей трудоемкости создания
программного продукта.

28.

Две задачи тестирования
Первая задача тестирования – подготовить набор тестов и
применить к ним ПС, чтобы обнаружить в нём по возможности
большее число несоответсвий.
Вторая задача тестирования — определить момент окончания
отладки ПС (или отдельной его компоненты).

29.

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

30. Требования к программному продукту и тестирование

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

31. Рекомендуемая стандартом IEEE 830 структура SRS

Введение
– Цели
– Соглашения о терминах
– Предполагаемая аудитория и последовательность восприятия
– Масштаб проекта
– Ссылки на источники
Общее описание
– Видение продукта
– Функциональность продукта
– Классы и характеристики пользователей
– Среда функционирования продукта (операционная среда)
– Рамки, ограничения, правила и стандарты
– Документация для пользователей
– Допущения и зависимости
Функциональность системы
– Функциональный блок X (таких блоков может быть несколько)
• Описание и приоритет
• Причинно-следственные связи, алгоритмы
• Функциональные требования

32. Рекомендуемая стандартом IEEE 830 структура SRS (продолжение)

Требования к внешним интерфейсам
– Интерфейсы пользователя (UX)
– Программные интерфейсы
– Интерфейсы оборудования
– Интерфейсы связи и коммуникации
Нефункциональные требования
– Требования к производительности
– Требования к сохранности (данных)
– Критерии качества программного обеспечения
– Требования к безопасности системы
Прочие требования
– Приложение А: Глоссарий
– Приложение Б: Модели процессов и предметной области и другие
диаграммы
– Приложение В: Список ключевых задач

33.

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

34. Стратегия проектирования тестов

В тестирование ПС входят
• постановка задачи для теста,
• проектирование,
• написание тестов,
• выполнение тестов,
• изучение результатов тестирования.

35.

По объекту тестирования
Функциональное тестирование
Тестирование производительности
Нагрузочное тестирование
Стресс-тестирование
Тестирование стабильности
Конфигурационное тестирование
Юзабилити-тестирование
Тестирование интерфейса пользователя
Тестирование безопасности
Тестирование локализации
Тестирование совместимости
По знанию системы
Тестирование чёрного ящика
Тестирование белого ящика
Тестирование серого ящика
По степени автоматизации –
Ручное тестирование
Автоматизированное тестирование
Полуавтоматизированное тестирование
По степени изолированности компонентов
Модульное тестирование
Интеграционное тестирование
Системное тестирование
По времени проведения тестирования
Альфа-тестирование
Дымовое тестирование
Тестирование новой функции
Подтверждающее тестирование
Регрессионное тестирование
Приёмочное тестирование
Бета-тестирование
По признаку позитивности сценариев
Позитивное тестирование
Негативное тестирование
По степени подготовленности к
тестированию
Тестирование по документации
(формальное тестирование)
Интуитивное тестирование (англ. ad hoc
testing)

36.

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

37.

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

38.

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

39.

Критерии полноты тестирования

40.

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

41. Критерии полноты тестирования

• Функциональные критерии:
• Структурные критерии:
1)
2)
3)
4)
5)
Покрытие операторов
Покрытие условий
Покрытие путей
Покрытие функций
Покрытие вход/выход

42. Критерии полноты тестирования

Критерий тестирования функций

43. Критерии полноты тестирования

Критерии тестирования входных и
выходных данных

44. Критерий тестирования функций

Критерии тестирования входных и
выходных данных
• Пример. Программа для учета кадров предприятия

45. Критерии тестирования входных и выходных данных

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

46. Критерии тестирования входных и выходных данных

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

47. Критерии тестирования входных и выходных данных

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

48. Критерии тестирования входных и выходных данных

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

49. Критерии тестирования входных и выходных данных

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

50. Критерии тестирования входных и выходных данных

Пример. Показывает отличие количества тестов при различных выбранных
структурных критериях.
В случае выбора критерия «Покрытие операторов» достаточен 1 тест
(рис.а)
В случае выбора критерия «Покрытие условий» достаточно двух тестов,
покрывающих пути 1, 4 или 2, 3 (рис.б)
В случае выбора критерия «Покрытие путей необходимо четыре теста
для всех четырех путей (рис.б)

51. Структурные критерии

Покрытие операторов
Пример 1
If ((A>1) and (B =0))
then X := X/A;
If ((A=2) or (X>1))
then X:=X+1;
Можно выполнить каждый оператор,
записав один-единственный тест,
который реализовал бы путь асе.
Иными словами, если бы в точке а были
установлены значения А = 2, В = 0 и Х =
3, каждый оператор выполнялся бы
один раз (в действительности Х может
принимать любое значение)

52.

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

53. Покрытие операторов

Покрытие условий
Пример 1
If ((A>1) and (B =0))
then X = X/A;
If ((A=2) or (X>1))
then X:=X+1;
Покрытие условий может быть выполнено двумя тестами,
покрывающими либо пути асе и abd, либо пути acd и abe.
Если мы выбираем последнее альтернативное покрытие, то входами двух тестов являются A = 3, В = 0, Х = 1 и A = 2, В = 1, Х = 1.

54. Покрытие операторов

Покрытие условий
Пример 2
a:=7;
while a>x do a:=a-1;
b:=1/a;
a:=7
a>x
—
b:=1/a
+
a:=a-1
Для того чтобы удовлетворить критерию покрытия ветвей в данном
случае достаточно одного теста. Например такого, чтобы х был равен
6 или 5. Все ветви будут пройдены. Но ошибка в программе
обнаружена так и не будет. Она проявится в единственном случае,
когда х=0. Но такого теста от нас критерий покрытия ветвей не
требует.

55. Покрытие условий

Покрытие путей
Пример 1
If ((A>1) and (B =0))
then X = X/A;
If ((A=2) or (X>1))
then X:=X+1;
Покрытие путей (все возможные пути
через заданную часть кода должны быть
выполнены и протестированы) может быть
выполнено четырьмя тестами:
a,c,e – A=2, B=0, X=3
a,b,e – A=2, B=1, X=1
a,b,d – A=3, B=1, X=1
a,c,d – A=3, B=0, X=1

56. Покрытие условий

Покрытие путей
a
Пример 1
If ((A>1) and (B =0))
then X = X/A;
If ((A=2) or (X>1))
then X:=X+1;
c
b
е
d

57. Покрытие путей

Критерий комбинаторного покрытия условий
Пример 2
If (a=0) or (b=0) or (c=0)
Then d:=1/(a+b)
Else d:=1;
Ошибка будет выявлена только при a=0 и b=0.
Критерий покрытия путей не гарантирует
проверки такой ситуации.
Для решения этой проблемы был предложен критерий комбинаторного
покрытия условий, который требует подобрать такой набор тестов, чтобы
хотя бы один раз выполнялась любая комбинация простых условий.
Критерий значительно более надежен, чем покрытие путей, но обладает
двумя существенными недостатками.
• Во-первых, он может потребовать очень большого числа тестов.
Количество тестов, необходимых для проверки комбинаций n простых
условий, равно 2n.
• Во-вторых, даже комбинаторное покрытие условий не гарантирует
надежную проверку циклов.

58. Покрытие путей

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

59.

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

60. Два основных вида тестирования

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

61. Уровни тестирования

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

62. Основные этапы разработки сценария автономного тестирования

Творческая работа
1. Разделиться на группы
2. Получить тему (практические работы по Delphi №№ 3, 5, 7,
9, 10)
3. Составить спецификацию
4. Разработать программу тестирования:
4.1. Определить виды тестирования
4.2. Определить объекты тестирования
4.3. Определить субъекты тестирования
4.4. Определить классы входных данных
4.5. Написать тест-кейсы для тестирования функций и ожидаемые
результаты
4.6. Написать тест-кейсы для структурного тестирования и
ожидаемые результаты
Составить чек-листы для проведения всех видов тестирования
5. Провести тестирование
6. Сделать выводы

63. Основные этапы разработки сценария автономного тестирования

Содержание ПЗ к проекту
Титульный лист
Бриф
Спецификация
ТЗ
Пользователи
Интерфейсы
Информационно-логическая схема
Схема БД
Алгоритм одной процедуры
Программа тестирования
Результаты тестирования

Рисунок 2 – последствия и результаты

проявления некоторых внутренних дефектов.

Системные ошибки в большом (сложном) программном обеспечении определяются, прежде всего неполной информацией о реальных процессах, происходящих в источниках и потребителях информации. На начальных стадиях проектирования программного обеспечения не всегда удается точно сформулировать целевую задачу всей системы и требования к ней. В процессе проектирования целевая функция системы уточняется и выявляются отклонения от уточненных требований, которые могут квалифицироваться как системные ошибки. Некачественное определение требований к программе приводит к созданию программы, которая будет правильно решать неверно сформулированную задачу. В таких случаях, как правило, требуется полное перепрограммирование. Признаком того, что создаваемая для заказчика программа может оказаться не соответствующей его истинным потребностям, служит ощущение неясности задачи. Письменная регистрация требований к программе заставляет заказчика собраться с мыслями и дать достаточно точное определение требований. Всякие устные указания являются заведомо ненадежными и часто приводят к взаимному недопониманию. При автономной и в начале комплексной отладки программного обеспечения доля найденных системных ошибок в нем невелика (примерно 10%), но она существенно возрастает (до 35—40%) на завершающих этапах комплексной отладки. В процессе эксплуатации преобладающими являются системные ошибки (примерно 80% всех ошибок). Ошибки в выборе алгоритма. Часто плохой выбор алгоритма становится очевидным лишь после его опробования. Поэтому все же следует уделять внимание и время выбору алгоритма, с тем, чтобы впоследствии не приходилось переделывать каждую программу. Во избежание выбора некорректных алгоритмов, необходимо хорошо ознакомиться с литературой по своей специальности. К алгоритмическим ошибкам следует отнести, прежде всего, ошибки, обусловленные некорректной постановкой функциональных задач, когда в спецификациях не полностью оговорены все условия, необходимые для получения правильного результата. Эти условия формируются и уточняются в значительной части в процессе тестирования и выявления ошибок в результатах функционирования программ. Также следует отнести ошибки связей модулей и функциональных групп программ. Их можно квалифицировать как ошибки некорректной постановки задачи. Алгоритмические ошибки проявляются в неполном учете диапазонов изменения переменных, в неправильной оценке точности используемых и получаемых величин, в неправильном учете связи между различными переменными, в неадекватном представлении формализованных условий решения задачи в спецификациях или схемах, подлежащих программированию и т.д. Эти обстоятельства являются причиной того, что для исправления каждой алгоритмической ошибки приходится изменять иногда целые ветви программного обеспечения, т.е. пока еще существенно больше операторов, чем при исправлении программных ошибок. Алгоритмические ошибки значительно труднее поддаются обнаружению методами формализованного автоматического контроля. Вот почему необходимо тщательным образом продумывать алгоритм прежде, чем транслировать его в программу. Некоторые программисты проверяют алгоритм следующим образом. Через несколько дней после составления алгоритма они повторно обращаются к описанию задачи и составляют алгоритм заново. Затем сличают оба варианта. Такой шаг на первый взгляд может показаться пустой тратой времени, однако всякая ошибка на уровне алгоритма может в дальнейшем обернуться катастрофой и повлечь основательный пересмотр программы. Технологические ошибки— это ошибки документации и фиксирования программ в памяти ЭВМ. Они составляют 5—10 % от общего числа ошибок, обнаруживаемых при отладке. Большинство технологических ошибок выявляются автоматически формализованными методами (например, транслятором). Программные ошибки. Языки программирования — это искусственные языки, созданные человеком для описания алгоритмов. Все предложения таких языков строятся по строгим синтаксическим правилам, обеспечивающим однозначное их понимание, что позволяет поручать расшифровку алгоритма ЭВМ, построенного по правилам семантики. Синтаксис — это набор правил построения из символов алфавита специальных конструкций, с помощью которых можно составлять различные алгоритмы (программы). Эти правила требуют их неукоснительного соблюдения. В противном случае будет нарушен основной принцип — четкая и строгая однозначность в понимании алгоритма.
Семантика языка — это система правил истолкования построений конструкций. Правила семантики конструкций обычно вполне естественны и понятны, но в некоторых случаях их надо специально оговаривать, комментировать. Таким образом, программы, позволяющие однозначно производить процесс переработки данных, составляются с помощью соединения символов из алфавита в предложения в соответствии с синтаксическими правилами, определяющими язык, с учетом правил семантики. Выделяют синтаксические и семантические ошибки. Под синтаксическими ошибками понимается нарушение правил записи программ на данном языке программирования. Они выявляются самой машиной, точнее транслятором, вовремя перевода записи алгоритма на язык машины. Исправление их осуществляется просто — достаточно сравнить формат исправляемой конструкции с синтаксисом в справочнике и исправить его. Семантические (смысловые) ошибки — это применение операторов, которые не дают нужного эффекта (например, а—вместо, а+в), ошибка в структуре алгоритма, в логической взаимосвязи его частей, в применении алгоритма к тем данным, к которым он неприменим и т.д. Правила семантики не формализуемы. Поэтому поиск и устранение семантической ошибки и составляет основу отладки. Каждая программная ошибка влечет за собой необходимость изменения команд существенно меньше, чем при алгоритмических и системных ошибках. На этапах комплексной отладки программного обеспечения и эксплуатации удельный вес программных ошибок падает и составляет примерно 15 и 30 % соответственно от общего количества ошибок, выявляемых в единицу времени.

1. CALS-технологии

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

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

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

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

Основные принципы CALS-технологий базируются на контроле и организации этапов существования продукции. К ним относят:

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

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

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

К преимуществам интегрированной среды можно отнести:

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

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

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

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

Примерами CALS-технологий являются цифровые методы проектирования производств, поддерживающие контроль жизненного цикла продукции (Product LifecycleManagement) — так называемые PLM-системы. К ним относят следующие классы систем:

• CAD – (Computer Aided Design) – решение задач проектирования изделий и элементов; моделирование объектов на плоскости (2D-модель) и в пространстве (3D-модель); средства получения чертежей; архивы данных по элементам конструкций и создание шаблонов документов.
• CAE – (Computer Aided Engineering) – исследование свойств объектов (при изготовлении и эксплуатации); создание проверочных систем анализа объекта по разработанной модели; оптимизация параметров объекта по заданным условиям и ограничениям.
• CAM — (Computer Aided Manufacturing) – программирование контроллеров станков с ЧПУ; исследование вариантов траектории инструмента по алгоритмам обрабатываемой поверхности; анализ геометрических конфликтов; подгонка к оборудованию.
• PDM — (Product Data Management) — хранение данных и контроль документации; создание архива образцов; обеспечение доступа к информации и ее защита.

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

Еще одной важной функцией вычислительных методов является управление различными ресурсами и потоками предприятия в реальном времени — материально-техническими, финансовыми, процессами складирования, персоналом, планированием и сбытом продукции. Системы, реализующие выполнение перечисленных задач относятся к ERP-системам (Enterprise Resource Planning − управление ресурсами предприятия).

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

К типовым функциям данного класса программных продуктов относят:

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

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

2 Первичные ошибки, вторичные ошибки и их проявления

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

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

Распределение выявленных ошибок

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

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

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

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

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

• системные ошибки;
• ошибки в выборе алгоритма;
• алгоритмические ошибки;
• технологические ошибки;
• программные ошибки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1


Лекция 2. Методы обеспечения качества программных средств Учебные вопросы 1. Классификация методов обеспечения качества ПС 2.Ресурсы, влияющие на качество ПС 3. Системное проектирование программных средств 4. Статистические характеристики проявления ошибок в программах

2


Вопрос 1

3


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

4


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

5


Методы первой и второй групп базируются на применении современных CASE- технологий и систем автоматизированного проектирования.

6


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

7


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

8


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

9


Вопрос 2

10


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

11


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

12


Вопрос 3

13


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

14


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

15


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

16

17


Основные компоненты процесса разработки системного проекта программного средства (ПС)

18


Основная цель системного проектирования — обоснование необходимости, направлений и концепций создания или модернизации ПС или изменений его качества. В настоящее время на этапе системного проектирования широко используются CASE- средства (Computer Aided Software (System) Engineering).

19


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

20


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

21


Вопрос 4

22


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

23


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

24


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

25


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

26


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

27


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

28


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

29


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