Принципы верификации и тестирования по реферат

Обновлено: 04.07.2024

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

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

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

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

1. Общие сведения о верификации и аттестации ПО.

1.1. Введение в верификацию и аттестацию

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

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

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

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

На рис. 1.1 показано место инспектирования и тестирования в процессе разработки ПО. Стрелки указывают на те этапы процесса разработки, на которых можно применять данные методы.

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

Ключевые слова:верификация, статический анализ, динамический анализ, интерпретация, символьное выполнение, проверка модели

Одна из главных проблем при разработке программного обеспечения является верификация программного обеспечения. Средства верификации программного обеспечения создаются специально для подтверждения требованиям заявленного конечного программного продукта, сама цель верификации программного обеспечения является обнаружение ошибок, некорректных свойств и уязвимость программы [1, с. 129–134]. Актуальной проблемой является формирование новой классификации способов верификациипрограммного обеспечения, и дает возможность рассмотреть существующие в настоящее время методы верификации ПО, обнаружить их преимущество и недостатки. Классификация и анализ существующих способов дает создать список требований и рекомендаций для будущего исследования и разработкисинтетического метода верификации программного обеспечения, по принципу SMT — решателя.

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

Одна из главных целей верификации программного обеспечения является проверка созданного программного кода техническому заданию и ее требования функциональности [2, с. 285–288].

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

Понятие верификации программного обеспечения в одной из нотаций [3, с. 272] обозначает символьное выполнение программы или проверку кода на наличие ошибок и уязвимости способов проверки модели.

Широко используется в настоящее время техника символьного выполнения [4–5, с. 68–79, 374], что позволяет проводить моделирование выполнения программы, при этом часть переменных представляются в символьном виде. Символ переменной показывает, что большинство значении входной переменны программы из области ее определения. Каждое символьное выполнение равноценно выполнению ПО, в наборе конкретных текстовых значении переменных, котороесокращает мощность множества изобретаемых тестов. Тоже самое означает альтернативная семантика исполнения программы — семантика условного выполнение для языка программирования, в котором объекты данных представлены в виде символов. Для работы с символьными значениями для этого семантика показывает пути расширения основных конструкции языков программирования.

Главные этапы верификации программного обеспечения — это тестирование программ на пригодность провозглашенным качественным характеристикам. Самые важные характеристики ПО перечислены ниже:

Корректность (аналогично системе своего назначение);
Безопасность системы;
Устойчивость системы в случае недетерминированного поведения окружения (например, неправильные входные данные);
Эффективность использования ресурсов времени и памяти;
Адаптируемость системы к небольшим преобразованиям окружения;
Переносимость и совместимость.

Экспертиза является самым популярным методом тестирование программ [2, с. 285–288]. Другими словами, это анализ ПО, проводимым экспертом, который может быть и разработчиком так же лицом, или группой лиц, привлеченных со стороны, для оценки ПО.

Тестирование программного обеспечения выполняется группой квалифицированных специалистов, но невозможно выполнить автоматически потому, что все этапы выполняются экспертами. При том что этот способ имеет высокую функциональную пригодность и способен решать огромный круг задач тестирование программного обеспечения, при этом может быть применим к любым свойствам ПО на любом этапе тестирование программ. Качество экспертизы зависит от опыта специалистов, выполняющих ее. С помощью метода экспертизы обнаруживают от 50 до 90 % ошибок и уязвимостей ПО [7, с. 560]. Такой метод помогает обнаружить фактически любые виды ошибок и считается одним из лучших способов, но только если экспертизу проводят опытные специалисты. И самым главным преимуществом является то что тестирование возможно проводить на любом этапе разработки проекта. Срок выполнение тестирование зависит от сложности программы и опытности команды специалистов. Из чего следует, что приоритетом этого метода является возможность использовать на любом этапе проекта и быстро устранить ошибки и уязвимости.

Формальные методы верификации — это верификация математической модели программы, а не ее исходный код. Требования к программе определяется в виде спецификации, то есть проверяется требование спецификации на модели программы. [1, с. 129–134]

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

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

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

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

В настоящем мире существуют две самые популярные группы методов статической верификации: это методы дедуктивного исследования программ метод проверки модели [11, с. 293–326].

Методы дедуктивного анализа применяется на основании пригодностипрограммы своей спецификации, как правило задаваемый в виде пред и постусловий. На данном уровне прогресс — это инструменты не пригодны для исследования больших программ потому, что требуют ручной аннотации функции и циклов в коде программы [13, с. 452].

