Pull to refresh
30
0

Пользователь

Send message

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

Это как если бы я со стабильного Дебиана щас перешел на Microsoft Insider Builds, и потом канифолил всем мозг на тему "Этот виндовс вапще ни разу не стабильный".

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

"ЛюбвИАбильный динозавр" - это какая-то игра слов, или вы правда считаете, что это слово так пишется?

Он еще и в целом приятный человек. Переписывался с ним по поводу дисковой подсистемы JSLinux году в 2013 или около того. Отлично пообщались.

В результате начинается использование виртуальной памяти, что замедляет производительность из-за более медленного доступа к данным.

Тут требуется уточнить, мне кажется.

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

NTFS(New Technology File System):

Ограничения по размеру файла и раздела:

  • Максимальный размер файла: 16 ЭБ (экзабайт).

  • Максимальный размер раздела: 256 ТБ.

Погодите-ка. Давайте разберём эти странные цифры из википедии.

16 экзабайт - это теоретический максимум размера файла для NTFS. Максимальный имплементированный размер файла - 8 PB. 256 TB минус 64 килобайта - это максимальный размер раздела с размером кластера 64Кб. Максимальный размер кластера, поддерживаемый NTFS - 2MB. Максимальный теоретический размер раздела для 2MB кластера - 32*256 TB?

Судя по всему, имеет смысл все-таки говорить о том, что имплементировано, и это, похоже, 8PB c кластером 2Mb для раздела и столько же для максимального размера файла.

Зависит от проекта и того, какой подход используется - Application Action или Page Object Model. Можно в Dictionary, можно в отдельный класс Selectors, можно как проперти Page Object, можно enum. Главное, чтобы в самих тестах использовались имена для элементов, с которыми вы работаете, а не селекторы напрямую.

При использовании Application Action может быть проще.

Пример. У меня был случай, когда был набор из нескольких веб-приложений построенных на одной кастомной UI библиотеке с 2-3 разными версиями этой самой библиотеки. Разные тестовые пакеты (один пакет на приложение) включают класс приложения. Класс приложения имеет проперти Locators, это проперти - объект, унаследованный от CommonHelpers.CommonLocators и расширяющий его специфическими для данного приложения локаторами. Объект - потому что туда же можно добавить методы для динамической генерации селекторов, а точные селекторы как проперти. В том случае, если в каком-то приложении селектор отличается от того же в CommonLocators, он просто добавляется в локальный класс Locators через override. Когда тестируемое приложение обновилось до совпадающей с CommonLocators версии UI библиотеки, локальные селекторы просто удаляются из локального класса селекторов и автоматически за счет наследования используются общие селекторы.

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

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

Я в целом тоже предпочитаю XPath, просто стараюсь писать менее хрупкие селекторы по возможности.

Уважаю ваше мнение, но по некоторым моментам могу сказать из практического опыта. Единый стиль селекторов - это практике обычно "nice to have". Поясню.

  1. Приложения могут писаться в течение долгих лет кучей разных людей и даже команд. На практике сложно наладить коммуникацию и внедрение id и name везде, если разработка не затрагивает более старые части приложения. Прямо сегодня они должны (на самом деле нет) писаться с добавлением уникальных идентификаторов, с этим согласен, но на практике я не скажу разработчикам "тут нет айди, иди переделывай", я скорее всего просто использую xpath и подожду, пока этот id там появится. Кроме того, он, в отличие от id, name и CSS, подходит для поиска элементов, которые содержат определенный текст, например, что бывает полезно иногда.

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

  3. С динамическими приложениями, в которых элементы генерируются автоматически, номер с id и name очень часто не пройдет, поэтому там проще использовать селектор-генераторы, функции, которые генерируют селекторы на основе xpath-шаблона для элементов определенных типов.

Я бы тоже предпочёл иметь везде id, потому что это не только проще использовать, но и сложнее сломать, но, к сожалению, это не всегда реалистично. XPath сильно гибче, но менее надёжен, если UI в активной разработке. Про CSS, который генерируется автоматом и минимизируется на каждый билд, поэтому меняется полностью каждый билд, вообще молчу. Поэтому временами приходится комбинировать и то, и то, и то, и просто стараться соблюдать баланс между покрытием, стабильностью тестов и удобством поддержки. В любом случае, это всё не для того, чтобы сделать вам приятно, а для того, чтобы бизнес мог решать свои задачи.

По поводу быстродействия полностью согласен. Разница в поиске была заметна во времена древних версий Internet Explorer может быть, ни для одного современного браузерного движка это не проблема, любой простой запрос на бэк + обновление DOM tree обычно занимает дольше.

