Здравствуйте, crazyfern, Вы писали:

C>Возник вопрос связанный с тестированием драйверов фильтров файловых систем (Windows).

C>При разработке драйвера фильтра рано или поздно (а обычно постоянно) приходится выполнять тестирование полученного драйвера. Для тестирования я использую приложения, которые выполняют некоторые действия, обеспечивающие реакцию ожидаемую драйвера + проверяю сам драйвер (free/checked) под verifier-ом и выполняю тесты FDTS(DTM).

Все правильно.

C>Однако, как показала практика, таким образом можно выявить в основном функциональные ошибки, т.е. те, которые достаточно легко подыграть. Ошибки, связанные с неправильной синхронизацией или те, что подыгрываются при достаточно редких действиях пользователя (которые сам порой придумать не сможешь) и подобные им могут не проявляться или проявляться от случая к случаю.

Угу. This is wild world. Невозможно протестировать всевозможные сочетания ПО (антивирусы, бэкап, контролирующие доступ, виртуализирующие диски и т.п.). Невозможно воссоздать всевозможные конфигурации сети и окружения ОС. А если к этому еще добавить баги самой ОС, то становится еще груснее.

C>Соответственно стало интересно, какими методами борьбы (кроме здравого смысла и внимательности) с подобными багами пользуются другие разработчики? Есть ли пакеты ПО, которые могут имитировать работу большого количества пользователей и приложений, выполняющих файловые операции, выполнять изменение в настройках Windows (иногда это тоже помогает выявить ошибку)?

Как правило, просто накапливается опыт и база знаний по инцидентам. Какие-то инциденты интерполируются на общий случай, какие-то остаются частным конкретным случаем вплоть до work around'а.

C>Кроме того, как вы выполняете тестирование, если ваш драйвер входит в состав большого комплекса ПО, состоящего из других фильтров, приложений и прочих модулей?

Это нормальная ситуация. К счастью, нынче есть возможность использования большого числа виртуалок, где разворачиваются разные конфигурации (в автоматическом режиме) и прогоняются тесты.