Программа сложной структуры с использованием меню

МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ГОРНЫЙУНИВЕРСИТЕТ кафедра вм Курсовик Программа сложной структурыс использованием меню ВЫПОЛНИЛ ПикулинЕ. Г. принял Солодовников А. Д. мОСКВА 1996 год ОГЛАВЛЕНИЕ. 1. ВИДЫКОНТРОЛЯ ПРОГРАММ 2.ЦЕЛИ, ПРИНЦИПЫ И ЭТАПЫ ТЕСТИРОВАНИЯ 3.СТРУКТУРНОЕ ТЕСТИРОВАНИЕ 4.СОВМЕСТНОЕ ТЕСТИРОВАНИЕ МОДУЛЕЙ 5.ФУНКЦИОНАЛЬНОЕ ТЕСТИРОВАНИЕ 6.ТЕСТИРОВАНИЕ ПРОГРАММНОГО КОМПЛЕКСА В ЦЕЛОМ 7.ОТЛАДКА ПРОГРАММ ВИДЫ КОНТРОЛЯ ПРОГРАММПрограммный комплекс - это совокупность программных модулей,предназначенных для решения одной задачи и составляющих одно целое.

Основнымиразновидностями контроля программного обеспечения являются визуальный, статический и динамический. Визуальныйконтроль - это проверка программ за столом , без использования компьютера.Напервом этапе визуального контроля осуществляется чтение программы, причем особое внимание уделяетсяследующим ее элементам комментариям и их соответствию тексту программы условиям в операторах условного выбора IF, CASE и цикла сложным логическим выражениям возможности незавершения итерационных циклов WHILE, REPEAT, LOOP . Второйэтап визуального контроля - сквозной контроль программы ее ручная прокрутка на нескольких заранее подобранных простых тестах . Распространенноемнение , что более выгодным является перекладывание большей части работы по контролюпрограммных средств на компьютере, ошибочно.

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

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

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

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

Примером подобной проверки может быть выявление втексте программы ситуаций, когда цикл образуется с помощью оператора безусловногоперехода использования оператора GOTO для перехода вверх по тексту программы . Для проведения контроля структурированности могут быть созданы специальные инструментальныесредства, а при их отсутствии эта форма статического контроля может совмещатьсяс визуальным контролем .Третья форма статического контроля - контроль правдоподобия программы, тоесть выявление в ее тексте конструкций, которые хотя и синтаксически корректны,но скорее всего содержат ошибку или свидетельствуют о ней. Основные неправдоподобныеситуации - использование в программе неинициализированных переменных то есть переменных,не получивших начального значения - наличие в программе описаний элементов, переменных, процедур, меток, файлов, в дальнейшем не используемых в ее тексте - наличие в тексте программы фрагментов, никогда не выполняющихся - наличие в тексте программы переменных, ни разу не используемых для чтенияпосле присваивая им значений - наличие в тексте программы заведомо бесконечных циклов Даже если присутствие в тексте программы неправдоподобныхконструкций не приводит к ее неправильной работе, исправление этого фрагмента повыситясность и эффективность программы, т. е. благотворно скажется на ее качестве.Для возможности проведения контроля правдоподобия в полномобъеме также должны быть созданы специальные инструментальные средства, хотя рядвозможностей по контролю правдоподобия имеется в существующих отладочных и обычных компиляторах. 4Следуетотметить, что создание инструментальных средств контроля структурированности и правдоподобияпрограмм может быть существенно упрощенопри применении следующих принципов 1 проведение этих дополнительныхформ статического контроля после завершения компиляции и только для синтаксическикорректных программ 2 максимальное использование результатовкомпиляции программы и, в частности, информации, включаемой в листинг компилятора 3 вместо полного синтаксическогоразбора текста проверяемой программы построение для нее списка идентификаторов исписка операторов с указанием всех их необходимых признаков.Приотсутствии инструментальных средств контроля правдоподобия эта фаза статическогоконтроля также может объединяться с визуальным контролем.Четвертойформой статического контроля программ является их верификация, то есть аналитическоедоказательство их корректности.Винтуитивном смысле под корректностью понимают свойства программы, свидетельствующиеоб отсутствии в ней ошибок, допущенных разработчиком на различных этапах проектирования спецификации, проектирование алгоритма и структур данных, кодирование . Корректностьсамой программы по отношению к целям, поставленным перед ее разработкой то естьэто относительное свойство . Отличие понятия корректности и надежности программв следующем надежность характеризует как программу,так и ее окружение качество аппаратуры, квалификацию пользователя и т.п. говоря о надежности программы, обычнодопускают определенную, хотя и малую, долю ошибок в ней и оценивают вероятностьих появления.

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

