Apple исправила баг и обвиняет Consumer Reports в неправильной методологии тестирования


    Та самая настройка Safari, из-за которой разгорелся спор

    Две недели назад поклонников «яблочной» продукции удивила новость: новые MacBook впервые не получили рекомендацию от Consumer Reports для покупки.

    Высочайшее качество ноутбуков Apple всем известно. Этой техникой пользуются лучшие хакеры, даже если приходится переустановить операционную систему. Не было ещё ни одного случая, чтобы ноутбуки не получили рекомендацию покупки Consumer Reports. Но это произошло с последней линейкой MacBook Pro из-за противоречивых результатов по времени работы от аккумулятора при открытии сайтов в браузере Safari.

    Сразу закралась мысль, что тут какое-то недоразумение. Так оно и вышло — Apple нашла и исправила очень странный баг. Но теперь она упрекает «слишком умных» экспертов Consumer Reports, которым удалось проявить этот баг. Мол, у них неправильная методология. Кто прав?

    Те результаты действительно оказались крайне странными. Судите сами. 13-дюймовый MacBook Pro с тачбаром проработал 16 часов в первом тесте, 12,75 ч во втором таком же тесте и 3,75 ч в третьем.

    13-дюймовый MacBook Pro без тачбара проработал 19,5 часов в первом тесте и 4,5 часа во втором.

    Для 15-дюймовой модели показатели составили 18,5 и 8 часов.

    Тест состоит из бесконечного количества циклов по открытию 10 страниц в браузере, которые передаются с локального сервера по WiFi. Цикл начинается при полном заряде аккумулятора, а заканчивается при выключении ноутбука. Тест проводился на стандартном браузере (в данном случае это Safari) на ОС с последними патчами. Проверку начали несколько недель назад, потом продолжили после выхода macOS Sierra 10.12.2, но разницы не было.

    Представители Consumer Reports пояснили, что обычно разница между результатами одинаковых тестов не превышает 5%, а здесь разница слишком велика.

    Теперь в комментарии для прессы компания Apple пояснила, в чём дело: «Во время тестирования аккумуляторов в Consumer Reports использовались скрытые настройки для разработчиков вместо нормальных настроек, которые люди используют повседневно».

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

    Загрузка сайтов с отключенным кэшем в браузере — вполне валидная и логичная методология тестирования.

    Но здесь случилось непредвиденное. Как показало совместно проведённое расследование Apple и Consumer Reports, активация этой конкретной настройки для разработчиков одновременно приводила к срабатыванию «неясного и прерывистого» бага, который перезагружал иконки (более подробное описание бага см. в комментарии пользователя foundout). Именно эта причина объясняет столь необычные результаты тестирования на время работы от аккумулятора.

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

    В конце концов, сейчас компания Apple всё-таки исправила этот злосчастный баг, так что редакция Consumer Reports может ещё раз провести тестирование и присвоить ноутбукам MacBook заслуженный высокий рейтинг и рекомендацию о покупке.

    Но Apple и Consumer Reports по-разному смотрят на проблему с тестами. Apple считает, что проблема в их методологии, а Consumer Reports говорит, что ноутбуки завалили тест из-за бага.



    В защиту своей методологии Consumer Reports пишет, что они тестируют все ноутбуки единообразным способом. А поскольку невозможно эмулировать поведение пользователей — все используют ноутбук по-разному, то их тесты на время работы от аккумулятора не предназначены для того, чтобы быть прямой эмуляцией поведения пользователя. Вместо этого они спроектированы так, чтобы учитывать максимальное количество переменных и выдать результат, максимально приближенный к реальности при средней загрузке процессоров, памяти, приёмопередатчиков ноутбука и работе дисплея. «Этот тест служил хорошим показателем времени работы от аккумулятора на сотнях ноутбуков в наших рейтингах», — пишет Consumer Reports. Но только не для MacBook.

    Исправление для браузера Safari опубликовано на сайте Apple Beta Software Program и доступно для участников этой программы. После бета-тестирования через несколько недель апдейт отправят на компьютеры всех пользователей через программу автоматического обновления. Возможно, исправление странного бага поможет тем пользователям, которые жалуются на форумах на слишком малое время работы ноутбука от аккумуляторов, что проявляется лишь эпизодически.

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

    Но стоит ещё раз обратить внимание, насколько профессионально работает PR-машина Apple. Специалисты преподносят ситуацию так, что дело вовсе не в баге Safari. По их мнению, у Consumer Reports проблема в методологии, а Apple помогла им выявить эту проблему, чтобы раскрыть глаза непутёвым и неразумным тестерам.
    Почему ноутбуки MacBook Pro показали слабые результаты в тестах Consumer Reports?

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

    Поделиться публикацией
    Никаких подозрительных скриптов, только релевантные баннеры. Не релевантные? Пиши на: adv@tmtm.ru с темой «Полундра»

    Зачем оно вам?
    Реклама
    Комментарии 106
    • +28
      Охренеть: «Да, у нас баг, то вы не должны были его найти! А раз нашли, то вы редиски, а мы — яблоки».
      • +2
        Просто баг не связан с временем работы, того что требовал тест. По правилам, им следовало эмулировать загрузки с разных адресов и разным контентом, чтобы не участвовал кэш, однако они _зачем_ то залезли в настройки разработчика, чтобы отключить кэш браузера. Честное слово, эппл на свое усмотрение мог бы сделать так, что при включенном режиме разработчика задействовались бы какие-то тяжелые сервисы, из за которых тест был бы провальным. В этом случае тоже бы сказали что виноваты эппл? Баг конечно баг, но проблема в методе тестирования.
        • +5
          По правилам, им следовало эмулировать загрузки с разных адресов и разным контентом, чтобы не участвовал кэш
          Это что за правила такие? У них их собственный тест с их собственными правилами, по которым они его проводят одинаково на всех ноутбуках.
          И да: можно поменять методику, но тогда придётся ещё и выкинуть в помойку данные по всем тестам, проведённым по существующей методике на ≈140 других ноутбуках.
          • +1
            Можно грузить одну и ту же страницу, но под случайным именем.
            • 0
              Только если на случайном домене, иначе придётся рандомизировать ещё и имена всех подключаемых на ней файлов.
              • 0

                Можно и рандомизировать имена всех файлов, это не трудно. А можно использовать относительные пути и рандомизировать только базовый путь.

          • НЛО прилетело и опубликовало эту надпись здесь
            • –8
              Тест использует режим разработчика, который вполне может нагружать компьютер, результаты теста справедливо могут отличаться от реальных кейсов использования. Демонстрация правильного прогноза разве не назначение задачи теста? Если тест выдает неправильный результат, может ли это быть виной продукта? Продукт это черный ящик.
              • +6
                Если тест выдает неправильный результат, может ли это быть виной продукта? Продукт это черный ящик.
                В этой цитате не достаёт логики.
                Продукт — чёрный ящик, всё правильно, поэтому тест должен быть таким, что бы не учитывать особенности этого чёрного ящика. До этого же всё работало много лет, и на макбуках тоже. И тут раз и всё сломалось на последних версиях ПО. Так почему вдруг это стало «ошибкой теста»?
                • +1
                  А с чего опция отключения кэша делает в режиме разработчика? И почему помимо отключения кэша происходят какие-то другие чудеса?
              • +1
                эппл на свое усмотрение мог бы сделать так, что при включенном режиме разработчика задействовались бы какие-то тяжелые сервисы
                Если бы Apple сделала так, что при отключении кэша, включались какие то тяжелые сервисы, это было бы странно, на грани нового бага. В таком случае на мой взгляд оказался бы виноват эпл, из за недокументированного поведения.
                Но вопрос в том, что другие пользователи, которые жаловались на эту проблему, они что то же отключали кэш, а зачем им это? Может те пользователи были разработчиками которым нужно было отключать кэш для работы, а тогда это баг эппла.
              • 0
                Нет, просто в одно и то же понятие «методология тестирования» впихнуто две темы.
                По факту, Эппл не правы в том, что тестирование без кеша — неправильное, но при этом правы, в том, что опции для разработчиков могут быть непредсказуемы, поэтому, их действия по переключению чего бы то ни было в этом режиме на Маке — некорректны. А то что, по другому не октлючить, ту уж — извините.
                Так что методология тестирования с учётом Мак машин — неправильная, подход с отключеним кеша верен, но не реализуем в данном случае, ну и, конечно, баг в сафари был, но не это не означает, что режим для разработчиков работает так же как для пользователей.
                • +3
                  По моему вы путаете опции разработчика и что то из разряда инженерного меню. Опции для разработчиков должны вести себя предсказуемо, иначе как разработчикам разрабатывать?
                  • 0
                    Разработчик по-твоему не пользователь?
                    • 0
                      Когда вы компилируете программу с отладочной информацией и без, с уровнем оптимизации позволяющим компилятору очень вольно интерпретировать программу, сильно ли отличается её код и производительность? Судя по тормозам в сетевых видеограх, сразу после глобального патча (его обычно с отладкой выставляют, потом минипач убирающий это дело) — да, сильно. Это было лирическое отступление, теперь по сути:
                      Кроме того, разработчикам важен процесс, поэтому допускаю, что в этом режиме (пункты меню появляются только после включения режима) могут включаться множество логирующих и проверяющих элементов сильно влиящих на производительность, что естественно не факт, потому как не я делал сафари и не знаю, но аналогию я привёл выше.
                      • 0
                        Когда вы компилируете программу с отладочной информацией и без, с уровнем оптимизации позволяющим компилятору очень вольно интерпретировать программу, сильно ли отличается её код и производительность?
                        Порой разница очень огромна. Один раз тестировал такое поведение на алгоритме перемножения больших матриц. Отладочная версия отрабатывала минут (!) за 30, а релизная (-О2) — минуты за 3-4.
                        Судя по тормозам в сетевых видеограх, сразу после глобального патча (его обычно с отладкой выставляют, потом минипач убирающий это дело) — да, сильно.
                        Ни кто так делать не будет, поверьте, в этом смысла просто нет. А лаги после выхода патча связаны с лимитами инфраструктуры игровых серверов, с которых и обновления качают и играть пытаются. Ни кто же не будет держать отдельные дата-центры только для обновлений.
                        допускаю, что в этом режиме (пункты меню появляются только после включения режима) могут включаться множество логирующих и проверяющих элементов сильно влиящих на производительность
                        Конкретно при отключении кеша, или другими настройками? Догадываетесь, или знаете? А то больше походит на «не смотрел, но осуждаю» :)
                • +1
                  «Нет смысла нанимать первоклассных специалистов и указывать им, что делать. Мы нанимаем первоклассных специалистов, чтобы они указывали, что делать нам» — вроде это слова Стива Джобса.
                  Его не стало — вот и результат.
                  • +9
                    Значит рекомендации к предыдущим макбукам надо отозвать и исключить из рейтинга Customer Reports, раз уж они тоже делались по «неправильной методике» ;)
                    • +8
                      You're holdingtesting it wrong
                      • –1
                        > Этой техникой пользуются лучшие хакеры

                        Чего? Хакеры используют BackTrack какой-нибудь, а не наглухо проприетарным софтом, который ваши отпечатки пальцев с облаком синхронизирует.
                        • +2
                          > даже если приходится переустановить операционную систему
                          Противоречий никаких нет.
                          • +4
                            У Линуса, например, макбук.
                            • –7
                              Так Лайнус ни разу не хакер.
                              • +4
                                А пингвин не птица.
                                • +1
                                  Зависит от трактовки. Если в изначальном смысле, то самый что ни на есть.
                            • +5
                              Отпечатки не синхронизируются, они даже не читаются вне Secure Enclave процессора.
                              Для логина сенсор передаёт данные в Secure Enclave, и получает подписанный идентификатором процессора ответ о (не)совпадении.
                              • 0
                                Не синхронизирует, учите матчасть, ваши отпечатки устройство не покидают.
                              • 0
                                И вообще, это не баг, а фича!
                                • +2
                                  PR-машина работает очень «профессионально» отвечая в стиле «сам дурак»?
                                  Как по мне, так это весьма часто встречается и совсем не профессионально, в противном случае Consumer Reports уже изменили бы технологию тестирования.
                                  • +3
                                    «Вы просто неправильно его держите» (с) Джобс.
                                    • 0
                                      Добавьте еще один пункт в опрос:
                                      «Apple стала использовать посредственное железо»
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                      • 0
                                        Баг, конечно, в сафари, даже непонятно что тут спорить. Но с другой стороны, если я правильно помню, то ребята из Consumer Reports утверждали, что их методика прекрасная и ничего они перетестировать не будут. А тут оказывается, что до этого они наклацали на свое усмотрение разные настройки.
                                        • +2
                                          Они «наклацали» настройки согласно своей методике тестирования так же, как и при тестировании любых других ноутбуков.
                                          • 0

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

                                            • +1
                                              Написано же, набор из нескольких страниц, перезагрузка с отключенным cache.
                                              Было бы странно каждый раз сажать реальных пользователей и грузить реальные сайты сотнями, при этом, те должны бы между тестами оставаться статичными.
                                              Иными словами, иная реализация крайне затруднительна, а использованная, применяемая униформно при тесте ноутбуков разных производителей, вполне объективно отражает возможности техники в условиях, максимально прилиженных к реальным.
                                              Заметьте: раньше Эппл не жаловалась на условия тестирования их ноутбуков.
                                              • 0

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

                                                • 0
                                                  Иными словами, иная реализация крайне затруднительна

                                                  Я не понял, а если сделать просто на странице автоперезагрузку по таймауту (как делают в самых простых веб-чатах, это ни разу не затруднительно и не требует никакого отключения кэшей) — это будет чем-то хуже? Страницу каждый раз совершенно новую генерировать, включая все стили и мелкую графику, как-нибудь даже детерминированно это можно сделать, чтобы все девайсы в совершенно одинаковых условиях.
                                                  • 0
                                                    Обновляться будет только не закешированная область. Внешний вид, картинки и тд, остануться на месте в кеше.
                                                    • 0

                                                      Очевидно, картинки и прочее надо точно так же по новым URL размещать.

                                                      • +1
                                                        Я говорю, всё динамически генерировать, в том числе картинки и т. д. То, что на предыдущем обращении называлось mymotherfuckingpicture0000024123412.png, при следующем обращении будет называться mymotherfuckingpicture0000024123413.png, и прописано в динамически сгенерированном теле страницы будет под этим, новым, уникальным урлом, и отдаваться будет уже по этому, новому, уникальному урлу.
                                                        • –1
                                                          Вы представляете сколько это будет стоить?
                                                          • 0

                                                            А в чем проблема?

                                                            • 0
                                                              Ну сделайте такой тест им бесплатно и предложите. Желательно так, чтобы тест выдавал на остальных сотнях ноутов, протестированных ранее, такие же результаты, как оригинальный.
                                                              Не хотите? А в чём проблема?
                                                              • 0
                                                                Давайте даже скинемся и доплатим им, чтоб взяли. Вы лично сколько денег готовы пожертвовать?
                                                            • +1
                                                              Гораздо меньше, чем вы думаете. Требуется студент-ПХПшник с соответствующей оплатой, неделя времени, готовая реализация вихря Мерсенна или другого генератора псевдослучайных чисел и стак оверфлоу что-бы тырить готовые куски кода.
                                                              • –1
                                                                И что он напишет? Сферическую страницу в вакууме, нагрузка на которой никак не будет коррелировать с уже проведёнными тестами?
                                                                • 0

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

                                                                  • 0
                                                                    Точнее серверную часть, которая будет процедурно генерировать и выдавать предсказуемую страницу с контентом и картинками в зависимости от УРЛа.
                                                                    • 0

                                                                      Это уже необязательная фича.

                                                                      • 0
                                                                        Разве? Мне казалось что это и есть основное требование — что-бы у было много разных и повторяемых страниц с уникальным контентом возибежание кеширования. Короче — процедурная генерация полноценных страниц по сиду.
                                                                        • 0

                                                                          Достаточно генерации имён, чтобы браузер загружал файлы заново. Более того, можно вместо изменения имени просто приписывать параметр, типа index.html?1, этого достаточно, чтобы файл загрузился заново.

                                                                          • 0
                                                                            document.getElementById(«image_id»).src='images/image.png?'+Math.random()+'';
                                                                          • 0
                                                                            Слишком просто и неинтересно. А потом сафари втихаря «оптимизируют» для прохождения таких тестов, у них там и так эвристики понапихано для всех действий подряд — допишут еще. Любовь корпораций к махинациям в подсчетах попугаев общеизвестна.
                                                                            • 0
                                                                              Мне вот интересно, а как вы будете менять хэш тела? Так что что бы не городить огород, проще вырубить кеширование в браузере и не мучиться. Это тоже самое, что пытаясь сделать код для зажигания светодиода в пару строк. сделать его же, но в пару тысяч.
                                                                              • 0

                                                                                А зачем менять хеш тела? И что вы вообще имеете в виду под "хешем тела"?

                                                                                • +2
                                                                                  Честно, не выспался и ляпнул не в том смысле. Но подведу все свои написания под знаменатель или равно, смотря как посмотреть.
                                                                                  Проще, удобнее, понятнее обновлять одну и ту же страницу. Ну, а то, что есть галочка для разработчиков, которая отключает кеширование, не значит что кривые руки у создателей теста. Галочка есть? Есть. Каждый может её щёлкнуть? Каждый. Тогда в чём проблема обсуждаемая в данной дискуссии, не ясно, баг браузера. Сам же тест прост, прозрачен, не позволяет никому сказать что мухлевали. А кто проконтролирует кучу одинаковых страниц? Будут сравнивать их хеш? Но ведь странички разные должны быть что бы не кешировались, при том одинаковые. Проблема реализации, как никогда остро. Вроде всё просто, но на мой взгляд нуба, я бы не поверил тесту отличимому от постоянной перезагрузки одной и той же страницы, того же размера.
                                                                                  • 0

                                                                                    А как вы будете контролировать что тест вообще проводился, а результаты не были взяты из справочника Потолоцкого? Да никак, либо поверите на слово или не поверите.


                                                                                    Вот и с однаковыми страницами так же. Можно при желании код сервера открыть, но даже это не обязательно.

                                                  • 0
                                                    Да но они не сравнивают ноутбуки между собой. Они советуют ноутбук к покупке.

                                                    И если 99% пользователей не включает такие настройки по которым тестировался ноутбук, то какая польза от подобного тестирования? Ответ — никакой? Или я где-то не прав?

                                                    p.s. Разве Apple не права тут? Ведь Consumer Reports утверждает что ноутбуки будут работать мало времени от батареи, а на деле у 99% людей они будут работать штатно.
                                                    • 0
                                                      Consumer Reports утверждает что ноутбуки будут работать мало времени от батареи
                                                      А это вы откуда взяли? Consumer Reports не рекомендуют не в смысле «рекомендуем не покупать», а в смысле «не можем поручиться, что это хорошая покупка». Т.е. всё равно как если бы не тестировали.
                                                      • +1
                                                        Вы вообще поняли, о чем речь? Настройка включена именно для того, чтобы имитировать работу нормального пользователя.
                                                        То, что баг в сафари проявился именно с этой настройкой, отнюдь не говорит, что он не проявится, если ее отключить. Просто галочка — это путь к стабильному воспроизведению блуждающего бага.
                                                        Отзывы пользователей о случайном проявлении того же бага при (я уверен) отключенной настройке это подтверждают.
                                                        • +1
                                                          Consumer Reports утверждает что ноутбуки будут работать мало времени от батареи,

                                                          Не так. Они утверждали, что ноутбуки про проведении нескольких повторных, одинаковых тестов показывали существенно различные результаты, что неправильно.

                                                          99% пользователей не включает такие настройки по

                                                          То кричат, мол маки — для разаработчиков и вебдизайнеров, то выясняется, что их 1% от ЦА…

                                                          И ниже отписалась еще одна потенциальная жертва бага, пострадавшая неколько иным образом:
                                                          Теперь понятно, почему меня банили в админке Vultr через несколько минут после логина, когда заходил туда из Сафари с отключенным кэшированием. Включаешь кэширование — все ок. Комментарии от саппорта — с вашего адреса идет слишком много запросов, срабатывает наша anti-DDoS система.
                                                    • –1
                                                      какое-то тестирование сферического коня в вакууме
                                                      вот поэтому нельзя верить любым тестам которые невозможно воспроизвести
                                                      на заметку consumer reports — можно просто загружать каждый раз новый урл (хоть и с одинаковым контентом) вместо ломания браузера
                                                      • +8
                                                        Как тестировщик, считаю нужным отметить, что неправы именно журналисты, но ошибка в методике не тестирования, а оценки результатов.

                                                        Поясню. Ключевой момент: «активация этой конкретной настройки для разработчиков одновременно приводила к срабатыванию «неясного и прерывистого» бага»

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

                                                        Но баг проявляется только при включении непопулярной настройки, т.е. автоматом перестает быть критичным вместе со всеми последствиями (вроде высадки батареи). High severity, low priority.

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

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

                                                        • +1
                                                          Насколько я понял из прочтения статей — Эпл просто объясняет, что неверные результаты теста были из-за бага. А то что у Consumer Reports неправильная методолгия — утверждает какой-то сраный журналист по имени Jim Dalrymple, видимо потому что он — безголовый фанат техники эпл (и скорее всего в технике вообще ничего не понимает). Жаль что не принято журналистов привлекать к судебной ответственности за клевету.
                                                          • 0
                                                            Я не тестировщик и опыта в тестировании у меня нет, но субъективно, некая доля вины Apple в наличии бага всё же есть, пусть даже незначительная. Настройка, отключающая кэш есть? Есть. Методика требует? Требует, т.к. без кэша результат будет более «составным» и объективным, ведь это именно тестирование на выносливость, а какая выносливость может быть проверена, когда данные можно не добывать извне, а брать из-под носа? Настройку может включить любой и она должна правильно работать? Конечно! Но результат при этом ухудшается, и не важно, насколько популярна эта настройка, если она делает этот тест возможным в принципе. ИМХО. И журналистов не оправдываю.
                                                            • 0
                                                              Настройка, отключающая кэш есть? Есть. Методика требует? Требует, т.к. без кэша результат будет более «составным» и объективным, ведь это именно тестирование на выносливость, а какая выносливость может быть проверена, когда данные можно не добывать извне, а брать из-под носа?


                                                              Это звучит, будто ноутбук делается не для потребителя/продаж, а затачивается для прохождения конкретного теста.

                                                              Раз есть баг — косяк Эплов. Нашли его благодаря Consumer Reports — круто. Думаю еще и спасибо сказали.

                                                              Тема слишком раздута…
                                                              • 0
                                                                звучит, будто ноутбук делается не для потребителя/продаж, а затачивается для прохождения конкретного теста
                                                                Вот сейчас вы открыли для себя всё суть прохождения автопроизводителями краштестов по методике EuroNCAP :)
                                                            • 0
                                                              Но баг проявляется только при включении непопулярной настройки, т.е. автоматом перестает быть критичным вместе со всеми последствиями (вроде высадки батареи). High severity, low priority.

                                                              Смотря какую категорию пользователей рассматривать. У веб-разработчика или тестировщика в веб-проекте эта опция бывает очень актуальной и может быть постоянно включена.
                                                              • +2
                                                                Не соглашусь: надстройка режима разработки открывает ряд функций, необходимых не только для разработчика, но и для сколь бы то ни было опытного пользователя — скажем, супруга время от времени вынуждена что-то из них использовать.
                                                                Например, без режима разработки нельзя:
                                                                • Очистить кэш
                                                                • Посмотреть код элемента
                                                                • Посмотреть активный код страницы (после выполнения скриптов)
                                                                • Отключить скрипты
                                                                • Отключить изображения
                                                                • Посмотреть ресурсы страницы
                                                                • Выполнять действительно «девелоперские» функции — менять user-agent, дебажить JS и т.п.


                                                                Кроме того, с багом сталкивался лично, и он действительно прискорбный.
                                                                Баг не требует галочки на «Очистить кэши» — он работает при включенном Safari и активированном меню разработки. У меня показывается активная оперативка — и в течение последних двух-трёх недель Safari за 5-6 часов работы умудрялся съесть от 5 до 12 гигабайт, после чего компьютер подвисал, включался вентилятор, а закончить беспорядок можно было только через killall в терминале. Даже после этого Мак продолжает сбрасывать кэш иконок и отрисовывает их «на глазах» при открытии любого меню — но я даже подумать не мог, что это может быть связано с опцией в браузере.

                                                                Скрин меню «разработки»:
                                                                image
                                                                • –2
                                                                  А я не соглашусь с вами. Вы забываете, что «сколько-нибудь опытные пользователи» — это 5% аудитории браузера, остальное — бабушки, домохозяйки, гуманитарии. И они за 5 лет никогда не воспользуются этой настройкой и, скорее всего, даже не увидят ее.
                                                                  А «общая» оценка ноута должна исходить именно из этих 95%, а не гиков вроде нас с вами.
                                                                  Баг, не могу спорить, прискорбный. Для вас, для меня. Но — повторюсь — НЕ критичный в общей картине вещей.
                                                                  • 0
                                                                    Вы точно про MacBook говорите? Основная аудитория пользователей, как по мне, это программисты, блогеры и множество прочих специалистов, которым нужен надежный инструмент для работы. И обычно эти люди продвинутые пользователи.
                                                                    • 0
                                                                      Ок, соглашаюсь, не подумал.
                                                                      По основному вопросу это означает, что мое мнение теперь зависит от того, на какой же настройке «висел» баг. Если на отключении кэшей, как написано в статье и в источнике, то по-прежнему не критичен. Если на верхнем уровне, «девелоперских настройках», как утверждает foundout — то соглашусь, что баг переходит в критичные.
                                                                • 0
                                                                  Как тестировщик вы гарантируете что это баг возникает только при активации этой конкретной настройки? Судя по всему — нет. А значит обычные пользователи тоже встречаются с этим багом, тыкая в другие пункты меню.
                                                                  • 0
                                                                    Простите, у вас логика поломалась. Ваш аргумент вида «не доказано, что A неверно»=>«A верно».
                                                                    Я исхожу из доступной информации, а не домыслов о возможном.
                                                                    А еще тестировщики никому ничего не гарантируют, эта профессия о другом.
                                                                • 0
                                                                  > Высочайшее качество ноутбуков Apple всем известно
                                                                  телефонов — еще куда ни шло. то есть даже соглашусь пожалуй, что тут почти нет им равных.
                                                                  что же касается планшетов и тем более ноутбуков, то лично я тут в корне не согласен. это с т.з. как рядового потребителя, так и человека много лет занимающегося ремонтом мобильной техники.
                                                                  • +4
                                                                    В целом, зашел из-за этой же ультражелтушной строки.
                                                                    В последнее время приходится сталкиваться в работе с теми или иными продуктами Эпла. И почти каждый раз я задаюсь одним и тем же вопросом «Почему? Почему они смогла заработать столько денег на этом?».
                                                                    • +2
                                                                      Почему? Почему они смогла заработать столько денег на этом?

                                                                      В ответ вспоминается фрагмент мультфильма, где старик продавал на рынке корову. Без пиара нынче никак.
                                                                      Конечно яблочная техника неплоха, но не идеальна. А то, что могло бы быть лучше, не обладало простым интерфейсом «для домохозяек», на чем и не смогло завоевать такую аудиторию.
                                                                    • 0
                                                                      Что именно не так? Лично у меня противоположные наблюдения. Те же макбуки показали себя как крайне надежные и продуманные решения. Планшеты тоже многое пережили. С айфонами были нюансы и по качеству сборки и по работе и по надежности.
                                                                      • +1
                                                                        Я свой телефон топил в унитазе, булькал в слив. Падал с металической лестницы пересчитав все ступени. Грызли коты. Падал со второго этажа на металлическую плитку. При этом телефон работает до сих пор и при этом ни разу не эппл и не водонепроницаемый, а тем более не ударазащищенный. Из повреждений, разболтавшиеся салазки, скол на стекле, обшарпанность лакированного покрытия, отломал блокировку аккумулятора.
                                                                        • +1
                                                                          А я на свой айпад мини 2 случайно сел опой, он погнулся. После этого я его разогнул и продолжаю пользоваться.
                                                                      • –1
                                                                        Позвольте с Вами не согласиться, 90% нашей страны вообще не знает что такое Apple, зная только iPhone, а 99% населения в руках даже его не держало. То есть как минимум большинству неизвестно качество продукции какой-то там «апле».
                                                                        • 0
                                                                          человека много лет занимающегося ремонтом мобильной техники

                                                                          У вас классический пример ошибки выжившего )
                                                                        • 0

                                                                          Самое ценное в Apple для меня было то, что это одна компания, которая ответственна за железо и операционную систему, когда у меня проблема — я просто иду к ним и они исправляют эту проблему.
                                                                          А вот когда у меня был телефон Nokia, купленный у ATT с операционной системой от Microsoft, и у этого телефона была проблема с батареей — меня просто каждая компания отфутболивала к следующей по кругу.

                                                                          • +3
                                                                            Когда у нас на всех маках с выходом Yosemite начал отваливаться wi-fi, Apple не просто отфутболивала по кругу, она просто забила огромный болт. На форуме у них был тред на несколько сотен страниц, куда представители компании просто не заходили. Фикс занял больше полугода. А господин Тим Кук собрал пресс-конференцию срочную и мы ждали, что будет обьявлено об отзыве Yosemite или о фиксе. Но он вышел и сказал, что у него важное известие, он гей!

                                                                            Когда с выходом El Capitan батарея начала разряжаться за часы, а в отдельных случаях за 1.5 часа (1 минута — 1% в простое), Apple аналогично забила болт с предложением сбросить что-то-там при загрузке или обратиться в сервис (хотя проблема не аппаратная!). Фикс выкатили где-то через 4 месяца.

                                                                            Поэтому я-бы не стал идеализировать Apple. Железо классное, а с софтом нужно, как и везде, быть ооочень аккуратным. У Apple добавился какой-то полный пофигизм на софтварные проблемы macOS после апдейта.

                                                                            P.S. У меня на руках 3 макбука про 2012, 2014 и 2016 годов. Плюс десяток у коллег. Все проблемы воспроизводились синхронно при обновлениях на всех доступных железках.
                                                                            • 0

                                                                              Да, я про эту проблему с WiFi слышал. У меня этой проблемы не было. Слышал, что она возникает с определенными WiFi роутерами (поэтому, наверное, и видели на всех железках в округе).
                                                                              У меня были другие проблемы с ноутбуком. Одна из них очень редкие зависания видеокарты. Сходил в Apple Store — за 3 дня поменяли материнскую плату, проблема ушла.

                                                                          • 0

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

                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                              • –2
                                                                                Вместо того чтобы рефрешить одну и туже страницу, можно было бы подгружать контент с разных страниц, что бы избежать этой проблемы и сохранить актуальность базы тестов.
                                                                                • 0
                                                                                  Гугл хрень сейчас на половине сайтов если брать случайные.
                                                                                  Статичных сайтов без рекламы не сыскать.
                                                                                  Писать ∞ своих сайтов, которые ни разу не пересекутся в течении 20 часов работы при загрузке одной страницы каждую секунду.

                                                                                  Вот как выглядит моя мысля.
                                                                                  • 0
                                                                                    Можно ещё настроить, чтобы по всем адресам вида *.mydomain.com открывался один и тот же сайт, и открывать каждый раз страницу с адресом {new GUID}.mydomain.com
                                                                                    Правда, всё равно страницу придётся писать специальную, чтобы никакие вызовы внешних API не ломались.
                                                                              • 0
                                                                                То есть методология тестирования, выявившая реальный баг, неверная? Вы точно ничего не попутали?
                                                                                • 0

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


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

                                                                                  • +1
                                                                                    Продукты с багами — не качественные. Методика служит для определения качественных продуктов. Методика показала что продукт некачественный, потому что в продукте содержался баг. Не вижу в данном силлогизме никаких ошибок и противоречий, методика отработала верно. В общем-то, компания Apple со мной согласна, и принзнала что это их баг виноват, смотрите их ответ по ссылке в статье.
                                                                                    • 0

                                                                                      Баги есть всюду, и тот факт что в других продуктах баги не обнаружены, ничего не говорит об их качестве. Поэтому использовать "признак наличие бага" при сравнении — неправильно.

                                                                                      • 0
                                                                                        Разумеется речь не об абстрактных необнаруженных багах, они могут быть везде. Если угодно, я перефразирую: «Продукты с уже найденными, но ещё не исправленными багами — не качественные».
                                                                                        • 0

                                                                                          В таком случае качественных ноутбуков, в вашем понимании, не существует в принципе.

                                                                                          • 0
                                                                                            А как же свежевышедшие? В которых ещё не успели найти баги.
                                                                              • 0
                                                                                Я все больше и больше убеждаюсь в том, что похоже уже никто не знает как все устроено «глубоко внутри», сами разработчики в том числе… Всякие фрейморки, библиотеки, оболочки, и вообще новый код, появляются с такой скоростью, что люди уже просто не способны отследить все, что происходит и как это все взаимодействует.
                                                                                • +3
                                                                                  > активация этой конкретной настройки для разработчиков одновременно приводила к срабатыванию «неясного и прерывистого» бага, который перезагружал иконки

                                                                                  Теперь понятно, почему меня банили в админке Vultr через несколько минут после логина, когда заходил туда из Сафари с отключенным кэшированием. Включаешь кэширование — все ок. Комментарии от саппорта — с вашего адреса идет слишком много запросов, срабатывает наша anti-DDoS система.
                                                                                  И еще стал понятен постоянный входящий трафик с районе 100-200К (в частности с хабра/GT). Вот сейчас включил кэширование — трафик пропал.
                                                                                  • 0
                                                                                    Гениально.
                                                                                    Ровно та же проблема, а я грешил на провайдера. При трассировке URL все узлы выдавали 2к+ пинг, скорость доходила до 10КБ/сек, при том макбук загружал всю сетку, и на всех домашних устройствах были проблемы с доступом к сети.
                                                                                    Сколько нервов вымотал себе и интернет-провайдеру, но и подумать не мог, что это в Safari сделали новую фичу. В последние 2-3 дня интернет «стабилизировался» — судя по всему, именно в этом интервале у меня и встал фикс.
                                                                                    • 0
                                                                                      При невозможности записать объект в кэш начинаешь какие-то из ресурсов страницы грузить в бесконечном цикле?
                                                                                    • 0
                                                                                      из-за бага в неправильной методологии тестирования сафари
                                                                                      • +2

                                                                                        один вопрос. А когда это отключение кэша стало опцией разработчика?

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