лекция. Сборник лекций по МДК _Технология разработки программного обеспе. Курс лекций для специальности спо базовой подготовки

Название	Курс лекций для специальности спо базовой подготовки
Анкор	лекция
Дата	02.09.2022
Размер	4.41 Mb.
Формат файла
Имя файла	Сборник лекций по МДК _Технология разработки программного обеспе.docx
Тип	Курс лекций #660044
страница	49 из 62

1 ... 45 46 47 48 49 50 51 52 ... 62

Моделирование предметной области (бизнес-моделирование, Business Modeling)

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

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

Определение требований (Requirements)

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

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

Анализ и проектирование (Analysis and Design)

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

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

Реализация (Implementation)

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

Тестирование (Test)

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

Развертывание (Deployment)

Задачи — установить систему в ее рабочем окружении и оценить ее работоспособность на том месте, где она должна будет работать.

Управление конфигурациями и изменениями (Configuration and Change Management)

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

Управление проектом (Project Management)

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

Управление средой проекта (Environment)

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

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

Рис. 3.8.Распределение работ между различными дисциплинами в проекте по RUP

Напоследок перечислим техники, используемые в RUP согласно [3].

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

Разработка программного обеспечения в стиле экстремального программирования

Экстремальное программирование (Extreme Programming, XP) [4] возникло как эволюционный метод разработки ПО "снизу вверх". Этот подход является примером так называемого метода "живой" разработки (Agile Development Method). В группу "живых" методов входят, помимо экстремального программирования, методы SCRUM, DSDM (Dynamic Systems Development Method, метод разработки динамичных систем), Feature-Driven Development (разработка, управляемая функциями системы) и др.

Основные принципы "живой" разработки ПО зафиксированы в манифесте "живой" разработки [5], появившемся в 2000 году.

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

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

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

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

По утверждению авторов XP, эта методика представляет собой не столько следование каким-то общим схемам действий, сколько применение комбинации следующих техник. При этом каждая техника важна, и без ее использования разработка считается идущей не по XP, согласно утверждению Кента Бека (Kent Beck) [4], одного из авторов этого подхода наряду с Уордом Каннингемом (Ward Cunningham) и Роном Джефрисом (Ron Jeffries).

Живое планирование (planning game)

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

Рис. 3.9.Схема потока работ в XP

Частая смена версий (small releases)

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

Метафора (metaphor) системы

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

Простые проектные решения (simple design)

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

Разработка на основе тестирования (test-driven development)

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

Постоянная переработка (refactoring)

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

Программирование парами (pair programming)

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

Коллективное владение кодом (collective ownership)

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

Постоянная интеграция (continuous integration)

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

40-часовая рабочая неделя

Сверхурочная работа рассматривается как признак больших проблем в проекте. Не допускается сверхурочная работа 2 недели подряд — это истощает программистов и делает их работу значительно менее продуктивной.

Включение заказчика в команду (on-site customer)

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

Использование кода как средства коммуникации

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

Открытое рабочее пространство (open workspace)

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

Изменение правил по необходимости (just rules)

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

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

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

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

XP как совокупность описанных техник впервые было использовано в ходе работы на проектом C3 (Chrysler Comprehensive Compensation System, разработка системы учета выплат работникам компании Daimler Chrysler). Из 20-ти участников этого проекта 5 (в том числе упомянутые выше 3 основных автора XP) опубликовали еще во время самого проекта и в дальнейшем 3 книги и огромное количество статей, посвященных XP. Этот проект неоднократно упоминается в различных источниках как пример использования этой методики [6,7,8]. Приведенные ниже данные собраны на основе упомянутых статей [9], за вычетом не подтверждающихся сведений, и иллюстрируют проблемы некоторых техник XP при их применении в достаточно сложных проектах.

Проект стартовал в январе 1995 года. С марта 1996 года, после включения в него Кента Бека, он проходил с использованием XP. К этому времени он уже вышел за рамки бюджета и планов поэтапной реализации функций. Команда разработчиков была сокращена, и в течение примерно полугода после этого проект развивался довольно успешно. В августе 1998 года появился прототип, который мог обслуживать около 10000 служащих. Первоначально предполагалось, что проект завершится в середине 1999 года и результирующее ПО будет использоваться для управления выплатами 87000 служащим компании. Он был остановлен в феврале 2000 года после 4-х лет работы по XP в связи с полным несоблюдением временных рамок и бюджета. Созданное ПО ни разу не использовалось для работы с данными о более чем 10000 служащих, хотя было показано, что оно справится с данными 30000 работников компании. Человек, игравший роль включенного в команду заказчика в проекте, уволился через несколько месяцев такой работы, не выдержав нагрузки, и так и не получил адекватной замены до конца проекта.

