- •Вопросы к экзамену по курсу «Программирование» для потока а-4,6,7,8,9,12-XX
- •Алгоритм и его основные свойства
- •Методы нисходящего и восходящего проектирования
- •Критерии качества программного продукта
- •С точки зрения пользователя[
- •Виды циклов в языке Паскаль. Итерационные циклы
- •Оператор выбора case
- •Способы структуризации алгоритмов
- •Классификация типов данных в Delphi. Тип Real
- •Порядковые типы. Целые типы в Delphi, тип диапазон
- •Порядковые типы. Символьный тип
- •Логический тип. Логические операторы и операции сравнения
- •Реализация
- •Доступные операции
- •Применение
- •Порядковые типы. Перечисляемый тип
- •Тип массив (статический): описание, ввод, вывод
- •Тип запись: описание, ввод, вывод. Оператор Wlith
- •Вввод / вывод записей в Паскале
- •Тип множество: описание, ввод, вывод, операции над множествами
- •Текстовый файл: описание, основные операции. Использование параметров программы для передачи программе имен файлов
- •Назначение и отличия процедур общего вида и функций
- •Описание и вызов процедур
- •Описание и вызов функций
- •Классы формальных параметров: параметры-константы, параметры-значения и параметры переменные. Ключевые слова const, var, out при описании параметров
- •Массивы и записи как формальные параметры процедур и функций
- •Имена процедур и функций как формальные параметры. Процедурный тип
- •Модули в Паскале: назначение, описание, использование. Обязательные и дополнительные разделы
- •Составление функциональных и структурных тестов на примере разработанной процедуры
- •Нисходящее и восходящее тестирование программ
- •Описание констант, переменных и пользовательских типов. Области видимости констант и переменных
- •Описание констант структурированных типов: массивов, записей и множеств
Нисходящее и восходящее тестирование программ
Восходящее тестирование.
При восходящем подходе программа собирается и тестируется снизу вверх. Только модули самого нижнего уровня (модули, не вызывающие других модулей) тестируются независимо, автономно. После того как тестирование этих модулей завершено, вызов их должен быть так же надежен, как вызов встроенной функции языка или оператор присваивания. Затем тестируются модули, непосредственно вызывающие уже проверенные. Эти модули более высокого уровня тестируются не автономно, а вместе с уже проверенными модулями более низкого уровня. Процесс повторяется до тех пор, пока не будет достигнута вершина. Здесь завершаются и тестирование модулей, и тестирование сопряжений программы. Для каждого модуля необходимо написать небольшую ведущую программу.
Нисходящее тестирование.
Нисходящее тестирование не является полной противоположностью восходящему, но в первом приближении может рассматриваться как таковое. При нисходящем подходе программа собирается и тестируется сверху вниз. Изолированно тестируется только головной модуль. После того как тестирование этого модуля завершено, с ним соединяются один за другим, модули, непосредственно вызываемые им, и тестируется полученная комбинация. Процесс повторяется до тех пор, пока не будут собраны и проверены все модули. Для имитации функций недостающих модулей программируются модули-”заглушки”, которые моделируют функции отсутствующих модулей.
Метод сэндвича.
Тестирование методом сэндвича представляет собой компромисс между восходящим и нисходящим подходами. При использовании этого метода одновременно начинают восходящее и нисходящее тестирование, собирая программу как снизу так и сверху и встречаясь в конце концов где-то в середине. Точка встречи зависит от конкретной тестируемой программы и должна быть заранее определена при изучении ее структуры. Если разработчик может представить свою систему в виде уровня прикладных модулей, затем уровня модулей обработки запросов, затем уровня примитивных функций, то он может решить применять нисходящий метод на уровне прикладных модулей, а на остальных уровнях применить восходящий метод.
В нашем случае применим метод сэндвича, поскольку перед проектированием основной программы необходимо создать комплекс интерфейсных и вспомогательных функций, которые, естественно должны быть проверены до создания основного тела программы.
Модуль-драйвер и модуль-заглушка при тестировании программ |
Для тестирования каждого модуля требуется специальный модуль-драйвер (driver module) и один или несколько модулей-заглушек (stub modules). На-пример, чтобы протестировать модуль B, сначала необходимо спроектировать тесты, а затем написать небольшую программу-драйвер, которая обеспечит передачу тестируемому модулю B входных параметров, необходимых для прогона тестов. (Для этой цели можно также воспользоваться инструмен-тальными средствами тестирования.) Драйвер должен показывать тестировщику результаты, выдаваемые модулем B. Кроме того, поскольку модуль B вызывает модуль E, управление при таком вызове должно куда-то передаваться. Это достигается за счет использования заглушки — специального модуля, которому присваивается имя "E" и который имитирует выполнение функций модуля E.После завершения модульного тестирования всех шести модулей их объединяют в единую программу. Альтернативный подход предполагает инкрементное тестирование. При таком подходе модули не тестируются изолированно друг от друга, а поочередно подключаются к постепенно наращиваемому набору уже проверенных модулей и лишь после этого подвергаются тестированию. Ввиду того, что число возможных реализаций инкрементного подхода слишком велико, пока что преждевременно рассматривать применение какой-либо конкретной методики к программе. Здесь ключевым является вопрос о том, с какого программного уровня должно начинаться тестирование: верхнего или нижнего. Но поскольку этот вопрос будет обсуждаться в следующем разделе, мы сейчас просто примем, что тестирование начинается с нижнего уровня. Первый шаг заключается в тестировании модулей E, C и F, что можно делать либо параллельно (силами трех человек), либо последовательно. Приэтом для каждого модуля придется создать драйвер; заглушки в данном случае не нужны. Следующий шаг — тестирование модулей B и D, но не изолированных, а объединенных соответственно с модулями E и F. Иными словами,чтобы протестировать модуль B, следует написать драйвер, объединяющий тесты, и протестировать пару B-E. Инкрементный процесс добавления очередного модуля к множеству или подмножеству ранее протестированных модулей продолжается до тех пор, пока не будет протестирован последний модуль (в данном случае A). Заметим, что с тем же успехом данную процедуру можно было бы выполнить и в нисходящем порядке. |