В зависимости от выполнения или невыполнения каждого издвух названных свойств программы различают шесть задач анализа корректности 1 доказательство частичной корректности 2 доказательство частичной некорректности 3 доказательство завершения программы 4 доказательство незавершения программы 5 доказательство тотальной полной корректности то есть одновременное решение первой и третьей задач 6 доказательство некорректности решение второй или четвертой задачи . Методы доказательствачастичной корректности программ как правило опираются на аксиоматический подходк формализации семантики языков программирования.

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

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

Метод состоит из трех этапов.Первый этап - получение аннотированной программы.

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

ЦЕЛИ , ПРИНЦИПЫ И ЭТАПЫ ТЕСТИРОВАНИЯ . Каждому программистуизвестно, сколько времени и сил уходит на отладку и тестирование программ.

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

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

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

Такое определениецели стимулирует поиск ошибок в программах.

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

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

Определение Г. Майерса указывает на объективную трудностьтестирования это деструктивный т.е. обратный созидательному процесс.

Посколькупрограммирование - процесс конструктивный, ясно, что большинству разработчиков программныхсредств сложно переключиться при тестированиисозданной ими продукции. 7У Майерса сформулированытакже основные принципы организации тестирования 1 необходимой частью каждого тестадолжно являться описание ожидаемых результатов работы программы, чтобы можно былобыстро выяснить наличие или отсутствие ошибки в ней 2 следует по возможности избегать тестирования программы ее автором, т.к. кроме уже указанной объективной сложноститестирования для программистов здесь присутствует и тот фактор, что обнаружениенедостатков в своей деятельности противоречит человеческой психологии однако отладкапрограммы эффективнее всего выполняется именно автором программы 3 по тем же соображениям организация - разработчик программного обеспечения не должна единолично его тестировать должны существовать организации, специализирующиеся на тестированиипрограммных средств 4 должны являться правилом доскональноеизучение результатов каждого теста, чтобы не пропустить малозаметную на поверхностныйвзгляд ошибку в программе 5 необходимо тщательно подбирать тест не толькодля правильных предусмотренных входных данных, но и для неправильных непредусмотренных 6 при анализе результатов кождоготеста необходимо проверять, не делает ли программа того, что она не должна делать 7 следует сохранять использованныетесты для повышения эффективности повторного тестирования программы после ее модификацииили установки у заказчика 8 тестирования не должнопланироваться исходя из предположения, что в программе не будут обнаружены ошибки в частности, следует выделять для тестирования достаточные временные и материальныересурсы 9 следует учитывать такназываемый принцип скопления ошибок вероятность наличия не обнаруженных ошибокв некоторой части программы прямо пропорциональна числу ошибок, уже обнаруженных в этой части 10 следует всегдапомнить , что тестирование - творческий процесс, а не относиться к нему как к рутинномузанятию.Существует два основныхвида тестирования функциональное и структурное.

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

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

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

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

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

