Владимир Липаев - Очерки истории отечественной программной инженерии в 1940-е – 80-е годы

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

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

В конце 1970-х годов было установлено отсутствие тождественности между понятиями правильной и надежной программы реального времени [17]. Понятие правильной, или корректной, программы может рассматриваться статически, вне временного функционирования. Корректная программа должна была обеспечивать выходные данные, соответствующие эталонным требованиям, в области изменения исходных данных заданных техническим заданием или спецификацией. Степень правильности программы можно характеризовать вероятностью попадания в область исходных данных, которая предусматривалась требованиями спецификации, но не была проверена при тестировании и испытаниях. В этой области исходных данных не гарантируются эталонные результаты из-за возможных ошибок в программе, не обнаруженных при отладке. При этом корректность программы не определена вне области данных, заданной спецификацией, и не зависит от динамики функционирования программ в реальном времени. Таким образом, некорректность исполнения программы определяется совмещением событий: попаданием исходных данных в область, заданную требованиями спецификации, но не проверенную при тестировании и испытаниях и наличием ошибки в программе при обработке таких данных.

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

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

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

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

Так как в программах нет необходимости «ремонта» компонентов с участием человека, то нужно добиваться высокой автоматизации программного восстановления функционирования. Автоматизируя процесс и сокращая время восстановления, можно преобразовать отказы в сбои и тем самым улучшить показатели надежности функционирования системы в реальном времени. Для решения этой задачи в комплексе программ должны быть средства, позволяющие [17]:

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

• диагностировать обнаруженные искажения;

• вырабатывать решения и выбирать методы и средства оперативного восстановления;

• реализовывать оперативное восстановление нормальной работоспособности;

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