Эквивалентное разбиение
 Скачать 5.11 Mb.
|
Тестирование модульных программ (отдельно)Кроме тестирования логики программного модуля, существует проблема тестирования комплексирующих программ, состоящих из нескольких модулей, ибо объединение протестированных модулей не всегда позволяет получать работоспособную комплексирующую программу. Наиболее распространенным приемом тестирования модульных программ является пошаговое тестирование. На практике применяют две его разновидности: восходящее тестирование; нисходящее тестирование. Области применения методов стратегии ‘черного ящика’. Обращает на себя внимание тот факт, что все методы рассматриваются на разных примерах. Это не является случайностью, так как не любой метод тестирования спецификаций может быть эффективно применен для разрабатываемой программы. Методы эквивалентного разбиения и функциональных диаграмм, как правило, применяются при разработке языковых процессоров, трансляторов и т.п. Метод граничных условий применяется при тестировании программ, осуществляющих статистическую обработку входной информации. Метод тестирования внешних спецификаций может быть применен везде, где в качестве спецификаций процессов обработки используются таблицы или деревья решений. Однако на практике можно рекомендовать сочетание таких методов, как функциональных диаграмм, таблиц решений и эквивалентного разбиения с методом граничных значений хотя бы для таких граничных условий, которые представляются достаточно явными. Например, при обработке информации из файлов такими явными граничными условиями является пустые файлы данных, файлы с пропущенными записями или с повторяющимися записями для тех спецификаций, где повторения не должно быть. 25. Основные положения метода эквивалентного разбиения. а) Каждый тест должен включать столько различных входных условий, сколько это возможно, с тем чтобы минимизировать общее число тестов. б) Необходимо пытаться разбить входную область программы на конечное число классов эквивалентности так, чтобы можно было предположить, что каждый тест, являющийся представителем некоторого класса, эквивалентен любому другому тесту этого класса. Другими словами, если один тест класса эквивалентности обнаруживает ошибку, то следует ожидать, что и все другие тесты этого класса эквивалентности будут обнаруживать эту ошибку. И наоборот, если тест не обнаруживает ошибки, то следует ожидать, что ни один тест этого класса эквивалентности не будет обнаруживать ошибки. 26. Основные положения метода граничных значений. - выбор любого элемента в классе эквивалентности в качестве представительного при анализе граничных значений осуществляется таким образом, чтобы проверить тестом каждую границу этого класса; - при разработке тестов рассматривают не только входные условия (пространство входов), но и пространство результатов, то есть выходные классы эквивалентности. 27. Пошаговое тестирование модульных программ. Достоинства и недостатки подходов.  Методика восходящего тестирования включает следующие шаги: Сначала тестируются ‘листья’ дерева структуры программы, т.е. модули Е,C,F. Поскольку это вызываемые программы, то для их тестирования программируются драйверы. В его функции входит формирование тестовых данных для отлаживаемого модуля и передача ему управления (вызов модуля). Затем аналогично тестируются модули вышележащего уровня совместно с уже оттестированными модулями нижележащего уровня. Применительно к рассматриваемому нами примеру проектируются драйверы для тестирования пар B-E и D-F. Пошаговый процесс продолжается до тех пор, пока не будет включен в процесс тестирования последний модуль. Для нашего примера это будет модуль А. Для его тестирования совместно с вызываемыми программами нижележащего уровня драйвер разрабатывать не требуется. Альтернативное нисходящее тестирование состоит из следующих действий: Тестирование начинается с вызывающего модуля программы. Для модулей нижележащего уровня (вызываемых) программируются так называемые ‘заглушки’. После проверки ‘корня’ дерева структуры комплексной программы переходят к тестированию нижележащих модулей. Причем, формализованной процедуры подключения к вызывающему модулю нижележащих вызываемых модулей не существует. Единственное ограничение, которым руководствуются при выборе очередного претендента на тестирование, заключается в том, что этот модуль должен вызываться уже оттестированным модулем вышележащего уровня. Если очередной тестируемый модуль вызывает модули еще нижележащего уровня, то аналогично пункту а) для нижележащих модулей программируются ‘заглушки’ Процесс тестирования продолжается до тех пор, пока не будет оттестирован последний модуль из ‘листьев’ дерева структуры программы. 28. Стихийное программирование. Этапы совершенствования архитектуры программ. «Стихийное» программирование - отсутствие сформулированной технологии, когда программирование было, по сути, искусством. Этап охватывает период от появления первых ЭВМ до середины 60-х гг. XX в. Основные веки этапа: двоичный код, восьмеричный код, шестнадцатиричный код, ассемблеры, макроассемблеры, алгоритмические языки, подпрограммы, пользовательские функции, процедуры, библиотеки расчетных и служебных подпрограмм. Развитие программирования шло по пути замены машинных языков ассемблерами, а затем алгоритмическими языками (РшЗгап, А^о1 и др.) и повторного использования подпрограммами, что повысило производительность труда программиста. Стихийно использовалась разработка «снизу вверх» - подход, при котором вначале проектировали и реализовывали сравнительно простые подпрограммы, а из них потом пытались построить сложную программу 29. Структурное программирование. Определение подхода, цель и принципы. Совокупность рекомендованных технологий, приемов, охватывающих выполнение всех этапов разработки ПО – структурный подход Представление задачи в виде иерархии подзадач, обеспечивающих проработку интерфейса программы. Цель: разработка программы, которой присуще определенные структуры, основанные на применение принципа структурирования программ. Принципы структурированного программ.: Каждый программный модуль (блок, функция, процедура) должен иметь 1 вход и 1 выход Рекомендовано применение 4 типа конструкции: Последователь. модулей оператора P Q P Разветвление С + Q - Цикл с предусловием С P  + - P С + - Цикл с постусловием Выбор из нескольких альтернатив  Разработка введется сверху вниз 30. Нисходящая стратегия разработки программ. Фундаментом любой технологии программирования является стратегия программирования. Разлачают различные стратегии программирования: "сверху-вниз"- нисходящая; "снизу-вверх"- восходящая; "изнутри-наружу"; "снаружи-внутрь". Нисходящая стратегия разработки программ предполагает наличие трех составляющих: 1) нисходящая разработка; 2) структурное кодирование (программирование); 3) сквозной контроль. Нисходящая разработка - это подход к разработке программного обеспечения, при котором оно разбивается на программные модули (подпрограммы, процедуры, функции), образующие многоуровневую структуру. Структурное кодирование – это метод кодирования (программирования), предусматривающий создание понятных, простых и удобочитаемых программных модулей на требуемом языке программирования. Сквозной контроль- это проверка программного комплекса, выполняемая на основе изучения его группой специалистов. На протяжении всего времени существования программного комплекса может осуществляться несколько проверок, охватывающих все этапы его разработки. Существенные преимущества стратегии: 1. Возможность начала программирования почти одновременно и параллельно с разработкой соответствующего алгоритма. 2. Легко модифицировать программу по уровням. 3. Упрощается отладка т.к. она ведется также по уровням. 4. Выполнять разработку алгоритма можно несколькими программистами. Недостатки: 1. Т.к. могут работать одновременно несколько программистов, то может оказаться необходимость в проведении одинаковых вычислений. Разные программисты могут отдельно их программировать. 2. Сложно использовать готовые модули, разработанные ранее. 31. Принципы модульного программирования. Модуль – библиотека готовых подпрограмм. Программист может не только использовать стандартные библиотеки процедур, но и создавать свои собственные модули. Обладающая тремя основными атрибутами: 1. он выполняет одну или несколько функций; 2. модуль реализует некоторую логику (алгоритм). 3. используется в одном или нескольких контекстах. Модульность — принцип, согласно которому программное средство (программа, библиотека, web-приложение и др.) разделяется на отдельные именованные сущности, называемые модулями. Модуль характеризуют: один вход и один выход, функциональная завершенность, логическая независимость, слабые информационные связи с другими программными модулями, обозримый по размеру и сложности программный элемент. Модульное программирование – это организация программы как совокупности небольших независимых блоков (модулей), структура и поведение которых подчиняется определенным заранее правилам. ( Pascal, и C, Phyton и даже Perl.) Модульное программирование предназначено для разработки больших программ. Это самый старый по возрасту принцип программирования. Модульным он назван потому, что каждая задача для предстоящего программирования разбивается на какие-то цельные завершенные части. И программирование ведется исключительно по этим частям – написали часть номер 1, протестировали ее, написали часть номер 2, протестировали ее – потом все вместе собрали и получили программный продукт. Большим плюсом данного подхода является возможность работы над программой не одного программиста, а коллектива программистов. Каждому программисту поручается разработка некоторой самостоятельной части программы. И он в таком случае отвечает за конструирование всех необходимых процедур и данных для этих процедур. Сокрытие данных (запрет доступа к данным из-за пределов модуля) предотвращает их случайное изменение и соответственно нарушение работы программы. Для взаимодействия отдельных частей (модулей) программы коллективу программистов необходимо продумать только интерфейс (взаимодействие) сконструированных модулей в основной программе. Принципы модульного программирования программных продуктов во многом сходны с принципами нисходящего проектирования. Сначала определяются состав и подчиненность функций, а затем – набор программных модулей, реализующих эти функции. Однотипные функции реализуются одними и теми же модулями. Функция верхнего уровня обеспечивается главным модулем; он управляет выполнением нижестоящих функций, которым соответствуют подчиненные модули. При определении набора модулей, реализующих функции конкретного алгоритма, необходимо учитывать следующее: § каждый модуль вызывается на выполнение вышестоящим модулем и, закончив работу, возвращает управление вызвавшему его модулю; § принятие основных решений в алгоритме выносится на максимально "высокий" по иерархии уровень; § для использования одной и той же функции в разных местах алгоритма создается один модуль, который вызывается на выполнение по мере необходимости. В результате дальнейшей детализации алгоритма создается функционально-модульная схема алгоритма, которая является основой для программирования. 32. Основные понятия объектно-ориентированного программирования. Объектно-ориентированное программирование (ООП) позволяет разложить проблему на составные части, каждая из которых становится самостоятельным объектом. Каждый из объектов содержит свой собственный код и данные, которые относятся к этому объекту. Любая программа, написанная на языке ООП, отражает в своих данных состояние физических предметов либо абстрактных понятий – объектов программирования, для работы, с которыми она предназначена. Все данные об объекте программирования и его связях с другими объектами можно объединить в одну структурированную переменную. В первом приближении ее можно назвать объектом. С объектом связывается набор действий, иначе называемых методами. С точки зрения языка программирования набор действий или методов – это функции, получающие в качестве обязательного параметра указатель на объект и выполняющие определенные действия с данными объекта программирования. Технология ООП запрещает работать с объектом иначе, чем через методы, таким образом, внутренняя структура объекта скрыта от внешнего пользователя. Описание множества однотипных объектов называется классом. Объект – это структурированная переменная, содержащая всю информацию о некотором физическом предмете или реализуемом в программе понятии. Класс – это описание множества объектов программирования (объектов) и выполняемых над ними действий. Класс можно сравнить с чертежом, согласно которому создаются объекты. Обычно классы разрабатывают таким образом, чтобы их объекты соответствовали объектам предметной области решаемой задачи. Основные понятия объектно-ориентированного программирования Любая функция в программе представляет собой метод для объекта некоторого класса. Класс должен формироваться в программе естественным образом, как только в ней возникает необходимость описания новых объектов программирования. Каждый новый шаг в разработке алгоритма должен представлять собой разработку нового класса на основе уже существующих. Вся программа в таком виде представляет собой объект некоторого класса с единственным методом run (выполнить). Программирование «от класса к классу» включает в себя ряд новых понятий. Основными понятиями ООП являются инкапсуляция; наследование; полиморфизм. Инкапсуляция данных (от «капсула») – это механизм, который объединяет данные и код, манипулирующий с этими данными, а также защищает и то, и другое от внешнего вмешательства или неправильного использования. В ООП код и данные могут быть объединены вместе (в так называемый «черный ящик») при создании объекта. Внутри объекта коды и данные могут быть закрытыми или открытыми. Закрытые коды или данные доступны только для других частей того же самого объекта и, соответственно, недоступны для тех частей программы, которые существуют вне объекта. Открытые коды и данные, напротив, доступны для всех частей программы, в том числе и для других частей того же самого объекта. Наследование. Новый, или производный класс может быть определен на основе уже имеющегося, или базового класса. При этом новый класс сохраняет все свойства старого: данные объекта базового класса включаются в данные объекта производного, а методы базового класса могут быть вызваны для объекта производного класса, причем они будут выполняться над данными включенного в него объекта базового класса. Иначе говоря, новый класс наследует как данные старого класса, так и методы их обработки. Если объект наследует свои свойства от одного родителя, то говорят об одиночном наследовании. Если объект наследует данные и методы от нескольких базовых классов, то говорят о множественном наследовании. Полиморфизм – это свойство, которое позволяет один и тот же идентификатор (одно и то же имя) использовать для решения двух и более схожих, но технически разных задач. Целью полиморфизма, применительно к ООП, является использование одного имени для задания действий, общих для ряда классов объектов. Такой полиморфизм основывается на возможности включения в данные объекта также и информации о методах их обработки (в виде указателей на функции). Будучи доступным в некоторой точке программы, объект , даже при отсутствии полной информации о его типе, всегда может корректно вызвать свойственные ему методы. Полиморфная функция – это семейство функций с одним и тем же именем, но выполняющие различные действия в зависимости от условий вызова. 33. Достоинства и недостатки объектно-ориентированного программирования. Достоинства ООП Возможность легкой модификации (при грамотном анализе и проектировании) Возможность отката при наличии версий Более легкая расширяемость «Более естественная» декомпозиция программного обеспечения, которая существенно облегчает его разработку. Сокращение количества межмодульных вызовов и уменьшение объемов информации, передаваемой между модулями. Увеличивается показатель повторного использования кода. Недостатки ООП Требуется другая квалификация Резко увеличивается время на анализ и проектирование систем Увеличение времени выполнения Размер кода увеличивается Неэффективно с точки зрения памяти (мертвый код - тот, который не используется) Сложность распределения работ на начальном этапе Себестоимость больше 34. CASE-технологии как результат эволюционного развития инструментальных средств. CASE-средства являются результатом естественного эволюционного развития отрасли инструментальных (или технологических) средств. CASE-технологии начали развиваться с целью преодоления ограничений методологии структурного программирования. Эта методология, несмотря на формализацию в составлении программ, характеризуется все же сложностью понимания, большой трудоемкостью и стоимостью использования, трудностью внесения изменений в проектные спецификации. Однако заложенные в ней принципы позволили развивать эту методологию и повысить ее эффективность за счет автоматизации наиболее рутинных этапов. Напомню, что автоматизация рутинных работ возможна только в случае их формализации. Формализация в структурном программировании оказалась наиболее приемлемой для автоматизации. CASE обладают следующими основными достоинствами: улучшают качество создаваемого ПО за счет средств автоматического контроля, прежде всего, контроля проекта; позволяют за короткое время создавать прототип будущей системы, давая возможность на ранних этапах оценить ожидаемый результат; ускоряют процесс проектирования и разработки; позволяют разработчику больше времени уделять творческой работе по созданию ПО, освобождая его от рутинной работы; поддерживают развитие и сопровождение разработки (заметим, что этот аспект не затрагивался ни одной из рассмотренных нами технологий программирования); поддерживают технологии повторного использования компонент разработки). 35. Сравнение этапов жизненного цикла в CASE-технологиях и при традиционной разработке ПО. При использовании CASE-технологий изменяются фазы жизненного цикла ПП как показано ниже: При традиционной технологии / При CASE-технологии: 1) Анализ / Прототипирование 2) Проектирование / Проектирование спецификаций 3) Контроль проекта 4) Кодирование / Кодогенерация 5) Тестирование / Системное тестирование 6) Сопровождение / Сопровождение Необходимо отметить, что наиболее просто автоматизируемыми фазами в CASE-технологии оказались контроль проекта и кодогенерация, хотя все другие фазы ЖЦ также поддерживаются CASE-средствами. Кроме изменения содержания фаз, существенно изменилось распределение трудозатрат по фазам Как Вы помните, модель ЖЦ ПО определяет порядок выполнения этапов, а также критерии перехода от этапа к этапу. Традиционная модель ЖЦ ПО строится по каскадному принципу (переход на следующий этап происходит после окончания работ по предыдущему этапу) или по поэтапному принципу с промежуточным контролем (с циклами обратной связи между этапами, что предполагает корректировки в процессе проектирования, но растягивает все этапы на весь период разработки). 36. Спиральная модель жизненного цикла программных продуктов. Коротко спиральную модель можно описать как повторяющуюся последовательность циклов разработки с непрерывным контролем рисков. Спиральная модель состоит из четырех главных повторяющихся стадий. В ходе процесса разработки проект несколько раз проходит через все эти фазы. Каждая такая итерация называется спиралью. Четыре главные фазы это: 1. Определение целей, альтернатив, ограничений, или фаза планирования. С этой стадии начинается работа над проектом. Команда разработчиков формулирует цели проекта, основные требования (такие как, например, Business Requirement Specifications, или BRS, System Requirement Specifications, или SRS), возможный дизайн и т.д. На последующих спиралях требования формируются согласно отзывам, полученным от заказчика. Именно поэтому постоянная коммуникация между заказчиком и командой крайне важна. 2. Анализ, определение и разрешение рисков является одной из самых значимых стадий разработки. В данном контексте, риски — это возможные события и состояния проекта, препятствующие достижению командой разработчиков поставленных целей. Существует довольно обширный диапазон возможных рисков, от тривиальных и легко преодолимых, до крайне серьезных. Главной задачей для команды разработчиков является выявление всех возможных рисков и присвоение им определенного уровня приоритета на основе их значимости. Следующим шагом является разработка возможных стратегий преодоления этих рисков. В итоге этих действий возможны изменения в последующих стадиях разработки. В качестве результата работы на этом этапе создается прототип. 3. Фаза разработки. На этом этапе происходит разработка и последующее тестирование продукта. Во время первой итерации, когда общие требования еще не так четко сформулированы, разрабатывается так называемый концепция будущего продукта (Proof Of Concept), которая необходима для получения отзыва заказчика. На последующих витках спирали рабочие версии продукта, или билды (builds), отправляются заказчику. Это позволяет получить более детальный отзыв и четче сформулировать требования. 4. Планирование следующей фазы. На этом этапе вся полученная информация используется для планирования дальнейших этапов разработки. Спиральную модель часто называют метамоделью, поскольку в ней используются два подхода: каскадная модель и модель прототипирования. Но крайне важно понимать, что спиральная модель не является простой последовательностью этапов разработки, следующих каскадной модели. На самом деле, спиральная модель является довольно гибкой. Стоит помнить, что схема, приведенная выше содержит определенные упрощения. Может показаться, что все стадии следуют одной спиральной последовательности. Но реальный жизненный цикл ПО более гибкий, чем это изображено на схеме. Существует даже возможность вернуться к предыдущим фазам в случае необходимости пересмотра принятых решений. 37. Дайте определение модели жизненного цикла ПП. Приведите каскадную и спиральную модели ЖЦ и дайте краткие пояснения. Модель ЖЦПП - структура определяющая последовательность осуществления процессов действий и задач, выполняемых на протяжении ЖЦ, а также взаимодействия между этими процессами. Каскадная модель ЖЦПП  задержка результата ошибки выявляются в конце сложность управления процессом высокий уровень риска |