[@McConnell2004]
- Каждому ли требованию, относящемуся к классу или методу, соответствует отдельный тест?
- Каждому ли аспекту проектирования, относящемуся к классу или методу, соответствует отдельный тест?
- Каждая ли строка кода протестирована хотя бы одним тестом? Проверили ли вы это, подсчитав минимальное число тестов, нужное для выполнения каждой строки кода?
- Каждый ли путь “определение — использование” в потоке данных протестирован хотя бы одним тестом?
- Проверили ли вы код на наличие в потоке данных путей, которые обычно ошибочны, таких как “определение — определение”, “определение — выход” и “определение — уничтожение”?
- Использовали ли вы список частых ошибок для написания тестов, направленных на обнаружение ошибок, которые часто встречались в прошлом?
- Протестировали ли вы все простые граничные условия: максимальные, минимальные и граничные условия с завышением или занижением на 1?
- Протестировали ли вы сложные граничные условия, т. е. комбинации входных данных, которые могут приводить к слишком малому или большому значению вычисляемой переменной?
- Тестируете ли вы код на предмет неверных видов данных, таких как отрицательное число сотрудников в программе расчета заработной платы?
- Тестируете ли вы код с использованием типичных средних значений?
- Тестируете ли вы минимальные нормальные конфигурации?
- Тестируете ли вы максимальные нормальные конфигурации?
- Тестируете ли вы совместимость со старыми данными? Тестируете ли вы код, работающий со старым оборудованием и старыми версиями операционной системы, а также интерфейсы со старыми версиями других программ?
- Позволяют ли тесты легко проверить результаты вручную?
Ключевые моменты
- Тестирование, выполняемое разработчиками, — один из важнейших элементов полной стратегии тестирования. Независимое тестирование не менее важно, но оно не является предметом этой книги.
- Написание тестов до написания кода требует примерно того же времени и тех же усилий, что и создание тестов после кода, но сокращает циклы регистрации — отладки — исправления дефектов.
- Даже если учесть, что тестирование имеет массу разновидностей, его все равно следует считать лишь одним из элементов хорошей программы контроля качества. Высококачественные методики разработки, позволяющие свести к минимуму число дефектов в требованиях и проектах, играют не менее, а то и более важную роль. Методики совместной разработки характеризуются не меньшей эффективностью обнаружения ошибок, чем тестирование, к тому же они позволяют находить другие ошибки.
- Опираясь на базисное тестирование, анализ потоков данных, анализ граничных условий, классы плохих и классы хороших данных, вы можете создать много тестов детерминированным образом. Методика угадывания ошибок укажет вам на некоторые дополнительные тесты.
- Обычно ошибки концентрируются в нескольких наиболее дефектных классах и методах. Найдите такой код, перепроектируйте его и перепишите.
- Для тестовых данных обычно характерна более высокая плотность ошибок, чем для тестируемого кода. Так как поиск ошибок в тестовых данных требует времени, не приводя к какому бы то ни было улучшению кода, эти ошибки более досадны, чем ошибки программирования. Избегайте их, разрабатывая тесты столь же тщательно, что и код.
- Автоматизация тестирования полезна вообще и практически необходима в случае регрессивного тестирования.
- Чтобы процесс тестирования был максимально эффективным, сделайте его регулярным, выполняйте его оценку и используйте получаемую информацию для его улучшения.