stringtranslate.com

Тестирование белого ящика

Тестирование белого ящика (также известное как тестирование «прозрачного ящика» , тестирование «стеклянного ящика» , тестирование «прозрачного ящика » и структурное тестирование ) — это метод тестирования программного обеспечения , который проверяет внутренние структуры или работу приложения, а не его функциональность (т. е. « черный ящик»). тестирование ). При тестировании «белого ящика» для разработки тестовых примеров используется внутренняя перспектива системы. Тестер выбирает входные данные для проверки путей прохождения кода и определения ожидаемых выходных данных. Это аналогично тестированию узлов в цепи, например, внутрисхемному тестированию (ICT). Тестирование белого ящика может применяться на уровне модуля , интеграции и системы процесса тестирования программного обеспечения. Хотя традиционные тестировщики склонны думать, что тестирование «белого ящика» проводится на уровне модуля, сегодня оно чаще используется для тестирования интеграции и системы. Он может тестировать пути внутри модуля, пути между модулями во время интеграции и между подсистемами во время тестирования на уровне системы. Хотя этот метод проектирования тестов может выявить множество ошибок или проблем, он потенциально может пропустить нереализованные части спецификации или недостающие требования. Если тестирование «белого ящика» основано на проектировании [1] , то есть определяется исключительно согласованными спецификациями того, как должен вести себя каждый компонент программного обеспечения (как в процессах DO-178C и ISO 26262 ), методы тестирования «белого ящика» могут обеспечить достижение результатов. оценка невыполненных или отсутствующих требований.

Методы проектирования тестов «белого ящика» включают следующие критерии покрытия кода :

Обзор

Тестирование белого ящика — это метод тестирования приложения на уровне исходного кода. Эти тестовые примеры создаются с использованием упомянутых выше методов проектирования: тестирование потока управления , тестирование потока данных, тестирование ветвей, тестирование пути, покрытие операторов и покрытие решений, а также покрытие модифицированных условий/решений. Тестирование белого ящика — это использование этих методов в качестве рекомендаций для создания безошибочной среды путем проверки всего кода. Эти методы тестирования «белого ящика» являются строительными блоками тестирования «белого ящика», суть которого заключается в тщательном тестировании приложения на уровне исходного кода для уменьшения скрытых ошибок в дальнейшем. [2] Эти различные методы используют каждый видимый путь исходного кода, чтобы минимизировать ошибки и создать безошибочную среду. Весь смысл тестирования «белого ящика» заключается в возможности узнать, какая строка кода выполняется, и в возможности определить, каким должен быть правильный результат. [2]

Уровни

  1. Модульное тестирование . Тестирование белого ящика проводится во время модульного тестирования, чтобы убедиться, что код работает должным образом, прежде чем произойдет интеграция с ранее протестированным кодом. Тестирование «белого ящика» во время модульного тестирования потенциально выявляет многие дефекты на ранних этапах и помогает устранить дефекты, которые возникают позже, после интеграции кода с остальной частью приложения, и, следовательно, снижает влияние ошибок на более поздних стадиях разработки. [2]
  2. Интеграционное тестирование . Тестирование белого ящика на этом уровне предназначено для проверки взаимодействия интерфейсов друг с другом. Тестирование на модульном уровне позволило убедиться, что каждый код был протестирован и работает соответствующим образом в изолированной среде, а интеграция проверяет правильность поведения в открытой среде посредством использования тестирования «белого ящика» для любых взаимодействий интерфейсов, которые известны программисту. [2]
  3. Регрессионное тестирование . Тестирование «белого ящика» во время регрессионного тестирования — это использование переработанных тестовых примеров «белого ящика» на уровне модульного и интеграционного тестирования. [2]

Основная процедура

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

  1. Входные данные включают в себя различные типы требований, функциональные спецификации, детальное проектирование документов, правильный исходный код и спецификации безопасности. [ нужна цитация ] Это подготовительный этап тестирования «белого ящика», на котором выкладывается вся основная информация.
  2. Обработка включает в себя проведение анализа рисков для управления всем процессом тестирования, правильного плана тестирования, выполнения тестовых примеров и передачи результатов. [ нужна цитация ] Это этап создания тестовых примеров, чтобы убедиться, что они тщательно протестируют приложение, и данные результаты записываются соответствующим образом.
  3. Результат включает подготовку окончательного отчета, который включает в себя все вышеперечисленные приготовления и результаты. [ нужна цитата ]

