Вообще ткните в нужно направлении в плане тестирования. Тут я полный чайник.
Проблема такая. Когда делаешь печ. форму протестировать ее работу не сложно. А вот когда делаешь обработку которая перебирает большой объем данных возникает вопрос как тестировать. Можно взять реальный объем данных и попробовать на нем. Иногда бывает что обработка будет работать не один час. Можно сделать тестовый пример в котором отразить все варианты использования, но тут есть вероятность что-то не предусмотреть, и тогда на реальных данных может возникнуть ошибка.
В целом, наверное, хочу научиться тестировать свои разработки.

(0) а что, сократить период нельзя?

(1) Есть вероятность, что в сокращенный период некоторые варианты не попадут.

(2) Вероятность того, что тесты не покроют 100% функционала - 100%

(3) вероятность накрытия в 90% уже лучше, чем покрытие в 0%

(0) Арендуйте быстрый сервер.

(4) Вероятность накрытия - это вероятность, что накроется всё? :-))

(5) Дело не в производительности. Какую бы быструю железку не купить все равно появятся задачи которые она будет долго обрабатывать. Тут еще вопрос целесообразности.

20% выборки отражает 80% действительности

я тестирую так, сначало на 1 примере, потом в запросах ставлю top 100 или top 1000,

финальное тестирование - на полных данных, у меня были обработки по 10 часов... Заодно при финальном тестировании пишу временной план (в екселе) и именно с ним потом иду на рабочую, и довожу до пользователей "мне нужно 47 часов" и неволнует...

(0) на малых объемах и тестируй. Если ты знаешь, для чего и как используется обработка, то проблем с "создать все варианты" не должно быть

(7) Какой бы большой период ьы не брал, всё равно найдутся данные на которых она откосит

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

(8) это фикси, у франча - куда деть те 47 часов тестирования?

+(11)после такого тестирования на тестовых малых данных в рабочем варианте все работало как требовало ТЗ.
так что объемы данных совсем не кретичны

(12) компьютер работает а человек занят другими задачами?

в чем проблемма?

(14) ну как видишь для (0) это проблема

(11) а представь что в базе например есть 1 документ с реквизитом - "обьект не найден" и ты обращаешся в обработке через точку...

будет обидно если на рабочей базе после 14 часов обработка вылетет по ошибке.

(16) видишь, такие ошибки можно планировать

(17) и как планирование такой ситации поможет? в реальности нужно в пользовательском режиме перезаполнить этот реквизит до начала обработки....

(18) не обращаться через точку, обращаться через точку в попытке

(16) и что мешает этому документу появиться в промежуток между тестированием и боевым запуском?

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

(20) шанс возникновения ошибки есть всегда, просто при полном "финальном" тестировании он значительно меньше.

(21) все предусмотреть невозможно, а вот опробовать на конкретной базе можно.

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

(23) это не всегда возможно

(24) практически всегда. Ну ладно в 99,999%

(24) Если это невозможно, то тут вообще звездец. А вообще то, как сказал (25), да, в большинстве случаев возможно. Если нет, тот тут уже надо думать отдельно в каждом конкретном уникальном случае.

(26) обработка больших данных - чаще всего это всегда  уникальный случай.

(0) я делал обычно тестовую базу с выборкой данных перебор которой занимает вменяемое время..

(27) На самом деле там куча типовых случаев:
1. Загрузка (справочников, документов, остатков) - всегда можно проверить, загружен ли уже этот элемент.
2. Изменение реквизита(ов) - тоже как правило, можно сделать отбор по еще не измененным объектам.
3. Если проверка на существование уже загруженного объекта занимает длительное время, можно тупо сначала загрузить в какой то регистр сведений справочник, а потом по мере конвертации в нормальные данные удалять записи регистра(элементы справочника).

(27) невозможно только в случае, когда на основании  большого кол-ва данных формируется ОДИН объект (а ля ввод остатков). Но не представляю, чтоб такой объект формировался 50 часов

(29) Обработка больших данных - это не только поменять значения реквизита у документа

(30) даже в этом случае можно сделать проверку на то, загружен объект данных или нет.
(31) Если надо обработает объекты по какому нибудь сложному хитрозадому алгоритму, можно сначала сформировать список, а потом по списку уже обрабатывать, удаляя из него уже обработанные элементы. Список можно хранить в регистре сведений.

(0) Анализируешь алгоритм на предмет проблемных моментов. Тестируешь их на небольших объемах. Если все ОК - делаешь тесты на реальных объемах.

(0)
Есть такая наука статистика
Как проверить 100 000 деталей

Случайно берется  несколько деталей (кол расчитывается, но небольшое)
И если ни в одной нет брака -
с вероятностью 99 %  нет брака в большой партии

Особое внимание случайных.

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