Рассмотримподробнее основные этапы тестирования программных комплексов.В тестированиемногомодульных программных комплексов можно выделить четыре этапа 1 тестирование отдельных модулей 2 совместное тестирование модулей 3 тестирование функций программного комплекса т.е. поиск различий между разработанной программой и ее внешней спецификацией 4 тестирование всего комплекса в целом т.е. поиск несоответствия созданного программного продукта сформулированнымранее целям проектирования, отраженным обычно в техническом задании .На первых двух этапахиспользуются прежде всего методы структурного тестирования, т.к. на последующих этапах тестирования эти методыиспользовать сложнее из-за больших размеров проверяемого программного обеспечения последующие этапы тестированияориентированы на обнаружение ошибок различного типа, которые не обязательно связаныс логикой программы.При тестированиикак отдельных модулей, так и их комплексов должны быть решены две задачи 1 построение эффективногомножества тестов 2 выбор способа комбинирования сборки модулей при создании трестируемого варианта программы . СТРУКТУРНОЕ ТЕСТИРОВАНИЕ . Посколькуисчерпывающее структурное тестирование невозможно, необходимо выбрать такие критерииего полноты, которые допускали бы их простую проверку и облегчали бы целенаправленныйподбор тестов.Наиболееслабым из критериев полноты структурного тестирования является требование хотя быоднократного выполнения покрытия каждого оператора программы.

Более сильнымкритерием является так называемый критерий С1 каждая ветвь алгоритма каждый переход должна быть пройдена выполнена хотя бы один раз. Для большинства языков программированияпокрытие переходов обеспечивает и покрытие операторов, но , например, для программна языке ПЛ 1 дополнительно к покрытию всех ветвей требуется всех дополнительныхточек входа в процедуру задаваемых операторами ENTRY и всех ON - единиц.

Использованиекритерия покрытия условий может вызвать подбор тестов, обеспечивающих переход впрограмме, который пропускается при использовании критерия С1 например, в программена языке Паскаль, использующей конструкцию цикла WHILE х AND y DO , применение критерия покрытия условий требуетпроверки обоих вариантов выхода из цикла NOT x и NOT y . С другой стороны покрытие условий может не обеспечиватьпокрытия всех переходов.

Например, конструкция IF A AND B THEN требует по критерию покрытия условий двух тестов например, A true, B false и A false, B true , при которых может не выполнятьсяоператор, расположенный в then - ветви оператора if. Практическиединственным средством, предоставляемым современными системами программирования,является возможность определения частоты выполнения различных операторов программы ее профилизации . Но с помощью этого инструмента поддержки тестирования можно проверитьвыполнение только слабейшего из критериев полноты - покрытие всех операторов.Правда, спомощью этого же инструмента можно проверить и выполнение критерия С1. Но для этогопредварительно текст программы должен быть преобразован таким образом, чтобы всеконструкции условного выбора IF и CASE 10или SWITCH содержали ветви ELSE или DEFAULT, хотябы и пустые.

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

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

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

Известны два подходак совместному тестированию модулей пошаговое и монолитное тестирование.

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

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

А B C D E F рис.112При сравнении пошаговогои монолитного тестирования можно отметить следующие преимущества первого подхода 1 меньшая трудоемкость для примерана рис.1 при монолитном тестировании требуются 5 драйверов и 5 заглушек при пошаговомтестировании требуются или только 5 драйверов - если модули подключаются снизувверх или только 5 заглушек - если модули подключаются сверху вниз 2 более раннее обнаружениеошибок в интерфейсах между модулями их сборка начинается раньше, чем при монолитномтестировании 3 легче отладка, то есть локализацияошибок они в основном связаны с последним из подключенных модулей 4 более совершенны результатытестирования более тщательная проверка совместного использования модулей .Есть приемуществаи у монолитного тестирования 1 меньше расход машинного времени хотя из-за большей сложности отладки может потребоваться дополнительная проверкапрограммы и это приемущество будет сведено на нет 2 предоставляется больше возможностейдля организации параллельной работы на начальном этапе тестирования.В целом более целесообразнымявляется выбор пошагового тестирования.

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

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

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

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

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

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

