Какое правило нужно соблюдать при работе с кэшем в тестировании
Вы успешно прошли собеседование и справились с тестовым заданием, работодатель готов предложить вашу первую работу начинающим тестировщиком. И вот, вы, воодушевленные своим успехом, рветесь в бой. Ведь перед этим вы прочли пару книг (а может и больше) по тестированию ПО, успешно окончили онлайн-курс, и даже почитали пару статей в интернете: “как же быть лучшим тестировщиком”. А теперь, уже три месяца, как внемлете рекомендациям и советам более опытных коллег, задерживаетесь, чтобы разобраться в сложном функционале, заводите миллионы багов и даже утомляете себя переработками.
Наконец, испытательный срок подходит к концу, и вы счастливо потираете ручки, уверенные в своем успехе. Но… Неожиданно руководитель мягко говорит, что продолжать сотрудничество он не намерен, а найдет другого тестировщика. Погодите-ка, но почему? Вы же вроде и книги читали по тестированию, и курсы проходили, да и советам коллег следовали. Я уж молчу про заведенные баги, коих миллионы, да и переработки никто не отменял. А тут такое…
Ну что же, давайте вместе разбираться: почему, несмотря на знания и старания, могут уволить начинающих тестировщиков, и как не оказаться в их числе?
Банальная невнимательность
Оказавшись в новом коллективе, каждый хочет понравиться, произвести хорошее впечатление, зарекомендовать себя. Именно по этой причине многие начинающие тестировщики задерживаются, перерабатывают и, порой, делают совершенно не ту работу, которую от них ожидают. А все потому, что были невнимательными.
Подобного рода ошибки для меня, как менеджера команд, являются очень показательными в профессиональном плане, ведь одно из самых важных качеств тестировщика – это его внимательность. А иначе, как я могу быть уверена в качестве его работы, если он и с заданием внимательно ознакомиться не в силах?
Для наглядности, приведу пару примеров из своего опыта.
Одна из моих команд занимается тестированием сайта, который предоставляет пользователям варианты разных кредитов. Сам сайт состоит всего из двух экранов: краткой формы и расширенной, где, задав определенные параметры и значения, можно получить информацию о кредите, срок, процентную ставку, сумму и другое.
Так вот, я дала своему тестировщику задание: построить таблицу решений по экрану с краткой формой. А тестировщик сделал по расширенной, потратил невообразимое количество драгоценного времени (на минуточку, в краткой форме – три поля и 9 значений, при этом, в расширенной – более 30-ти значений), и в итоге, сделал совершенно не то, что требовалось.
Другая же моя сотрудница проходила юзабилити чек-лист, одним из пунктов которого была проверка быстродействия поискового механизма на сайте.
Пункт чек-листа звучит примерно: “Как быстро работает поиск”. И ожидается довольно простой ответ: “работает быстро, отклик укладывается в 3 секунды” (что, по общепринятым нормам – хорошо), но, почему-то такая простота смутила мою сотрудницу и она привела мне определение быстродействия, способы его замера, а вот на вопрос: “быстро ли работает поиск?” – так и не ответила. Как вы думаете, обрадовалась ли я такой “самодеятельности”? И вы будете правы, ответив нет. Время снова потрачено, а результат нулевой.
Поэтому я всегда говорю, дорогие тестировщики, будьте, пожалуйста, внимательнее, ведь в постановке задачи (вопроса) очень часто содержится и часть ответа. Не изобретайте велосипеда там, где этого от вас не требуют!
“А как же улучшить свою внимательность?” – спросите вы, и это справедливо. Ниже я поделюсь несколькими советами, которые опробовала на себе и на тестировщиках из своей команды.
- Беритесь только за одно дело. Не хватайте сразу и побольше. Многозадачность – это круто, но очень трудозатратно. Наш бедный мозг не успевает обрабатывать несколько дел одновременно и какое-то точно пустит на самотек.
Получив задачу на тестирование, занимайтесь только ей, а не говорите по телефону с подругой и не серфите в соцсетях. - Сконцентрируйтесь! Внимательно (несколько раз!) прочитайте постановку задачи, в 90% случаях в ней уже содержится алгоритм выполнения или какая-то подсказка.
- Делайте необходимое, избегая лишнего. Тут все банально просто: попросили вас декомпозировать функционал – декомпозируйте, попросили предоставить список дефектов на версии – предоставьте, а не выдумывайте от себя.
- Записывайте задачи. Память может подвести, поэтому ведите список краткосрочных (на день) и среднесрочных (неделя, спринт) дел, и отмечайте их выполнение.
Принятие всего на веру
Пожалуй, одно из тех качеств, которых не должно быть у тестировщика, – это принятие всего на веру.
“Ну так в ТЗ было написано…” Да мало ли, что в ТЗ написано! На заборе тоже много чего написано, но это же не значит, что вы всему должны верить.
Включайте, пожалуйста, свое критическое мышление, размышляйте! А такой ли результат выполнения вы ожидали? А какой будет правильным? А может быть стоит сходить к аналитику или разработчику за уточнением? Ведь в ТЗ тоже могут быть ошибки, именно поэтому его также тестируют и находят баги.
Почему важно тестировать техническое задание? Потому что это первое, куда заглянет тестировщик при возникновении вопроса. И если вы понимаете, что ТЗ нелогично, противоречиво, содержит неточности – смело идите к аналитикам по продукту и выясняйте, как должно быть на самом деле, а не принимайте на веру все написанное.
Еще одно важное правило: не верьте разработчикам, которые просят: “Не заводи ошибку, я сейчас допью кофе и за 2 минуты все сделаю”. Как правило, этот дефект так и останется не исправленным, а вы будете виноваты, что не завели баг и доказать ничего не сможете.
Личный опыт – красноречивее любых слов. На одном из моих проектов команда проходила еженедельные регрессы по сложному функционалу. Регресс был довольно длинным и занимал много времени. Один из сотрудников прошел его невероятно быстро, чем вызвал у меня очень много вопросов. Я была уверена, что просто физически невозможно пройти регресс с такой скоростью. Тестировщик же уверял, что прошел все кейсы до единого. В итоге, после его проверок стали вылазить баги на тех шагах, где он поставил статусы “пройдено”.
Оказалось, мой сотрудник перед прохождением регресса общался с разработчиком, который уверял, что все шаги (условно, с 5 по 22) были “пофикшены в этой версии и можно смело ставить статусы “пройдено”.
Довольный тестировщик поверил разработчику на слово, а может просто поленился перепроверить. Своим поступком он вызвал во мне шквал эмоций и вовсе не приятных. Отличный кандидат на увольнение, не правда ли?
Итак, чтобы не прослыть самым доверчивым и наивным тестировщиком в команде, достаточно запомнить несколько простых правил:
- Документируйте все, даже минорные баги (если, конечно, у вас на уровне SLA не прописано обратное).
- Заставляйте свой мозг думать. Когда вы обнаружили неточность между технической документацией и реализацией функционала, смело идите к аналитику или разработчику за уточнениями.
- Не принимайте в работу незадокументированные задачи. Запомните, незадокументированной задачи в нашем информационном мире просто не существует. Просите, чтобы на вас ставили или переводили задачи в таск–трекере, ну или, на самый крайний случай, – отправляли на электронную почту.
- Всегда перепроверяйте задачи, а не слепо доверяйте словам разработчиков, потому что именно мы, тестировщики, предоставляем информацию о качестве тестируемого продукта. И отвечать за проделанную работу тоже нам. Помните об этом, и не подводите себя и руководителя команды.
Ошибки, связанные с баг-трекингом
Вы можете заводить миллионы багов, быть чемпионом в вашей команде, но если баги заведены плохо (неточно, некорректно), то нет никакого смысла в их количестве!
Самая свежая и нехорошая ошибка, за которую не то, что уволить, а сразу голову оторвать хочется – это 4 баг-репорта с одинаковым заголовком: “Ошибка в форме при ее открытии”.
Именно для того, чтобы заводить ошибки понятно и беречь к тому же нервные клетки тим-лидов и разработчиков, придумали прекрасную мнемонику: “Что? Где? Когда?”
- Что?
Что происходит, или же не происходит, согласно вашему представлению о нормальной работе тестируемой системы. - Где?
В каком месте интерфейса или архитектуры системы найдена ошибка. - Когда?
В какой момент работы системы, по наступлению какого события или при каких условиях, проблема проявляется.
Если ваш баг-репорт не отвечает на эти вопросы – то это плохой баг-репорт.
Еще одной, довольно частой (на удивление) ошибкой в баг-трекинге является указание в summary ожидаемого и фактического результатов для каждого шага.
По правилам, в баг-репорт записывается один фактический и один ожидаемый результат после всех шагов. Помните, пожалуйста, что вы пишите не тест-кейс, а баг-репорт, а он имеет свою строго обозначенную структуру:
- заголовок;
- предусловия;
- шаги воспроизведения;
- фактический результат;
- ожидаемый результат;
- приложения (скриншоты, видео, логи и пр.)
Следующая ошибка, связанная с баг-трекингом, – это отсутствие конкретики. Не информативно выглядят описания дефектов с абстрактными словами: несколько, множество, разные или подходящие (про значения). Разработчик ждет конкретных указаний для воспроизведения дефекта и, скорее всего, его “несколько” и ваше “несколько” – это разные вещи. Заводя дефекты без конкретных данных, на которых можно повторить ошибку, вы тратите не только время команды разработки, но и свое собственное. Потому что в 99% случаях такой баг вернется вам на доработку. А как вы знаете, время в тестировании – на вес золота.
Еще одна, довольно грубая ошибка, когда в одном баг-репорте содержится несколько найденных дефектов. Такие репорты скорее напоминают простыню текста, а не привычное описание ошибки.
Запомните, один баг = один репорт! Так они намного легче исправляются и, главное, отслеживаются и перепроверяются тестировщиками. Согласитесь, гораздо проще проверить одну описанную ситуацию, нежели 15.
Ваш менеджер, увидев такие баг-репорты, явно не захочет читать морали, а просто решит сменить вас на другого специалиста, потому что умение четко и понятно заводить баги – одна из главных задач тестировщика.
Вместо заключения
Все мы люди и все мы совершаем ошибки. Не нужно этого бояться (особенно, если вы новичок). Ошибки – это хорошо, ведь благодаря им можно учиться и приобретать полезный и ценный опыт. Но когда одна и та же ошибка повторяется из раза в раз – это дает пищу для размышления вашему менеджеру и порождает желание заменить вас на другого специалиста.
Именно сейчас самое время остановиться и немного подумать: а все ли правильно я делаю? Как часто допускаю ошибки? Выношу ли из них полезный урок? Эти вопросы очень важны, чтобы определить, в верном ли направлении вы движетесь. Помните, что испытательный срок – это не повод паниковать, это — всего лишь отправная точка вашего становления как тестировщика. И чтобы он прошел гладко, без лишнего волнения, я поделюсь с вами секретами на своем курсе. На нем вы познакомитесь с миром тестирования, узнаете о его техниках, видах, научитесь правильно и хорошо заводить баг-репорты, писать отчеты по тестированию, а также тестировать требования, и, что тоже немаловажно, научитесь деловому общению.
Работа с контрольными точками остановы
Отдельного внимания заслуживает настройка точек остановки (брейкпоинты), с помощью которых пользователи могут перехватывать конкретные запросы. Выполнить установку контрольных точек можно посредством контекстного меню выбранного запроса.
После выполнения таких действий все идентичные запросы будут перехвачены в автоматическом порядке. Пользователь при желании сможет их просматривать и редактировать.
Дополнительно можно рассмотреть вопросы тестирования ПО на плохой связи. Системные возможности Charles Proxy позволяют тестировать сервис при таких условиях с помощью простой конфигурации пропускной нагрузки выбранного канала (англ. throttling).
Данная функция крайне полезна для проверки разнообразных десктопных утилит, так как уровень связи для портативных гаджетов можно редактировать посредством панели разработчика.
К слову, настройка данного процесса происходит в панели Proxy > Throttling settings. Пользователь может включить ограничение как для хостов из предложенного списка, так и для абсолютно всех перехваченных запросов.
Зачем нужен кэш?
Сохранение данных веб-страниц на компьютере, вместо их повторной загрузки, помогает экономить время открытия веб-сайтов в браузере. Также используется меньше данных, что особенно полезно для мобильных пользователей с ограниченными тарифными планами. Ваш телефон не должен загружать каждое изображение и веб-страницу несколько раз, поскольку он может восстановить данные из кэша. Но сохранение данных происходит не только в браузере и для веб-страниц.
Таким образом
В целом Charles Proxy являет собой первоклассный инструмент, который решает вопросы минимальных потребностей при взаимодействии с сетевыми запросами. С его помощью пользователи могут не просто тестировать запросы, но и выполнять всевозможные конфигурационные настройки под собственные надобности и поставленные задачи.
Кэш – это комплексная система. Соответственно, под разными углами результат может лежать как в действительной, так и в мнимой области. Очень важно понимать разницу между тем, что мы ждем и тем, что есть на самом деле.
Давайте прокрутим полный оборот ситуаций.
Итак, теперь мы хотим показывать на нашем сайте курс доллара к евро. Для этого нам нужно получить курс, поэтому на нашем сайте мы создаём API-обёртку для удобного использования:
И в шаблонах в нужном месте вставляем что-нибудь вроде:
Вот тут на сцену выходит его величество Кэш
Зачем нам спрашивать курс для каждого пользователя на каждое обновление страницы, если для людей эта информация, в общем-то, не нужна так часто? Давайте просто ограничим частоту обновления до, например, раз в 5 секунд. Пользователи, переходя со страницы на страницу, всё равно будут видеть новое число, а мы платить будем в 1000 раз меньше.
Сказано – сделано! Добавляем несколько строчек:
Это самый главный аспект кэша: хранение последнего результата.
И вуаля! Сайт снова становится для нас почти бесплатным… До конца месяца, когда мы обнаруживаем от внешней системы счет на 4 евро. Конечно, не 6, но мы ожидали намного большей экономии!
К счастью, внешняя система позволяет посмотреть начисления, где мы видим всплески по 100 и более запросов каждые ровные 5 секунд в течение пиковой посещаемости.
Так мы познакомились со вторым важным аспектом кэша: дедупликацией запросов. Дело в том, что как только значение устарело, между проверкой наличия результата в кэше и сохранением нового значения, все пришедшие запросы фактически выполняют запрос к внешней системе одновременно.
В случае с memcache это можно реализовать, например, так:
И вот, наконец, потребление сравнялось с ожидаемым — 1 запрос в 5 секунд, расходы сократились до 2 евро в месяц.
Почему 2? Было 6 без кэширования для тысячи человек, мы же всё закэшировали, а сократилось всего в 3 раза? Да, стоило просчитать пораньше… 1 раз в 5 секунд = 12 в минуту = 72 в час = 576 за рабочий день = 17 тысяч в месяц, а ещё не все ходят по расписанию, есть странные личности заглядывающие поздней ночью… Вот и получается, в пике вместо сотни обращений одно, а в тихое время — по-прежнему запрос почти на каждое обращение проходит. Но всё равно, даже в худшем случае счёт должен быть 31×86400÷5 = 5.36 евро.
Так мы познакомились с еще одной гранью: кэш помогает, но не устраняет нагрузку.
Впрочем, в нашем случае люди приходят в проект и уходят и в какой-то момент начинают жаловаться на тормоза: страницы замирают на несколько секунд. А еще бывает под утро сайт не отвечает вообще… Просмотр консоли сайта показывает, что иногда днём запускаются дополнительные инстансы. В это же время скорость выполнения запросов падает до 5-15 секунд на запрос — из-за чего это и происходит.
Упражнение для читателя: посмотреть внимательно предыдущий код и найти причину.
Кстати, это грабли отнюдь не только кэша, это общий аспект распределённых блокировок: важно освобождать блокировки и иметь таймауты, во избежание дедлоков. Если бы мы добавляли "?" вообще без времени жизни, всё б замирало при первой же ошибке связи с внешней системой. К сожалению, memcache не предоставляет хороших способов для создания распределённых блокировок, использование полноценной БД с блокировками на уровне строк лучше, но это было просто лирическое отступление, необходимое просто потому, что на эти грабли наступили.
Итак, мы исправили проблему, вот только ничего не изменилось: всё равно изредка начинались тормоза. Что примечательно, они совпадали по времени с информационным бюллетенем от внешней системы о технических работах…
Ну-ка ну-ка… Давайте сделаем краткую передышку и пересчитаем, что мы насобирали уже сейчас, что должен уметь кэш:
- помнить последний известный результат;
- дедуплицировать запросы, когда результат еще или уже не известен;
- обеспечивать корректную разблокировку в случае ошибки.
Отсюда: кэш обязан уметь какое-то время хранить отрицательный результат. Наше наивное исходное предположение по сути подразумевает хранение отрицательного результата 0 секунд (но передачу этого самого отрицания всем, кто уже ждёт его). К сожалению, в случае с Memcache реализация нулевого времени ожидания весьма проблематична (оставлю как домашнее задание въедливому читателю; cовет: используйте механизм CAS; и да, в AppEngine можно использовать и Memcache и Memcached).
Мы же просто добавим сохранение отрицательного значения с 1 секундой жизни:
Казалось бы, ну теперь-то уже всё, и можно успокоиться? Как бы не так. Пока мы росли, наш любимый внешний сервис тоже рос, и в какой-то момент начал иногда тормозить и отвечать аж по секунде… И что примечательно – вместе с ним начал тормозить и наш сайт! Причем снова для всех! Но почему? Мы же всё кэшируем, в случае ошибок запоминаем ошибку и тем самым отпускаем всех ожидающих сразу, разве нет?
…А вот и нет. Внимательно посмотрим на код еще раз: запрос ко внешней системе будет исполняться столько, сколько позволит file_get_contents() . На время исполнения запроса все остальные ждут, поэтому каждый раз, когда кэш устаревает, все потоки ждут исполнения главного, и получат новые данные только, когда они поступят.
Что ж, мы можем вместо ожидания, добавить ветку else<> у условия вокруг memcache->add … Правда, стоит, наверное, вернуть последнее известное значение, да? Ведь мы кэшируем ровно затем, что мы согласны получить устаревшие сведения, если нет свежих; итак, еще одно требование к кэшу: пусть подтормаживает не более одного запроса.
Итак, мы снова победили: даже если тормозит внешний сервис, подтормаживает не более одной страницы… То есть как бы среднее время ответа сократилось, но пользователи всё равно немного недовольны.
Примечание: обычный PHP по умолчанию пишет сессии в файлы, блокируя параллельные запросы. Чтобы избежать этого поведения, можно передать в session_start параметр read_and_close либо принудительно закрывать через session_close сессию после совершения всех необходимых изменений, иначе тормозить будет не одна страница, а один пользователь: так как скрипт, обновляющий значение, будет блокировать открытие сессии другим запросом от того же пользователя. При исполнении на AppEngine по умолчанию включено хранение сессий в memcache, то есть без блокировок, поэтому будет проблема не так заметна.
Так вот, пользователи всё равно недовольны (ох уж эти пользователи!). Те, кто проводят времени больше всех на сайте, всё равно замечают эти короткие зависания. И их нисколько не радует осознание факта того, что так случается редко, и им просто не везёт. Придётся для данного случая сделать требование еще более жестким: никакие запросы не должны ждать ответа.
Что же мы можем сделать в такой постановке вопроса? Мы можем:
-
Попытаться исполнить трюки «исполнение после ответа», то есть если мы должны обновить значение – регистрируем хендлер, который это сделает после исполнения всего остального скрипта. Вот только это сильно зависит от приложения и окружения исполнения; самый надёжный способ — использование fastcgi_finish_request() , требующий настройку сервера через php-fpm (соответственно, недоступен для AppEngine).
Итак, наш поставщик данных растёт, но не все его клиенты читают хабр, а потому они не используют правильного кэширования (если используют его вообще) и в какой-то момент начинают выдавать огромное количество запросов, из-за чего сервису становится плохо, и эпизодически он начинает отвечать не просто медленно, а очень медленно. До десятков секунд и более. Пользователи, конечно, быстро обнаружили, что можно нажать F5 или иначе перезагрузить страницу, и она появляется моментально – вот только страница снова начала упираться в бесплатные пределы, так как постоянно начали висеть процессы, просто ожидающие внешний ответ, но потребляющие наши ресурсы.
В числе прочих побочных эффектов участились случаи показа устаревшего курса. [Мда… в общем, представьте, что мы сейчас говорим не про наш случай, а про что-нибудь более сложное, где устаревание видно невооруженным глазом :) на самом деле, даже в простом случае обязательно найдётся пользователь, который заметит такие совершенно неочевидные косяки].
Смотрите, что получается:
- Пришел запрос 1, данных в кэше нет, так что добавили маркер '?' на 5 секунд и пошли за курсом.
- Спустя 1 секунду пришел запрос номер 2, увидел маркер '?', вернул данные из stale записи.
- Спустя 3 секунды пришел запрос номер 3, увидел маркер '?', вернул stale.
- Спустя 1 секунду маркер '?' устарел, несмотря на то, что запрос 1 всё еще ждет ответа.
- Спустя еще 2 секунды пришел запрос номер 4, маркера нет, добавляет новый маркер и отправляется за курсом.
- …
- Запрос 1 получил ответ, сохранил результат.
- Пришел запрос X, получил актуальный ответ из кэша 1-го вопроса (а когда пришел тот ответ? На момент запроса, или момент ответа? –, этого никто не знает…).
- Запрос номер 4 получил ответ, сохранил результат – причем снова непонятно, был ли этот ответ более новый или более старый.
Итак, давайте подведём промежуточный итог. В бытовом понимании кэш:
- заменяет большинство запросов на получение уже известного ответа;
- ограничивает число запросов к получению дорогих данных;
- делает время запросов невидимыми для пользователя.
- заменяет некоторые запросы из окна жизни кэша на запомненные значения (кэш может потеряться в любой момент, например, из-за нехватки памяти либо экстравагантных запросов);
- пытается ограничить число запросов (но без специальной имплементации ограничения частоты исходящих запросов, реально можно обеспечить только характеристики типа «максимум 1 исходящий запрос в один момент времени»);
- время исполнения запроса видимо только некоторым пользователям (причем распределены «счастливчики» отнюдь не равномерно).
- кэш может быть потерян в любой момент времени. Даже наши маркеры блокировки исполнения '?' могут быть потеряны, если параллельно еще 10 тысяч пользователей гуляет по сайту, все сохраняя что-то (зачастую время последнего обращения на сайт) в сессию, которая лежит на том же кэш-сервере; после того как маркер потерян («кэш отравлен»), следующий запрос опять начнёт процедуру обновления значения в кэше;
- чем быстрее исполняется запрос в удалённой системе, тем меньше запросов будет дедуплицировано в случае отравления кэша.
Рассмотрим простейший случай:
- Мы смотрим на систему в спокойном состоянии, и видим среднее время исполнения 0.05 сек.
- Вывод: 1 процесс может обслужить 20 запросов в секунду, значит, для 100 запросов в секунду достаточно 5 процессов.
- Вот только если время обновления запроса возрастает до 2 секунд, то получается:
- 1 процесс занят обновлением (в течение 2 секунд);
- в течение этих 2 секунд у нас доступно только 4 процесса = 80 запросов в секунду.
Особенно прекрасно это смотрится, когда после новостной рассылки с какими-либо новыми функциями практически одновременно приходит волна пользователей. Эдакий маркетологический хабраэффект на регулярной основе.
Всё это не означает, что кэш нельзя или вредно использовать! О том, как правильно применять кэш для улучшения стабильности системы и как восстанавливаться от вышеупомянутой петли гистерезиса, мы поговорим в следующей статье, не переключайтесь.
Использование Charles Proxy при тестировании мобильного ПО
Итак, перед нами поставлена задача провести проверку мобильного ПО. Для этого нам потребуется включить Charles Proxy на ПК, который находится внутри той же локальной сети, что и тестируемый продукт. Подобное соединение выстраивается по Wi-Fi сети.
Стоит отметить тот факт, что в Android все сертификаты верифицируются в Settings > Trusted Credentials во вкладке User.
Алгоритмы кэша
Алгоритм кэширования — это подробный список инструкций, который указывает, какие элементы следует отбрасывать в кэш.
Наименее часто используемые (Least Frequently Used — LFU). Данный алгоритм основывается на отслеживании частоты доступа к записи. При использовании алгоритма кэширования LFU запись с наименьшим счетом удаляется первой. Этот метод используется не так часто, так как он не учитывает элемент, который изначально имел высокую скорость доступа, а затем долго не использовался.
Давно неиспользованные (Least Recently Used — LRU): этот алгоритм кэширования хранит недавно использованные элементы в верхней части кэша. При каждом обращении к новому элементу LRU помещает его в верхнюю часть кэша. Когда лимит кеша будет достигнут, элементы, к которым давно не обращались, будут удалены, начиная с нижней части кэша. Это может быть дорогостоящим алгоритмом, поскольку он должен содержать «биты возраста», которые точно показывают, когда к элементу обращались. Кроме того, когда алгоритм кэширования LRU удаляет элемент, «возрастной бит» изменяется для всех других элементов.
Последние использованные (Most Recently Used — MRU): этот алгоритм кэширования, в отличии от предыдущего, удаляет самые последние использованные элементы в первую очередь. LRU ориентируется на время: здесь чем старше элемент, тем он меньше используется и удаляется в первую очередь. MRU — наоборот, чем старше элемент, тем чаще к нему обращаются, и в первую очередь здесь удаляются последние использованные элементы, так как они меньше всего использовались. Таким образом, LRU удаляет самые неиспользуемые элементы — самые старые, а в MRU удаляет самые новые.
Кэш адаптивной замены (Adaptive Replacement Cache — ARC): этот алгоритм использует оба вышеуказанных, чтобы наилучшим способом использовать доступный кэш.
Использование при тестировании
Проблемы с Кэшем
Несмотря на то, что кэш позволяет сохранять время и данные, он может быть искаженным и иногда приносить больше вреда, чем пользы.
Вирус может скачать себя в кэш браузера, заражая весь ваш компьютер.
Файлы могут сильно устареть, если кэш не очищается автоматически, а это означает, что просматриваемые страницы могут быть неактуальными или даже вызывать ошибки.
Один из частых вопросов разработчика на баг это: “А ты кэш почистил?”. Не забывайте очищать кэш перед воспроизведением бага.
Кэш может занимать гигабайты данных. Учитывая, что компьютеры и телефоны имеют очень ограниченный размер хранилища. Кэш всех видов должен очищаться по необходимости.
Очистка кэша
Удалить кэш в браузере можно через опцию «Очистить историю».
Вы тестировщик и чувствуете, как страдает работа на проекте? Понимаете, что неразбериха наступает из-за хаотичного отношения к требованиям? В этой небольшой статье мы собрали несколько советов о том, как правильно работать с требованиями, а также чек-лист проверки того, пора ли что-то менять.
Сперва определитесь точно, нужно ли что-то менять в вашем проекте. Ведь все проекты разные, и единого пути нет. Как это сделать? Воспользуйтесь нашим чек-листом! Если совпадет хотя бы 3 пункта, пора действовать.
Чек-лист возможных проблем на проекте по тестированию:
1. У заказчика никогда нет времени, чтобы сформулировать или согласовать требования.
2. Команда не может напрямую взаимодействовать с пользователями.
3. Нет приоритетов у требований. Для заказчика одинаково важно всё.
4. У команды тестировщиков много вопросов по требованию в процессе работы. Приходится много раз переписывать тестовые сценарии и код, тратить на это время.
5. Заказчики придумывают задачи в отрыве от потребностей пользователя.
6. Заказчик вносит изменения в требования после их согласования.
7. Постоянно откладываются сроки релиза – добавляют новые требования.
8. Функции, которые попросил заказчик, конечному пользователю не нужны, и поэтому не используются.
9. Пользователи не удовлетворены функционалом ПО.
Что же делать, если вы узнали в этих пунктах свой случай? Наладить процесс рецензирования требований до старта проекта. Для этого есть два варианта.
Первый: как только спецификация написана, ее передают на проверку экспертам, чтобы пункты из чек-листа выше не появлялись в процессе работы.
Плюсы этого варианта:
1. Можете быть уверены, что в процесс разработки и тестирования выйдет уже проверенная, «стабильная» версия документа.
2. Можно погрузиться глубже и учесть неявные требования, потому что весь фокус будет только на рецензировании.
3. Стабильность позволяет лучше контролировать сроки и бюджеты.
Минусы:
1. Высокая степень ответственности тех, кто проверяет (рецензентов). Если в процессе работы найдут ошибки, то спрашивать будут с вас.
2. Нужно очень хорошо разбираться в предметной области, технических аспектах.
3. Нужно выделять время и бюджет на эту задачу. Заказчикам будет сложно объяснить, зачем им тратить все это на рецензирование.
Поэтому многие выбирают второй вариант – рецензировать требования в процессе разработки.
Плюсы:
1. Не надо отдельно выделять время на рецензирование. Вся команда работает над одним блоком функциональности, и вопросы решаются быстро.
2. К рецензированию меньше требований – все равно бОльшая часть ошибок будет найдена разработчиками и тестировщиками.
Минусы:
1. Приходится запоминать много информации, например, как что работает в чужом модуле.
2. Частые переключения между видами активностей: то писать тесты, то прочитать документацию, с кем-то связаться и т.п.
Что ж, есть ли метод, который объединит плюсы рецензирования до разработки и после начала процесса разработки? Да! И это «метод набегающей волны»
(Rolling Wave Planning).
Чем волна дальше, тем она меньше. Чем ближе, тем больше. Так и в этом методе: перед началом разработки мы делаем высокоуровневую проверку, не углубленную. А вот перед началом проверки какого-либо конкретного модуля уже проводим анализ моделей, ищем ошибки в требованиях. То есть больше детализируем. И в конце, перед началом итерации, тестируем требования через разработку тестовой документации. Так мы снижаем риск ошибок и уменьшаем затраченное время.
Нужен простой пример? Возьмем путешествие. Сначала вы планируете шаги: сделать загранпаспорт, получить визу, прививку, купить билеты, забронировать жилье. Потом увеличиваете количество задач: сделать загранпаспорт – это заполнить заявление, оплатить пошлину, съездить в такое-то учреждение или зарегистрироваться на определенном сайте. Получить визу – это также заполнить заявление, сделать фото, выписки по счету, сдать биометрию и т. д.
пример метода набегающей волны
Так же переходить к задачам нужно будет и на проекте в тестировании.
Надеемся, что вам помог наш чек-лист, а перечисленные методы подтолкнули к тому, чтобы изменить процессы к лучшему. И пускай каждая команда тестировщиков выстроит идеальный процесс работы с требованиями!
Остались вопросы? Чувствуете, что вашей команде не хватает структурированной информации? Интересно узнать весь процесс работы с требованиями от начала до конца?
Итак, анализаторы трафика, или снифферы – это особый инструментарий, позволяющий тестировщикам перехватывать и анализировать запросы, которые проходят через них. Подобные технологии очень полезны в ситуации, когда пользователю нужно получить сведения или сконфигурировать необходимый ответ от сервера. Такие методики работы с запросами позволяют не просто выполнять модульное тестирование ПО, но и работать с разными версиями веб-продукта.
Преимущество использования снифферов в целом и Charles Proxy в частности в том, что можно просматривать весь трафик как с экранов локальных машин, так и с мобильных устройств. Это существенным образом облегчает жизнь QA-специалиста при выполнении клиент-серверных работ.
Как просматривать SSL-трафик
После того, как мы выполнили процесс установки SSL-сертификата, для анализа зашифрованного трафика нам останется всего лишь активировать SSL proxying для необходимого хоста непосредственно в Charles Proxy. Все это можно выполнить через специальное контекстное меню определенного хоста.
Если неудобно включать каждый хост по отдельности, можно перейти в меню Proxy>SSL Proxying settings и в первой вкладке активировать пункт Enable SSL Proxying.
Кэш (Cache)
Кэш — это временное хранилище для данных посещенного сайта.
В кэше сохраняются:
· Изображения — логотипы, картинки, фоны и т. д.;
Типы использования кэша
Сервер кэширования: выделенный сетевой сервер или служба, действующая как сервер или веб-сервер, который сохраняет веб-страницы или другой интернет-контент локально. Кэш-сервер иногда называют прокси-кэшем.
Дисковый кэш: содержит недавно прочитанные данные и, возможно, смежные области данных, которые, вероятно, будут доступны в ближайшее время. Некоторые диски кэшируют данные в зависимости от того, как часто они читаются. Часто читаемые блоки хранения называются горячими блоками и автоматически отправляются в кэш.
Кэш-память: кэш-память процессора часто связана непосредственно с процессором и используется для кэширования часто используемых инструкций. Кэш-память оперативки намного быстрее, чем кэш-память на диске, но кэш-память процессора намного быстрее, чем кэш-память оперативки, потому что она находится так близко к процессору.
Флэш-кэш: временное хранение данных на микросхемах флэш-памяти — часто с использованием твердотельных накопителей — для выполнения запросов данных быстрее, чем это было бы возможно, если бы кэш находился на традиционном жестком диске или его части.
Постоянный кэш: учитывается фактическая емкость хранилища, где данные не теряются в случае перезагрузки или сбоя системы. Резервная батарея используется для защиты данных или данные сбрасываются в динамической оперативной памяти с резервным питанием от батареи в качестве дополнительной защиты от потери данных.
Использование на ПК
Charles Proxy содержит массу вариаций по фильтрации запросов. Их анализ можно выполнять следующими способами:
- Использование вкладки Structure. Для начала можно просто скопировать хост и проставить его в поле Filter. Подобная манипуляция позволяет ознакомиться с запросами данного хоста.
- Использование вкладки Sequence. Здесь мы можем не только ознакомиться с данными о запросах, но и поработать с регулярными выражениями. Параметр autoscroll позволяет выбирать требуемое количество строк, которые мы можем или нам необходимо обработать в процессе тестирования.
Charles Proxy также позволяет фильтровать не просто отображение, но и процесс записи запросов. Для настройки данной конфигурации необходимо перейти в Proxy > Record Settings и вручную указать тестовые условия на вкладке Include или же Exclude.
Подобная манипуляция позволяет включать или выключать процесс записи запросов выбранного хоста.
Как работает кэш?
Когда вы открываете веб-страницу, браузер кэширует эти данные: загружает картинки, текст на ваш компьютер. Когда вы заходите на сайт снова, эти данные уже находятся на вашем компьютере или устройстве. При повторном заходе на сайт, если веб-страница не изменилась, браузер загружает файлы из кэша, а не заново скачивает из Интернета.
Читайте также: