Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Шпоры по ТП.doc
Скачиваний:
39
Добавлен:
11.03.2015
Размер:
655.36 Кб
Скачать

Спектр подходов к проектированию тестов.

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

между следующими двумя крайними подходами

Левый крайний подход заключается в том, что тесты проектируются только на основании изучения спецификаций ПС

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

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

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

Виды отладки:

- автономная отладка ПС- раздельное тестирование отдельных частей программы;

- комплексная отладка - тестирование ПС в целом.

Вопрос №39

Отладка программного средства. Заповеди отладки.

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

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

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

Заповедь 3. Готовьте тесты как для правильных, так и для неправильных данных.

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

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

Заповедь 6. Пропускайте заново все тесты, связанные с проверкой работы какой-либо программы ПС или ее взаимодействия с другими программами, если в нее были внесены изменения (например, в результате устранения ошибки).

Вопрос №40

Объектный подход к разработке ПС. Объекты и отношения.

Окружающий нас мир состоит из объектов и отношений между ними. Согласно В. Далю объект (предмет)  это все, что представляется чувствам (объект вещественный) или уму (объект умственный).

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

Отношение связывает некоторые объекты. Если отношение связывает n объектов, то такое отношение называется n-местным (n-арным). Множество всех объектов, которые обладают каким-то общим набором свойств, называется классом объектов.

С точки зрения разработчиков ПС следует различать следующие категории объектов (и, соответственно, их классов):

  • объекты модельного (вещественного или умственного) мира,

  • информационные модели объектов реального мира (будем называть их пользовательскими объектами),

  • объекты процесса выполнения программ,

  • объекты процесса разработки ПС (технологические объекты программирования).

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

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

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

При этом многие процессы разработки ПС приобретают специфические («объектные») черты:

  • использование системы понятий, позволяющих описывать объекты и их классы,

  • декомпозиция объектов является основным средством упрощения ПС,

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

  • предпочтение (приоритет) разработки структуры данных перед реализацией функций.

Вопрос №41

Методы разработки структуры программы.

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

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

а направленные дуги (стрелки) показывают статическую подчиненность модулей

каждый модуль может обращаться к подчиненным ему модулям

Спецификация программного модуля содержит

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

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

Функциональная спецификация модуля строится так же, как и функциональная спецификация ПС.

Метод восходящей разработки

Сначала строится модульная структура программы в виде дерева

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

Метод нисходящей разработки

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

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

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

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

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

Вопрос №42

Разработка структуры программы и модульное программирование.

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]