Тогда 1 может оказаться труднымили даже невозможным построить такой тест на входе модуля J, который соотвеьствовалбы любой заданной наперед последовательности значений данных на входе модуля Н 2 не всегда окажется возможнымлегко оценить соответствие значений данных на входе модуля J требуемым тестам дляпроверки модуля Н 3 т. к. результаты выполненияпрграммы на построенном для проверки модуля Н тесте выводятся не им, а модулемI , может оказаться трудным восстановлениидейсвительных результатов работы модуля Н.Другие проблемы, которые могут возникать при нисходящемтестировании появляется соблазн совмещениянисходящего проектирования с тестированием, что, как правило, неразумно, т.к. проектирование- процесс итеративный и в нем неизбежен возврат на верхние уровни и исправлениепринятых ранее решений, что обесценивает результаты уже проведенного тестирования может возникнуть желаниеперейти к тестированию модуля следующего уровня до завершения тестирования предыдущегопо объективным причинам необходимости создания нескольких версий заглушек, использованиямодулями верхнего уровня ресурсов модулей нижних уровней . При восходящем тестировании прверка программыначмнается с терминальных модулей т.е. тех, которые не вызывают не каких другихмодулей программы . Эта стратегия во многом противоположна нисходящему тестированию в частности, преимущества становятся недостатками и наоборот .Нет проблемы выбора следующего подключаемого модуля- учитывается лишь то , чтобы он вызывал только уже протестированые модули.

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

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

Функциональноетестирование.

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

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

Этот процесс зависит от вида входного условия.

