- •Специфицирование и тестирование программ
- •1 Краткие теоретические сведения
- •1.1 Внешние спецификации программного обеспечения
- •1.1.2 Спецификация функций с помощью таблиц решений
- •1.2 Стратегии тестирования
- •1.3 Метод тестирования таблиц решений
- •2 Методика выполнения курсовой работы
- •2.1 Цель работы
- •2.3 Ограничения на входные и выходные данные
- •2.2 Постановка задачи обработки информации
- •2.4 Структурирование целей разрабатываемой программы
- •2.5 Внешние спецификации функций разрабатываемой программы
- •2.6 Рекомендации по кодированию программы
- •2.7 Тестирование программы
- •2.7.1 Тестирование функции ‘проверка на корректность f2’
- •2.7.2 Тестирование функции ‘формирование строк выходной таблицы’
- •3 Оформление и содержание курсовой работы
- •Список литературы
- •Специфицирование и тестирование программ
- •Специфицирование и тестирование программ
1 Краткие теоретические сведения
1.1 Внешние спецификации программного обеспечения
1.1.1 Структурирование целей разрабаЬҐh_cа _____e______Ђ_________Д__Qq__________________fА______________________љ____________l__L____l__L___Lm______Lm______dm______dm______dm______xm______xm______xm______xm______xm______€m__^___жm__в___xm______Zp__[___Иn__^___&o______<o______<o______<o______Xp______Xp______Xp______Xp______Zp______Zp______Zp______Zp______Zp______Zp______µp__X___q__D___Zp______________________dm______Xp________‚_‘___%_<o______Xp______________________Xp______Xp______Zp______Xp______Lm______Lm______<o______________________Иn____стракции с ограничением числа элементов на каждом из уровней (обычно от 3 до 6-7). В технологии программирования эта идея была сформулирована как один из принципов структурного программирования: разработку программ рекомендуется вести сверху вниз или, иначе, по нисходящей стратегии.
Суть нисходящей стратегии в том, что цели разрабатываемого ПП структурируются по схеме: цели - подцели 1-го уровня - ... - подцели i-го уровня - ... - подцели n-уровня - функции до такой степени детализации, когда реализация подцелей последнего уровня (функций) становится очевидной.
Для примера рассмотрим функционирование банкомата при обслуживании клиента по его кредитной карте /4/. Цель верхнего уровня ‘обслужить клиента’ включает такие подцели:
а) получить пароль,
б) получить запрос на обслуживание,
в) обработать запрос на обслуживание,
г) обработать кредитную карту.
Подцели ‘а’, ‘б’ и ‘г’ не требуют дальнейшей детализации, а подцель ‘в’ не является столь очевидной и требуется ее структурирование на подцели следующего уровня. Этими подцелями будут:
обработать внутреннюю банковскую документацию;
распечатать баланс клиента;
распечатать операцию клиента ( уведомление о проведенной операции);
подготовить деньги клиента.
Окончательная структура целей для рассматриваемого примера приведена на рисунке 1.1.
обслужить
получить
получить обработать
обработать
пароль запрос на запрос карту
обслужив.
обработать распечатать распечатать подготовить
документа- баланс операцию деньги
цию клиента клиента клиенту
Рисунок 1.1
1.1.2 Спецификация функций с помощью таблиц решений
Результатом структурирования целей ПО является выявление всех его функций, которые необходимо запрограммировать. Как следует из вышеприведенного определения нисходящей стратегии, функциями являются ‘листья’ дерева целей. В нашем примере это функции: ‘получить пароль’, ‘получить запрос на обслуживание’, ‘обработать карту’, ‘обработать документацию’, ‘распечатать баланс клиента’, ‘распечатать операцию клиента’ и ‘подготовить деньги клиента’.
На следующем этапе составляются внешние спецификации выявленных функций или, иначе, спецификации процессов. Фактически спецификации являются описаниями алгоритмов соответствующих функций. Для этих целей существует достаточно много методов, которые перечислим в порядке увеличения трудности проектирования алгоритмов /4/:
- текстовое описание,
- структурированный естественный язык,
- таблица решений,
- дерево решений,
- визуальный язык,
- блок-схема,
- язык программирования.
Следует отметить, что в перечисленном выше порядке увеличивается степень формализации описания алгоритма и понимание деталей его функционирования проектировщиками и программистами, но уменьшается степень понимания алгоритма заказчиком и будущим пользователем ПО, для которого оно разрабатывается. Компромиссным решением проблемы понимания являются методы алгоритмизации, лежащие в середине спектра методов. Рассмотрим подробнее таблицу решений как вариант этого компромисса /4/.
Проектирование спецификаций процессов с помощью таблиц решений (ТР) заключается в задании матрицы, отображающей множество входных условий и множество решений.
ТР состоит из двух частей. Верхняя часть таблицы используется для определения условий. Обычно условие является ЕСЛИ-частью оператора ЕСЛИ-ТО и требует ответа ‘да-нет’. Нижняя часть ТР используется для определения действий, т.е. ТО-части оператора ЕСЛИ-ТО. Левая часть ТР содержит собственно описание условий и действий, а в правой части перечисляются все возможные комбинации условий и, соответственно, указывается, какие конкретно действия и в какой последовательности выполняются, когда определенная комбинация условий имеет место.
Поясним сказанное на примере спецификации процесса выбора символов из входного потока по следующим правилам:
а) если очередной символ является управляющим, то подать звуковой сигнал и вернуть код ошибки;
б) если буфер формируемой строки заполнен, то подать звуковой сигнал и вернуть код ошибки;
в) если очередной символ не находится в заданном диапазоне, (положим, от ‘а’ до ‘я’), то подать звуковой сигнал и вернуть код ошибки;
г) иначе поместить символ в буфер, увеличить значение счетчика выбранных символов и вернуть новое значение счетчика.
Таблица решений для данного примера приведена ниже ( таблица 1.1).
Здесь ‘Д’ означает ‘да’, ‘Н’ - ‘нет’, 1,2 - помеченные действия выполняются в указанном порядке.
Таблица 1.1 - ТР для функции выбора символов из входного потока
Условия |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
С1 символ управляющий? |
Д |
Д |
Д |
Д |
Н |
Н |
Н |
Н |
С2 буфер заполнен? |
Д |
Д |
Н |
Н |
Д |
Д |
Н |
Н |
С3 символ от ‘a’ до ’я’? |
Д |
Н |
Д |
Н |
Д |
Н |
Д |
Н |
Действия |
|
|
|
|
|
|
|
|
D1 подать звуковой сигнал |
1 |
1 |
1 |
1 |
1 |
1 |
1 |
|
D2 вернуть код ошибки (>0) |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
|
D3 увеличить значение счетчика и вернуть его |
|
|
|
|
|
|
|
2 |
D4 поместить символ в буфер |
|
|
|
|
|
|
|
1 |
Заметим, что если выполняется условие С1, то нет необходимости в проверке условий С2 и С3. Поэтому комбинации условий 1,2,3,4 могут быть заменены обобщающей комбинацией (Д, -, -), где ‘-’ означает любую из возможных альтернатив (в данном случае Д или Н). Аналогично комбинации условий 5 и 6 могут быть заменены обобщающей комбинацией (Н, Д, -). Редуцированная таким образом ТР будет иметь вид таблицы 1.2.
Таблица 1.2 Редуцированная ТР
Условия |
1 |
2 |
3 |
4 |
С1 символ управляющий? |
Д |
Н |
Н |
Н |
С2 буфер заполнен? |
- |
Д |
Н |
Н |
С3 символ от ‘a’ до ’я’? |
- |
- |
Д |
Н |
Действия |
|
|
|
|
D1 подать звуковой сигнал |
1 |
1 |
1 |
|
D2 вернуть код ошибки (>0) |
2 |
2 |
2 |
|
D3 увеличить значение счетчика и вернуть его |
|
|
|
2 |
D4 поместить символ в буфер |
|
|
|
1 |
Методика построения ТР заключается в следующем:
а) определить все условия и действия в спецификации;
б) вписать действия и условия в таблицу;
в) в нумерованных столбцах отметить все возможные комбинации условий и выполняемых при выполнении условий действий;
г) при необходимости редуцировать таблицу (если есть 2 столбца, у которых перечень действий совпадает и которые отличаются только результатами условий ‘Д’ и ‘Н’ в одной строке, то такие столбцы могут быть слиты в один).
Отметим, что на основе ТР легко осуществить кодирование программы на языке высокого уровня, таком , как Pascal.
