Как сотрудники QA могут проверить логику кэширования, которую они не видят?

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

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

Но кто-нибудь может предложить несколько лучших практик для этой ситуации?

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

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

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

Вы реализовали кеш (я полагаю), потому что система работала недостаточно хорошо. Это то, что актуально для пользователя. Вот что может проверить QA:

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

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

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

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

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

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

Тест производительности, как указано в ответе Энди.

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

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

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

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

Чтобы быть ясным

• базовое тестирование производительности для тестирования времени, которое ОДИН запрос делает.
• нагрузочное тестирование аналогично тестированию производительности, но рассматривает реакцию, когда система также находится под нагрузкой от других запросов.

Вы также можете найти следующие ссылки полезными:

• Лучшие практики для методов модульного тестирования, которые интенсивно используют кэш?
• Методика нагрузочного теста для кеша
• Есть ли способ проверить, как сайт будет работать под нагрузкой
• http://www.procata.com/cachetest/

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

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

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

На этот вопрос действительно очень простой ответ, и он связан с уровнем кэширования. То, что вы заметите, когда кэширование будет правильным, - это отсутствие запросов в месте назначения запросов. Итак, все сводится к избитой фразе QA «ожидаемые результаты».

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

так далее...

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

Логика кэширования - это то, что должно быть проверено юнитом разработчиком, так как QA в основном выполняет тестирование «черного ящика».

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

Когда я тестировал решение для кэширования, мы реализовали то, что мы тестировали, в основном производительность. Мы сделали это решение для кэширования результатов XML, и после кэширования ответ занимает очень мало времени. Также мы проверили это с журналом сервера, проверив записи журнала.