потому что надо доказать что правильно работает код на контрольных данных

а нагрузочное тестирование делается вообще отдельно и только с эмуляцией поведения приближенной к реальномв

потому не нужно тратить время на покрытие не своего кода тестами.

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

Получается, у меня может быть не пустая база, тогда в теории создав набор данных для этого отчета, установив программно отборы по этим данным я проверю поведение?
Сейчас я обычно именно так делаю. Тест запускается в окружении каких-то данных. Но входные данные теста создаются только для него

Отчет это наверное самый лучший пример сценария с большими зависмостями от данных.

Все зависит от того что ты хочешь проверить?

внешний вид?

данные?

группировки?

данные в первую очередь с группировками

применимость отборов?

просто нет смысла тестировать скд и тестировать подсистему варианты отчетов. их тестируем мы и они оверпокрыты тестами

Когда есть достаточно сложный запрос + сложный набор ресурсов

И несколько пользователей с довольно разными настройками

Или отчет это уже то, что не стоит покрывать тестами из-за того, что отчет сам сложный и еще куча зависимостей

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

Ты проверишь компоновку с набором ресурсов и запросом, но проверять генерацию макета не будешь.

Хм, а почему не надо генерацию макета проверять?

То, что покрыто в БСП - не причина. У меня макет может быть допилен как раз и просто ТЗ не спасет - нужен вид.
Пример: ОСВ из БП.

ну да, тогда надо будет с макетом как эталоном сравнивать

В двух словах конечно не получится, но кратко. Обучение - простые тесты, тесты с параметрами, выделание общих "тестов". Например, создание номенклатуры, можно выделить в общую библиотеку с параметрами. А потом в основном сценарии вызывать такую библиотеку. На сколько частей разбить (создание общих библиотек) зависит от того, что хотите заполнять. Пока у нас 2 параметра (у номенклатуры), возможно потом будет больше. (Желательно не больше 5-7 параметров, потом сложно поддерживать).  И ещё плюс общих библиотек, что если какой-то реквизит в Номенклатуре добавился, не надо менять все сценарии где номенклатура используется, а лишь изменить общую библиотеку. Итого - обучение: простые тесты, тест с параметром, выделение общих библиотек и на основе этих библиотек создать простенький cross-тест, то есть от ввода данных до построения отчёта. После обучения - уже, пощупав инструмент, можно сесть и составить план тестирования. Что хотите проверять, зачем, почему. И пока цель должна быть не "заипать" тестами - а чтобы они помогали. А то мотивация быстро закончится :) Как было указано выше, не надо покрывать тестами часто меняющиеся механизмы - просто устанете переписывать и будет копиться неготив. Пока я бы вот это рекомендовал.