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] Это может быть исходный код, требования, описания входного пространства или один из десятков типов моделей проектирования. Поэтому различие «белый ящик / черный ящик» менее важно, а термины менее актуальны. [ необходима цитата ]

Взлом

В тестировании на проникновение тестирование «белого ящика» относится к методу, при котором хакер «белой шляпы» имеет полное представление об атакуемой системе. [6] Целью теста на проникновение «белого ящика» является имитация злонамеренного внутреннего нарушителя, имеющего знания и, возможно, основные учетные данные для целевой системы. Для такого теста на проникновение обычно предоставляются административные учетные данные для анализа того, как или какие атаки могут повлиять на высокопривилегированные учетные записи. [7] Исходный код может быть предоставлен для использования в качестве справочного материала для тестировщика. Когда код сам по себе является целью, это не (только) тест на проникновение, но и аудит безопасности исходного кода (или обзор безопасности). [8]

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

Ссылки

  1. ^ Стейси Нельсон (июнь 2003 г.), NASA/CR–2003-212806 Процессы сертификации для критически важного для безопасности и критически важного для аэрокосмической отрасли программного обеспечения (PDF) , Исследовательский центр Эймса , стр. 25, [Глоссарий] Тестирование методом белого ящика: тестирование, основанное на дизайне , при котором инженеры изучают внутреннюю работу кода.
  2. ^ abcde Уильямс, Лори . «Тестирование методом белого ящика» (PDF) . стр. 60–61, 69. Архивировано из оригинала (PDF) 3 марта 2016 г. Получено 13 февраля 2013 г.[ требуется проверка ]
  3. ^ Биндер, Боб (2000). Тестирование объектно-ориентированных систем . Addison-Wesley Publishing Company Inc. ISBN 9780201809381.
  4. ^ abc Амманн, Пол; Оффатт, Джефф (2008). Введение в тестирование программного обеспечения. Cambridge University Press. ISBN 978-0-521-88038-1.
  5. ^ Майерс, Гленфорд (1979). Искусство тестирования программного обеспечения . John Wiley and Sons. ISBN 9780471043287.
  6. ^ "Модель тестирования на проникновение" (PDF) . Федеральное управление по информационной безопасности (BSI).
  7. ^ Баран, Эвелина. «Типы тестирования на проникновение». Blaze Information Security GmbH . Получено 12 сентября 2024 г.
  8. ^ Салливан, Джеймс. «Что такое аудит кода: понимание его цели и процесса». 17 Web Dev, LLC . Получено 12 сентября 2024 г.

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