Буква A может выглядеть так:

>+++++++++++++[<+++++>-]<.

Вместо 65 плюсов можно было показать в статье как организуются и работают циклы, и заодно сократить длину программы. Согласен с комментарием @bfDeveloper по поводу того, что алгоритмы - это про логику, а не конструкции языка. Было бы отлично показать больше логики в статье, на мой вкус получилось так себе, хоть и не минусовал. Плюс, для такого транслятора разворачивать аж целый python runtime чувствуется как солидный оверхэд. Но это ладно. Если использовать match (с версии 3.10, если не ошибаюсь), код можно сделать проще. Плюс начало цикла "[" само по себе ничего не делает, а просто служит точкой останова для "]". ] - это буквально "проверить значение в текущей ячейке, и, если не ноль, уменьшать индекс рабочей ячейки в массиве программы, пока не найдено [, увеличить индекс на 1 (>)". Как-то так.

Если интересуют "более другие" варианты писать на BF, есть отличная среда программирования bfdev (HTTP без S), включающая в том числе расширения языка и автоматическую оптимизацию кода, насколько помню. Я ее использовал, когда преподавал курс по BF лет 7 назад.

В своё время работал с провиженингом девайсов от разных производителей (ealink, правда, мало застал, в основном Cisco и Polycom), лучшая защита передаваемых данных - это использовать HTTPS, а не TFTP. Тогда можно использовать клиентские сертификаты устройств и двустороннюю TLS аутентификацию.

Многие, если не все, производители добавляют в прошивку клиентские сертификаты, содержащие Mac-адрес телефона. В этом случае можно отсекать нелигитимные запросы прямо на этапе хэндшейка (мак-адрес из сертификата, название запрашиваемого файла, intermediate сертификат производителя, которым подписан сертификат телефона), и заодно китайские подделки с клонированными чипами. Правда мы это делали в промышленном масштабе, 5+20 - это мало, у нас были пяти-шестизначные цифры, но, тем не менее, приципиально это ничего не меняет. Просто валидация CA на сервере, без всего остального, сильно усложняет запросы от всего, что не телефон, причем быстро.

TFTP в пределах одной организации вполне себе может быть, если SIP-шлюз тоже внутри. Не все хотят заморачиваться с безопасностью в локальной сети в малых организациях. Любой выход наружу - HTTPS, плюс защитные меры выше, плюс еще кучу проверок можно добавить если запрос каким-то чудом проскочил mutual authentication, можно валидировать вообще всё, что приходит в запросе, до отдачи конфига (заголовки HTTP-запроса, например, размер запроса, и так далее). Ломать SSL/TLS - так себе занятие. Дорого, скучно, проще другого провайдера найти, с защитой попроще. Ломать SSL/TLS + проверки провиженинг-сервера - это надо быть очень целеустремлённым.

Сами телефоны обычно пароль не отображают, в открытом виде или в виде хэша, в гуе, и многие при скачивании конфигов его в эти конфиги не пишут. Передача - внутри HTTPS, что уменьшает шансы перехвата, оставляя, в общем, только MITM с кучей дополнительных телодвижений, что, опять же, и долго, и недёшево, и явно того не стоит.

В общем, хотите безопасности - используйте провиженинг-сервер и HTTPS, а не DHCP+TFTP.

Представьте: вы сможете удержать в кратковременной памяти не 3-4 концепта, а 40-50! И не просто удержать в памяти, а мгновенно выделить несколько взаимосвязанных концептов, сформулировать эту связь и сделать вывод. Потом использовать этот вывод как ещё один концепт, найти новые связи... И ни один этап не вызовет затруднений.

Отлично представляю, потому что примерно так мой мозг и работает. Но есть нюанс. Так работает мозг людей с расстройством аутистического спектра в гиперфокусе. Тут вы, на удивление, даже в количеством концептов угадали. На самом деле можно больше (раза в три), просто тогда время начинает идти субъективно неравномерно, и устаешь быстрее.

Не уверен, получилось бы у нейротипичного мозга так работать или нет.

Так что я бы сказал так: главный инструмент тестировщика - автоматизированные тесты.

После работы тестировщиком больше 12 лет могу сказать, что главный инструмент тестировщика - это мозг.

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

И, кроме того, автотесты - это checks, а не tests.

Да, я согласен, что если что-то надо делать руками регулярно, это можно автоматизировать, чтобы освободить время для exploratory тестинга. И Cypress - это отличный инструмент в некоторых случаях (в том числе и за счет cy.intercept()), как и Playwright (который тоже умеет в перехват запросов). Единственное только, тестирование - это контекстно-зависимая штука, и контекст, в котором вы говорите, насколько я понял, - это только фронтенд. Не все могут в контекст.

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

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

