В основе любого правильно спроектированного нагрузочного теста (на производительность, баланс, стабильность) лежит сценарий, который покрывает бизнес функциональность. Это может быть пользовательская история (например «как пользователь я хочу зарегистрироваться на сайте»), тест цепочки функций (не обязательно с прямой ценностью для бизнеса). В результате, при запуске косвенно пройдёт функциональный тест. Разница только в количестве пользователей и покрытии. Всё-таки целью нагрузочного тестирования является оценка узких мест в архитектуре и реализации программного продукта, а не покрытие всей функциональности.

Чтобы не путаться с терминологией. Я под стресс тестом считаю тест, при котором создаётся избыточная нагрузка на приложение через ввод данных и [или] ограничение ресурсов).

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

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

Допустим мы опускаем функциональное тестирование и начинаем с нагрузочного. Подготовили нагрузчики (хорошо, если они уже есть), стенды, собрали большую схему с балансировкой нагрузки и прочее. Запустили. Непроверенный функционал сломался (не из-за нагрузки, а, например, неправильно сформировалась контрольная сумма в пакете). Разгребли кучу трейсов, нашли что именно не сработало, починили, собрали, может даже проверили, опять накатили все на стенды, опять запустили. Отвалился другой функционал, который зацепили при починке прежней ошибки, либо еще что-то, поехало все заново. Не проще сначала было проверить функционал?

Я не специалист по нагрузочному тестированию, занимаюсь по большей части ручным, но иногда и нагрузку приходится проверять. Согласно моему опыту стенды для нагрузки настраиваются дольше, а ошибки диагностируются сложнее. Это еще хорошо, если Вы у себя имеете возможность делать нагрузочное тестирование. А если надо его делать на оборудовании заказчика (а такое бывает)? И поехали туда, либо через VPNы полезли, а это еще затягивает все процессы (в больших компаниях все медленно делают).

Кстати, обычно рекомендуют нагрузочное тестирование напоследок не откладывать, а делать периодически после проверки определенной части функционала, чтобы к концу разработки проекта не оказалось, что были выбраны неверные архитектура/технологии. Так что заявление о несмешении для меня, честно говоря, открытие.

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

При проведении стресс тестирования будут находится именно функциональные недочеты, которые иначе трудно выявить (как правильно отметил Рома). Но, как правильно отметил Алекс в первом коменте, ценность таких недочетов несколько иная. А возможно даже пути исправления другие.

Например, программа виснет при попытке открыть 500Мб XML файл. Баг? Баг! Но 500Мб XML файл это стрессовый вариант (например, обычно файлы открываемые программой не превосходят 1Мб). Тогда у нас есть требование на исправление — сделать так, чтобы программа не висла, а сообщала об ошибке при неудачной попытке открытия чрезмерно большого файла и продолжала работать дальше. При функциональном тестировании мы бы попросили исправить так, чтобы программа смогла открыть такой файл. И опять же, как уже написал Рома, мы не можем быть уверенны, открывает вообще ли программа XML файлы или нет — все-равно проводить второй эксперимент и выяснять.

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