Я мог бы четко понять эту проблему в тех областях, где вы охватываете каждый дюйм аппаратного обеспечения, например, многопоточный игровой движок нового поколения AAA, который использует каждое ядро процессора, встроенные SIMD, GPU, GPGPU и т. Д., Обеспечивая при этом кроссплатформенность. продукт.
В этих случаях вашим худшим кошмаром часто будут те случаи, когда ваши тесты (модуль и интеграция) пройдут для первых 5000 протестированных машин / платформ, но не пройдут для 5 001-й из-за ошибки драйвера для малоизвестной модели графического процессора. Просто подумайте это вызывает у меня дрожь - вы не можете проверить или предвидеть это заранее.
Особенно, если вы пишете шейдеры для GPU, вы можете закончить розыгрышем в виде обратной лотереи, когда половина написанного вами кода вызовет неопределенное поведение, поскольку существует мало портативных стандартных гарантий, которые применяются всеми задействованными моделями / драйверами GPU. Хотя в наши дни становится все меньше и меньше, как играть в тральщика, это должно дать людям представление: http://theorangeduck.com/page/writing-portable-opengl . Попытка сделать это в конце 90-х и начале 2000-х была поистине ужасной, и это был тральщик на всем пути.
В таких случаях часто требуются группы из более чем 10 000 тестировщиков с действительно широким спектром оборудования и операционных систем, чтобы действительно укрепить продукт и почувствовать уверенность в нем до стабильной версии. Не все компании могут позволить себе иметь такую широкую базу тестов, и не у всех есть дисциплина, чтобы сделать это правильно (все широко заметные проблемы должны быть решены до того, как столько тестеров будет на какой-то внутренней стадии до альфа / альфа или иначе поток избыточных отчетов может привести разработчиков в паническое состояние.
В этом случае я рекомендую то, что предложили другие, сосредоточиться на распределенном наборе интеграционных тестов. Вы можете связать его с установщиком, требуя, чтобы пользователи проходили базовую диагностическую проверку с внимательным вниманием к предоставлению подробной информации о том, почему установка не удалась, и что они могут передать вам, разработчикам.
Еще одна вещь (если вы можете убедить начальника) - это иметь в наличии широкий спектр оборудования для непрерывной интеграции. Чем больше разнообразия в аппаратных / ОС комбинациях, тем лучше. Вам нужно даже различное дерьмовое оборудование, которое моделирует минимальные требования к оборудованию для ваших CI-серверов: вы никогда не знаете.
Но есть еще одна вещь, которую я бы предложил:
логирование
Если вы имеете дело с чем-то похожим на сценарий, который я описал выше, то часто вы не можете проверить эти вещи, которые, как правило, являются наиболее проблематичными (те худшие возможные ошибки, которые обнаруживаются в наихудшее возможное время и не могут проявиться даже в наиболее исчерпывающий набор тестов, поскольку эта проблема ограничена очень специфической комбинацией оборудования / ОС).
Тем не менее, большинство таких проблем, как неясная несовместимость аппаратного обеспечения или явные сбои драйверов или связывание с неправильным дистрибутивом (я никогда не сталкивался с этой проблемой), не дадут вам далеко пройти запуск программного обеспечения. Грубо говоря, он скоро рухнет и сгорит.
Ради здравого смысла я рекомендую принять неизбежное. Вы ничего не можете сделать с этими вещами, которые вы не можете проверить всесторонне. Не пытайтесь предотвратить ураган (невозможно), но загляните в эти окна.
Как правило, здесь лучшее, что мы можем сделать, - это выяснить проблему как можно скорее, где она возникает как можно более подробно (чтобы сузить наш список подозреваемых), и устранить проблему как можно скорее после ее сообщения.
В этом случае регистрация может быть спасителем. Для таких полей вы можете создавать такие технические журналы спама, которые никто никогда не будет читать. Часто релевантной является только самая последняя строка, записанная в журнале до того, как пользователь столкнулся со сбоем из-за сбоя драйвера, например, Вы можете написать внешний процесс или ловушку, которая отслеживает сбои, а затем показывает последнюю строку журнала, которую пользователи могут скопировать и вставьте вам, например, в дополнение к аварийному дампу.
Поскольку для этого часто требуется детализированная информация, а множество наиболее уязвимых областей кода для решения этих проблем с оборудованием / платформой / драйвером является критически важным для производительности, существует такая неловкая проблема, когда ведение журнала может происходить с такой частой скоростью, что на самом деле оно будет медленным вниз по программному обеспечению.
Полезный трюк в этом случае состоит в том, чтобы полагаться на предположение, что что-то выполненное один раз будет успешно выполнено во второй раз, в третий раз и т. Д. Это не самое правильное предположение, но часто это «достаточно хорошо» (и бесконечно лучше, чем ничего) , При этом вы можете использовать немного внешнего состояния, чтобы отслеживать, когда что-то уже зарегистрировано, и пропустить последующие попытки войти в систему для тех действительно гранулированных случаев, когда код будет вызываться повторно в цикле.
Во всяком случае, я надеюсь, что это поможет. Я сталкивался с подобным искушением в прошлом и испытываю некоторую паранойю вокруг кодирования GPU (GPGPU и шейдеров) в результате некоторого прошлого опыта между мной и моей командой (иногда просто видя, как другие члены команды действительно занимаются этим Позднее и после релиза у меня возникли проблемы, как некоторые ошибки ATI в конкретной модели Radeon, которые приводили к сбою при рендеринге сглаженных линий, позже сообщалось и отмечалось как известная проблема только с доступным обходным решением).
Ведение журнала было тем, что спасло нас от пота, позволяя нам часто видеть проблему на 10,001-м непонятном прототипе машины с встроенным графическим процессором, о котором мы никогда не слышали, а последняя строка кода сразу же позволила нам точно определить, где произошел сбой до 2 или 3 строки кода в качестве подозрительных, например, если он находится внутри сложного шейдера, мы вроде SOL, так как мы не можем вести логирование внутри шейдера GPU, но мы можем, по крайней мере, использовать логирование, чтобы увидеть, какой шейдер имел проблему прямо сейчас начать расследование.