Тестирование белого ящика (также известное как ясный тестирования окна , тестирование стекла коробки , тестирование прозрачной коробки , и структурное тестирование ) является методом тестирования программного обеспечения , которое проверяет внутренние структуры или выработок приложения, в отличие от его функциональности (то есть черный ящик тестирование ). При тестировании методом белого ящика для разработки тестовых примеров используется внутренняя перспектива системы, а также навыки программирования. Тестировщик выбирает входные данные для отработки путей прохождения кода и определяет ожидаемые результаты. Это аналогично тестированию узлов в цепи, например, внутрисхемному тестированию (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 . Проверено 13 февраля 2013 года . Цитировать журнал требует
|journal=
( помощь )[ требуется проверка ] - ^ Биндер, Боб (2000). Тестирование объектно-ориентированных систем . Addison-Wesley Publishing Company Inc.
- ^ а б в Амманн, Пауль; Оффатт, Джефф (2008). Введение в тестирование программного обеспечения . Издательство Кембриджского университета. ISBN 978-0-521-88038-1.
- ^ Майерс, Гленфорд (1979). Искусство тестирования программного обеспечения . Джон Уайли и сыновья.
Внешние ссылки
- BCS SIGIST (Группа специалистов Британского компьютерного общества по вопросам тестирования программного обеспечения): http://www.testingstandards.co.uk/Component%20Testing.pdf Standard for Software Component Testing ], Working Draft 3.4, 27. April 2001.
- http://agile.csc.ncsu.edu/SEMaterials/WhiteBox.pdf содержит дополнительную информацию о тестировании потока управления и тестировании потока данных.
- http://research.microsoft.com/en-us/projects/pex/ Pex - автоматическое тестирование методом белого ящика для .NET.