Тестирование белого ящика
 | Эта статья нуждается в дополнительных цитатах для проверки . ( февраль 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.