СТРУКТУРНОЕ ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Основы структурного тестирования программного обеспечения

Основные понятия и принципы тестирования ПО

Тестирование — процесс выполнения программы с целью обнаружения ошибок. Шаги процесса задаются тестами.

Каждый тест определяет:

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

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

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

Целью проектирования тестовых вариантов является систематическое обнаружение различных классов ошибок при минимальных затратах времени и стоимости.

Тестирование обеспечивает:

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

Тестирование не может показать отсутствия дефектов (оно может показывать только присутствие дефектов)

Рассмотрим информационные потоки процесса тестирования. Они показаны на рис.1.

Рис. 1. Информационные потоки процесса тестирования

На входе процесса тестирования три потока:

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

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

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

качество и надежность ПО удовлетворительны;
тесты не способны обнаруживать серьезные ошибки.

В конечном счете, если тесты не обнаруживают ошибок, появляется сомнение в том, что тестовые варианты достаточно продуманы и что в ПО нет скрытых ошибок. Такие ошибки будут, в конечном итоге, обнаруживаться пользователями и корректироваться разработчиком на этапе сопровождения (когда стоимость исправления возрастает в 60-100 раз по сравнению с этапом разработки).

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

Существуют 2 принципа тестирования программы:

функциональное тестирование (тестирование «черного ящика»);
структурное тестирование (тестирование «белого ящика»).

Тестирование методом «белого ящика» и его использование в тестировании базового пути, условий, циклов

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

Известны: функции программы.

Исследуется: работа каждой функции на всей области определения.

Как показано на рис.2, основное место приложения тестов «черного ящика» — интерфейс ПО.

Эти тесты демонстрируют:

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

При тестировании «черного ящика» рассматриваются системные характеристики программ, игнорируется их внутренняя логическая структура. Исчерпывающее тестирование, как правило, невозможно. Например, если в программе 10 входных величин и каждая принимает по 10 значений, то потребуется 10¹⁰ тестовых вариантов. Отметим также, что тестирование «черного ящика» не реагирует на многие особенности программных ошибок.

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

Известна: внутренняя структура программы.

Исследуются: внутренние элементы программы и связи между ними (рис. 3).

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

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

Особенности тестирования «белого ящика»

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

В этом случае формируются тестовые варианты, в которых:

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

Недостатки тестирования «белого ящика»:

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

При п = 5 и k = 20 количество маршрутов т = 10¹⁴. Примем, что на разработку, выполнение и оценку теста по одному маршруту расходуется 1 мс. Тогда при работе 24 часа в сутки 365 дней в году на тестирование уйдет 3170 лет.

2. Исчерпывающее тестирование маршрутов не гарантирует соответствия программы исходным требованиям к ней.

3. В программе могут быть пропущены некоторые маршруты.

4. Нельзя обнаружить ошибки, появление которых зависит от обрабатываемых данных (это ошибки, обусловленные выражениями типа if abs (a-b) < eps...,

if (a+b+c)/3=a...).

Достоинства тестирования «белого ящика» связаны с тем, что принцип «белого ящика» позволяет учесть особенности программных ошибок:

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

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

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

СПОСОБ ТЕСТИРОВАНИЯ БАЗОВОГО ПУТИ

Тестирование базового пути — это способ, который основан на принципе «белого ящика». Автор этого способа — Том МакКейб (1976) [49].

Способ тестирования базового пути дает возможность:

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

Тестовые варианты разрабатываются для проверки базового множества путей (маршрутов) в программе. Они гарантируют однократное выполнение каждого опера тора программы при тестировании.

Потоковый граф

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

Граф строится отображением управляющей структуры программы. В ходе отображения закрывающие скобки условных операторов и операторов циклов (end if; end loop) рассматриваются как отдельные (фиктивные) опера
торы.
Узлы (вершины) потокового графа соответствуют линейным участкам программы, включают один или несколько операторов программы.
Дуги потокового графа отображают поток управления в программе (передачи управления между операторами). Дуга — это ориентированное ребро.
Различают операторные и предикатные узлы. Из операторного узла выходит одна дуга, а из предикатного — две дуги.
Предикатные узлы соответствуют простым условиям в программе. Составное условие программы отображается в несколько предикатных узлов. Составным называют условие, в котором используется одна или несколько булевых операций (OR, AND).

Например, фрагмент программы

If a OR b

then x

else у end If;

