Была исследована сложность тестирования типовых структур модулей при различных критериях выделения маршрутов, а также достигаемая их корректность в зависимости от объема тестов. Для логических программ наибольшее значение имело тестирование при значениях исходных данных, определяющих реализуемые маршруты исполнения программ. Систематизированы и оценены по эффективности методы тестирования потоков данных. Для вычислительных программ особенно важны были методы тестирования корректности обработки каждой переменной и оценки точности результатов вычислений.
Детерминированное тестирование структуры программных модулей имело целью проверять корректность выделенных маршрутов исполнения программ и обнаружение в основном логических ошибок формирования маршрутов. На практике при отсутствии упорядоченного анализа потоков управления некоторые маршруты в программе могли оказаться пропущенными при тестировании, поэтому первая задача, которая решалась при исследовании тестирования структуры программ, – это получение информации о полной совокупности реальных маршрутов исполнения в каждой программе. Такое представление маршрутов позволяло упорядоченно контролировать достигнутую степень проверки маршрутов и в некоторой степени предохраняло от случайного пропуска отдельных не трестировавшихся. В результате значительно повышалось достигаемое качество программ, и тестирование приобретало планируемый систематический характер.
Сложность и трудоемкость тестирования потоков управления определяются комбинаторным характером схем принятия решений во многих программных модулях, что приводит к большому числу маршрутов обработки информации в программах. Анализ критериев тестирования и выделение тестируемых маршрутов удобно было проводить, используя графовые модели программ. При планировании тестирования структуры программ были исследованы, прежде всего, две задачи, формирование критериев выделения маршрутов для тестирования и выбор стратегий упорядочения выделенных маршрутов.
В ряде случаев была подтверждена адекватность использования структурной сложности программ для оценки трудоемкости тестирования, вероятности не выявленных ошибок и затрат на разработку программных модулей в целом. В качестве исходной информации при тестировании структуры программ использовалась схема связей между операторами текста программы. По этой схеме выделялся полный набор маршрутов исполнения ПМ, подлежащих отладке. Для каждого выделенного маршрута по тексту программы формировался набор условий, определяющих его реализацию при соответствующем тесте. Сложность тестирования программных модулей можно было оценивать по числу маршрутов, необходимых для их проверки, или более полно – по суммарному числу условий, которое необходимо задать в тестах для прохождения всех маршрутов программы.
Показано, что маршруты исполнения ПМ можно было разделить на два вила: маршруты исполнения преимущественно вычислительной части программы и преобразования непрерывных переменных; маршруты принятия логических решений и преобразования логических переменных. Маршруты первого вида обычно логически проще и короче, чем второго, и предназначены для преобразования величин, являющихся квантованными результатами измерения некоторых непрерывных физических характеристик (непрерывные переменные). Такие переменные связаны условиями гладкости, т. е. условиями малых изменений производных этих переменных по времени или по другим параметрам.
При оценке сложности вычислительных маршрутов программ необходим был учет числа операндов, участвующих в вычислениях. Кроме того, исходные и результирующие данные при тестировании должны были принимать несколько значений. Во всем диапазоне исходных переменных следовало выбирать характерные точки (предельные и промежуточные значения), при которых проверяется программа. В особых точках значений и сочетаний переменных и в точках разрыва функции необходимо было планировать дополнительные проверки.
Проведенные исследования позволили оценивать достигаемую полноту тестирования при заданном числе тестов. Влияние критериев выбора маршрутов, стратегий их упорядочения и вероятностей ветвления в вершинах на вероятность проявления ошибок при тестировании программ более наглядно отражается на графах программ. Для выбора маршрутов тестирования наиболее подробно были исследованы критерии, при которых каждая дуга графа программы проверяется хотя бы один раз и маршруты различаются хотя бы одной дугой.
Ветвления в программах реального времени специализированных ЭВМ происходили через 5 – 10 операторов текста программ, поэтому число маршрутов исполнения ациклических ПМ было пропорционально их размеру, выраженному числом строк текста программ. Реализация каждого маршрута ПМ определяется числом условий, которые необходимо задать для его исполнения при тестировании. Поэтому полное число условий в тестях для покрытия тестями структуры ПМ было пропорционально квадрату строк текста программы в модуле и соответственно быстро возрастало при увеличении размера ПМ. На этой основе было показано, что при разработке ПМ целесообразно учитывать рациональное ограничение размеров модулей на уровне трехсот строк текста, что соответствует приблизительно тридцати альтернативам в ациклических программах. Поэтому при разработке ПМ был рекомендован рациональный размер программ модулей в пределах 100–200 строк текста на автокоде, для полного тестирования которых достаточно использовать 10–20 тестов с суммарным числом условий до 100. При превышении рекомендуемых размеров ПМ их трудно протестировать полностью, и целесообразно было делить на более мелкие компоненты, доступные для полного покрытия тестами.
Исследование структуры реальных программ, заказных специализированных ЭВМ позволило выявить около трети ПМ, содержащих циклы. При наличии в ПМ циклов, число необходимых тестов быстро возрастало в зависимости от числа маршрутов в теле цикла и числа различных итераций цикла, необходимых для проверки этой части ПМ. Рекомендовано при планировании тестирования ПМ по возможности предварительно выделять и отдельно тестировать циклы, а затем их включать в ациклическую часть программ для полного тестирования ПМ.
Продолжительность разработки программ всегда ограничена, что обычно не позволяет обеспечить полное покрытие тестами структуры ПМ. Поэтому при тестировании целесообразно упорядочивать маршруты исполнения программы и начинать тестирование либо с маршрутов, самых длинных по числу строк текста программы, либо с наиболее сложных по числу ветвлений в графе программы, либо с наиболее вероятных при исполнении ПМ. Было показано, что при одинаковом числе вершин ветвления в программах, сложность тестов, обеспечивающих достаточно низкую вероятность ошибок, в зависимости от структуры программы и критерия выделения маршрутов, может различаться почти на два порядка. Графы реальных программ практически всегда являются несимметричными как по структуре, так и по вероятностям исполнения маршрутов в ПМ. Это свойство целесообразно использовать при упорядочении последовательности, выделяемых при планировании для тестирования маршрутов, начиная с наиболее вероятных. Выполненные исследования позволили выработать рекомендации, как рационально планировать тестирование, в целях получения максимальной корректности модулей при ограниченных ресурсах на отладку. Для этого были созданы инструментальные средства автоматизированного планирования отладки программных компонентов.
5.3. Методы оценивания и обеспечения корректности и надежности программных продуктов – 1975-е годы
В конце 1970-х годов было установлено отсутствие тождественности между понятиями правильной и надежной программы реального времени [17]. Понятие правильной, или корректной, программы может рассматриваться статически, вне временного функционирования. Корректная программа должна была обеспечивать выходные данные, соответствующие эталонным требованиям, в области изменения исходных данных заданных техническим заданием или спецификацией. Степень правильности программы можно характеризовать вероятностью попадания в область исходных данных, которая предусматривалась требованиями спецификации, но не была проверена при тестировании и испытаниях. В этой области исходных данных не гарантируются эталонные результаты из-за возможных ошибок в программе, не обнаруженных при отладке. При этом корректность программы не определена вне области данных, заданной спецификацией, и не зависит от динамики функционирования программ в реальном времени. Таким образом, некорректность исполнения программы определяется совмещением событий: попаданием исходных данных в область, заданную требованиями спецификации, но не проверенную при тестировании и испытаниях и наличием ошибки в программе при обработке таких данных.