Способы проверки модели основываются из кода программы и создают ее математическую модель, обычно в качестве модели используют Крипк [13, с. 452], после этого анализируют эту модель на предмет исполнения установленных условии и ограничений.

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

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

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

Мониторинг — это такой метод, при котором исходит проверка, регистрация и оценка работы ПО [2, с. 285–288]. Протоколируемая информация подчиняется от оценки характеристик системы. Получая данные о работе, при этом используются разные методы инструментированная и это все является мониторинг.

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

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

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

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

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

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

Метод динамического исследование также имеет недочеты, прежде всего недостатком этого метода является огромное количество ошибочных срабатываний. Величина ошибочных срабатывании при использовании новейших инструментов исследования порядочно велико и составляет, от 20 до 30 % [15-16, с. 514–518], все-таки динамический анализ — это порядочно эффективный метод для проверки программного обеспечения на присутствие уязвимости.

1. Бурякова Н. А., Чернов А. В. Классификация частично формализованных и формальных моделей и методов верификации программного обеспечения // Инженерный Вестник Дона. 2014. № 4. 129–134 c.

4. Глухих М. И., Ицыксон В. М., Цесько В. А. Использование зависимостей для повышения точности статического анализа программ // Моделирование и анализ информационных систем. 2011. № 4. 68–79 c.

5. Гурин Р. Е. Обзор и анализ инструментов, который осуществляют верификацию бинарного кода программы // Новые информационные технологии в автоматизированных системах: материалы 17-го научно-практического семинара. Вып. 17. М.: ИПМ им. М. В. Келдыша, 2014. 514–518. 421 с.

7. Канер Кем, Фолк Джек, Нгуен Енг Кек.Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений. — Киев: ДиаСофт, 2001. — 544 с. —ISBN 9667393879.

8. Карпов Ю. Г. MODEL CHECKING. Верификация параллельных и распределенных программных систем. СПб.: БХВ-Петербург, 2015. 560 с.

10. Лаврищева Е. М., Петрухин В. А. Методы и средства инженерии программного обеспечения: учебник. М.: МФТИ, 2009. 304 с.

12. Мандрыкин М. У., Мутилин В. С., Новиков Е. М., Хорошилов А. В. Обзор инструментов статической верификации С программ в применении к драйверам устройств операционной системы Linux // Сборник трудов Института системного программирования РАН. Т. 22. М.: ИСП РАН, 2012. C. 293–294. DOI: 10.15014/ISPRAS-2012–22–17. 345 c.

13. Рудаков И. В., Гурин Р. Е., Ребриков А. В. Верификация программного обеспечения: обзор методов и характеристик // Национальная ассоциация ученых (НАУ). Ежемесячный журнал. 2014. № 3, ч. 2. 22–26 c.

14. Beyer B. Status repоrt on software verification (competition summary SV-COMP 2014) // Tools and Algorithms for the Construction and Analysis of Systems / ed. by E. Abraham, K. Havelund. Springer Berlin Heidelberg, 2014. P. 373–388. DOI: 10.1007/978–3-642–54862-8_25 (Ser. Lecture Notes in Computer Science; vol. 8413.).377 c.

15. Boehmn B., Basilir V. Top 10 list [software development] // IEEE Computer. 2001. Vol. 34, no. 1. P. 135–137. DOI: 10.1109/2.962984. 136 c.

16. Boywer R. S., Elspaser B., Levitt K. N. SELECT — a formal system for testing and debugging programs by symbolic execution // Proceedings of the International Conference on Reliable Software, Los Angeles, California, 1985. ACM New York, NY, USA, 1985. P. 234–254. DOI: 10.1145/800027.808445. 244 c.

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

Под верификацией понимается процесс определения, в какой степени программные средства выполняют наложенные на них требования. Функции, выполняемые верификацией, определены в стандарте “ISO 12207” (SoftWare LifeCycle Processes. Процессы жизненного цикла программных средств).

В соответствии с требованиями стандарта “ISO 12207” процессы верификации программного средства включают в себя следующие задачи:

Во-первых, в том, что поставщик имеет возможность удовлетворить требования контракта;

Во-вторых, в том, что требования непротиворечивы и покрывают все нужды пользователя;

В-третьих, в том, что предусмотрены адекватные процедуры для регулирования изменений требований и возрастающих проблем;

В-четвертых, в том, что предусмотрены процедуры и их приложение на сотрудничество между сторонами, включая право собственности, гарантию, авторское право и конфиденциальность;

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

