Як співробітники QA можуть перевірити логіку кешування, яку вони не бачать?

Я щойно реалізував шар кешування у своєму веб-додатку, і тепер мені цікаво, як QA повинен це перевірити, оскільки кешування прозоре для користувача.

Однією з моїх ідей є введення методів реєстрації методів, які викликають код, який заповнює кеш, і записувати, коли об’єкт витягується з кеша і коли він потребує відтворення з бази даних, і тоді тестери можуть переглянути журнали, щоб побачити, наприклад, певний об'єкт перезавантажується з db кожні 10 хвилин замість кожного перегляду сторінки.

Але чи може хтось запропонувати кілька кращих практик у цій ситуації?

Одне питання полягає в тому, чи справді кеш-пам'ять справді є вимогою, яку слід перевірити QA. Кешування покращує продуктивність, щоб вони могли перевірити різницю в продуктивності, щоб переконатися, що вона відповідає певній вимозі.

Але гарна ідея провести тестування навколо кешування, хто б не відповідав за це. Ми використовували лічильники продуктивності. Якщо ваша система кешу використовує ці переваги, вони є прямими. Якщо є можливість отримати підрахунок із самого кеша, це інший варіант.

Використання вашого підходу теж приємно. Якщо будь-який із них обгорнуто автоматизованими тестами, які перевіряють результати, нікому не доведеться переглядати журнали, щоб знайти відповіді.

Ви реалізували кеш (я припускаю), оскільки система працювала недостатньо добре. Це щось актуальне для користувача. Ось такі, які QA може перевірити:

• Що система після кешу була введена, все ще правильно. Це означає, що вони повинні спробувати ввести кеш у наданні несвіжих даних, що QA може перевірити, і переконатися, що нічого іншого не було порушено.
• Що система тепер відповідає порогам продуктивності, що вона не зустрічалася, коли ви вирішили покращити продуктивність. Вони можуть порівняти старі вимірювання та порівняти їх з новими.

Пам’ятайте, що користувачів (і, відповідно, QA) не хвилює, як ви вирішили проблему. Вони дбають лише про те, щоб проблема була вирішена і не створювали нових проблем. Це вірно, чи ви впровадили кешування, вдосконалили розбір рядків, здійснили оновлення обладнання або посипали чарівну казкову пил на сервері.

Поховання важливої ​​логіки бізнесу або стану системи в чорний ящик ускладнює перевірку правильності поведінки системи. Простіше вичерпно перевірити поведінку одного компонента в системі, ніж всієї системи. Я віддаю перевагу викриттю таких речей явно через якийсь механізм, щоб це могло бути одиничним / регресійним / інтеграційним / якісним тестуванням перевіреним деяким змістом.

Одним із варіантів кешу може бути відкриття спеціальної сторінки, яка містить деякі деталі кеша (вміст, стан тощо). Це може допомогти з налагодженням у розвитку та, можливо, у виробництві. QA також може скористатися цією сторінкою для створення тестових випадків кешу, якщо їм буде надано детальну інформацію про те, якою є очікувана поведінка кешу. Використання лічильників продуктивності та / або файлів журналів для явного документування поведінки кеша - ще один менш помітний, але життєздатний підхід.

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

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

Виконання тесту, як зазначено у відповіді Енді.

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

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

У середовищі тестування продуктивності додаток має працювати у виробничому режимі. Вам потрібно більше ніж один сервер, якщо виробництво робить, пул підключень до бази даних та кешування повинні бути встановлені для виробничого середовища тощо.

Ви також захочете розглянути інструмент, який допоможе перевірити навантаження.
jmeter дуже популярний, хоча я вважаю його досить непривітним та примітивним у використанні.
Інший маршрут, який я використав, - це просто URL-адреса curlз рубіновим сценарієм.

Щоб було зрозуміло

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

Також вам можуть бути корисні такі посилання:

• Кращі практики для одиничних методів тестування, які активно використовують кеш?
• Завантажте методологію тестування кешу
• Чи є можливість перевірити, як буде працювати сайт під навантаженням
• http://www.procata.com/cachetest/

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

Найскладніше для тестування полягає в тому, що, однак, дані оновлюються, ніколи не зберігаються застарілі результати з кешу.

Частково цьому можна допомогти, використовуючи дані в кеші, щоб заповнити сторінку підтвердження, яку бачить користувач після внесення змін. Наприклад, не використовуйте об'єкт, який ви використовували для оновлення бази даних, але запитайте дані з кешу, який потім вимагає їх з бази даних. Трохи повільніше, але набагато більше шансів виявити помилки швидше.

Ця відповідь насправді має дуже просту відповідь і пов'язана з рівнем кешування. Що ви будете спостерігати, коли кешування правильне, це відсутність запитів у цілі запитів. Отже, це зводиться до вирваної QA фрази "очікувані результати".

Якщо реалізувати кеш на веб-ярусі, я б очікував, що елементи, що підлягають кешуванню, відображатимуться лише один раз для кожного перевіреного сеансу користувача (якщо впровадити кеш-пам'ять клієнта) або один раз для декількох користувачів (якщо реалізується кеш-пам'ять стилю CDN). Якщо ви реалізуєте кеш на рівні даних для отримання загальних результатів, я б очікував, що у вашому ярусі кешування з’явиться високе відношення кеш-пам'яті разом із відсутністю запитів у журналі профілів для рівня даних.

тощо ...

Деякі речі краще перевірити програмістом, можливо, тим, хто написав код, використовуючи одиничні тести. Перевірка правильності коду кешування - одна з таких речей. (З того, як ви ставите це запитання, я припускаю, що ваші QA люди ставляться до програми як до "чорної скриньки" і перевіряють її через його зовнішній інтерфейс.)

Логіка кешування - це те, що розробник повинен перевірити, оскільки QA в основному проводить тестування в чорному ящику.

QA буде дбати лише про аспекти продуктивності або будь-яке виправлення, яке ви реалізували таким чином, ви можете надати QA механізм включення / відключення кешування або будь-який механізм, який ви використовували для підвищення продуктивності, і тоді вони можуть перевірити різницю в продуктивності. Звичайно, QA також може просто перевірити старий реліз щодо вашої покращеної продуктивності.

Коли я тестував рішення кешування, ми реалізували тоді те, що ми протестували, в основному, продуктивність. Ми зробили це рішення кешування для результатів XML, і після кешу потрібно дуже мало часу, щоб дати відповідь. Також ми перевірили його за допомогою журналу сервера, перевіривши записи журналу.