Тестирование и отладка
Никакой сложный фрагмент программного кода не может считаться безошибочным. Фольклор программистов утверждает, что если в программе нет ошибок, то ошибка в компиляторе, поэтому он не выявил всех ошибок в программе.
Ошибки нельзя уничтожить, их можно только лишь ограничить. Все это становится наиболее очевидным, когда программное обеспечение начинает взаимодействовать с программами и аппаратурой других поставщиков, зачастую представляющими черный ящик.
Тестирование можно разделить на два этапа. Первый — достаточно сумбурный этап первоначального эмпирического накопления данных о поведении сложившейся конфигурации аппаратуры и программного обеспечение. Разумеется, у опытных разработчиков этот этап короче и проходит рациональнее.
Второй этап обязан обобщить полученные на первом этапе сведения, простроить приемлемую модель возникновения проблем и провести их поэтапную ликвидацию. Если второй этап не справляется с такой постановкой вопроса и превращается в первый, то вся работа превращается в беспорядочные метания.
Разумеется, поэтапное тестирование значительно эффективнее, нежели тестирование по окончании разработки системы целиком. Хотя такой подход требует большего набора фрагментарных тестов, действенность этого подхода неоспорима. Хотя бы по той простой причине, что дата завершения тестирования при таком подходе более предсказуема, нежели для продукта, который ни разу не тестировался по частям.
В литературе, посвященной тестированию, различают "прирастающее" тестирование (с постепенным усложнением) и более формальное регрессивное тестирование (когда происходит откат на предыдущий шаг в случае неудачи). По мере расширения проекта, эти сохраненные предшествующие тесты позволят удостовериться, что изменения не внесли ошибок в прежде разработанные фрагменты.
Зачастую аппаратура разрабатывается параллельно программному обеспечению. При раннем частичном тестировании дефекты в аппаратуре выявляются раньше и, соответственно, остается больше времени на исправление ошибок ее проектирования.
Вообразите, насколько убийственной для графика работ окажется неожиданное осознание того, что следует закупить другие микросхемы, сделать еще одну итерацию печатной платы или, что гораздо хуже, полузаказной интегральной схемы.
Немногие фирмы могут позволить себе иметь отдельные команды разработчиков и испытателей. Таким образом, автор драйвера должен зачастую параллельно разрабатывать и драйвер, и поэтапные тесты для него. Преимуществом такого "унитарного" подхода является то, что автор в курсе предельных параметров драйвера и устройства. Недостаток состоит в том, что оптимально устроенное мышление разработчика не планирует тестов на некоторые редко встречающиеся ошибочные ситуации, что впоследствии может оказаться серьезной проблемой конструкции и программного обеспечения.
Разумеется, должна быть установлена хорошая дисциплина для обеспечения достаточного времени и для разработки, и для тестирования. Сокращение стадии тестирования для ускорения общего графика — плохая услуга любому проекту.
