Суть проектирования программирование и тестирование реферат

Обновлено: 30.06.2024

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

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

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

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

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

2) проектирование программы;

3) построение модели;

4) разработка алгоритма;

5) реализация алгоритма;

6) анализ алгоритма и его сложности;

7) тестирование программы;

Кратко остановимся на каждом из этих этапов.

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

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

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

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

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

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

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

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

Методы проектирования архитектуры делятся на две группы:

1) ориентированные на обработку и

2) ориентированные на данные.

Методы, ориентированные на обработку, включают следующие общие идеи.

а) Модульное программирование. Основные концепции:

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

б) Функциональная декомпозиция.

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

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

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

г) Технология структурного анализа проекта.

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

Методы проектирования, основанные на использовании структур данных, описаны ниже.

а) Методология Джексона.

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

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

б) Методология Уорнера.

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

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

в) Метод иерархических диаграмм.

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

Алгоритм проектирования по этому методу заключается в следующих шагах:

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

г) Объектно-ориентированная методология проектирования.

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

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

· создание объектов и их атрибутов;

· определение операций над объектами;

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

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

При дедуктивном подходе (рис.3.3) рассматривается частный случай общеизвестной фундаментальной модели. Здесь при заданных предположениях известная модель приспосабливается к условиям моделируемого объекта. Например, можно построить модель свободно падающего тела на основе известного закона Ньютона та = mg - F_coпp и в качестве допустимого приближения принять модель равноускоренного движения для малого промежутка времени.

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

Технология построения модели при индуктивном способе:

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

4) построение модели.

На этапе реализации алгоритма происходит конструирование и реализация алгоритма, включая:

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

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

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

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

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

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

Особое внимание необходимо уделять тестам на граничных условиях. Граничные условия - это ситуации, возникающие непосредственно на, выше или ниже границ входных и выходных классов эквивалентности (т.е. вблизи границ эквивалентных разбиений). В частности, примерами классов эквивалентных тестов для алгоритма решения квадратного уравнения могут служить следующие классы: множество действительных, отличных от нуля, чисел а, b, с, таких, что b∙b - 4∙а∙с b и с не равны нулю; b = 0, а и с не равны нулю, и т.п.

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

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

Есть золотое правило программистов - оформляй свои программы в том виде, в каком бы ты хотел видеть программы, написанные другими. К каждому конечному программному продукту необходимо документированное сопровождение в виде помощи ( help ), файлового текста ( readme . txt ).

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

Зачем нужно проектирование программного обеспечения

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

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

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

Подготовительный этап

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

При подготовке к проектированию решаются организационные вопросы:

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

Этапы и результаты проектирования

Что делаем (описание продукта, функционала, пользователей)?
Как делаем (архитектура)?
Как проверить, что цель достигнута (тестирование, критерии оценки)?

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

Требования к техническому заданию на разработку программного обеспечения

Минимально достаточное ТЗ должно:

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

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

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

Примеры техзаданий на разработку ПО

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

ТЗ на программное обеспечение Protector

Сценарии использования образовательной системы

Объект ТЗ: создание образовательной системы

ТЗ на разработку ПО SMPP-шлюз

Объект ТЗ: разработка программного обеспечения SMPP-шлюза
Заказчик: IMT

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

Проектирование — для больших парней

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

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

Содержание

Прикрепленные файлы: 1 файл

Программная инженерия.docx

ФЕДЕРАЛЬНОЕ АГЕНСТВО ПО ОБРАЗОВАНИЮ

Московский государственный университет экономики, статистики и информатики

Кафедра Информационных технологий,

Естественнонаучных и математических дисциплин

Выполнил: студент 1 курса

Кузьмин Валентин Валентинович

Проверила: Александрова Вера Алексеевна

Список использованной литературы…………………………………….19

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

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

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

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

Тестирование программного обеспечения (software testing) – это процесс анализа или эксплуатации программного обеспечения с целью выявления дефектов.

Слово процесс (process) используется для того, чтобы подчеркнуть, что тестирование это плановая, упорядоченная деятельность.

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

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

Модульное тестирование (юнит–тестирование). Данный вид тестирования позволяет проверить на корректность отдельные модули исходного кода программы.

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

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

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

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

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

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

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

Министерство образования Российской Федерации

Государственное образовательное учреждение
среднего профессионального образования

Филиал г. Мурманск

Рассмотрено и одобрено цикловой комиссией программирования и ИТ

для курсового проекта студенту колледжа

Тимониной Зои Викторовне

Задание: Составить программу и оттестировать ее по методу эквивалентных разбиений (указать возможные ошибки). Тесты составить только для неправильных классов эквивалентности.

