2100

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

Пример: Процедура сжатия Процедура сжатия

1)Выполнять пока не EOF

1)Читать запись;

2)Если запись пуста

3)То удалить запись;

4)Иначе если поле a>= поля b

5)То удалить b

6)Иначе удалить a;

7b

R3

8

Рис. 27. Потоковый граф процедуры сжатия.

7.4.3. Тестирование условий

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

153

образом, чтобы были проверены все операторы всех ветвей программы [15].

Простое условие представлено выражением вида E1 <Оператор отношения> E2

Выражения

Операторы таковы: = <>,< , >, ≤, ≥. Элементами сложного условия являются:

булев оператор; булева переменная; пара скобок; оператор сложения;

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

ошибка Булева оператора; ошибка Булевой переменной; ошибка пары скобок; ошибка оператора сложения;

ошибка арифметических выражений. Способы составления тестов:

1)тестирование ветвей

для любого составного условия проверяется любое входящие в него простое условие;

True – ветвь;

False – ветвь;

2)тестирование области определения

для всех отношений составлено 3-4 теста

(<, >, = , <>);

для булевых выражений с n переменными составляем 2n тестов;

154

7.4.4. Тестирование потоков данных

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

Пусть граф имеет вид.

3

4

5

c

6

Рис. 28. Пример потокового графа и информационных потоков

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

a и b определяются в вершине 1; c – в вершине 4;

a - используется в 4;

b - используется в 3 и 6; c – используется в 6.

Для всех вершин графа можно записать:

155

множество определений данных

DEF (i) = {x | i-я вершина содержащей определение x};

множество использованных данных USE (i) = {x | I –я вершина использует x}.

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

X:=……….

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

ния…:= … Х.

DU – цепочкой называется конструкция [x, i, j], где i, j – вершины, i- вершина определения, j – вершина использования.

DU цепочки для графа на рис. 27: [a, 1, 4],[b, 1, 3],[b, 1, 6],[c, 4, 6].

Способ DU – тестирования требует охвата всех DU – цепочек программы.

Шаги DU – тестирования:

1)построение управляющего графа программы;

2)построение информационного графа;

3)формирование полного набора DU цепочек;

4)формирование полного набора отрезков путей в управляющем графе, то есть отображение набора DU цепочек информационного графа;

5)построение маршрутов – полных путей на управляющем графе, покрывающих набор отрезков путей управляющего графа;

6)подготовка тестовых вариантов.

Область применения этого способа составления тестов – программы с выполняемыми условными операторами и операторами цикла.

7.5. Методы компоновки программных систем

156

Монолитный метод

Каждый компонент системы тестируется отдельно, собирается вся система и тестируется [2, 11, 15, 16].

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

Драйвер моделирует вызывающую тестируемый модуль программу, заглушка – вызываемую программу.

Нисходящий метод

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

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

Восходящий метод

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

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

Метод ядра

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

157

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

Применяется при разработке больших развивающихся программных систем.

Метод сэндвича

Компромисс между 2 и 3 методами: компоновка начинается одновременно с верхнего и нижнего уровня иерархии по направлению к центру.

7.6. Технология тестирования

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

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

Следует избегать тестирования программы ее ав-

тором.

Следует разработать тесты для неправильных данных.

Следует проверять не только то, что делает программа, но и то, что она не должна делать.

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

Удачным считается тот тест, который обнаружит ошибку.

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

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

Существуют стандартные обязательные тесты

для ПС.

158

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

2.Тестирование удобства эксплуатации: удобство работы системного администратора и другого обслуживающего персонала.

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

4.Тестирование предельных объемов.

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

6.Тестирование системы защиты данных от несанкционированного доступа.

7.Тестирование требований к вычислительным ресурсам.

8.Тестирование на совместимость с другими программами.

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

Контрольные вопросы

1.Что включает в себя отладка программ?

2.Какие виды тестирования существуют?

3.Что должен включать в себя тест?

4.Можно ли говорить о причине ошибки по симптомам ее проявления?

5.В чем состоят основные принципы сокращения тестов?

6.В чем заключается стратегия тестирования «черного» ящика?

7.Для чего выделяют при тестировании классы эквивалентности?

159

8.В чем заключается стратегия тестирования «белого» ящика?

9.В чем заключается стратегия тестирования базового пути?

10.Как строится потоковый граф?

11.Как происходит компоновка и тестирование ПС?

12.Существуют ли стандартные тесты ПС?

8. СОПРОВОЖДЕНИЕ ПРОГРАММНЫХ СИСТЕМ

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

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

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

каковы затраты на выполнение корректировок и их распространение пользователям;

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

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

160

для какого числа пользователей может быть полезно данное изменение;

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

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

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

явных ошибок; изменения, вносимые в следующую версию для улуч-

шения эффективности; изменения, требующие дополнительного анализа целе-

сообразности и эффективности их реализации (могут не внедряться в очередную версию);

изменения, не оправдывающие затрат на разработку или не влияющие на эффективность программ;

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

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

8.1. Тиражирование и издание версий

Для тех программ, которые отобраны для реализации, выполняются корректировки программного кода [1, 3]. Все эти корректировки выполняются и проверяются на версиях программ разработчиков, из которых формируются подлинник следующей версии - эталонная версия. Эталонная версия тес-

161

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

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

8.2. Исходные и отчетные документы при испытаниях

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

объекты испытаний (ветвь программы, модуль, подсистема, комплекс программ, объект, на который воздействует программа);

цель испытаний; план тестирования (набор тестов, которые проводятся

при испытаниях); методики испытаний (условия тестирования, средства,

методики обработки и оценки результатов).

162