Как вы проводите стресс-тестирование своего программного обеспечения?

Question

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

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

Спасибо, как всегда.

Answer 1

Ну, похоже, вы говорите о двух разных вещах «тестирование функциональности вашего приложения» и «стресс -тестирование» (что является названием вашего вопроса)

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

Эти вопросы звучат больше как вопрос о обеспечении качества. Вот для чего нужны тестеры / бета -тестеры. Но есть вещи, которые вы можете сделать сами, чтобы подтвердить, что ваше приложение работает как можно лучше.

Модульный тестирование вашего кода будет хорошим началом, он поможет вам найти эти краевые случаи. Если ваш метод принимает такие вещи, как INT, попробуйте пропустить Int.Max, Int.Min и посмотреть, что взрывается. Передайте нули во все. Если вы используете .NET, вы можете посмотреть на PEX, он пройдет через все ветви/кодепаты, которые есть в вашем приложении. Это может помочь вам дополнительно уточнить ваши модульные тесты, чтобы проверить ваше приложение как можно лучше.

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

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

Answer 2

Убедитесь, что у вас достаточное покрытие кода в модульных и интеграционных тестах.

Используйте соответствующую проверку пользовательского интерфейса и тестируйте комбинации, которые могут его сломать.

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

Answer 3

Автоматизация.

(Re) Установите свой код, чтобы другая программа могла бросить в него пользовательские события. Создайте простые сценарии событий пользователей и воспроизводите их обратно в свою программу. Захватывают события от бета -пользователей и сохраняют тестовые сценарии (полезны для воспроизведения проблем и проверки на регрессии). Напишите Fuzz-Tester, который применяет небольшие случайные изменения к сценариям, а также попробуйте их против вашей программы.

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