задний план
Причиной инцидента стали две недавние «провалы» босса, одна в прошлом году и одна недавно. Распространенная причина заключается в том, что скаффолдинг допустил ошибку, когда платформа публикации выпустила пакет, что привело к недоступности белого экрана онлайн-приложения.
Самое удивительное, что после нескольких обзоров кода не было обнаружено никаких ошибок, которые могут вызвать эту проблему.Наконец, есть предположение, что проблема может быть с сервером, когда он был выпущен и упакован.
Когда босс в N+1-й раз пожаловался на летающий котел, который он получил от написанного им инженерного инструмента, я вдруг подумал о том, как избежать такого рода летающих горшков.
В конечном счете, причина таких онлайн-сбоев в том, что упакованный и запущенный код не был проверен. Есть два способа решить эту проблему:
- Чтобы решить основную проблему, из-за разных адресов запросов предварительная (тестовая) версия не может быть напрямую размещена в Интернете, а в онлайн-версии отсутствует процесс проверки перед подключением к сети. Таким образом, бета-версия может быть добавлена между предварительным выпуском и онлайн-выпуском системы выпуска.Бета-выпуск использует процесс упаковки онлайн-выпуска.Разница в том, что разрешен только доступ к интрасети, который специально используется для внутреннего тестирования. Некоторые люди могут спросить, даже если бета-версия будет добавлена, все равно нет гарантии, что онлайн-выпуск и перепаковка не испортятся? Ключевым моментом является то, что ядро этого решения заключается в том, что после прохождения бета-тестирования упакованный продукт, выпущенный бета-версией, напрямую выпускается в Интернете.Поскольку нет необходимости во вторичной упаковке, избегаются новые проблемы в процессе упаковки. Поскольку добавление бета-версий требует различных должностей, таких как совместная работа по эксплуатации и техническому обслуживанию, серверной части и мобильным терминалам, это сложно реализовать.
- Для устранения симптомов, так как онлайн-версия не может быть проверена до ее выхода в сеть, она вернется к проверке сразу после выхода в сеть, а при обнаружении каких-либо проблем будет произведен откат вручную. Как говорится, неисправность, которую никто не находит, не является неисправностью, идеально!
Как упоминалось ранее, трудно реализовать метод лечения первопричины, поэтому мы сосредоточимся на методе лечения симптомов, то есть на проверке регрессии после запуска.
Сказав это, я хотел бы задать вам вопрос: после того, как требования будут запущены, как интерфейс, вы возьмете на себя инициативу выполнить регрессионную проверку вместо того, чтобы ждать проверки теста?
Будете вы или нет, я все равно не буду [доже].
В этом случае лучше всего подходит автоматическое тестирование пользовательского интерфейса.
Что такое автоматизированное тестирование пользовательского интерфейса переднего плана
Как мы все знаем, тестирование — очень важная часть, из-за его важности в разработке программного обеспечения появился даже термин TDD.
В прошлом так называемое внешнее тестирование было больше связано с тестированием страницы на человеческом теле, что, несомненно, было неэффективным.
Таким образом, при автоматизированном тестировании переднего плана вместо людей используются машины. Вообще говоря, автоматизированное тестирование интерфейса делится на два типа: модульное тестирование и e2e-тестирование (автоматизированное тестирование пользовательского интерфейса).
Модульное тестирование — это, по сути, тест белого ящика, который проверяет наименьшую тестируемую единицу в программе.
e2e-тестирование — это, по сути, тест «черного ящика», который эквивалентен моделированию доступа пользователя к приложению, в основном для проверки правильности интерфейса или функции.
По сравнению с модульным тестированием, автоматизированное тестирование пользовательского интерфейса выполняется с точки зрения пользователя и выявляет проблемы с точки зрения пользователя. Однако, поскольку это фактически тест черного ящика, его эффективность ниже, чем у тестирования белого ящика.
Сравнение фреймворка для автоматизации тестирования пользовательского интерфейса
Selenium: Создатель среды тестирования e2e, существуют версии на нескольких языках программирования. Если вы спросите о тестировании вашей компании, вы обнаружите, что они используют версию Selenium для Python для написания сценариев автоматизированного тестирования. Стоит отметить, что он реализован на основе вебдрайвера, а не ядра вебкита, поэтому совместимость с браузерами Selenium намного лучше, чем у других браузеров.
PhantomJS: Новорекварующая безголовая структура тестирования, что такое безголовый? То есть браузер без интерфейса пользовательского интерфейса. Самым большим преимуществом безголова является то, что вы можете запустить тесты E2E на командной строке, как и тесты подразделения.
nightmare: Одним словом - расширенная версия PhantomJS, по сравнению с PhantomJS, значительно улучшена как эффективность разработки, так и эффективность работы.
Советы: у Nightmare есть еще одно преимущество — он предоставляет плагин для Chrome.daydream, плагин может автоматически генерировать тестовый код, записывая экран, что является евангелием для ленивых людей.
nightwatch: e2e-фреймворк с названием, похожим на кошмар, но совершенно другим, использующим Node для вызова веб-драйвера для реализации. По сравнению с Selenium эффективность разработки и эксплуатации выше, а самое главное, что итерация идет очень активно, что понимают пользователи продуктов с открытым исходным кодом.
cypress: Первый тестовый фреймворк e2e, с которым я столкнулся, продукт с совершенным тестовым интерфейсом и документацией, я рекомендую всем попробовать его.
puppeteer: интегратор среды тестирования e2e, которая по умолчанию работает в автономном режиме, но также может быть настроена для работы в Chromium. Эффективность разработки и эксплуатации первоклассные, и, что наиболее важно, он предоставляет подключаемый модуль для генерации тестового кода, как в кошмарном сне ——puppeteer-recorder.
Подводя итог, если рассматривать совместимость браузера, используйтеnightwatch, иначе выбираемcypressилиpuppeteer, если вам нужна автономная или автоматическая генерация кода, используйтеpuppeteer.
Ценность использования автоматизированного тестирования пользовательского интерфейса переднего плана
С точки зрения преимуществ автоматизированного тестирования, автоматизированное тестирование имеет формулу:
自动化的收益 = 迭代次数 * 全手动执行成本 - 首次自动化成本 - 维护次数 * 维护成本
Короче говоря, чем чаще выполняются итерации и чем выше стоимость обслуживания проекта, тем выше ценность добавления автоматических тестов. Внедрение тестирования автоматизации пользовательского интерфейса в инфраструктурных проектах или часто итерационных проектах может значительно сократить время, затрачиваемое на ручное тестирование после каждой итерации. Автоматизированные тесты интерфейса пользователя быстрее и тщательнее, чем ручное тестирование.
С другой стороны, при стремительном развитии фронтенд-технологий системы фронтенд-разработки и мониторинга различных компаний были усовершенствованы, но отсутствует расширение фронтенда в сторону тестирования. Самая большая ценность автоматизированного тестирования пользовательского интерфейса переднего плана заключается в том, что в части переднего плана оно заполняет пустую область между разработкой и мониторингом, образуя полный замкнутый цикл.Трехсторонний подход в значительной степени гарантирует качество проекта.
Взгляд на будущее
Что касается автоматизации front-end UI-тестирования, я думаю об этом давно, лично я считаю, что есть два основных направления:
- Для одного проекта тестируется ряд ключевых функций. Однако, если вам необходимо провести тестирование, это требует много времени. Это относительно рутинное и усовершенствованное тестовое решение, поэтому оно больше подходит для некоторого долгосрочного обслуживания. инфраструктурные проекты или масштабные бизнес-проекты.Недостаток в том, что страница активности в основном не освещается.
- Для всех проектов добавьте автоматические тестовые леса (или платформу), которые могут автоматически получать доступ к целевой странице через элементы конфигурации и проводить серию e2e-тестов, делать снимки экрана, создавать PDF-файлы и выдавать предупреждения в соответствии с различными результатами.Различные решения для обработки.
Вторая программа заключается в том, что план обобщения также является ключевым направлением, которое я недавно разработал.Далее я должен специально написать статью, в которой собираюсь представить дизайн программы и конкретную реализацию (если у меня нет эпизода ленивого рака [ ДОЖ]).
Если у вас есть другие идеи, поделитесь с нами ~
мой гитхаб:GitHub.com/kart медсестра Лори…