Тестирование и отладка программы

1.7.3 Тестирование и отладка программы

После окончания этапа программирования, т.е. собственно процесса написания программы, проводится ее проверка для обнаружения и исправления возможных ошибок. На эмуляторе микропроцессора АТ89С51 проверяется корректность кода программы по содержимому различных регистров процессора. В контрольных точках программы, выбранных для удобства после каждого логически законченного куска кода, мы смотрим содержимое регистра R7. Внесенные в программу отладочные строки для контроля ее пошагового выполнения позволяют своевременно выявлять неточности реализации общего алгоритма изделия ТС16Е1. Применение модульного принципа тестирования программы существенно облегчает этот процесс.

Далее проверенный таким образом ассемблерный текст программы с помощью компилятора ассемблера микропроцессора АТ89С51 переводится в hex‑файл. На этом этапе так же можно проконтролировать возможные неточности кода. При дальнейшем переводе этого текста программы в машинный код, производится поиск синтаксических ошибок в программе и, в случае их обнаружения, печатается диагностика, помогающая последующей локализации ошибок. Отсутствие синтаксических ошибок не говорит о том, что в программе нет ошибок.

По окончании такой отладки программы начинается ее эксплуатация. С помощью программатора полученный машинный код прошивается в тестовой ПЗУ с ультрафиолетовым стиранием, и начинается тестирование опытного образца. Производится анализ работы системы в целом, обычно многократный. Первые полученные результаты реальных данных подвергаются тщательному анализу, чтобы убедиться в пригодности использованного метода и установить согласованность полученных результатов с имеющимися данными и теорией. Если правильность получаемых результатов не. вызывает сомнений и эффективность программы удовлетворительна, то ее эксплуатация продолжается. В случае отклонения результатов работы программы от ожидаемых, происходит возврат к поиску возможных ошибок на этапе кодирования общего алгоритма изделия ТС16Е1.

1.7.4 Оформление программы и ее возможная модернизация

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

Если разработчик программы постоянно работает в некоторой области науки или техники, то обычно рано или поздно наступает такой момент, когда перед ним возникает вопрос о модернизации старой программы или о составлении новой, развивающей идеи, реализованные в прежней программе. Модернизация программы проходит те же этапы, что и разработка, и начинается с составления технического задания на модернизацию. Успешное осуществление модернизации зависит от того, насколько легко можно будет при разработке новой программы использовать блоки старой программы и вносить в них изменения. Быстрое выполнение такого рода работ зависит, в свою очередь, как от структуры модернизируемой программы, так и от качества ее оформления.

1.7.5 Надежность программного продукта

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

Программы, разрабатываемые для решения инженерных и научно-исследовательских задач характеризуются неполным использованием ресурсов вычислительных систем и относительно небольшим временем жизненного цикла. Длительность разработки этих программ обычно невелика. Их эксплуатация носит эпизодический и кратковременный характер, отсутствуют жесткие ограничения на допустимую длительность ожидания результатов, практически всегда имеется возможность достаточно строго проконтролировать выходные данные и при необходимости поставить контрольные эксперименты. К этому типу программ практически неприменимы основные понятия теории надежности. И тем не менее, основные принципы создания надежного программного обеспечения справедливы и в этом случае.

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

·           проверку исправности системы;

·           проверку работоспособности системы и возможности выполнения всех функций с характеристиками, заданными технической документацией;

·           проверку правильности функционирования в данном режиме работы в данный момент времени;

·           поиск и локализацию неисправностей в системе.

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

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