Пусть имеется несколько функций одного аргумента Х. Для каждой из них требуется распечатать таблицу значений на некотором отрезке. Отрезок [a,b] для каждой функции свой, также для каждой задан шаг изменения аргумента dX.

F1(X) = X*sin(X) a=0.0 b=1.0 dX=0.1

F2(X) = X*cos(X) a=0.5 b=2.1 dX=0.2

F3(X) = a=2.0 b=4.75 dX=0.25

Дата выдачи задания___________________

Дата сдачи проекта____________________

Общая часть

Теоретические основы тестирования. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Обоснование выбора комплекса технических средств,

используемых для решения задачи. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Обоснование выбора комплекса программных средств,

используемых для решения задачи. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Специальная часть

Постановка задачи. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

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

Спецификация программы, спецификация переменных. . . . . . . . . . . . . . . . . . . . . .30

Алгоритм программы и его описание. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

Описание программы. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Тестирование программы. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Контрольный пример. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

Инструкция пользователю. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Приложение 1

Приложение 2

Список используемой литературы

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

1.1 Теоретические основы тестирования

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

Изучение методологий проектирования тестов дает ответ на этот вопрос.

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

Методологии, обсуждаемые в настоящей главе, представлены ниже.

Черный ящик Белый ящик

Эквивалентное разбиение Покрытие операторов

Анализ граничных значений Покрытие решений

Применение функциональных Покрытие условий

диаграмм Покрытие решений/условий

Предложение об ошибке Комбинаторное покрытие условий

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

Тестирование путем покрытия логики программы.

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

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

Эквивалентная программа, написанная на языке PL/1, имеет вид:

M: PROCEDURE (A,B,X);

IF ((A=2) | (X>1)) THEN DO;

Можно выполнить каждый оператор, записав один – единственный тест, который реализовал бы путь ace. Иными словами, если бы в точке а были установлены значения A=2, B=0 и X=3, каждый оператор выполнялся бы один раз (в действительности Х может принимать любое значение).

К сожалению, этот критерий хуже, чем кажется на первый взгляд. Например, пусть первое решение записано как или, а не как и. При тестировании по данному критерию эта ошибка не будет обнаружена. Пусть второе решение записано в программе как X > 0; эта ошибка также не будет обнаружена. Кроме того, существует путь, в котором X не изменяется (путь abd). Если здесь ошибка, то она не будет обнаружена. Таким образом, критерий покрытия операторов является настолько слабым, что его обычно не используют.

Более сильный критерий покрытия логики программы известен как покрытие решений, или покрытие переходов. Согласно данному критерию должно быть записано достаточное число тестов, такое, что каждое решение на этих тестах примет значение истина и ложь по крайне мере один раз. Иными словами, каждое направление перехода должно быть реализовано по крайне мере один раз. Примерами операторов перехода или решений являются операторы DO (или PERFORM UNTIL в Коболе), IF, многовыходные операторы GO TO.

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

Изложенное выше предполагает только двузначные решения или переходы и должно быть модифицировано для программ, содержащих многозначные решения. Примерами таких программ являются программы на PL/1, включающие операторы SELECT (CASE) или операторы GO TO, использующие метку – переменную, программы на Фортране с арифметическими операторами IF, вычисляемыми операторами GO TO или операторами GO TO по предписанию, и программы на Коболе, содержащие операторы GO TO или операторами GO TO по предписанию, и программы на Коболе, содержащие операторы GO TO вместе с ALTER или операторы GO – TO – DEPENDING – ON. Критерием для них является выполнение каждого возможного результата всех решений по крайне мере один раз.

В программе, представленной на рисунке выше, покрытие решений может быть выполнено двумя тестами, покрывающими либо пути ace и abd, либо пути acd и abe. Если мы выбираем последнее альтернативное покрытие, то входами двух тестов являются А = 3, В = 0, Х =3 и А = 2, В = 1, Х = 1.

Покрытие решений – более сильный критерий, чем покрытие операторов, но и он имеет свои недостатки. Например, путь, где Х не изменяется (если выбрано первое альтернативное покрытие), будет проверен с вероятностью 50%. Если во втором решении существует ошибка (например, Х 1), то ошибка не будет обнаружена двумя тестами предыдущего примера.

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

DO K = 0 TO 50 WHILE (J + K 1, B = 0, A = 2 и Х > 1. Следовательно, требуется достаточное число тестов, такое, чтобы реализовать ситуации, где А > 1, A

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

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

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

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

DO I=1 TO TABSIZE WHILE (NOTFOUND); /*поиск в таблице*/

Последовательность операторов, реализующая процедуру поиска,

Аналогичный отчет, но упорядоченный по качеству;

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