Необходимость тестирования

Есть такой миф из XP/TDD, что можно полностью покрыть веб-приложение модульными и функциональными тестами, написать большое количество Selenium-тестов, кликающих по системе снаружи и без страха вносить в систему доработки и выкладывать на рабочий сервер через процесс непрерывной интеграции.

Вот несколько причин ошибочности данного суждения:

• Требования к веб-проекту будут постоянно меняться, до самого запуска. Теоретически, можно их зафиксировать, конечно, но перед запуском часто происходит такое, что нужно что-то в проекте срочно изменить.
• Если все покрывать тестами по совести, не хватит программистов и времени. Нередко встречаются отклонения от тестов, например написание mock-объектов к API Amazon.
• Если на веб-проекте часто меняется верстка будет очень сложно поддерживать Selenium-тесты в актуальном состоянии.
• Некоторые вещи, например устойчивость сайта под нагрузкой, непросто протестировать. Нужно придумать схему нагрузки, похожую на реальную, но она будет все равно другой.
• Разработчик интуитивно доверяет языку программирования, а он может содержать ошибки, которые могут появиться совершенно внезапно. Не будем же мы поэтому покрывать тестами PHP?
• и т.п.

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

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

  Нагрузочное тестирование

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

Зачастую, простые корректировки конфигурации могут ускорить проект в 5-10 раз и сделать его устойчивым к стрессовым нагрузкам, поэтому:

• Проводите нагрузочное тестирование на реальных данных с «боевых серверов»;
• Используйте монитор производительности;
• Эмулируйте действия пользователей на проекте;
• Эмулируйте импорты/экспорты/веб-сервисы.

Подходящими инструментами для нагрузочного тестирования являются:

• Jmeter
• WAPT
• httperf
• ab

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