вместо прямого отображения в потоковый граф вида, показанного на рис. 4, отображается в преобразованный потоковый граф (рис..5).

рис.4. Рис. 5. Преобразованный потоковый граф.
Замкнутые области, образованные дугами и узлами, называют регионами.

Окружающая граф среда рассматривается как дополнительный регион. Например, показанный здесь граф имеет три региона — Rl, R2, R3,

Пример 1. Рассмотрим процедуру сжатия:

процедура сжатие

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

читать запись;
если запись пуста

то удалить запись;
иначе если поле а >= поля b

то удалить b;
иначе удалить а;
7а конец если;

7а конец если; 7Ь конец выполнять;

8 конец сжатие;

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

Она отображается в потоковый граф, представленный на рис. 6. Видим, что этот потоковый граф имеет четыре региона.

Цикломатическая сложность

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

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

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

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

Перечислим независимые пути для потокового графа из примера 1:

Путь1: 1-8.

Путь 2: 1-2-3-7а-7b-1-8.

ПутьЗ: 1-2-4-5-7а-7b-1-8.

Путь 4: 1-2-4-6-7а-7b-1-8.

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

1. Тесты, обеспечивающие его проверку, гарантируют:

однократное выполнение каждого оператора;
выполнение каждого условия по True-ветви и по False-ветви;

2) мощность базового множества равна цикломатической сложности потокового графа.

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

Цикломатическая сложность вычисляется одним из трех способов:

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

V(G)=E-N+2, где Е — количество дуг, N — количество узлов потокового графа;

3) цикломатическая сложность формируется по выражению V(G) =p + 1, где р — количество предикатных узлов в потоковом графе G.

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

потоковый граф имеет 4 региона;
V(G) - 11 дуг - 9 узлов + 2 = 4;
V(G) - 3 предикатных узла +1=4.

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

Шаги способа тестирования базового пути

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

Процедура сред:

1 i := 1:

1 введено :=0;

1 колич := 0;

1 сум := 0;

вып пока 2- вел( i ) <> stop и введено <= 500 -3

4 ведено:= веденo_+_ 1;

если 5 вел (i)>=мин и вел( i ) <= макс 6

7 то колич :=колич+ 1; 7 сум := сум + вел( i );

8 конец если;

8 i := i + 1;

9 конец вып;

10 если колич > О

11 то сред := сум / колич;

12 иначе сред := stop;

13 конец если;

13 конец сред;

Заметим, что процедура содержит составные условия (в заголовке цикла и условном операторе).

Шаг 1. На основе текста программы формируется потоковый граф:

нумеруются операторы текста (номера операторов показаны в тексте процедуры);
производится отображение пронумерованного текста программы в узлы и вершины потокового графа (рис. 7).

Рис. 7. Потоковый граф процедуры вычисления среднего значения

Шаг 2. Определяется цикломатическая сложность потокового графа — по каждой из трех формул:

V(G) = 6 регионов;
V(G) = 17 дуг - 13 узлов + 2 = 6;
V(G) = 5 предикатных узлов + 1 = 6.

Шаг 3. Определяется базовое множество независимых линейных путей:

Путь 1: 1-2-10-11-13; /вел=stор, колич>0.

Путь 2: 1-2-10-12-13; /вел=stop, колич=0.

Путь 3: 1-2-3-10-11-13; /попытка обработки 501-й величины.

Путь 4: 1-2-3-4-5-8-9-2-... /вел<мин.

Путь 5: 1-2-3-4-5-6-8-9-2-... /вел>макс.

Путь 6: 1-2-3-4-5-6-7-8-9-2-... /режим нормальной обработки.
Для удобства дальнейшего анализа по каждому пути указаны условия запуска. Точки в конце путей 4, 5, 6 указывают, что допускается любое продолжение через остаток управляющей структуры графа.

Шаг 4. Подготавливаются тестовые варианты, инициирующие выполнение каждого пути.

Каждый тестовый вариант формируется в следующем виде: Исходные данные (ИД): Ожидаемые результаты (ОЖ.РЕЗ.):

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

Определим тестовые варианты, удовлетворяющие выявленному множеству независимых путей.

Тестовый вариант для пути 1 ТВ1:

ИД: вел(k) = допустимое значение, где k < i; вел(i) = stop, где 2 < i < 500.

ОЖ.РЕЗ.: корректное усреднение основывается на kвеличинах и правильном подсчете.

Путь не может тестироваться самостоятельно, а должен тестироваться как часть путей 4, 5, 6 (трудности проверки 11 -го оператора).