В ходе выполнения данного дипломного проекта была разработана программа управления автоматизированным комплексом многоканальной связи. Предъявленные в техническом задании к проекту требования выполнены полностью: программное обеспечение для процессора АТ89С51 разработано в соответствии с общим алгоритмом ПО изделия ТС16Е1, ОЗУ данных процессора АТ89С51 использовано для хранения карты памяти состояний части битов регистров CR1, CR2, TSR и PSR 16‑ти линейных интерфейсов по заданным адресам в заданном порядке, обеспечено своевременное обновление карты памяти состояний части битов регистров CR1, CR2, TSR и PSR всех интерфейсов через подпрограмму обработки прерываний линейных интерфейсов, обеспечена возможность передачи карты памяти состояний оговоренных регистров, взаимодействуя с внешней ПЭВМ, используя интерфейс RS‑232, через последовательный порт Р3. Подробно описана структура программы, алгоритмы построения и работы всех трех ее частей для дальнейшего использования, модернизации и возможного применения отдельно взятых частей кода при разработке подобных программных продуктов для устройств связи.
2. Технологическая часть 2.1 Требования к программным системам

Каждая программа, входящая в систему, должна отвечать таким требованиям, как:

·           правильность

·           точность

·           совместимость

·           надежность

·           универсальность

·           защищенность

·           полезность

·           эффективность

·           проверяемость

·           адаптируемость

Будем говорить, что программа является:

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

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

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

·           надежной, если она при всех условиях обеспечивает полную повторяемость результатов. Любой человек, имеющий опыт работы с ЭВМ, может подтвердить, что в его практике еще не встречалось ни абсолютно надежного системного программного обеспечения, ни безукоризненно работающих машин. И, несмотря на оптимистичность высказываний некоторых программистов, то же самое можно сказать о прикладных программных системах. Впрочем, уровень их надежности может быть повышен за счет использования встроенных механизмов резервирования и самоконтроля.

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

·           защищенной, если она сохраняет работоспособность при возникновении сбоев. Это качество особенно важно для программ, предназначенных для решения задач в режиме реального времени. В подобных приложениях отказ оборудования может повлечь катастрофические последствия – например, аварию ракеты или ядерного реактора. Указанным свойством должны также обладать программы с большим временем выполнения, осуществляющие обработку постоянно хранимых файлов.

·           полезной, если задачи, которые она решает представляют практическую ценность.

·           эффективной, если объем требуемых для ее работы ресурсов ЭВМ не превышает допустимых пределов.

·           проверяемой, если ее качества могут быть продемонстрированы на практике. Здесь подразумевается возможность проверки таких свойств программы как правильность и универсальность. Можно применить формальные математические методы, позволяющие установить, действительно ли программа удовлетворяет техническим условиям и выдает достаточно точные результаты. Однако существуют и неформальные способы оценки качества программ, причем иной раз они оказываются более убедительными, чем формальные. Имеются в виду такие неформальные приемы, как прогоны с остановами в контрольных точках, обсуждение результатов с заинтересованными пользователями и др.

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

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

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

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

Всякое использование ЭВМ предполагает стандартизацию данных и способов обработки. Эффективная реализация преимуществ ЭВМ возможна лишь в тех случаях, когда необходимо выполнять либо трудоемкие вычисления, либо обработку больших объемов информации.

После завершения этапа предварительных исследований составляется список требований, предъявляемых к системе. В него должны быть включены результаты анализа обстановки, описание выполняемых системой функций и ограничения, которые необходимо учитывать в процессе проектирования. Под обстановкой в данном случае понимается совокупность условий, при которых предполагается эксплуатировать систему. К ним относятся аппаратные и программные ресурсы, предоставляемые системе, внешние условия ее функционирования а также состав людей и работ, имеющих к ней отношение. Должны быть продуманы изменения в текущей деятельности организации, обусловленные внедрением системы. Возможно, понадобится иная расстановка персонала, придется внести изменения в структуру выполняемых работ. Могут также потребоваться дополнительные вычислительные мощности.

Функциональные требования к системе содержат четкое описание всего того, что она должна делать. Ограничениями в процессе проектирования являются директивные сроки завершения отдельных этапов, имеющиеся в наличии ресурсы, организационные процедуры и мероприятия, обеспечивающие сохранность информации.

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