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

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

Исследования показали, что радикальное повышение качества отечественных программных продуктов и обеспечение их конкурентоспособности возможно только на базе внедрения регламентированных технологий и систем качества, поддерживающих и контролирующих весь жизненный цикл производства программного продукта. Основой обеспечения высокого качества сложных комплексов программ является полнота тестирования программных компонентов – модулей (ПМ) [19]. Для отладки программ наиболее полно в 80-е годы исследованы методы и характеристики тестирования структуры ПМ и обработки в них потоков данных (Борис Аронович Позин). Тестирование структуры ПМ позволяло выявлять наиболее грубые и опасные ошибки в программах, которые могли приводить к резким отличиям результатов их исполнения, от предполагаемых эталонов. Имевшиеся всегда реальные ограничения ресурсов на разработку программных компонентов, вызывали необходимость рационального их использования, и систематизированного применения различных методов в целях достижения наивысшего качества программ.

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

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

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

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

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

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

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

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