3. Тестирование и отладка по. Основные принципы тестирования. Стратегии тестирования программных модулей. Методы структурного тестирования. (тп)

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

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

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

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

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

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

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

Формирование таблицы решений. Преобразование булевого графа в таблицу решений путём методического прослеживания состояний условий диаграммы.

Генерация тестового набора по столбцам таблицы решений.

Статическое и динамическое тестирование

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

Стати́ческий ана́лиз ко́да (англ. static code analysis) — анализ программного обеспечения, производимый без реального выполнения исследуемых программ (анализ, производимый с выполнением программ называется динамический анализ кода). В большинстве случаев анализ производится над какой-либо версией исходного кода, хотя иногда анализу подвергается какой-нибудь вид объектного кода, например P-код или код на MSIL. Термин обычно применяют к анализу, производимому специальным ПО, тогда как ручной анализ называют пониманием или постижением программы.

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

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

При тестировании белого ящика (структурное тестирование)(англ. white-box testing, также говорят — прозрачного ящика), разработчик теста имеет доступ к исходному коду и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции — работоспособны и устойчивы, до определенной степени.

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

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

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ № 10