Если входноеусловие описывает область например, х lt 0.5 или количеством например, размермассива А равен 50 допустимых значений входных данных, то определяются один ПКЭ х lt 0.5 или размер А равен 50 и два НКЭ х lt -0.5 х gt 0.5 или размер Аменьше 50 размер А больше 50 .Если входноеусловие описывает дискретное множество допустимых значений входных данных например,В может равно -1, 0 или 1 , то определяются ПКЭ для каждого значения из множества в данном примере 3 и один НКЭ В lt gt -1 amp В lt gt 0 amp В lt gt 1 . Если входноеусловие описывает ситуацию ложно быть например, N gt 0 , то определяются одинПКЭ N gt 0 и один НКЭ N lt 0 .На втором этапеметода эквивалентного разбиения выделенные классы эквивалентности используются дляпостроения тестов каждому классу присваиваетсясвой номер проектируются тесты для ПКЭ таким образом,что кажлый тест покрывает как можно больше еще не покрытых ПКЭ, до тех пор, покавсе ПКЭ не будут покрыты проектируются тесты для НКЭ такимобразом, что каждый тест покрывает один и только один НКЭ, до тех пор, пока всеНКЭ не будут покрыты.Нарушение третьегоусловия приводит к тому, что некоторые тесты с недопустимыми значениями входныхданных проверяют только одну ошибку и скрывают реакцию программы на другие ошибки.Метод эквивалентногоразбиения значительно лучше случайного подбора тестов, но имеет свои недостатки.Основной из них - пропуск определенных типов высокоэффективных тестов т.е. тестов,характеризующихся большой вероятностью обнаружения ошибок . От этого недостаткаво многом свободен метод анализа граничных условий.Под граничнымиусловиями понимают ситуации, возникающие непосредственно на границе определенногов спецификации входного или выходного условия, выше или ниже ее . Метод анализаграничных условий отличается от метода эквивалентного разбиения следующим выбор любого представителя классаэквивалентности осуществляется таким образом, чтобы проверить тестом каждую границуэтого класса при построении тестоврассматриваются не только входные условия, но и выходные т.е. определенные во внешнейспецификации ограничения на значения входных данных .Общие правиламетода анализа граничных условий 1 построить тесты для границобласти допустимых значений входных данных и тесты с недопустимыми значениями, соответствующиминезначительному выходу за границы этой области например, для области -1.0 1.0 строим тесты -1.0 1.0 -1.001 1.001 2 построить тесты дляминимального и максимильного значений входных условий, определяющих дискретное множестводопустимых значений входных данных, и тесты для значений, больших или меньших этихвеличин например, если входной файл может содержать от 1 до 225 записей, то выбираютсятесты для пустого файла, содержащего 1, 255 и 256 записей 3 использовать правило1 для каждого выходного условия например, программа вычисляет ежемесячный расходчастного лица или небольшого предприятия, минимум которого 0.00 , а максимум1165.50 тогда необходимо постоить тесты, вызывающие отрицательный расход, расходы,равные 0.00 и 1165.50 , и расход, больший 1165.50 4 использовать правило2 для каждого выходного условия например, программа ищет и отображает на экранедисплея наиболее подходящие , в зависимости от входного условия, рефераты статей,но не более четырех тогда необходимо построить тесты, приводящие к отображению0, 1, 4 рефератов и попытки ошибочного отображения 5 рефератов 5 если входные и выходные данныепрограмы представляют собой упорядоченное множество последовательный файл, линейныйсписок, таблицу , то пре тестировании сосредоточить внимание на первом и последнемэлементе множества 6 попытаться найти и проверитьтестами другие граничные условия.Важность проверкиграниц выходных условий объясняется тем, что не всегда граничным значениям входныхданных соответствуют граничные значения результатов работы программ.Для иллюстрациинеобходимости анализа граничных условий приведем тривиальный пример. Пусть имеетсяпрограмма, осуществляющая ввод трех чисел интерпретирующая их как длины сторон треугольникаи выводящая сообщение о типе треугольника разносторонний , равнобедренный или равносторонний . Допустим также, что в программе содержится ошибка при проверкеусловия построения треугольника сумма длин любых двух сторон должна быть большетретьей используется операция отношения gt вместо gt . При проектировании тестовпо методу эквивалентного разбиения будутпостроены тесты для случаев возможности построения треугольника например, 3,4, 5 и невозможности его построения например, 1, 2, 4 , т.е. ошибка в программене будет обнаружена на входные данные 1, 2, 3 будет выведено сообщение разностороннийтреугольник . Но подобный тест будет получен при использовании метода анализа граничных условий.Анализ граничныхуловий - один из наиболее полезных методов проектирования тестов.

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

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

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

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

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

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

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

На рис.3 приведены базовыесимволы для записи функциональных диаграмм каждый узел функциональной диаграммыможет находиться в состоянии 1 - существует - или 0 - не существует .а Тождество а 1 gt b 1 amp а 0 gt b 0 а b б Отрицание а 1 gt b 0 amp a 0 gt b 1 a bв Дизъюнкция a 1 b 1 gt c 1 amp a 0 amp b gt 0 gt c 0 a c bг Конъюнкция a 1 amp b 1 gt c 1 amp a 0 b 0 gt c 0 a amp c b рис.3 На четвертом этапефункциональная диаграмма снабжается комментариями, которые задают ограничения накомбинации причин и следствий.

На рис.4 приведены знаки комментариев, задающих этиограничения. а Исключение одной из причин a E a 1 b 1 a 1 amp b 1 a 0 amp b 0 b б Включение хотя бы одной причины a I a 1 b 1 amp a 0 amp b 0 b в Существуетодна и только одна причина a O a 1 b 1 amp a 1 amp b 1 amp a 0 amp b 0 b г Одна причина влечет за собой лругую a R a 1 amp b 0 b д Одно следствие скрывает в себе другое a M a 1 amp b 0 amp a 1 amp b 1 b рис.4 Пятый этап - функциональнаядиаграмма преобразуется в таблицу решений выбирается следствие, которое устанавливаетсяв 1 находятся все комбинации причин с учетом ограничений ,которые устанавливаютвыбранное следствие в 1.