Основные группы методов статического анализа артефактов жизненного цикла

Лекция 5. Основные группы методов статического анализа артефактов жизненного цикла. Классификация методов динамической верификации Основные группы методов статического анализа артефактов жизненного цикла Основные две группы методов статического анализа артефактов жизненного цикла – контроль того, что все формализованные правила корректности построения этих артефактов выполнены, и поиск типичных ошибок и дефектов в них на основе некоторых шаблонов. Чаще всего используется статический анализ исходных текстов программ, и для них существует большой набор различных инструментальных средств, выполняющих такой анализ, например, три из них, реализующих наиболее сложные виды анализа – PolySpace Verifier, Coverity Prevent и Klocwork K7. Проверенные на практике правила корректности текстов программ или шаблоны типичных ошибок переносятся в среды разработки и постепенно становятся семантическими правилами языков программирования, их проверка возлагается уже на трансляторы этих языков. Поэтому статический анализ можно считать наиболее широко применяемым методом верификации. Все методы автоматической статической верификации артефактов, представленных в текстовой форме построены либо на непосредственном анализе соответствия некоторой формальной грамматике, либо на средствах поиска. В свою очередь использующих формальные грамматики описания образцов, в частности, на основе регулярных выражений. При этом конкретная реализация как правило скрывает непосредственные описания таких грамматик от разработчика, предоставляя более высокоуровневые инструменты на языке понятий верифицируемых артефактов. Если в проекте используются языки описания архитектуры или графические языки проектирования, построенные с их помощью артефакты можно также проверять с помощью специализированных инструментов. Очевидно, что для возможность однозначной проверки таких артефактов их внтуренне представление должно выражать не столько наблюдаемую разработчика визуальную форму символа графического, сколько предоставлять его однозанчное соотвествие символу алфавита некоторого формального языка. Или даже целой последовательности символов такого формального языка, или их совокупности. Одним из основных способов такого представление является представление символов как объектов, внутреннее описание которых, а также связей между ними дается на некотором формальном языке, использующем текстовое представление, и используемом для верификации подобных артефактов. Сами же инструменты на основе таких описаний генерируют визаулизацию для разработчика. А создание таких артефактов во многом аналогично работе с векторными графическими редакторами (поскольку ряд векторных графических форматов тоже представлент элементы векторной иллюстрации в текстовйо форме).Подобные инструменты также постепенно встраиваются в широко используемые среды моделирования, например такие как Rational Rose и т.п. Поэтому методы верификации при помощи статического анализа либо уже прошли апробацию на практике и используются в коммерческих инструментах и широко применяемых инструментах разработки общего назначения, либо все еще остаются в ранге новаторских, исследовательских работ. Исследовательские методы на данный момент, в основном, связаны с формализацией различных характеристик и свойств ПО и поэтому могут рассматриваются как синтетические подходы к верификации. Классификация методов динамической верификации Динамические методы верификации используют результаты реальной работы проверяемой программной системы или ее прототипов, чтобы проверять соответствие этих результатов требованиям и проектным решениям. Существует два основных вида динамических методов верификации: – мониторинг, в рамках которого идет только наблюдение, запись и оценка результатов работы ПО при его обычном использовании, и тестирование, при котором проверяемое ПО выполняется в рамках заранее подготовленных сценариев; – тестирование Во втором случае результаты работы тоже записываются, анализируются и оцениваются, основное отличие тестирования от мониторинга — целенаправленные попытки создать определенные ситуации, чтобы проверить работу ПО в них. Разделение мониторинга и тестирования несколько условно, тестирование всегда включает в себя и мониторинг. Общим для этих методов верификации является создание контролируемой среды выполнения ПО, обеспечивающей получение результатов его работы и измерение различных характеристик ПО, а также оценка этих результатов и характеристик. Виды мониторинга Собственно верификационном мониторинге (monitoring, runtime verification, online verification, passive testing) поведение проверяемой системы в ходе ее обычной работы протоколируется и оценивается его соответствие требованиям и проектным решениям. Профилирование (profiling), при котором обычно измеряются показатели производительности, который может считаться частным случаем мониторинга из-за использования сходных техник, но имеет более конкретную цель – обычно измеряются показатели производительности. Довольно часто можно встретить употребление термина «профилирование» как для мониторинга, включающего контроль операций с памятью и взаимодействие параллельных потоков и процессов в системе. Подробная классификация видов верификационного мониторинга и профилирования может быть проведена на основании техники и инструментов, различающихся по видам протоколируемой ими информации, способу получения данных о работе ПО и способу получения оценок характеристик ПО, и соответствует конкретным методам осуществления мониторинга и профилирования при решении конкретных задач. Тем не менее, можно выделить следующие большие группы: – мониторинг и профилирование со стороны внешней среды – не производится какого-либо вмешательства в саму верифицируемую систему, все измерения и оценки каких-либо параметров производятся только стандартными внешними средствами целевой внешней среды, например оценкой со стороны операционной системы выделенных ресурсов, времени исполнения, частоты и длительности интервалов задействования вычислительных блоков, частоты обращения к тем или иным функциям; – мониторинг и профилирование с изменением – тем или иным способом изменяется сама верифицируемая система либо используется объемлющая система, отличающаяся от целевой объемлющей системы для возможности взаимодействия мониторинга, верифицируемой соответственно программной мониторинг и системы с системой профилирование путем инструментирования и симуляторный мониторинг и профилирование) – мониторинг и профилирование средствами самой верифицируемой системы – применимы, если соответствующие средства являются частью самой верифицируемой системы при её нормальном (обычном) функционировании, например учет объемов переданных и принятых данных, задействованных ресурсов памяти, скорости обработки информации. Виды тестирования Классификация видов тестирования достаточно сложна, потому что может проводиться по нескольким разным аспектам. По уровню или масштабу проверяемых элементов системы тестирование делится на следующие виды. Модульное или компонентное (unit testing, component testing) — проверка корректности работы отдельных компонентов системы, выполнения ими своих функций и предполагаемых проектом характеристик. Интеграционное (integration testing) — проверка корректности взаимодействий внутри отдельных групп компонентов. Системное (system testing) — проверка работы системы в целом, выполнения ею своих основных функций, с использованием определенных ресурсов, в окружении с заданными характеристиками. По проверяемым характеристикам качества тестирование может быть тестирование функциональности, производительности (и по времени, и по другим ресурсам), надежности, переносимости или удобства использования. Более специфические виды тестирования, нацеленные на оценку отдельных атрибутов, — тестирование защищенности, совместимости или восстановления при сбоях. Специфическим видом тестирования, нацеленным на минимизацию риска того, что в результате доработки или внесения ошибок качество системы изменилось в худшую сторону, является регрессионное тестирование (regression testing). При его проведении используется уже применявшийся ранее набор тестов, и оно должно выявить различия между результатами, полученными на этих тестах ранее, и наблюдаемыми после внесения изменений. По источникам данных, используемых для построения тестов, тестирование относится к одному из следующих видов. Функциональное называется тестирование тестированием (functional соответствия, testing, conformance часто testing, также или тестирование черного ящика, black-box testing) — нацелено на проверку соблюдения требований. Использует критерии полноты, основанные на требованиях, и техники построения тестов, использующие только информацию, заданную в требованиях к проверяемой системе. Частными случаями этого вида тестирования являются тестирование на соответствие стандартам и квалификационное или сертификационное тестирование, нацеленное на получение некоторого сертификата соответствия определенным требованиям или стандартам. Структурное тестирование (structural testing, также тестирование белого (прозрачного) ящика, white-box testing, glass-box testing) — нацелено на проверку корректности работы программы, представленной своим исходным текстом до автоматической трансляции. Использует критерии полноты и техники построения тестов, основанные на структуре проверяемой системы, ее исходных текстов. Тестирование серого ящика (grey-box testing) использует для построения тестов как информацию о требованиях, так и коде. На практике оно встречается чаще, чем предыдущие крайние случаи. Тестирование, нацеленное на ошибки — использует для построения тестов гипотезы о возможных или типичных ошибках в ПО такого же типа, как проверяемое. К этому типу относятся, например, следующие виды тестирования: – тестирование работоспособности (sanity testing, smoke testing), нацеленное на проверку того, в систему включены все ее компоненты и операции, и система не дает сбоев при выполнении своих основных функций в простейших сценариях использования; – тестирование на отказ, пытающееся найти ошибки в ПО, связанные с контролем корректности входных данных; – нагрузочное тестирование (load testing), проверяющее работоспособность ПО при больших нагрузках — больших объемах входных, выходных или промежуточных данных, большой сложности решаемых задач, большом количестве пользователей, работающих с ПО и пр. – тестирование в предельных режимах (stress testing), проверяющее работоспособность ПО на границах его возможностей и на границах той области, где оно должно использоваться. По роли команды, выполняющей тестирование, оно может относиться к следующим видам. Внутреннее тестирование выполняется в рамках проекта по разработке системы силами организации-разработчика ПО. Независимое тестирование выполняется третьими лицами (не разработчиками, не заказчиками и не пользователями) для получения объективных и аккуратных оценок качества системы. Аттестационное тестирование (приемочные испытания) выполняется представителями заказчика непосредственно перед приемкой системы в эксплуатацию для проверки того, что основные функции системы реализованы. Часто аттестационные тесты являются очень простыми тестами функциональности и производительности. Пользовательское тестирование осуществляется силами пользователей системы. У него есть два часто упоминаемых частных случая: – альфа-тестирование (alpha-testing) выполняется самими разработчиками, но в среде, максимально приближенной к рабочему окружению системы и на наиболее вероятных сценариях ее реального использования; – бета-тестирование (beta-testing) выполняется пользователями, желающими познакомиться с возможностями системы до ее официального выпуска и передачи в эксплуатацию. Динамическая верификация может быть также реальной или имитационной, в зависимости от того, используется в ее ходе само ПО, его прототип или исполнимая модель. Основное достоинство динамических методов верификации — возможность получить информацию о реальной работе ПО и о реальных показателях его функциональности, производительности, надежности или переносимости. Имитационные методы этого качества лишены и применяются на практике либо для валидации проектных решений, либо для верификации моделей очень сложных систем, для которых эти модели представляют самостоятельную ценность, например, потому, что они впоследствии будут автоматически оттранслированы в исходный тексты программ на языках высокого уровня.