- •Специфицирование и тестирование программ
- •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.3 Метод тестирования таблиц решений
Одним из методов тестирования программ по стратегии ‘черного ящика’ является метод функциональных диаграмм. Он хорошо вписывается в методы структурного анализа, реализующиеся в современных CASE-средствах разработки программного обеспечения. Этот метод излагается в /2/, требует предварительного изучения методики построения функциональных диаграмм, в силу чего является достаточно сложным для начинающих программистов. Однако интерес представляет тот факт, что метод сводится к получению в качестве промежуточного результата таблицы решений и составления тестов по этой таблице. Некоторые методики структурного анализа также включают тестирование спецификаций, полученных методами, обладающими недостаточными процедурными возможностями (они перечислены первыми среди методов специфицирования процессов в пункте 1.2.).
Тестирование ТР заключается в том, что проектируется такое количество тестов, которое позволяет покрыть все возможные комбинации условий. Как правило, количество этих тестов совпадает с числом столбцов в ТР. Так, для рассмотренного в пункте 1.1.2 примера выбора символов из входного потока (см. таблицу 1.2) необходимо реализовать 4 теста:
а) символ из входного потока является управляющим;
б) во входном потоке символов больше, чем помещается в буфере формируемой строки и ни один символ из входного потока не является управляющим;
в) во входном потоке символов меньше, чем вмещает буфер формируемой строки, среди них нет управляющих символов, но присутствуют символы, не входящие в диапазон от ‘а’ до ‘я’;
г) во входном потоке символов меньше, чем вмещает буфер формируемой строки, и все символы принадлежат диапазону от ‘а’ до ‘я’.
Положим, что управляющими символами являются ‘! & *’ и пусть буфер формируемой строки рассчитан на 10 символов. Тогда соответствующие тесты могут быть:
а) &
б) а б в г д е ж з и к л м
в) а б 1 в г 5 д
г) а б в г д е ж з и .
Ожидаемыми результатами тестирования являются:
а) звуковой сигнал и отличный от нуля код ошибки;
б) звуковой сигнал и отличный от нуля код ошибки;
в) звуковой сигнал и отличный от нуля код ошибки;
г) отсутствие звукового сигнала и равный нулю код ошибки.
Метод достаточно прост, позволяет эффективно проверить соответствие разработанной программы ее внешним спецификациям, но не всегда позволяет выявить случаи, когда программа делает то, что спецификацией не предусмотрено. Кроме того, спецификация может содержать ошибки, которые при таком тестировании выявлены не будут, особенно если результаты тестирования являются правдоподобными. Предварительное построение сначала функциональных диаграмм, а затем ТР позволяет осуществлять логический контроль спецификации сначала на уровне функциональных диаграмм, а затем уже на уровне ТР, что значительно снижает вероятность ошибок в спецификации.
2 Методика выполнения курсовой работы
2.1 Цель работы
Целью курсовой работы, методика выполнения которой изложена ниже, является получение начальных навыков проектирования и разработки программ с применением структурных методов анализа, а также усвоение методов тестирования разработанных программ.
