Как спланировать тестирование whitebox

Question

Я относительно новичок в мире тестирования WhiteBox и мне нужна помощь в разработке плана тестирования для одного из проектов, над которыми я сейчас работаю. В данный момент я просто слежу за поиском тестируемых фрагментов кода, а затем пишу для этого некоторые модульные тесты. Я как-то чувствую, что это далеко не так, как должно быть. Не могли бы вы дать мне совет, как лучше подготовиться к тестированию этого проекта? Какие-нибудь инструменты или шаблоны плана тестирования, которые я мог бы использовать? Используемый язык - C ++, если это будет иметь значение.

Answer 1

Одна из целей тестирования белого ящика - охватить 100% (или как можно ближе) операторов кода. Я предлагаю найти инструмент покрытия кода C ++, чтобы вы могли видеть, какой код выполняются вашими тестами и какой код вы пропустили. Затем спроектируйте тесты так, чтобы тестировалось как можно больше кода.

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

Вы также можете разработать тесты для анализа жизненного цикла важных переменных. Проверьте их определение, их использование и их уничтожение, чтобы убедиться, что они используются правильно:)

Есть три идеи, с которых можно начать. Удачи

Answer 2

Попробуйте «Эффективно работать с устаревшим кодом»: http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

Это важно, поскольку под «устаревшим» он подразумевает код, который не имеет тестов.Это также довольно хорошая книга.

Соответствующие инструменты: http://code.google.com/p/googletest/ и http://code.google.com/p/gmock/ Могут быть и другие модульные тесты и макеты, но я знаком с ними и рекомендуювысоко.

Answer 3

В данный момент я просто слежу за поиском тестируемых фрагментов кода, а затем пишу для этого некоторые модульные тесты. Я как-то чувствую, что это далеко не так, как должно быть.

Люди говорят, что одним из главных преимуществ ' разработки, основанной на тестировании ', является то, что она поощряет вас разрабатывать компоненты с учетом тестируемости: это делает ваши компоненты более тестируемыми.

---

Мой личный (не TDD) подход заключается в следующем:

• Понимание функциональности, необходимой и реализованной: как «априори» (т. Е. Путем чтения / изучения функциональной спецификации программного обеспечения), так и путем чтения исходного кода для обратного инжиниринга функциональности
• Реализация тестов черного ящика для всех реализованных / требуемых функций (см., Например, ' Следует ли тестировать внутреннюю реализацию или только тестировать публичное поведение? ').

Поэтому мое тестирование не совсем «белая коробка», за исключением того, что я перепроектирую тестируемую функциональность. Затем я проверяю эту функциональность с обратной инженерией и избегаю использования какого-либо бесполезного (и, следовательно, непроверенного) кода. Я мог бы (но не часто) использовать инструмент покрытия кода, чтобы увидеть, какая часть исходного кода выполняется тестами черного ящика.