2010-06-18 1 views
25

В частности, у меня есть метод, который выбирает n элементов из списка таким образом, что% из них удовлетворяют одному критерию, а b% соответствуют секунде и так далее. Упрощенным примером будет выбор 5 элементов, у которых 50% имеют заданное свойство со значением «true» и 50% «false»; В 50% случаев метод вернет 2 true/3 false, а остальные 50%, 3 true/2 false.Каков наилучший способ модульного тестового кода, который генерирует случайный выход?

Статистически говоря, это означает, что более 100 пробегов, я должен получить около 250 true/250 false, но из-за случайности 240/260 вполне возможно.

Каков наилучший способ тестирования устройства? Я предполагаю, что, хотя технически 300/200 возможен, вероятно, это должно завершиться неудачно, если это произойдет. Существует ли общепринятая толерантность к таким случаям, и если да, то как вы определяете, что это такое?

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

+0

в примере, вы хотите, по крайней мере, 50% или примерно 50%? Чтобы быть более конкретным, какова случайность в этом тесте? – Gishu

+1

Я подозреваю, что вы на самом деле не пишете модульные тесты. Если вы тестируете серверы, работающие на разных компьютерах, вы фактически находитесь в системном тесте. Я просто могу сказать вам: если у вас есть модульные тесты для классов, запущенных на этих серверах, вам больше не нужно многое (подробное) тестирование системы. –

+0

Нет, нужно убедиться, что алгоритм действительно выбирает 2/3 50% времени, а 3/2 остальные 50% (в этом простом примере), независимо от того, где он используется. Это не одна система, которая будет производить это; Запуск его 1000 раз на одной машине считается адекватным тестом, чтобы продемонстрировать, что если он будет запущен 10 раз на 100 машинах по всему миру, он будет выровняться соответствующим образом, поэтому я планирую его модульное тестирование. – Flynn1179

ответ

22

Случайные и статистические данные не используются в модульных тестах. Единичные тесты должны всегда возвращать тот же результат. Всегда. Не в основном.

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


Дополнительные мысли:

Вы могли бы рассмотреть, чтобы изменить реализацию, чтобы сделать его более проверяемым. Постарайтесь получить как можно меньше случайных значений. Например, вы можете получить только одно случайное значение, чтобы определить отклонение от среднего распределения. Это было бы легко проверить. Если случайное значение равно нулю, вы должны получить точное распределение, которое вы ожидаете в среднем. Если значение равно, например, 1.0, вы пропускаете среднее значение по определенному коэффициенту, например, на 10%. Вы также можете реализовать некоторую гауссовскую дистрибуцию и т. Д. Я знаю, что это не тема здесь, но если вы свободны реализовать ее по своему усмотрению, рассмотрите возможность тестирования.

+1

+1 для изменения перспективы. –

+0

Вы не считаете, что значение должно быть Flynn1179

+0

Что делать с разными машинами в единичном тесте? –

4

Согласно статистической информации, которую вы имеете, определите диапазон вместо определенного отдельного значения.

+2

Пока у вас есть случайные в тесте, он все равно может быть ложным положительным ложным отрицательным. –

2

Вы должны проверить распределение результатов в единичном единичном тесте, т. Е. Чтобы результат был как можно ближе к желаемому распределению в каждом отдельном прогоне. Для вашего примера, 2 true/3 false в порядке, 4 true/1 false не является результатом.

Также вы можете написать тесты, которые выполняют метод, например. 100 раз и проверяет, что среднее значение распределений «достаточно близко» к желаемой скорости. Это пограничный случай - запуск больших партий может занять значительное количество времени, поэтому вы можете запускать эти тесты отдельно от ваших «обычных» модульных тестов. Кроме того, как указывает Стефан Штайнеггер, такой тест будет терпеть неудачу каждый раз, а затем, если вы определите «достаточно близко» более строгим или начнете бессмысленным, если вы слишком слабо определите порог. Так что это сложный случай ...

3

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

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

4

Многие вероятностные алгоритмы, например. научные вычисления используют pseudo-random number generators, а не true генератор случайных чисел. Несмотря на то, что они по-настоящему не случайны, тщательно подобранный генератор случайных чисел будет отлично работать.

Одним из преимуществ псевдо генератора чисел в -Random является то, что последовательности случайных чисел они производят полностью воспроизводимы. Поскольку алгоритм детерминирован, то же самое семя всегда будет генерировать ту же последовательность. Это часто является решающим фактором, почему они выбраны в первую очередь, потому что эксперименты должны быть повторяемыми, результаты воспроизводимы.

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

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

1

Я думаю, что если бы у меня была такая же проблема, я, вероятно, построил доверительный интервал для обнаружения аномалий, если у вас есть статистика о среднем/stddev и т. Д. Поэтому в вашем случае, если среднее ожидаемое значение равно 250, тогда создайте доверительный интервал 95% вокруг среднего, используя нормальное распределение. Если результаты за пределами этого интервала вы не прошли тест.

см more

0

Почему не переделан случайное число генерации кода и пусть рамки модульного тестирования и исходный код и использовать его? Вы пытаетесь проверить свой алгоритм, а не рандомизированную последовательность?

4

Мне кажется, есть по крайней мере три различных вещей, которые вы хотите проверить здесь:

  1. Корректность процедуры, которая генерирует выходной сигнал, используя случайный источник
  2. Это распределение случайного источника является то, что вы ожидаете
  3. это распределение продукции является то, что вы ожидаете

1 должен быть детерминированным, и вы можете модульное тестирование его путем подачи выбранного множество о f известные «случайные» значения и входы и проверка того, что он производит известные правильные выходы. Это было бы проще всего, если бы вы структурировали код, чтобы случайный источник передавался как аргумент, а не встроенный в код.

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

Требования к применению будут зависеть от ожидаемого распределения. Для 2 вы, скорее всего, ожидаете равномерного распределения случайного источника. Для этого существуют различные тесты, в зависимости от того, как вы хотите быть, см., Например, Tests for pseudo-random number generators on this page.

Ожидаемое распределение по 3 будет зависеть от того, что вы производите. Простой вопрос 50-50 в вопросе в точности эквивалентен testing for a fair coin, но, очевидно, другие случаи будут более сложными. Если вы можете решить, что должно быть в дистрибутиве, может помочь chi-square test.

0

Прежде всего, вы должны знать, какое распределение должно быть результатом процесса генерации случайных чисел. В вашем случае вы генерируете результат, который равен 0 или 1 с вероятностью -0.5. Это описывает binomial distribution с p = 0,5.

Учитывая размер выборки n, вы можете построить (как предложил более ранний плакат) доверительный интервал вокруг среднего значения. Вы также можете делать различные заявления о вероятности получения, например, 240 или менее результатов, когда n = 500.

Вы можете использовать предположение о нормальном распределении для значений N больше 20, если p не очень велико или очень мало. У Wikipedia post есть больше об этом.

 Смежные вопросы

  • Нет связанных вопросов^_^