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

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

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

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

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

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

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