Другим подходом к проверке программы модуля без машины является прогон тестовых вариантов с прослеживанием хода выполнения программы. Тестовые варианты должны быть простыми и в ограниченном количестве, с тем чтобы избежать громоздкого ручного процесса прокрутки. Подборку тестовых вариантов целесообразно поручить разработчику модуля (или модулей), вызывающего данный тестируемый модуль. Разработчик тестируемого модуля в процессе прокрутки дает разъяснения логики модуля. Этот контакт позволяет не только проверить логику модуля, но и получить список дополнительных проблем, включающих плохую практику программирования, неэффективность приемов реализации отдельных частей или алгоритма в целом и другие рекомендации. [c.147]
Совокупность дедуктивного вывода, обеспечиваемого планировщиком на функциональной модели, описание самой модели, связанных с ней программных модулей и закономерностей данной проблемной области вместе с процедурами их проверки образуют то, что сейчас принято называть интеллектуальным пакетом прикладных программ. Именно в виде такого пакета выступает в ситуационном управлении Коррелятор. Основная его компонента — набор логико-трансформационных правил [c.237]
Три завершающих шага назначения тестовых комбинаций базируются на проверке логики модуля. Для выбираемого множества тестовых комбинаций в качестве критерия полноты может выступать утверждение о том, что каждая команда контролируемого модуля выполняется хотя бы один раз. Этот критерий необходим, но он не всегда является выполнимым. Лучшим критерием является обеспечение достаточного количества тестовых условий, позволяющих для каждой спроектируемой конструкции i модуля, которая порождает многовариантный переход, прохождение каждой ветви. Для автоматизации выаол- яения контроля лучшим решением будет построение граф-схемы программы модуля и на ее основе получение необ-< ходимых тестовых комбинаций, обеспечивающих работу по шагам два и три общего подхода. 174 [c.174]