Во-первых, в том, что требования проектного планирования адекватны и скоординированы во времени;

Во-вторых, в том, что процессы, выбранные для проекта, адекватны, реализуемы, выполняются, как запланировано и соответствуют контракту;

В-третьих, в том, что стандарты, процедуры и область функционирования адекватны для проектных процедур;

В-четвертых, в том, что проект укомплектован ресурсами, и персонал обучен, как требуется по контракту.

Во-первых, в том, что требования системы непротиворечивы, выполнимы и проверяемы;

Во-вторых, в том, что требования системы распределены между компонентами аппаратных средств, компонентами программного средства и ручными операциями согласно критериям проекта;

В-третьих, в том, что требования к программному средству последовательны, выполнимы, тестируемы и точно отражают требования системы;

В-четвертых, в том, что требования к программному средству, связанные с безопасностью, защитой и критичностью правильны, как показано соответствующими точными методами анализа.

Во-первых, в том, что проект корректен и не противоречит исходным требованиям контракта;

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

В-третьих, в том, что выбранный проект полностью исходит от требований;

В-четвертых, в том, что проект реализует безопасность, защищенность и другие критические требования, правильно, как показано соответствующими точными методами анализа.

Во-первых, в том, что текст программы удовлетворяет проекту и требованиям, тестируем, корректен и соответствует стандартам программирования;

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

В-третьих, в том, что программа исходит из проекта и требований контракта;

В-четвертых, в том, что программа обеспечивает безопасность, защищенность и другие критические требования корректно, как показано соответствующими точными методами анализа.

Во-первых, в том, что компоненты программного средства и элементы каждого компонента программного средства полностью и правильно интегрированы в комплекс программ;

Во-вторых, в том, что компоненты аппаратных средств, компоненты программного средства и ручные операции полностью и правильно интегрированы в информационную систему;

В-третьих, в том, что интеграционные задачи выполнены согласно интеграционному плану.

Во-первых, в том, что документация адекватна, полна и последовательна;

Во-вторых, в том, что подготовка документации выполнена своевременно;

В-третьих, в том, что схема управления документами следует определенным плановым процедурам.

Для повышения эффективности затрат при реализации проекта, верификация должна быть выполнена как можно раньше.

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

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

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

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

Выполняя тестирование необходимо, во-первых, проверить, делает ли данный программный продукт то, для чего он предназначен; во-вторых, проверить, не делает ли данный программный продукт, то, что он не должен делать.

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

При разработке тестов необходимо исходить из того, что исчерпывающее тестирование для всех входных данных невозможно. Поэтому каждый тест должен давать максимальную отдачу по сравнению с произведенными затратами. Отдача теста измеряется вероятностью того, что тест выявит не обнаруженную прежде ошибку. Затраты измеряются стоимостью подготовки теста, стоимостью его выполнения, и стоимостью анализа результатов теста.

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

Разработка тестов должна соответствовать международным и российским стандартам. Можно выделить следующие стандарты:

Стандарт ISO 12119 (“ Пакеты программ. Требования к качеству и тестирование”). Данный стандарт содержит раздел, который кратко определяет порядок тестирования программного продукта на соответствие данного программного продукта требованиям к качеству. Данные указания охватывают как тестирование для характеристик, присущих всем аналогичным продуктам, так и тестирование для особых характеристик, декларированных в описании данного программного продукта.

В стандарте ANSI/IEEE 1008 (“Тестирование программных модулей и компонентов ПС”) рассмотрена методика отладки отдельных модулей и небольших групп программ. Целями данного стандарта являются создание единого подхода к тестированию компонентов программного средства, который может быть использован на практике в качестве основы для получения эффективных ПС, а также описание концепций и допущений, принимаемых при тестировании.

Эффективная организация тестирования должна основываться на соблюдении следующей совокупности принципов.

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

Принцип проектирования тестирования. Данный принцип требует рассмотрения вопросов тестирования на всех этапах проектирования программного обеспечения.

Принцип моделирования. Данный принцип предусматривает предварительное построение моделей. Моделирование позволяет обеспечить разработку и проверку тестов до разработки основных элементов программного обеспечения.

Принцип выборочного контроля. Тестирование не может быть исчерпывающим, поэтому для контроля выбирают определенную совокупность данных.

Принцип стандартизации. Стандартизация важна как средство для упрощения проблем тестирования и развития методологии получения надежных средств программного обеспечения.

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

Можно выделить два вида тестирования:

Во-первых, структурное тестирование;

Во-вторых, функциональное тестирование.

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

Полное покрытие всей логики программы, т.е. исчерпывающее тестирование, предполагает выполнение программы по всем маршрутам передач управления. Если программа содержит цикл, то полное тестирование предполагает необходимость расчета по каждому из вариантов цикла. Например, если циклически повторяется обработка записей трех наборов данных, каждый из которых может содержать до 10 тысяч записей, то полное тестирование предполагает создание, по меньшей мере 10000*10000*10000 тестов. Если алгоритм будет содержать логическую обработку, то количество необходимых тестов при полном тестировании многократно возрастает. Поэтому при тестировании путем покрытия логики программы при создании теста ориентируются не на полный тест, а на тест, отвечающий требуемому критерию. Для создания тестов при структурном тестировании могут быть использованы следующие методы:

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

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

Реальное тестирование с применением управления по данным ограничивается использованием небольшого подмножества всех возможных данных. Тесты, которые позволяют обнаружить ошибки одного типа, объединяются в классы эквивалентности.

Можно выделить следующие методы функционального тестирования:

При выделении классов различают правильные классы эквивалентности и неправильные классы эквивалентности. Правильные классы эквивалентности представляют правильные входные данные программы. Неправильные классы эквивалентности представляют ошибочные входные данные.

Отличительные особенности анализа граничных значений заключаются в следующем:

Во-первых, в том, что элементы в класс эквивалентности выбираются таким образом, чтобы проверить тестом каждую границу класса эквивалентности;

Во-вторых, при разработке тестов рассматриваются не только входные, но и выходные классы эквивалентности.

Следует отметить следующие особенности функционального тестирования:

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

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

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

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

Для выполнения тестирования создается программная среда, которая обеспечивает запуск и выполнение тестируемого модуля, передаёт ему входные данные, и собирает реальные выходные данные, полученные в результате работы системы на заданных входных данных. После этого, программная среда тестирования должна сравнить реальные выходные данные, с ожидаемыми данными, и на основании выполненного сравнения сделать вывод о готовности модуля. Программная среда тестирования может иметь следующий вид:

Можно выделить следующие инструментальные средства программной среды тестирования:

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

В стандарте ANSI/IEEE 1012 (“Планирование проверки (оценки) и подтверждения достоверности (валидация — аттестация) программных средств”) понятие валидации определено, как систематическое, поэтапное тестирование компонентов разного уровня интеграции в течение всего жизненного цикла программных средств. В стандарте оговорены единые требования, предъявляемые к формату и содержимому методик проверки программного средства и аттестации результатов тестирования. Данный стандарт обеспечивает всестороннюю оценку каждой фазы проекта программного средства и дает возможность гарантировать соблюдение следующих условий:

Во-первых, обнаружение и устранение ошибок на как можно более ранней стадии жизненного цикла ПС;

Во-вторых, снижение риска, связанного с проектом, затрат и действий, связанных с планированием разработки;

В-третьих, повышение качества и надежности ПС;

В-четвертых, улучшение обозримости организации проведения работ в процессе создания ПС;

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

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

Рис. 1 Тестирование, верификация и валидация

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

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

Но далеко не всегда продукт, соответствующий установленным требованиям, можно применять в конкретной ситуации. Например, лекарство прошло все положенные испытания и поступило в продажу. Значит ли это что оно может быть применено каким-то конкретным больным? Нет, так как каждый пациент имеет свои особенности и конкретно для этого лекарство может быть губительным, то есть кто-то (врач) должен подтвердить: да, этому больному можно принимать это лекарство. То есть врач должен выполнить валидацию: придать законную силу конкретному применению.

Или еще пример. Предприятие выпускает трубы, предназначенные для закладки в землю, в соответствии с некоторыми ТУ (Техническими условиями). Продукция этим ТУ соответствует, но поступил заказ, предполагающий укладку труб по дну моря. Могут ли трубы, соответствующие имеющимся ТУ, быть применены в данном случае? Именно валидация и дает ответ на этот вопрос.

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

Таким образом, можно констатировать следующее:

- верификация — проводится практически всегда, выполняется методом проверки (сличения) характеристик продукции с заданными требованиями, результатом является вывод о соответствии (или несоответствии) продукции,

- валидация — проводится при необходимости, выполняется методом анализа заданных условий применения и оценки соответствия характеристик продукции этим требованиям, результатом является вывод о возможности применения продукции для конкретных условий.

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

Читайте также: