Как проверить множество событий разумным способом

Question

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

Количество событий составляет около 200. Какой подход я должен использовать для эффективного тестирования и проверки рефакторинга кода иэффективно ?

Спасибо.

Answer 1

Я бы добавил тесты до того, как вы выполните рефакторинг.вы не знаете, где вы его уже сломали:).

вы говорите, что он входит в EventViewer и DB, я надеюсь, что вы представили функцию ведения журнала как интерфейс, чтобы вы могли:

• Расширьте его, чтобы войти в какое-либо другое устройство, если это необходимо

• Также значительно упрощает насмешку

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

Я бы сделал это следующим образом:

• Я бы искал все места, где используется мой интерфейс ведения журнала, отмечал все классы и сначала начинал с критических путей / путей (таким образом, вы по крайней мере покрываете критические)

• или вы можете начать с конца, т.е. записать все возможные комбинации журналов, которые вы получаете, возможно, указать на устаревшие данные, чтобы вы зналиесли ввод одинаковый, вывод тоже должен быть одинаковым.И каждый раз, регрессивно тестируйте ваши новые двоичные файлы с этими данными, и вы должны получать одинаковое количество / уровень логов.

Answer 2

Это не должно быть трудно.

Выберите бесплатный инструмент для автоматического веб-тестирования, такой как Watir (java) или WatiN (.net), (или VS UI Test, если он у вас есть.)

Создание тестов, охватывающих те области веб-приложения, которые вы ожидаете / должны запускать события. Изучайте базу данных SQL после каждого теста, чтобы увидеть, какие события сработали.

Если эти потоки событий верны для теста, добавьте в тест шаг, чтобы убедиться, что именно этот поток событий был создан в БД.

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

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

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

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

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

Надеюсь, это поможет, Chris

Answer 3

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

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

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

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

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

Надеюсь, это поможет