Тестирование белого ящика
 | Эта статья нуждается в дополнительных ссылок для проверки . ( февраль 2013 г. ) |
| Системы черного ящика | |
|---|---|
 | |
| Система | |
| Черный ящик , машина Oracle | |
| Методы и техники | |
| Тестирование «черного ящика» , «черный ящик» | |
| Связанные методы | |
| Упреждение , Обфускация , Распознавание образов , Белый ящик , Тестирование белого ящика , Тестирование серого ящика , Идентификация системы | |
| Основы | |
| Априорная информация , Системы управления , Открытые системы , Исследование операций , Термодинамические системы | |
| Часть серии о |
| Разработка программного обеспечения |
|---|
Тестирование белого ящика (также известное как тестирование «прозрачного ящика» , тестирование «стеклянного ящика» , тестирование «прозрачного ящика» и структурное тестирование ) — это метод тестирования программного обеспечения , который проверяет внутренние структуры или работу приложения, а не его функциональность (т. е. « черный ящик»). тестирование ). При тестировании «белого ящика» для разработки тестовых примеров используется внутренняя перспектива системы. Тестер выбирает входные данные для проверки путей прохождения кода и определения ожидаемых выходных данных. Это аналогично тестированию узлов в цепи, например, внутрисхемному тестированию (ICT). Тестирование белого ящика может применяться на уровне модуля , интеграции и системы процесса тестирования программного обеспечения. Хотя традиционные тестировщики склонны думать, что тестирование «белого ящика» проводится на уровне модуля, сегодня оно чаще используется для тестирования интеграции и системы. Он может тестировать пути внутри модуля, пути между модулями во время интеграции и между подсистемами во время тестирования на уровне системы. Хотя этот метод проектирования тестов может выявить множество ошибок или проблем, он потенциально может пропустить нереализованные части спецификации или недостающие требования. Там, где тестирование «белого ящика» основано на дизайне, [1] то есть, руководствуясь исключительно согласованными спецификациями того, как должен вести себя каждый компонент программного обеспечения (как в процессах DO-178C и ISO 26262 ), методы тестирования «белого ящика» могут выполнить оценку нереализованных или отсутствующих требований.
Методы проектирования тестов «белого ящика» включают следующие покрытия кода критерии :
- потока управления Тестирование
- Тестирование потока данных
- Тестирование филиалов
- Покрытие заявлений
- Охват решений
- Измененное покрытие условий/решений
- Тестирование основного пути
- Тестирование пути
Обзор [ править ]
Тестирование белого ящика — это метод тестирования приложения на уровне исходного кода. Эти тестовые примеры создаются с использованием упомянутых выше методов проектирования: тестирование потока управления , тестирование потока данных, тестирование ветвей, тестирование пути, покрытие операторов и покрытие решений, а также покрытие модифицированных условий/решений. Тестирование белого ящика — это использование этих методов в качестве рекомендаций для создания безошибочной среды путем проверки всего кода. Эти методы тестирования «белого ящика» являются строительными блоками тестирования «белого ящика», суть которого заключается в тщательном тестировании приложения на уровне исходного кода для уменьшения скрытых ошибок в дальнейшем. [2] Эти различные методы используют каждый видимый путь исходного кода, чтобы минимизировать ошибки и создать безошибочную среду. Весь смысл тестирования «белого ящика» заключается в возможности узнать, какая строка кода выполняется, и в возможности определить, каким должен быть правильный результат. [2]
Уровни [ править ]
- Модульное тестирование . Тестирование белого ящика проводится во время модульного тестирования, чтобы убедиться, что код работает должным образом, прежде чем произойдет интеграция с ранее протестированным кодом. Тестирование «белого ящика» во время модульного тестирования потенциально выявляет многие дефекты на ранних этапах и помогает устранить дефекты, которые возникают позже, после интеграции кода с остальной частью приложения, и, следовательно, снижает влияние ошибок на более поздних стадиях разработки. [2]
- Интеграционное тестирование . Тестирование белого ящика на этом уровне предназначено для проверки взаимодействия интерфейсов друг с другом. Тестирование на модульном уровне позволило убедиться, что каждый код был протестирован и работает соответствующим образом в изолированной среде, а интеграция проверяет правильность поведения в открытой среде посредством использования тестирования «белого ящика» для любых взаимодействий интерфейсов, которые известны программисту. [2]
- Регрессионное тестирование . Тестирование «белого ящика» во время регрессионного тестирования — это использование переработанных тестовых примеров «белого ящика» на уровне модульного и интеграционного тестирования. [2]
Основная процедура [ править ]
Основные процедуры тестирования «белого ящика» требуют от тестировщика глубоких знаний тестируемого исходного кода. Программист должен иметь глубокое понимание приложения, чтобы узнать, какие виды тестовых случаев создавать, чтобы каждый видимый путь использовался для тестирования. Как только исходный код будет понятен, его можно будет проанализировать для создания тестовых примеров. Ниже приведены три основных шага, которые необходимо выполнить при тестировании «белого ящика» для создания тестовых примеров:
- Входные данные включают в себя различные типы требований, функциональные спецификации, детальное проектирование документов, правильный исходный код и спецификации безопасности. [ нужна цитата ] Это подготовительный этап тестирования «белого ящика» для предоставления всей основной информации.
- Обработка включает в себя проведение анализа рисков для управления всем процессом тестирования, правильного плана тестирования, выполнения тестовых примеров и передачи результатов. [ нужна цитата ] Это этап создания тестовых примеров, позволяющий убедиться, что приложение тщательно протестировано, а полученные результаты соответствующим образом записываются.
- Результат включает подготовку итогового отчета, который включает в себя все вышеперечисленные приготовления и результаты. [ нужна цитата ]
Преимущества [ править ]
- Побочные эффекты знания исходного кода полезны для тщательного тестирования. [ нужна цитата ]
- Оптимизация кода становится проще, поскольку выявляются незаметные узкие места. [ нужна цитата ]
- Дает программисту возможность самоанализа, поскольку разработчики тщательно описывают любую новую реализацию. [ нужна цитата ]
- Обеспечивает прослеживаемость тестов из источника, что позволяет легко запечатлеть будущие изменения в источнике в недавно добавленных или модифицированных тестах. [3]
- Легко автоматизировать. [4]
- Предоставляет четкие, инженерно обоснованные правила, определяющие, когда следует прекратить тестирование. [5] [4]
Недостатки [ править ]
|
- Тесты белого ящика пишутся для проверки деталей конкретной реализации. Это означает, что тесты завершатся неудачей при изменении реализации, поскольку тест тесно связан с реализацией. Необходимо провести дополнительную работу по обновлению тестов, чтобы они снова соответствовали реализации при ее изменении. С другой стороны, при тестировании «черного ящика» тесты независимы от реализации, поэтому они все равно будут выполняться успешно, если реализация изменится, а выходные данные или побочные эффекты реализации — нет.
- Тестный код, тестируемый код, может быть переписан, чтобы реализовать одну и ту же функциональность по -другому, что лишено недействительным предположениям, зачитываемым в тесте. Это может привести к ненужному сбою тестов или, в худшем случае, к тестам, которые теперь дают ложные срабатывания и маскируют ошибки в коде. Тест белого ящика никогда не был написан таким образом, чтобы проверять предполагаемое поведение тестируемого кода, а только таким, чтобы конкретная реализация делала то, что делает.
- Тестирование «белого ящика» усложняет тестирование, потому что тестировщик должен знать программу, или в команде тестирования должен быть хотя бы один очень хороший программист, который может понимать программу на уровне кода. Тестирование белого ящика требует от программиста высокого уровня знаний из-за сложности уровня тестирования, которое необходимо выполнить.
- В некоторых случаях невозможно протестировать каждое существующее состояние приложения, и некоторые условия остаются непроверенными.
- Тесты сосредоточены на программном обеспечении в том виде, в котором оно существует, и недостающие функции могут быть не обнаружены.
Современный вид [ править ]
Более современная точка зрения заключается в том, что дихотомия между тестированием «белого ящика» и тестированием «черного ящика» размыта и становится менее актуальной. Если первоначально «белый ящик» означал использование исходного кода, а «черный ящик» означал использование требований, то теперь тесты создаются на основе множества документов на различных уровнях абстракции. Реальная точка заключается в том, что тесты обычно разработаны из абстрактной структуры, такой как входное пространство, график или логические предикаты, и вопрос в том, от какого уровня абстракции мы получаем эту абстрактную структуру. [4] Это может быть исходный код, требования, описания входного пространства или один из десятков типов моделей проектирования. Следовательно, различие «белого ящика / черного ящика» менее важно, и термины менее актуальны. [ нужна цитата ]
Взлом [ править ]
В тестировании на проникновение тестирование «белого ящика» относится к методу, при котором хакер в белой шляпе имеет полное знание атакуемой системы. Целью теста на проникновение «белого ящика» является имитация злонамеренного инсайдера, обладающего знаниями и, возможно, базовыми учетными данными для целевой системы.
См. также [ править ]
Ссылки [ править ]
- ^ Стейси Нельсон (июнь 2003 г.), NASA/CR–2003-212806 Процессы сертификации критически важного для безопасности и критически важного аэрокосмического программного обеспечения (PDF) , Исследовательский центр Эймса , стр. 25,
[Глоссарий] Тестирование белого ящика: тестирование , основанное на проектировании , при котором инженеры исследуют внутреннюю работу кода.
- ^ Перейти обратно: а б с д Это Уильямс, Лори . «Тестирование белого ящика» (PDF) . стр. 60–61, 69. Архивировано из оригинала (PDF) 3 марта 2016 года . Проверено 13 февраля 2013 г. [ нужна проверка ]
- ^ Биндер, Боб (2000). Тестирование объектно-ориентированных систем . издательской компании Addison-Wesley Publishing Company Inc. ISBN 9780201809381 .
- ^ Перейти обратно: а б с Амманн, Пол; Оффатт, Джефф (2008). Введение в тестирование программного обеспечения . Издательство Кембриджского университета. ISBN 978-0-521-88038-1 .
- ^ Майерс, Гленфорд (1979). Искусство тестирования программного обеспечения . Джон Уайли и сыновья. ISBN 9780471043287 .
Внешние ссылки [ править ]
- BCS SIGIST (Группа специалистов Британского компьютерного общества по тестированию программного обеспечения): http://www.testingstandards.co.uk/Component%20Testing.pdf Стандарт тестирования компонентов программного обеспечения ], рабочий проект 3.4, 27 апреля 2001 г.
- http://agile.csc.ncsu.edu/sematerials/whitebox.pdf имеет больше информации о тестировании потока управления и тестировании потока данных.
- http://research.microsoft.com/en-us/projects/pex/ Pex – автоматическое тестирование «белого ящика» для .NET.