В предложенном выше решении для того, чтобы увеличить скорость генерации чисел, пожертвовали памятью, причем конкретно так, не скупясь, на порядок.
В моей версии размер массива ровно равен требуемой дискретности (собственно, можно обойтись только массивом вероятностей, хотя это несколько (на одну операцию сложения) снизит скорость работы). Да, в моем варианте скорость генерации ниже (по причине необходимости просматривать массив вероятностей сначала до, в худшем случае, конца), но, для задач, озвученных ТС — имхо, некритично.
В целом — правильно, хотя не обязательно писать тест-кейсы сразу на всю систему — главное, чтобы к моменту реализации определенного блока требований, к нему были написаны все тест-кейсы. Т.е., в идеале, необходимым (но не достаточным) критерием качества тестирования является 100%-е покрытие тест-кейсами требований (на каждое требование имеется по меньшей мере один тест-кейс, который его проверяет).
По поводу интеграционных тестов — по определению (см. например в википедию), интеграционное тестирование проверяет качество взаимодействия отдельных модулей, но при этом проводится после модульного тестирования, которое, в свою очередь, обычно проводится на тест-кейсах.
Простой пример: пусть тестируется веб-система, например, интернет-магазин, в котором объектом тестирования выступают два модуля: корзина и модуль «с этим товаром заказывают еще». На модульном тестировании проверяются корректность работы каждого модуля в отдельности (в корзине корректно отрабатывают кнопки изменения кол-ва товара, пересчет стоимости, применимость скидки и т.п., в модуле кросс-продаж — что имея на вход профиль пользователя и список его покупок он корректно возвращает список похожих товаров), а на интеграционном — корректность отображения списка похожих товаров при работе с корзиной (данные из корзины корректно уходят в модуль, результаты корректно отображаются).
Т.е. интеграционное тестирование предполагает, что модули по отдельности работают корректно.
Смотря куда лететь собираетесь :) Это лучше, чем отсутствие тестирования, но прошу обратить внимание — у вас отсутствует тестирование по тест-кейсам (если, конечно, я правильно понял термин «интеграционные тесты»), т.е. с таким подходом Вы сможете, с определенной долей уверенности, сказать «Реализованный функционал работает без ошибок», но не сможете сказать «Реализованный функционал работает правильно».
Написание тестов для багов — это обычное регрессионное тестирование, которое помогает поднять качество, но не является ключевым его фактором. Узкое место в вашей концепции — это отсутствие взгляда «сверху» на качество системы. Т.е. аналитик пишет тесты для себя, разработчик — для себя.