Тестирование со случайными лучшими практиками исходных данных

Относительно 3-го вопроса по-моему, случайные тесты не хорошо подходят для поблочного тестирования. Если относится та же часть кода, модульный тест должен всегда успешно выполняться или всегда перестать работать (т.е. неправильное поведение из-за ошибок должно быть восстанавливаемым). Вы могли однако использовать случайные методы, чтобы генерировать большой набор данных, затем использовать тот набор данных в Ваших модульных тестах; нет ничего неправильно с ним.

Ничего себе, большой вопрос! Некоторые мысли:

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

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

Q2) я предполагаю, что Вы могли попытаться использовать статистику для создания доверительного интервала вокруг того, что обнаружили все "ошибки". Но практический ответ: запускайте свои рандомизированные тесты так много раз, как можно предоставить.

Q3) я нашел, что рандомизированное тестирование полезно, но после записи нормальной батареи единицы, интеграционных и регрессионных тестов. Необходимо интегрировать рандомизированные тесты как часть нормального набора тестов, хотя, вероятно, маленькое выполнение. Если ничто иное, Вы избегаете разрядной гнили в самих тестах и получаете некоторое покрытие капельки, поскольку команда запускает тесты с различными случайными исходными данными.

Q4), Когда запись рандомизировала тесты, удостоверьтесь, что Вы сохраняете случайное семя с результатами тестов. Нет ничего более расстраивающего, чем нахождение, что Ваши случайные тесты поймали ошибку, и не бывший способный запускать тест снова с тем же входом. Удостоверьтесь, что Ваш тест может или быть выполнен с сохраненным семенем также.

To make tests reproducible, simply use a fixed seed start value. That ensures the same data is used whenever the test runs. Tests will reliably pass or fail.

• Good / bad candidates? Randomized tests are good at finding edge cases (exceptions). A problem is to define the correct result of a randomized input.
• Determining the number of times to run the code: Simply try it out, if it takes too long reduce the iteration count. You may want to use a code coverage tool to find out what part of your application is actually tested.
• Are these kinds of tests well suited for unit tests? Yes.

Несколько вещей:

• Со случайным тестированием Вы не можете действительно сказать, насколько хороший часть кода, но можно сказать, как плохо это.
• Случайное тестирование лучше подходит для вещей, которые имеют случайные исходные данные - главный пример - что-либо, что это выставляется пользователям. Так, например, что-то, что случайным образом нажимает и вводит на всем протяжении Вашего приложения (или ОС) является хорошим тестом общей устойчивости.
• Точно так же разработчики рассчитывают как пользователи. Таким образом, что-то, что случайным образом собирает GUI от Вашей платформы, является другим хорошим кандидатом.
• Снова, Вы не собираетесь находить все ошибки этим путем - что Вы ищете, "если я делаю миллион эксцентричных вещей, КАКОЙ-ЛИБО из них приводит к системному повреждению?" В противном случае можно чувствовать некоторый уровень уверенности, что app/OS/SDK/whatever мог бы содержать воздействие нескольких дней пользователям.
• ... Но, что еще более важно, если Ваше random-beater-upper тестовое приложение может разрушить Ваше приложение/ОС/SDK приблизительно через 5 минут, это о том, сколько времени Вы будете иметь до первого пожарного учения, при попытке поставить того сосунка.

Также примечание: ВОСПРОИЗВОДИМОСТЬ ВАЖНА В ТЕСТИРОВАНИИ! Следовательно, имейте свой журнал инструмента тестирования случайное семя, которое он использовал, и имейте параметр для запуска с того же семени. Кроме того, имейте его любой запуск от известного "основного состояния" (т.е. переустановите все из изображения на сервере и запуститесь там), или некоторое recreatable основное состояние (т.е. переустанавливают из того изображения, затем изменяет его согласно некоторому случайному семени, которое инструмент тестирования берет в качестве параметра.)

Конечно, разработчики будут ценить, если инструмент будет иметь хорошие вещи как, "сохраняют состояние каждые 20 000 событий" и "остановки прямо перед событием #" и "шаг вперед 1/10/100 события". Это значительно поможет им в репродуцировании проблемы, нахождении и фиксации его.

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

И помните: "система пошла, 24 часа случайного обстрела без ошибок" не означают, что это готово поставляться, это просто означает, что это достаточно стабильно для запуска некоторого серьезного тестирования. Прежде чем это сможет сделать это, QA должен не стесняться говорить, "смотрят, Ваш POS не может даже продлиться 24 часа под как живым случайным пользовательским моделированием - Вы фиксируете это, я собираюсь провести некоторое время, пишущий лучшие инструменты".

О, да, одна последняя вещь: в дополнение к "фунту это настолько быстро и трудно как Вы можете" тесты, имейте способность сделать "точно, что сделает реальный пользователь [кто был, возможно, нарушен, или ребенок, ограничивающий клавиатуру/мышь]". Таким образом, если Вы делаете случайные пользовательские события; сделайте их на скорости, которую очень быстрая машинистка или очень быстрый пользователь мыши могли сделать (со случайными задержками, для моделирования МЕДЛЕННОГО человека), в дополнение к "с такой скоростью, как моя программа может плюнуть событиями". Они равняются двум ** очень отличающийся* типы тестов и получат совсем другие реакции, когда ошибки найдены.

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

Вот мой ответ на похожий вопрос: Является ли плохой практикой случайная генерация тестовых данных? . Другие ответы также могут быть полезны.

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

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

Затем вы переходите от случайного тестирования к статистическое тестирование.

 if (a> 0)
 // Do Foo
иначе (если b <0)
 // Do Bar
еще
 // Делаем Foobar

Если вы выбираете a и b случайным образом в int диапазон, вы тренируетесь Foo 50% время, Бар 25% времени и Foobar 25% времени. Скорее всего что вы найдете больше ошибок в Foo чем в Bar или Foobar .

Если вы выберете a так, чтобы он был отрицательное 66,66% времени, бар и Foobar тренируется больше, чем с ваше первое распространение. Действительно три ветви выполняются каждый 33,33% времени.

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