Курсовая: Программа сложной структуры с использованием меню - текст курсовой. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Курсовая

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

Банк рефератов / Программирование

Рубрики  Рубрики реферат банка

закрыть
Категория: Курсовая работа
Язык курсовой: Русский
Дата добавления:   
 
Файл недоступен К сожалению, файл недоступен для скачивания.
Заказать
Узнать стоимость написания уникальной курсовой работы

Узнайте стоимость написания уникальной работы

МОСКОВСКИЙ ГОСУД ?АРСТВЕННЫЙ ГОРНЫЙ УНИВЕРСИТЕТ кафедра вм Курсовик “ П рограмма сложной стру ктуры с испол ьзованием меню ” ВЫПО ?ЛНИЛ : Пикулин Е . Г. принял : Солодовников А . Д. мОСКВА 1996 год ОГЛАВЛЕНИЕ. 1. ВИДЫ КОНТРОЛЯ ПРОГРАММ 3 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 рис . 1 12 При сравне нии пошагового и монолитного тестирования можно отметить следующие пр еимущества первого подхода : 1) меньшая тру ?доемкость ( для примера на рис .1 при мо ?нолитном тестирован ии требуются 5 драйверов и 5 з аглушек ; при п ошаговом тестирован ии требуются или только 5 др айверов - если модули подключаются “ снизу вверх ? ” , - или толь ко 5 заглушек - если модули подключаются “ с верху вниз ” ) ; 2) более ранн ее обнаружение ошибок в и ?нтерфейсах между модулями ( их сборка начин ается раньше , чем при монол итном тестировании ) ; 3) легче отла дка , то есть локализация ошибок ( они в основном свя заны с послед ним из подклю ченных модулей ) ; 4) более сове ршенны результаты тестирования ( более тщательная ? проверка сов ?местного использова ния модулей ). Есть приемуществ ?а и у м ?онолитного тестиров ания : 1) меньше рас ход машинного времени ( хотя из- за большей сложности от ладки может п отребоваться дополн ительная проверка программы и это приемуще ство будет св едено на нет ) ; 2) предоставляется больше возмо жностей для о рганизации параллел ьной работы н а начальном э тапе тестирования. В целом бо ?лее целесообразным является выб ор пошагового тестирования . При ? его использо ?вании возможны две стратегии подключения модулей : нисходящая и восходящая . Нисходящее т естирование начинае тся с главног о ( или верхнег о ) модуля прог раммы , а выбор следующего п одключаемого модуля происходит и з числа модул ей , вызываемых из уже про ?тестированных . Одна из основных проблем , возн икающих при н исходящем тестирова нии , - создание заглу шек . Это тривиальная зада ?ча , т . к . как правило недостаточно , что ?бы в заглушке ? выполнялся в ?ывод соответствующе го информационного сообщенияи и возврат всег да одних и тех же значений выходны ?х данных . Другая прблема , которую необ ходимо решать при нисходящем тестировании , - форма представле ?ния тестов в программе , та к как , как правило , главный модуль получ ает входные д анные не непо средственно , а через специальны ?е модули ввод ?а , которые при ? тестировании в начале з ?аменяются заглушкам и . Для передач и в главный модул ь ра ?зных тестов н ?ужно или имет ?ь несколько р ?азных заглушек , или записать эти тесты в файл во внешней памя ти и с помощью заглушки считывать их. Поскольку после тестирования главного модуля процесс пров ерки может пр одолжаться по- раз ?ному , следует придерживатьс я следующих правил ? : а ) модули , содержащие о перации ввода- выв ?ода , должны по ?дключаться к тестированию как ? можно раньше ? ; б ) критические ( т. е . наибо лее важные ) дл я программы в целом модули также должны тестироваться в п ервую очередь. 12 Ос новные достоинства нисходящего тестирования : уже на р анней стадии тестирования есть возможность получить работающий вариант разр абатываемой програм мы ; быстро мог ут быть вы ?явлены ошибки , связанные с организацией вза ?имодействие с пользователем. Недостатки нисхо ?дящей стратегии продемонстрируются с помощью рис .2. Допустим , что на следующем шаге тестировани ?я заглушка мо ?дуля H заменяется его реальным тек стом . Тогд а 1) может оказ ?аться трудным или даже н ?евозможным построит ь такой тест на входе модуля J, который соотвеьствовал бы любой з ?аданной наперед последовательности значений данных на входе модуля Н ; 2) не всегда окажется воз можным легко оценить соответстви е значений да нных на входе модуля J требу емым тестам д ля проверки м одуля Н ; 3) т . к . результаты выпол ?нения прграммы на построенном для проверки модуля Н тесте выводятся не им , а модулем I , мож ?ет оказаться трудным восстано ?влении дейсвительны х результатов работы модуля Н. Другие проблемы , которые могу т возникать п ри нисходящем тестировании : появляется соблазн совмещен ?ия нисходящего проектирова ния с тестированием , что , как правило , неразумн ?о , т. к . прое ктирование - процесс итеративный и в нем неизбежен возвра ?т на верхние уровни и исправление прин ?ятых ранее ре ?шений , что обе ?сценивает результат ы уже проведе нного тестирования ; может возникнуть желание перейти к тестированию модуля следующег ?о уровня до завершения т естирования предыду щего по объек тивным причинам ( необходимости со ?здания нескольких версий заглу шек , использования модулями вер хнего уровня ресурсов модулей нижних у р ?овней ). При восходящем тестировании прверка программ ?ы начмнается с терминальных модулей ( т. е . тех , кото ?рые не вызыва ?ют не каких других модул ей программы ). Эта стратегия во многом противоположна н ?исходящему тестиров анию ( в частно сти , преимущества становя тся недостатками и наоборот ). Нет проблемы выбора следующег ?о подключаемого модуля - учитывает ?ся лишь то , чтобы он вызывал только уже протести рованые модули . В отличие от заглушек драйверы не должны иметь несколько версий ? , поэтому их разработка в большенст ве случаев проще ( кроме того , использование средств автомати ?зации и отлад ?ки облегчает создание как раз драйверов , а не з аглушек ). Другие достоинст ?ва восходящего тестирования : поскольку нет промежуточных модулей ( тест ируемый модуль я вляется для рабочего вар ианта программы модулем самого верхнего уро вня ), нет пробл ем , связанных с возможностью или тружностью задания тест ов ; нет возмож ности совмещения проектирования с тестированием ; нет трудно стей , вызывающих желание перейти к тестирован ию следующего модуля , не завершив проверк ?и предыдущего. Основными недост ?атком восходящего тестирования является то , что проверка всей структуры разрабатываемого программного комплекса возмож ?на только на завершающей стадии тестирования. Хотя однозначног ?о вывода о преимущества той или ин ?ой стратегии пошаговаого тест ?ирования сделать нельзя ( нужно учитывать ко нкретные характерис тики тестируемой программы ), в большинстве случаев более предпочтительным является восходя ?щее тестирование . На третьем этапе тестирован ?ия программных комплексов ( тести ?ровании функций ) ипользуются преж ?де всего мето ?ды функционального тестирования. Функционал ?ьное тестирование. Обзор ? методов прое ?ктирования тестов при функц иональеом тестир ?овании начнем с метода з ?квивалентного разби ения. Т. к . нашей целью является построения м ножества тестов , характеризующегося наивысшей вероят ?ностью обнаружения большинстыва ошибок в т ?естируемой программ е , то тест из этого м ?ножества должен : 1 ) уменьшать ( более чем на единицу ) число других тестов , которые должны быть разработанны для достижения заранее пост авленной цели “ удовлетворительного ” тестирования ; 2) покрывать собой значительную часть других возможных те стов . Друг ими слов ами : 1) каждый тес ?т должен закл ?ючать в себе проверку наи большего числа задаваемых внешн ?ей спецификацией входных усло вии ( ограничений на входные данные ) для того , чтобы минимизировать о ?бщее число не ?обходимых тестов ; 2) необходимо разбить обла сть значений входных данных на конечное число подобласте ?й ( которые буд ?ут называться классами эквивал ?ентности ), чтобы можно было полагать каждый тест , являющи йся представителем некоторого к ласса , эквивалентным люб ому др ?угрому тесту этого класса ( т. е . обнаружив ающим одни и те же ошибки ). В общем сл ?учае использование термина “ кла ?сс эквивалентности ” является зд ?есь не вполне ? точным , т. к . выделенные подобласти могут пересекаться. Проектирование т ?естов по мето ?ду эквивале нтно го разбиения проводится в два этапа : выделение по внещней сп ецификации классов эквивалентности ; построение множества тестов ?. На пе ?рвом этапе пр ?оисходит выбор из спецификации каждого вход ного условия и разбиени е его на две ? или более группы , соотв етствующие так называемым “ пра вильным ” ( ПКЭ ) и “ неправильным ” классом экв ?ивалентности ( НКЭ ), т. е . облат ям допустых д ля программы и недопустимых значений входных ? данных . Этот процесс зави сит от вида входного усл овия . Если вхо дное условие описывает область ( например , х <=0.5) или количест ?вом ( например , размер массива А равен 50) допустимых значе ?ний входных д ?анных , то опре ?деляются один ПКЭ ( х <=0.5 или размер А равен 50) и д ва НКЭ ( х < -0.5 ; х >0.5 или раз мер А меньше 50 ; ра змер А больше 50). Если входное условие описывае ?т дискретное множество допуст ?имых значений входных данных ( например , В может равно -1, 0 или 1) , то определяются ПКЭ ? для каждого значения из множества ( в данном приме ре 3) и один НКЭ ( В <>-1 & В <>0 & В <>1). Если входное условие описывае ?т ситуацию “ ложно быть ” ( например , N>0), то определяются оди ?н ПКЭ (N>0) и один НКЭ (N<=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) попытаться найти и пр ?оверить тестами другие граничные ? условия. Важность проверк ?и границ выхо ?дных условий объясняется тем , что не всегда граничным ? значениям вх ?одных данных соответству ют граничные значен ?ия результатов работы программ. Для иллюстрации необходимости анализа граничны ?х условий при ?ведем тривиальный пример . Пусть имеется прог рамма , осуществляюща я ввод трех чисел интерп ретирующая их как длины сторон треугольн ?ика и выводящ ?ая со общение о типе тре ?угольника (“ разност оронний ” , “ равнобед ренный ” или “ равносторонний ” ). Допустим также , что в программе содержитс я ошибка : при проверке усл овия построения треугольника ( сум ?ма длин любых ? двух сторон должна быть больше треть ей ) используется операция отношен ?ия >= вместо >. Пр и проектировании тестов по методу эквив алентного разбиения будут постро ены тесты для случаев возм ожности построения треугольника ( например , 3, 4, 5) и невозможности ег ?о построения ( например , 1, 2, 4), т. е . ошибка в програ мме не будет обнару жена ( на входн ые данные 1, 2, 3 бу дет выведено сообщение “ разносто ?ронний треугольник ” ). Но подобный ? тест будет получен при использовании метода анализа граничных ус ловий . Анализ граничных ? уловий - один из наиболее полезных мет одов прое ктирова ?ния тестов . Но ? он часто оказывается неэф ?фективным из- за того , что граничные услови ?я иногда едва ? уловимы , а их выявление весьма трудн о. Общим недостатко ?м двух рассмо ?тренных выше методов функцион ?ального тестировани я является то , что при их применени не исследуются исследуются возм ?ожные комбинации входных усло вий . Следует , п равда , заметить , что из- за весьма большого числа таких комбинаций , и х анализ вызы вает существенные затруднения . Но существует метод ( метод функциональных д ?иаграмм ), позволяющий ? в эт ом случае систе матическим образом выбрать высо ко эффективные тесты . Полезным побочным эфф ектом этого м етода является обнаружение непо ?лноты и проти ?воречивости во внешних специфик ?ациях. Функцион ?альная диаграмма - это текст на некотором формальном я зыке , на котор ый транслируется спецификация , составленная на естественном или полуформальн ?ом языках . Дал ?ее будет назы ?ваться причиной отдельное входно ?е условие и следствием - в ыходное условие или преобразован ?ие системы ( т. е . остаточное действие програм ?мы , вызванное определенным вхо ?дным условием или их ком ?бинацией ). Например , для программ ы обновления файла изменение в нем явля ?ется преобразование м системы , а подтверждающее это изменение сообщение - вы ходным условием. Метод функционал ?ьных диаграмм с остоит из шести основн ых этапов . На первом из них ( необязат ельном ) внешняя спецификация бол ?ьшого размера разбивается на отдельные уч астки ( например , спецификация ком ?пилятора языка программирования разбивается на участки , опре деляющие синтаксиче ский контрол ь отдельных оп ераторов языка ). На втором этапе в сп ?ецификации выделяют ся причины и следствия , а на третьем - анализируется семантическое со ?держание спецификац ии и она преобразуется в булевский гр аф , связывающий причины и следствия и называющийся фун ?кционал ьной диа граммой . На ри с .3 приведены б азовые символы для записи функциональных д ?иаграмм ( каждый узел функциональ ?ной диаграммы может находиться ? в состоянии 1 - “ существует ” - или 0 - “ не с ?уществует ” ). а ) Тождество : ( а 1 >b 1) & ( а 0 >b 0) а b б ) Отрицание : ( а 1 >b 0) & (a 0 >b 1) ~ a b в ) Дизъюнкция : (a 1 b 1 >c 1) & (a 0&b >0 >c 0) a c b г ) Конъ юнкция : (a 1&b 1 >c 1) & (a 0 b 0 >c 0) a & c b рис .3 На четвертом этапе функционал ?ьная диагр амма снабжается к омментариями , которы е задают огра ничения на ко мбинации причин и следствий . На рис .4 при ?ведены знаки комментариев , зад ?ающих эти огр ?аничения. а ) Исключение одной из причин : a E ((a 1 b 1)^~(a 1&b 1)) (a 0&b 0) b б ) Включение хотя бы одной причины : a I (a 1 b 1)&~(a 0&b 0) b в ) Существует ?одна и только ? одна причина ? : a O (a 1 b 1)&~(a 1&b 1)&~(a 0&b 0) b г ) Од на причина влеч ет за собой лругую : a R ~(a 1&b 0) b д ) Одно следствие скрыва ?ет в себе другое : a M (a 1&b 0)&(a 1&b 1) b рис .4 Пятый этап - функциональная д ?иаграмма преобразуе тся в таблицу решений : выбирается с ледствие , которое устанавливается в 1 ; находятся вс е комбинации прич ин ( с у ?четом ограничений ), которые устанавл ?ивают выбранное следствие в 1
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

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

Узнайте стоимость курсовой, диплома, реферата на заказ.

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

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2016
Рейтинг@Mail.ru