(Тестовый вариант для пути 2 ТВ2:

ИД:вел(1)=stор.

ОЖ.РЕЗ.: сред=stор, другие величины имеют начальные значения. Тестовый вариант для пути 3 ТВЗ:

ИД: попытка обработки 501-й величины, первые 500 величин должны быть правильными.

ОЖ.РЕЗ:. корректное усреднение основывается на kвеличинах и правильном подсчете.

Тестовый вариант для пути 4 ТВ4: ИД:вел(i)=допустимое значение, где i< 500; вел(&) < мин, где k < i.

ОЖ.РЕЗ.: корректное усреднение основывается на kвеличинах и правильном подсчете.

Тестовый вариант для пути 5 ТВ5:

ИД: вел(i)=допустимое значение, где i< 500; вел(£) > макс, где k < i.

ОЖ.РЕЗ.: корректное усреднение основывается на п величинах и правильном подсчете.

Тестовый вариант для пути 6 ТВ6:

ИД.вел(i)=допустимое значение, где i < 500.

ОЖ.РЕЗ.: корректное усреднение основывается на п величинах и правильном подсчете.

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

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

Способы тестирования условий

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

Рассмотрим используемую здесь терминологию.

Простое условие — булева переменная или выражение отношения.

Выражение отношения имеет вид

Е1 «оператор отношения> Е2,

где El, E2 — арифметические выражения, а в качестве оператора отношения используется один из следующих операторов: <, >, =, *, <, >.

Составное условие состоит из нескольких простых условий, булевых операторов и круглых скобок. Будем применять булевы операторы OR, AND (&), NOT. Условия, не содержащие выражений отношения, называют булевыми выражениями.

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

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

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

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

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

Существует несколько методик тестирования условий.

Простейшая методика — тестирование ветвей Здесь для составного условия С проверяется:

каждое простое условие (входящее в него); Тгие-ветвь; False-ветвь.

Другая методика — тестирование области определения. В ней для выражения отношения требуется генерация 3-4 тестов. Выражение вида

Е1 «оператор отношения> Е2

проверяется тремя тестами, которые формируют значение Е1 большим, чем Е2, равным Е2 и меньшим, чем Е2.

Если оператор отношения неправилен, а Е1 и Е2 корректны, то эти три теста гарантируют обнаружение ошибки оператора отношения.

Для определения ошибок в Е1 и Е2 тест должен сформировать значение Е1 большим или меньшим, чем Е2, причем обеспечить как можно меньшую разницу между этими значениями.

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

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

ТЕСТИРОВАНИЕ ВЕТВЕЙ И ОПЕРАТОРОВ ОТНОШЕНИЙ

Способ тестирования ветвей и операторов отношений (автор К. Таи, 1989) обнаруживает ошибки ветвления и операторов отношения в условии, для которого выполняются следующие ограничения [72]:

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

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

ОУ_с =(d₁,d₂,...d_n),

где di — ограничение на результат i-ro простого условия. Ограничение на результат фиксирует возможные значения аргумента (перемен ной) простого условия (если он один) или соотношения между значениями аргументов (если их несколько).

Если i-e простое условие является булевой переменной, то его ограничение на результат состоит из двух значений и имеет вид

d_i=( true, false).

Если j-е простое условие является выражением отношения, то его ограничение на результат состоит из трех значений и имеет следующий вид:

dj=(>,<,=).

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

На основе ограничения условия ОУ создается ограничивающее множество ОМ, элементы которого являются сочетаниями всех возможных значений d₁_td₂, d₃, ..., d_n.

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

b&(х>у)&а.

Условие принимает истинное значение, если все простые условия истинны. В тер минах значений простых условий это соответствует записи

(true, true, true),

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

(true, >, true).

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

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

Пример 1. В качестве примера рассмотрим два типовых составных условия:

С_& = а & b, С_or=а orb, где а и b — булевы переменные. Соответствующие ограничения условий принимают вид

OY_& = (d₁, d₂ ) , OY_or= (d₁, d₂ )

где d₁ = d₂= (true, false).

Ограничивающие множества удобно строить с помощью таблицы истинности (табл. 6.1).

Таблица 1. Таблица истинности логических операций

Вариант	а	b	a&b	a or b
1	false	false	false	false
2	false	true	false	true
3	true	false	false	true
4	true	true	true	true

Видим, что таблица задает в ОМ четыре элемента (и соответственно, четыре тестовых варианта). Зададим вопрос — каковы возможности минимизации? Можно ли уменьшить количество элементов в ОМ?

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

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

для условия типа И (а & b) варианты 2 и 3 поглощают вариант 1. Поэтому ограничивающее множество имеет вид:

ОМ_& = {(false, true), (true, false), (true, true)};

для условия типа ИЛИ (a or b) варианты 2 и 3 поглощают вариант 4. Поэтому ограничивающее множество имеет вид:

ОМor = {(false, false), (false, true), (true, false)}.

Рассмотрим шаги способа тестирования ветвей и операторов отношений.

ДЛЯ каждого условия в программе выполняются следующие действия:

строится ограничение условий ОУ;
выявляются ограничения результата по каждому простому условию;
строится ограничивающее множество ОМ. Построение выполняется путем подстановки в константные формулы ОМ_& или ОМ_ОГ выявленных ограничений результата;
Для каждого элемента ОМ разрабатывается тестовый вариант.

Примep 2. Рассмотрим составное условие С₁вида:

B₁& (E₁=E₂)

Где В₁ булево выражение, Е₁,Е₂ — арифметические выражения.

Ограничение составного условия имеет вид

OY_c = (d₁, d₂ )

где ограничения простых условий равны

d₁ = (true, false), d₂ = (=, <, >) .

Проводя аналогию между С₁ и С_&(разница лишь в том, что в С₁ второе простое условие — это выражение отношения), мы можем построить ограничивающее множество для С, модификацией

ОМ_& - {(false, true), (true, false), (true, true)}.

Заметим, что true для (E_l* E₂) означает «, a false для (E₁ - E₂) означает или <, или >. Заменяя (true, true) и (false, true), ограничениями (true, -) и (false, -) соответственно, a (true, false) — ограничениями (true, <) и (true, >), получаем ограничивающее множество для С₁,

OM_C1={(false,=),(true,<),(true,>),(true,=)}.

Покрытие этого множества гарантирует обнаружение ошибок булевых операторов и операторов отношения в С₁.

Пример 3. Рассмотрим составное условие С₂ вида

(E₃ >E₄)&(E₁ =E₂),

где E₁, E₂, E₃, E₄ — арифметические выражения.

Проводя аналогию между С₂ и С, (разница лишь в том, что в С₂ первое простое условие — это выражение отношения), мы можем построить ограничивающее множество для С₂модификацией ОМ_С:

ОМ_С2 = {(=, =), (<, =), (>, <), (>, >), (>, =)}.

Покрытие этого ограничивающего множества гарантирует обнаружение ошибок операторов отношения в С₂.

Способ тестирования потоков данных

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

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

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

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

в вершине 1 определяются значения переменных а, b
значение переменной а используется в вершине 4;
значение переменной bиспользуется в вершинах 3, 6;
в вершине 4 определяется значение переменной с, которая используется в вершине 6.

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

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

DEF(i) - { х | i -я вершина содержит определение х};

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

USE (i) - { х | i -я вершина использует х}.

Под определением данных понимают действия, изменяющие элемент данных, Признак определения — имя элемента стоит в левой части оператора присваивания: x:= f(…)

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

ИМЯ:= f(х)
Здесь ИМЯ - место подстановки другого имени.

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

В примере существуют следующие DU цепочки:

[a,1,4], [b,1,3],[b,1,6],[c,4,6].
Способ DU тестирования требует охвата всех DU-цепочек программы. Разработка теста проводится на основе анализа жизни всех данных программы.

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

Шаги способа DU-тестирования:

построение управляющего графа программы;
Построение информационного графа;
Формирование полного набора DU- цепочек;
Формирование полного набора отрезков путей в управляющем графе
Построение маршрутов –полных путей на управляющем грае, покрывающих набор отрезков путей управляющего графа;
Подготовка тестовых вариантов.

Тестирование циклов

Цикл — наиболее распространенная конструкция алгоритмов, реализуемых в ПО. Тестирование циклов производится по принципу« белого ящика», при проверке циклов основное внимание обращается на правильность конструкций циклов.

Различают 4 типа циклов: простые, вложенные, объединенные, неструктурированные. Типовые структуры циклов

Простые циклы

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

прогон всего цикла;
только один проход цикла;
два прохода цикла;
m проходов цикла, где т < п;
п - 1, п, п + 1 проходов цикла.

Вложенные циклы

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

Рис.6.12. Шаги тестирования вложенных циклов

Шаги тестирования.

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

Объединенные циклы

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

Неструктурированные Циклы.

Неструктурированные циклы тестированию не подлежат. Этот тип циклов должен быть переделан.

ФУНКЦИОНАЛЬНОЕ ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Функциональное тестирование программного обеспечения

1 ... 45 46 47 48 49 50 51 52 ... 62