Тестирование ПО. Основные принципы тестирования. Структурное и функциональное тестирование. Методы функционального тестирования. (ТП)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если «альфа-» и «бета-тестирование» относятся к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «черного ящика» имеет отношение к способам, которыми тестировщик достигает цели.

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

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

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

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

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

Несоответствие поведения системы требованиям

Неадекватное поведение системы в ситуациях, не предусмотренных требованиями.

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

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