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

33

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

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

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

Джошуа Фрэнк
источник
6
связанные: методика нагрузочного теста
комнат
5
Я работаю над производительностью весь день и "как QA может проверить ваши изменения?" это вопрос, который мне постоянно задают.
Брэндон
1
Обычно кэш предназначен для ускорения операции за счет сохранения в памяти результатов, которые в противном случае поступили бы из другого источника (БД, удаленный сервер, вычислительно дорогой метод и т. Д.). Поэтому измерение времени, которое должно занять время при попадании в кеш, кажется самым простым способом. Также проверьте наличие проблем с устаревшим кешем (обновления реальных данных не появляются, потому что предыдущая версия все еще кешируется)
GordonM

Ответы:

37

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

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

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

Энди Визендангер
источник
+1 за тестирование производительности вместо кеширования. Какую ценность для бизнеса кеширует само по себе? (Нет.) Конечно, вы работаете над тем, чтобы что-то ощутимо повлиять на что-то, иначе вы бы потратили время на его реализацию? Тест на это воздействие.
alexanderbird
74

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

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

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

durron597
источник
1
Заявление о том, что QA не заботится о том, как вы решаете проблему, представляет собой очень упрощенное представление о том, что интересует QA. Они заботятся о том, действительно ли вы улучшили производительность, внесли дополнительный технический долг, риск или дефекты и т. Д.
Eric
4
@Eric При разработке программного обеспечения «QA» как группа обычно не относится к разработчикам / инженерам. Технический долг - это проблема разработчика / инженера (и проблема управления, поскольку она может повлиять на сроки, затраты и т. Д.). То же самое относится и к риску. Задача QA - убедиться, что программное обеспечение соответствует требованиям (и, возможно, случайно помочь в процессе устранения неясных требований). Если они вообще заботятся о внедрении, это должно быть лишь средством поиска творческих способов сломать систему.
jpmc26
3
@Eric Я ничего не путаю. «КИ» действительно относятся к тестерам в программном обеспечении. Вы интерпретируете этот термин настолько широко, что он должен включать в себя всю компанию, разрабатывающую программное обеспечение, и даже клиента, если это система, созданная для них на заказ, поскольку у каждого есть качество.
jpmc26
1
@Eric Пожалуйста, не заставляй меня спорить, как язык и семантика работают с тобой. Я призываю вас найти 5 экземпляров этого StackExchange, где этот термин используется таким образом, менее чем за 30 минут. Кроме того, даже в соответствии с этим определением лучшее, что может сделать отдельная группа контроля качества для решения проблем, выходящих за рамки самого продукта, - это навязывать разработчикам политики, а когда политика и процесс превышают создание хороших продуктов, вы обычно получаете плохие продукты. Кроме того, я могу заверить вас, что сотрудники «QA», с которыми я работаю, определенно являются тестировщиками и мало что говорят о моем процессе разработки.
jpmc26
4
@Eric: ничто не мешает компании или группе людей, определяющих «QA», придерживаться более целостного взгляда. Тем не менее, по моему опыту (в 5 очень разных компаниях) стадия QA, как и все те, кто специализируется на ней, в разработке программного обеспечения, как правило, фокусируется на тестировании поведения системы в «черном ящике». Хотя у нас также могут быть названия «Контроль качества», «Kwalitee» и другие, придуманные, чтобы охватить специалиста в более широких вопросах качества.
Нил Слэйтер
3

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

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

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

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

Эрик
источник
3

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

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

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

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

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

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

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

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

Майкл Даррант
источник
2

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

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

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

Ян
источник
1

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

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

так далее...

Джеймс Пулли
источник
0

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

Алекс Д
источник
0

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

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

Фред Томсен
источник
-4

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

user204667
источник
3
Я не совсем уверен, что понимаю, что вы говорите или что говорит ваш ответ, чего нет в семи предыдущих ответах.