ВУЗ: Томский государственный университет систем управления и радиоэлектроники
Категория: Учебное пособие
Дисциплина: Проектирование информационных систем
Добавлен: 21.10.2018
Просмотров: 10082
Скачиваний: 6
16
лишь
36 %
на
этапе
кодирования.
Однако
эти
ошибки
могут
быть
очень
дорогостоящими
(DO
4
I=1,5
и
DO
4
I=1.5
).
В
общем
случае
кодирование
освоено
лучше,
чем
другие
этапы
создания
программ,
и
очень
четко
формализовано.
2.5
Тестирование
Этап
тестирования
обычно
в
финансовых
затратах
со-
ставляет
половину
расходов
на
создание
системы.
Плохо
спла-
нированное
тестирование
приводит
к
существенному
увеличе-
нию
сроков
разработки
системы
и
является
основной
причиной
срывов
графиков
разработки.
В
процессе
тестирования
используются
данные,
харак-
терные
для
системы
в
рабочем
состоянии,
т.е.
данные
для
тес-
тирования
выбираются
случайным
образом.
План
проведения
испытаний
должен
быть
составлен
заранее,
обычно
на
этапе
проектирования.
Тестирование
подразумевает
три
стадии:
−
автономное;
−
комплексное
и
−
системное.
При
автономном
тестировании
модуль
проверяется
с
по-
мощью
данных,
подготовленных
программистом.
При
этом
программная
среда
модуля
имитируется
с
помощью
программ
управления
тестированием,
содержащих
фиктивные
программы
вместо
реальных
подпрограмм,
с
которыми
имеется
обращение
из
данного
модуля
(заглушки).
Подобную
процедуру
называют
про-
граммным
тестированием,
а
программу
тестирования
—
UUT
(тестирующей
программой).
Модуль,
прошедший
автономное
тес-
тирование,
подвергается
комплексному
тестированию.
В
процессе
комплексного
тестирования
проводится
совме-
стная
проверка
групп
программных
компонент.
В
результате
имеем
полностью
проверенную
систему.
На
данном
этапе
тес-
тирование
обнаруживает
ошибки,
пропущенные
на
стадии
ав-
тономного
тестирования.
Исправление
этих
ошибок
может
со-
ставлять до ¼ от общих
затрат.
Системное
(или
оценочное)
тестирование
—
это
завер-
шающая
стадия
проверки
системы,
т.е.
проверка
системы
в
це-
17
лом
с
помощью
независимых
тестов.
Независимость
тестов
яв-
ляется
главным
требованием.
Обычно
Заказчик
на
стадии
при-
емки
работ
настаивает
на
проведении
собственного
системного
тестирования.
Для
случая,
когда
сравниваются
характеристики
нескольких
систем
(имеется
альтернативная
разработка),
такая
процедура
известна
как
сравнительное
тестирование.
В
процессе
тестирования,
для
определения
правильности
выполнения
программы
вводится
ряд
критериев:
1)
каждый
оператор
должен
быть
выполнен,
по
крайней
мере,
один
раз
для
заданного
набора
тестов,
и
про-
грамма
должна
выдать
правильный
результат;
2)
каждая
ветвь
программы
должна
быть
опробована,
и
программа
при
этом
должна
выдать
правильный
ре-
зультат;
3)
каждый
путь
в
программе
должен
быть
испытан
хотя
бы
один
раз
с
использованием
набора
тестовых
данных,
и
программа
должна
выдать
правильный
результат;
4)
для
каждой
спецификации
программы
необходимо
располагать
набором
тестовых
данных,
позволяющих
установить,
что
программа
правильно
реализует
дан-
ную
спецификацию.
Хотя
критерии
1)
и
2)
кажутся
схожими,
в
действительно-
сти
они
сильно
разнятся.
Например,
арифметический
оператор
IF
в
Fortran:
IF
(
Выражение) N1, N2, N3.
Критерий
1)
подразумевает,
что
IF
должен
быть
выпол-
нен,
в
то
время
как
2)
подразумевает
различные
наборы
данных,
для
того
чтобы
выполнились
условия
N1
,
N2
,
N3
(т.е.
передачу
на
эти
метки).
В
общем
случае
не
существует
единого
программного
критерия,
определяющего
«хорошо
проверенную»
программу.
Тесно
связаны
с
тестированием
понятия
«верификация»
и
«испытание».
Испытание
системы
осуществляется
посредством
тести-
рования.
Цель
такой
проверки
—
показать,
что
система
функ-
18
ционирует
в
соответствии
с
разработанными
на
нее
специфика-
циями.
Верификация
заключается
в
выполнении
доказательств,
что
программа
удовлетворяет
своим
спецификациям.
Современный
процесс
разработки
программ
не
позволяет
реализовать
обе
указанные
концепции.
Для
ситуаций,
не
кон-
тролируемых
тестовыми
данными,
система,
прошедшая
испы-
тания,
может
дать
неверные
результаты.
После
проведения
ве-
рификации
система
работает
правильно
лишь
относительно
первоначальных
спецификаций
и
допущений
о
поведении
ок-
ружающей
среды;
формальные
доказательства
правильности
программ
весьма
сложны
и
слабо
разработаны.
Общий
процесс
создания
правильных
программ
с
помо-
щью
процедур
испытания
и
верификации
называется
аттеста-
цией.
Различаются
три
вида
отклонения
от
нормальной
работы
системы.
Сбой
системы
—
это
явление,
связанное
с
нарушением
системой
установленных
на
нее
спецификаций.
Данные,
при
обработке
которых
правильными
алгорит-
мами
системы
происходит
сбой,
называются
выбросом.
Ис-
правление
выброса
можно
предусмотреть
в
программе,
так
что
не
каждый
выброс
может
приводить
к
сбою.
Ошибка
—
это
алгоритмический
дефект,
который
создает
выброс
(программная
ошибка).
Различают
понятия
«правильная»
и
«надежная»
програм-
ма.
Правильная
программа
—
это
та,
что
удовлетворяет
своим
спецификациям.
Что
касается
надежной
программы,
то
она
не
обязательно
является
правильной,
но
выдает
приемлемый
ре-
зультат
даже
в
том
случае,
когда
входные
данные
либо
условия
ее
использования
не
удовлетворяют
принятым
допущениям.
Естественно
стремление
иметь
«живую»
(robustness)
систему,
т.е.
систему,
способную
воспринимать
широкий
спектр
вход
-
ных
данных
при
неблагоприятных
условиях.
Система
является
правильной,
если
в
системе
нет
ошибок,
а
ее
внутренние
данные
не
содержат
выбросов.
Система
назы-
вается
надежной,
если,
несмотря
на
сбои,
она
продолжает
удов-
19
летворительно
функционировать.
Это
особо
видно
на
примере
операционной
системы
(ОС),
включающей
систему
обработки
сбоев.
При
обнаружении
выброса
такая
система
прекращает
работу
с
сохранением
текущей
информации
и
возможности
продолжения
работы
после
устранения
выброса.
2.6
Эксплуатация
и
сопровождение
С
учетом
затрат
на
эксплуатацию
и
сопровождение
вре-
менные
затраты
на
разработку
программной
системы
можно
представить
так
(рис.
2.5):
1)
анализ
требований;
2)
определение
спецификаций;
3)
проектирование;
4)
кодирование;
5)
автономное
тестирование;
6)
комплексное
тестирование;
7)
сопровождение.
Рис.
2.5
—
Временные
затраты
на
реализацию
этапов
жизненного
цикла
программного
обеспечения
Анализ
требований
(3%)
Определение
спецификаций
(3%)
Проектирование
(5%)
Кодирование
(7%)
Автономное
тестирование
(8%)
Комплексное
тес-
тирование
(7%)
Сопровождение
(67%)
20
Ни
одна
из
вычислительных
систем
не
остается
неизмен-
ной
по
мере
ее
эксплуатации.
Это
объясняется
несколькими
причинами,
среди
которых
можно
выделить
следующие:
1.
Заказчик
обычно
не
может
четко
сформулировать
свои
требования,
редко
бывает
удовлетворен
созданной
сис-
темой
и
поэтому
настаивает
на
внесении
изменений
в
готовую
систему.
2.
Могут
быть
обнаружены
ошибки,
пропущенные
при
тестировании.
3.
Могут
потребоваться
специальные
модификации
сис-
темы
для
частных
условий
функционирования,
связан-
ные
с
различными
применениями.
4.
Сопровождение
многочисленных
компонентов
систе-
мы.
Рассмотрим
затраты,
оказывающие
наибольшее
влияние
на
процесс
разработки
системы.
В
первую
очередь
следует
от-
метить,
что
методы
разработки,
стимулирующие
раннее
завер-
шение
проекта,
могут
привести
к
весьма
высоким
затратам
по
сопровождению.
Поэтому
не
следует
ориентироваться
на
воз-
можно
ранний
переход
на
этап
кодирования.
Хотя
написание
кодов
и
создает
иллюзию
благополучия
у
руководителя
проек-
та,
однако
это
чревато
такими
последствиями,
как
многократное
тестирование
и
возникновение
большого
числа
проблем
на
бо-
лее
позднем
этапе
сопровождения.
Задачу
сопровождения
обычно
трактуют
как
задачу
отра-
ботки
непомерно
возрастающего
числа
версий
системы.
Пусть
некоторая
система
содержит
компоненты
A,
B,
C
и
установлена
у
потребителей
I,
II,
III
(рис.
2.6).
Рис.
2.6
—
Исходные
системы
потребителей
В
процессе
эксплуатации
системы
потребитель
I
обнару-
жил
ошибку
и
сообщил
об
этом
разработчику.
Последний
кор-
ректирует
ее
и
направляет
исправленный
модуль
A
’
всем
поль-
A
B
C
I
A
B
C
III
A
B
C
II