Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Основы разработки программного обеспечения на примере языка С. Учебное пособие для СПО
.pdf
строки 80
символов
"1234567890.........2,,,,,,,,,8,,"
Сообщение "Ошибка во
входной строке"
4.3.3
Длина строки
больше 80
символов
"1*2"
Сообщение "Ошибка во
входной строке"
4.3.2
Строка
содержит
недопустимый
символ
"...123"
Сообщение "Ошибка во
входной строке"
4.3.1
Ведущие
разделители
не пробелы
""
Сообщение "Работа
закончена"
4.2
Введена
пустая строка
Замечание
Приведенный выше тест-план не проверяет (явно) вывод
предупреждающего сообщения о вводе новой строки. Такое требование
не было явно определено в разделе 4. Это недоработка требований по
проверке функций программной реализации. Хороший тестировщик
должен сам включить подобную проверку в свой тест-план.
Дополнительные пункты плана явно зависят от конкретного
программного кода и поэтому не приведены в данном примере.
Вопросы и задачи для самостоятельного решения
Определите понятие покрытия тестами исходного текста модуля.
В чем разница тестирования требований спецификации на
программный модуль и тестирования исходных текстов
программного модуля?
Может ли быть несколько тестовых примеров для проверки
одного тест-требования? А один тест-пример для проверки
нескольких тест-требований?
Напишите тест-план на функцию вычисления периметра
треугольника.
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
181
Напишите тест-план на функцию вычисления максимума трех
чисел для покрытия следующего кода
1. по операторам;
2. по условиям:
int max3(int a, int b, int c)
{
int max;
max = a;
if (b > max) { max=b; };
if (c > max) { max=c; };
return max;
}
Напишите тест-план на функцию int Compare(int A, B),
если в функциональных требованиях сказано, что функция должна
сравнивать на равенство числа в пределах от - 76 до +77 и
возвращать 0 при совпадении значений параметров.
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
182
Разработка модуля или программы
Проектировщик должен опираться на опыт, на строгое логическое
мышление и на педантичную точность.
Никлаус Вирт
Как уже говорилось ранее, при написании программы, модуля или
функции можно применять два подхода к проектированию (нисходящий
или восходящий) или комбинировать их. В любом случае, необходимо
добиться структуры конечной программы, состоящей из набора
законченных блоков (модулей, функций, ...), каждый из которых имел бы
достаточно полную и законченную функциональность.
Добиться этого можно разными путями, но результат всегда должен
удовлетворять некоторым критериям, а именно:
максимальная независимость блоков между собой;
минимальное количество передаваемой между блоками
информации;
отражение логики и данных каждого отдельного блока на
отдельные сущности и понятия решаемой задачи.
8.1. проектирование архитектуры
Перед началом проектирования программы необходимо разработать
требования к ПО. На этом этапе определяются основные функции
будущего ПО. Требования должны однозначно определять всю
функциональность и одновременно описывать все нестандартные
ситуации. Например, если речь идет о функции деления одного числа
на другое, требования должны содержать ответ на вопрос: "А что вернет
функция, если знаменатель равен нулю?". Однако в требованиях не
стоит забывать и об основных задачах функции, которые порой
исчезают за многочисленными особыми случаями. Так, например, в
требованиях к функции деления необходимо указать, что функция
должна выполнять именно деление, по каким правилам оно должно
происходить и с какой точностью.
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
183
Часто удобно вводить условности, отличающие отдельные требования
друг от друга и от пояснений. Хорошей практикой будет использование
глагола должен (должна, должны) в каждом требовании, например:
"Функция деления должна вернуть нуль в случае, если знаменатель или
числитель, или они оба равны нулю". При этом требования могут
делиться на разделы, которые описывают различные функции
программы и форматы ее взаимодействия с окружением.
Одновременно с требованиями к самому ПО на их основе, как уже
говорилось ранее, могут разрабатываться тест-требования, в которых
отражается то, что надо будет проверить в ходе тестирования, чтобы
убедиться, что ПО соответствует разрабатываемым требованиям.
Каждое тест-требование выделяет некий класс эквивалентности (или
область), в котором надо проверить поведение программы, и обычно
начинается со слов "проверить, что". Например, для функциональности,
приведенной в предыдущем абзаце, тест-требования можно
сформулировать следующим образом:
Проверить, что если числитель равен нулю, а знаменатель не
равен нулю, то функция возвращает нуль.
Проверить, что если числитель не равен нулю, а знаменатель
равен нулю, то функция возвращает нуль.
Проверить, что если числитель равен нулю и знаменатель равен
нулю, то функция возвращает нуль.
Далее по требованиям и тест-требованиям формируют тест-план, а на
его основе уже реализуют сами тестовые примеры.
По требованиям разрабатывается архитектура ПО, определяющая все
модули, функции, их интерфейсы, а также алгоритмы работы и
структуры данных. Можно сказать, что архитектура ПО должна отвечать
на вопрос "КАК работает программа?", в то время как требования к ПО
отвечают на вопрос "ЧТО должна делать программа?". Лишь после
разработки архитектуры можно приступать к кодированию. На этом
этапе происходит воплощение архитектуры в виде программного кода
на выбранном языке программирования с учетом всех его особенностей
и возможностей. При кодировании необходимо учитывать не только
свойства языка программирования, но и особенности выбранной
архитектуры целевой машины.
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
184
Тестирование программы следует начинать с отдельных функций, затем
переходить к модулям и только потом ко всей программе. После этого
полностью "собранная" программа должна пройти все тестовые
примеры, определенные в тест-плане. Таким образом, различные
требования тестируются на разных уровнях интеграции.
8.2. Внешнее взаимодействие
Существуют некоторые отличия проектирования и реализации
отдельной функции от проектирования и реализации законченной
программы, встроенной программы и программы, выходящей на
непосредственный диалог с пользователем. Здесь необходимо отметить,
что законченная программа может иметь некоторый диалог с
пользователем, достаточный для выполнения ее функций и
поясняющий пользователю, что программа от него "хочет".
Все введенные пользователем данные необходимо проверять более
тщательно, нежели формальные входы, полученные от других
программных функций. Сам диалог с пользователем может
представлять собой:
графический диалог;
графическое меню;
меню цифрового выбора;
командный выбор функций;
просто линейный ход выполнения (ничего не запрашивает у
пользователя);
мигание каких-либо индикаторов, перемещение каких-либо
подвижных частей, например стрелочного индикатора и т.д.
Кроме самого обмена данными с пользователем, необходимо всегда
учитывать время внешнего "бездействия" программы для пользователя,
проявляемое неизменением никаких внешне видимых данных
("зависание" программы). Считается, что время спокойного ожидания
пользователя равно примерно двум секундам, далее необходимо
изменить что-нибудь на экране, что-нибудь переместить, мигнуть, иначе
пользователь начнет сомневаться, что программа работает. Для таких
целей часто применяют так называемый "прогресс бар" или
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
185
процентную шкалу, отображающую степень выполнения программы
(алгоритма).
Отдельная проблема - борьба с ошибками ввода. Человек всегда может
нажать что-нибудь не то, например при вводе числового значения
нажать букву, поставить лишнюю запятую, пропустить пробел. Поэтому
данные, вводимые вручную, надо всегда проверять на соответствие
требованиям. Зато, обнаружив ошибку пользователя, всегда можно
переспросить, попросить повторно ввести значение или ис-править
введенный символ.
При проектировании пользовательского интерфейса полезно
постараться уменьшить вероятность совершения ошибки ввода. Во
многих случаях следует заменить прямой ввод значения выбором его из
словаря данных. Такой прием можно использовать при выборе
комплектующих из списка доступных изделий, имен файлов в
компьютере и т.п. Этот подход предполагает, что программа имеет
доступ ко всему множеству допустимых входных значений, может
визуализировать его пользователю и предоставить возможность выбора
нужного значения из списка.
При значительных размерах словаря данных рекомендуется применить
иерархический отбор. Например, выбрать сначала факультет, потом
курс, группу и только в списке группы уже выбирать фамилию нужного
студента. Часто такой путь не только предотвращает ошибки ввода, но и
дает возможность одновременно производить выборку нужных данных
из базы, хранящейся на внешних устройствах вычислительной машины.
Специальные требования следует учитывать, когда программа
взаимодействует с формальным пользователем - устройством или
другой самостоятельной программой. Здесь меньше вероятность
появления ошибки ввода, но есть опасность, что передаваемые в канале
обмена данные подвергнутся искажению или программа-партнер
нарушит протокол обмена из-за ошибки реализации. В конце концов,
она может просто "повиснуть", или связь с ней может прерваться, а мы
будем "сидеть" и ждать от нее ответа.
Вопросы и задачи для самостоятельного решения
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
186
Каковы критерии разделения программы на модули?
Как следует формулировать требования, чтобы они отличались от
пояснений?
Как следует формулировать описание тест-требований?
Какой документ отвечает на вопрос: "Что должна делать
программа?"
Какие виды диалогов с пользователем Вам известны?
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
187
Обмен данными и вопросы кодирования
Любые предложения люди понимают иначе, чем тот, кто их вносит.
Закон Чизхолма
Следствие:
Даже если ваше объяснение настолько ясно, что исключает всякое
ложное толкование, все равно найдется человек, который поймет вас
неправильно.
9.1. Соглашения о связи
При общении с формальными устройствами следует строго
придерживаться принятых договоренностей - протоколов
взаимодействия. Например, перед обращением к устройству надо
проверить, что оно включено и не занято взаимодействием с другим
партнером (с другой программой). Такое обычно возможно, если мы
"тесно" связаны с устройством, живем в одном адресном пространстве,
на одном компьютере.
Но это далеко не всегда так. Часто мы взаимодействуем с другим
формальным партнером только через канал передачи данных. Да еще
этот канал подвержен внешним воздействиям, которые могут исказить
передаваемый сигнал. Тогда кроме соблюдения протокола важны еще и
средства контроля приема/передачи данных.
Протокол подобного обмена обычно служит для посылки сообщения от
одного источника к нескольким потребителям. Поэтому адрес
(идентификационный код) источника включается в заголовок
передаваемого блока данных. Для этой цели в начале передачи
сообщения следует признак начала (STX), в который включают и
идентификатор, и длину передаваемой последовательности.
Получив его, принимающая сторона может зарезервировать буфер
необходимого размера для ввода сообщения, после чего отправляет
приглашение к продолжению диалога (RTS). По окончании передачи
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
188
источником данных посылается признак конца сообщения (ETX). В
состав завершающей посылки обычно включается контрольная сумма.
На переданное сообщение источником ожидается либо подтверждение
(AK), либо указание на сбой в приеме данных (NAK). В последнем
случае передача повторяется.
Любое принятое сообщение сначала контролируется на целостность, а
уже потом расшифровывается (интерпретируется). Принимающая
сторона может проверить и то, что отдельные элементы
последовательности получены, и то, что все сообщение принято
правильно (принятая контрольная сумма совпадает с рассчитанной по
тексту сообщения).
При нарушении целостности партнеру обычно направляется просьба
повторить посылку. Конечно, при большой "зашумленности" канала
связи/передачи оба партнера будут все время переспрашивать друг
друга, так и не произведя собственно обмен данными. Поэтому в
сообщения стараются ввести такую избыточность, которая позволила
бы в ряде случаев не только обнаружить искажение, но и исправить
отдельные ошибки в принятом блоке данных.
9.2. Помехозащищенное кодирование
Первый уровень избыточности вводится на уровне передаваемых
символов (8 бит), слов, размер которых может быть 16, 32, 64 бита в
зависимости от "ширины" линии передачи данных. Например, для этого
в состав символа, для кодирования которого используется 8 бит (256
возможных значений), добавляется дополнительный "контрольный"
разряд. Этот избыточный бит не создает новых символов, но его
значение устанавливается, например, так, чтобы сумма единиц в
передаваемом коде была всегда четная.
Другими словами, складывая биты принятого символа по модулю два с
учетом контрольного разряда, принимающая сторона должна всегда
получать 0. При этом способе избыточного кодирования, передавая код
01001101, мы должны добавить контрольный разряд, равный 0, а для
кода 11101100 контрольный разряд должен быть равным 1.
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
189
Такая система избыточного кодирования позволяет обнаружить неверно
переданный символ, если в его коде произошла одна ошибка (пропуск замена 1 на 0 или ложное срабатывание - замена 0 на 1).
Как правило, подобного контроля достаточно для фиксации ошибки при
приеме. Далее можно запросить источник данных повторить неверно
принятый символ. Однако в системах реального времени порой
невозможно прервать прием. Связь устанавливается на большие
расстояния, и у нас нет возможности ждать реакции приемника на
каждый переданный символ.
Передающая сторона вынуждена непрерывно передавать пакет данных,
надеясь, что ее верно поймут на стороне приема. В лучшем случае она
может подождать реакции в конце передачи и повторить весь пакет
заново. Часто бывает нужно не только обнаружить факт наличия
ошибки в сообщении, но и постараться исправить его. Для одиночных
ошибок для этого достаточно применить похожий прием добавления
контрольного разряда и передать в конце сообщения контрольный байт
(слово, значение контрольной суммы), разряды которого сформированы
по тому же принципу, что и контрольный разряд символа.
Таблица 9.1(a). Пример
сообщения из пяти байт
Разряды: 0 1 2 3 4 5 6 7 к.р.
0 байт 1 0 1 1 0 1 0 1 1
1 байт 1 1 1 0 0 1 0 1 1
2 байт 0 0 1 0 0 0 1 0 0
3 байт 1 1 1 1 0 0 1 0 1
4 байт 0 0 0 1 1 0 1 1 0
Контр.байт 1 0 0 1 1 0 1 1 1
В табл. 9.1(а)
приведен пример кодирования по указанной схеме
сообщения из пяти байт, контрольный разряд каждого из которых
формируется по ранее упомянутому алгоритму. Для контроля передачи к
сообщению добавлен шестой контрольный байт, значащие разряды
которого дополняют соответствующие разряды переданного сообщения
до четного количества единиц (в колонках).
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
190
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]