Преимущества

  1. Побочные эффекты знания исходного кода полезны для тщательного тестирования. [ нужна цитата ]
  2. Оптимизация кода становится проще, поскольку выявляются незаметные узкие места. [ нужна цитата ]
  3. Дает программисту возможность самоанализа, поскольку разработчики тщательно описывают любую новую реализацию. [ нужна цитата ]
  4. Обеспечивает отслеживаемость тестов из источника, тем самым позволяя легко фиксировать будущие изменения в источнике во вновь добавленных или измененных тестах. [3]
  5. Легко автоматизировать. [4]
  6. Предоставляет четкие, инженерно обоснованные правила, определяющие, когда следует прекратить тестирование. [5] [4]

Недостатки

  1. Тесты белого ящика пишутся для проверки деталей конкретной реализации. Это означает, что тесты завершатся неудачей при изменении реализации, поскольку тест тесно связан с реализацией. Необходимо провести дополнительную работу по обновлению тестов, чтобы они снова соответствовали реализации при ее изменении. С другой стороны, при тестировании «черного ящика» тесты независимы от реализации, и поэтому они все равно будут выполняться успешно, если реализация изменится, а выходные данные или побочные эффекты реализации — нет.
  2. Тестируемый код можно переписать, чтобы реализовать ту же функциональность другим способом, что сделает недействительными предположения, заложенные в тест. Это может привести к ненужному сбою тестов или, в худшем случае, к тестам, которые теперь дают ложные срабатывания и маскируют ошибки в коде. Тест белого ящика никогда не был написан таким образом, чтобы он проверял предполагаемое поведение тестируемого кода, а только так, чтобы конкретная реализация делала то, что делает.
  3. Тестирование «белого ящика» усложняет тестирование, потому что тестировщик должен знать программу, или в команде тестирования должен быть хотя бы один очень хороший программист, который может понимать программу на уровне кода. Тестирование белого ящика требует от программиста высокого уровня знаний из-за сложности уровня тестирования, которое необходимо выполнить.
  4. В некоторых случаях невозможно протестировать каждое существующее состояние приложения, и некоторые условия остаются непроверенными.
  5. Тесты сосредоточены на программном обеспечении в том виде, в котором оно существует, и недостающие функции могут быть не обнаружены.

Современный вид

Более современная точка зрения заключается в том, что дихотомия между тестированием «белого ящика» и тестированием «черного ящика» размыта и становится менее актуальной. Если первоначально «белый ящик» означал использование исходного кода, а «черный ящик» означал использование требований, то теперь тесты создаются на основе множества документов на различных уровнях абстракции. Суть в том, что тесты обычно разрабатываются на основе абстрактной структуры, такой как входное пространство, граф или логические предикаты, и вопрос в том, на каком уровне абстракции мы получаем эту абстрактную структуру. [4] Это может быть исходный код, требования, описания входного пространства или один из десятков типов проектных моделей. Следовательно, различие между «белым ящиком» и «черным ящиком» менее важно, а сами термины менее актуальны. [ нужна цитата ]

Взлом

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

Смотрите также

Рекомендации

  1. ^ Стейси Нельсон (июнь 2003 г.), NASA/CR-2003-212806 Процессы сертификации критически важного для безопасности и критически важного аэрокосмического программного обеспечения (PDF) , Исследовательский центр Эймса , стр. 25, [Глоссарий] Тестирование белого ящика: тестирование , основанное на проектировании, при котором инженеры исследуют внутреннюю работу кода.
  2. ^ abcde Уильямс, Лори . «Тестирование белого ящика» (PDF) . стр. 60–61, 69. Архивировано из оригинала (PDF) 3 марта 2016 года . Проверено 13 февраля 2013 г.[ нужна проверка ]
  3. ^ Биндер, Боб (2000). Тестирование объектно-ориентированных систем . ISBN издательской компании Addison-Wesley Publishing Company Inc. 9780201809381.
  4. ^ abc Амманн, Пол; Оффатт, Джефф (2008). Введение в тестирование программного обеспечения. Издательство Кембриджского университета. ISBN 978-0-521-88038-1.
  5. ^ Майерс, Гленфорд (1979). Искусство тестирования программного обеспечения . Джон Уайли и сыновья. ISBN 9780471043287.

Внешние ссылки