Организация диагностирования МПС. Тестирование программ

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

Любое тестирование и отладка сложных систем ПО могут только показать наличие ошибок, но не доказать их отсутствие. Поэтому программисты говорят: «Последняя найденная в программе ошибка является на самом деле предпоследней». В то же время последствия ошибок ПО могут быть весьма серьезными. Стал уже классическим пример, когда из-за одной ошибки в операторе на Фортране не состоялся запуск американского космического корабля на Венеру. Особенно важно отсутствие ошибок ПО в безопасных системах. Например, в микропроцессорных централизациях стрелок и сигналов на станциях программным путем проверяются условия безопасности при установке маршрутов и открытии сигналов (свободность участков маршрута, контроль положения стрелок, отсутствие враждебных маршрутов и другие).

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

Статистика показывает, что интенсивность ошибок в ПО лежит в диапазоне от 0,25 до 10 на 1000 команд. Исправление одной программной, алгоритмической или системной ошибки требует корректировки в среднем 6, 14 или 25 команд соответственно. При этом материальные затраты на исправление ошибки с течением времени жизненного никла ПО возрастают, а вероятность правильного исправления ошибки уменьшается. Поэтому целесообразно осуществлять тестирование ПО с самого начала его разработки, учитывая то, что на тестирование и сопровождение (устранение ошибок в процессе эксплуатации) приходится до 75% всех материальных затрат. По мере исправления ошибок в процессе сопровождения (если при этом не вносятся новые ошибки) частота отказов в ПО уменьшается (рисунок 1), поскольку программы «не изнашиваются» и «не стареют» в отличие от аппаратуры.

 

Рисунок 1 – Зависимость частоты отказов аппаратуры (1) и ПО (2) от времени

 

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

Тестирование состоит в выполнении программы с целью обнаружения ошибок при отсутствии реальной внешней среды. Специально подбирают входные данные (тесты); реакция ПО для данных сравнивается с эталонной. В структурированной программе выделяют четыре уровня тестирования: тестирование модулей, сопряжений между модулями, тестирование внешних функций, комплексное тестирование.

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

Тестирование разделяется на три этапа: составление (генерация) тестов, выполнение программы на этих тестах и оценку полученных результатов. Выполнение программы на тестах может осуществляться вручную (на бумаге, «в уме») для несложных программ. Такой вид тестирования называется статическим. Динамическое тестирование выполняется с использованием ЭВМ. Результаты прохождения анализирует программист или ЭВМ, для чего требуется иметь эталонные результаты и хранить их в памяти для сравнения. Возможно также использование эталонной программы, которая запускается на тех же тестах и вырабатывает эталонные выходные данные.

Тесты составляют программисты или автоматические системы генерации тестов. При этом используются два подхода: функциональный и структурный (рисунок 2).

Рисунок 2 – Методы тестирования программ

 

Рассмотрим эти подходы на примере тестов для бинарной программы вычисления булевой функции

Метод бинарных программ основан на том, что процесс вычисления булевой функции можно свести к последовательности выполнения команд условного перехода i: если А, то j, иначе i+ 1, где i – порядковый номер команды: А – булева переменная, значение которой проверяется данной командой. Если А = 1, то осуществляется переход к выполнению команды с порядковым номером j, если А = 0 – переход к выполнению команды с порядковым номером i +1.