По поводу вашего коммента ниже - тоже согласен, можно автоматизировать проверки на фронте за пару пятничных вечеров, но, вы же понимаете, что это только самое начало? Мало написать, надо поддерживать, актуализировать, где возможно и имеет смысл - спускать на более низкий уровень пирамиды тестирования. Просто хотя бы потому, что я могу прогнать 300 API тестов за минуту и гораздо меньше E2E сценариев за то же время, даже если перехватывать запросы на бэк. И зря вы так категорично сразу про GraphQL. Хорошая штука, но... Если на бэк идет много запросов (почему, собственно, он их и отдает, он же не сам решает вам жысонов в браузер напихать), то надо думать об архитектуре в первую очередь, доменной области и как там представлены данные, и почему в этой модели фронтенд хочет эти разные данные. Может так случиться, что GraphQL не понадобится, потому что он только сделает хуже, хотя бы потому, что данные через REST можно получать в параллель, и так далее.

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

К статье еще бы добавил блокировку запросов по маске в Dev Tools.

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

Спасибо, что объяснили, не очень понятно было. Извините, с суммами с недосыпа это я тупанул конечно.

Я конкретно про ответ petropavel и твой вопрос "при чем здесь сумма?", в котором буквально есть слово "сумма". А не про то, о чем ты раньше спросил.

То есть, тут получается просто кастомный компаратор по длине вектора? Или вы что-то другое ожидаете?

Насколько я понял (может я не прав, конечно), тут говорится о сумме "значение на одной кости плюс значение на другой кости", что само по себе можно рассматривать как независимое событие (как и бросание монетки). При увеличении количества опытов до 100, 1000, 10000, бесконечности мы получим пределы вероятности выпадения каждой возможной суммы, которые стремятся к значению в районе 1/36. В том смысле, что стремятся стать равновероятными. Принципиально это не отличается от подбрасывания монетки. @petropavel, или вы не об этом?

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

Вы сначала описываете контракт формально, а потом еще и OpenAPI спеку генерите из того, что получилось? И потом тестеры руками сравнивают то, о чем было договорено и то, что нагенерилось? Я просто не совсем понимаю смысл генерации спеки из того, что может быть потенциально некорректно реализовано (что, в свою очередь, сгенерирует кривую спеку), мне субъективно кажется более логичным написать спеку на контракт, и потом сделать кодогенерацию по ней, чем наоборот. Опять же, так было бы проще искать некоторые баги, вместо того, чтобы выяснять, где правильно - там, где договорено, или там, где реализовано.

Я, конечно не автор, но могу предположить, что там что-то МЕДЛЕННО отрисовывается на каждой панели, как минимум 2 секунды, плюс-минус 0-5 секунд. Меня больше смущает, что там каждый раз создается implicitlyWait в цикле, при этом цикл for, а не какой-то forEach или типа того. И вот это:

WebElement elem = new WebDriverWait(driver, 5)
.until(ExpectedConditions.visibilityOfElementLocated(By.className(SELECTOR)));

Почему-то думал, что wait.until() таки void.

Согласен с @KMA7. Selenium это прям серьезный оверхэд (библиотеки, браузер, веб-драйвер, дополнительный код на джаве), более целесообразным кажется плагин для графаны все-таки притащить. Но если для вас работает, то почему бы и нет. Мы все велосипедим иногда. Главное понимать, что это все-таки лучше со временем сделать по-другому.

Сам обычно пользуюсь PerfMon и Server Agent. Но в моем случае это обычно изолированное окружение без Grafana, которое кроме меня никто не трогает, и никакого графического интерфейса на клиентской ноде (как и на северах) нет, просто чтобы более полно утилизировать ресурсы и максимально убрать погрешности измерений, поэтому можно самому ставить агент и собирать метрики сразу со всех серверов. Тем более что постоянно требуется кастомизировать, например, сбор метрик по памяти (виртуальная для системы, виртуальная для процесса, оперативная, своп). Кстати говоря, non-GUI настоятельно рекомендуется при проведении тестов. Картинки рисуются в самом JMeter сразу после загрузки метрик из файла, оттуда же сохраняются, если надо. Не разбирался, честно говоря, как оттуда скриптом картинку вытащить, просто потому, что на этом работа не заканчивается, и просто иметь картинку обычно недостаточно.

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

PerfMon умеет хранить информацию в текстовом виде (CSV вроде), и, если надо, можно строить графики с помощью других средств. При помощи той же графаны с CSV плагином вроде как может сработать.

Information

Rating
Does not participate
Registered
Activity