Похоже, у вас есть черный ящик в отношении тестирования.
http://en.wikipedia.org/wiki/Black-box_testing
Проще говоря, это ужасно, но, возможно, все, что вы можете сделать, если не можете изолировать систему каким-либо образом.
Вам необходимо вставить известные данные в вашу систему и сравнить результат с известным выводом.
Вам действительно нужны известные данные и вывод для
нормальные значения - нормальные данные - вы обнаружите, что они, по крайней мере, могут показаться правильными
ошибочные значения - орфографические ошибки, недопустимые значения - так что вы знаете, что он сообщит вам, если ввод - мусор
вне диапазона - -1 для целых чисел со знаком, значения, превышающие 2,7 миллиарда (при условии 32-битного) и т. Д., Поэтому вы знаете, что это не приведет к сбою при серьезно неправильно введенных или поврежденных данных
опасно - ввод, который сломает SQL, симулирует SQL-инъекцию
И наконец, убедитесь, что все ошибки тщательно обрабатываются, а не регистрируются, и что плохое / поврежденное / нулевое значение передается через систему.
Любые процессы, которые вы можете изолировать и протестировать таким образом, облегчат отладку, поскольку тестирование черного ящика не может сказать вам, где произошла ошибка. Это значит, что вам нужно диагностировать ошибки на основе того, что произошло, скорее в стиле House MD, чем в обычном сеансе отладки.
Если у вас есть различные типы данных, перечисленные выше, вы можете протестировать все изменения изолированно с ними, а затем в системе в целом. Со временем, когда вы в конце концов коснетесь большинства аспектов системы, у вас будут тестовые случаи для всех областей, и вы сможете сказать, где наиболее вероятно, что сбой произошел легче.
Также: убедитесь, что вы включили трассировщики в свои известные данные, чтобы случайно не указать сбой на фондовом рынке при тестировании ограничений диапазона на модуль, чтобы вы могли вывести его из потока результатов до того, как он закончится на столе генерального директора.
Надеюсь, это поможет