Методологические основы

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

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

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

При выборе и применении методов тестирования программных компо­нентов необходимо учитывать общие требования к ним и их особенности '.

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

• 
  В процессе разработки программ специалисты должны стремиться охватить тестированием функционирование ПС во всей доступной области изменения исходных данных и режимов применения. При этом номенклату­ра и диапазоны варьирования тестов ограничены либо допустимой дли­тельностью подготовки и исполнения тестов, либо вычислительными ре­сурсами, доступными для использования с целью контроля и тестирова­ния в режиме нормальной эксплуатации. Это отражается на выборе методов тестирования и последовательности анализа компонентов ПС, объеме при­меняемых тестов и на глубине тестирования. На выбор эффективных ме­тодов тестирования и последовательность их применения в наибольшей степени влияют основные характеристики тестируемых объектов:
  

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

• 
  Тестовые варианты должны быть разработаны так, чтобы верифици­ровать корректность функционирования и определить условия, при кото­рых могут проявляться потенциальные ошибки. Анализ покрытия тес­тами требований к ПС должен определять, какие требования не были протестированы и какие структуры программного средства не были ис­полнены при тестировании. Анализ тестового покрытия состоит из двух шагов, включающих анализ покрытия, основанного на требованиях, и ана­лиз структурного покрытия. Первый шаг анализирует тестовые наборы относительно требований ПС, чтобы подтвердить, что выбранные наборы тестов удовлетворяют установленным критериям. Этот анализ покрытия, основанного на требованиях, должен определить, насколько полно тести­рование проверило реализацию всех требований в спецификации к ПС, и показать потребность в дополнительных тестовых наборах. Тестовые ва­рианты, основанные на требованиях, могут не полностью покрыть струк­туру программы. Поэтому дополнительно выполняется анализ структур­ного покрытия и проводится его верификация. Второй шаг должен под­твердить, что процедуры тестирования, основанные на требованиях, покрыли всю структуру программы. Анализ структурного покрытия дол­жен определять, не пропущены ли элементы структуры программы, кото­рые не проверены тестовыми процедурами, основанными на требованиях.
  
• 
  Далее внимание сосредоточено на основных методах обеспечения качества относительно простых программ. К ним относятся отдельные программные модули (ПМ) или их небольшие группы, решающие доста­точно простую функциональную задачу. Однако ниже эти компоненты не различаются, и преимущественно используется термин — программный модуль. Эти объекты тестирования имеют ряд принципиальных осо­бенностей, которые отличают их от сложных программных средств и не­посредственно отражаются на применяемых методах и средствах автома­тизации тестирования.
  
• 
  Невысокая размерность ПМ обеспечивает их обозримость и возмож­ность детального анализа функций, структуры программы и процесса реше­ния задач. Детализированный контроль ПМ может проводиться планомер­но и детерминированно с точностью до любого оператора или операнда в программе. Стремление к снижению сложности тестирования реализуется частично путем укрупнения наблюдаемых и анализируемых компонентов до уровня небольших групп операторов на языке программирования в пределах одного структурного элемента программы. Тем самым контролю доступны вся логика решения задачи и все возможные маршруты и вари­анты исполнения программы. В результате при тестировании имеется воз­можность оценивать и контролировать степень проведенной проверки и достигнутое качество компонентов ПС, а также выделять следующие виды тестирования.
  
•