Вступительный доклад - Тестируемый JavaScript - Архитектура вашего приложения для тестируемости
Марк Тростлер (Google)
Тестируемый JavaScript — это процесс. Независимо от того, начинаете ли вы с чистого листа или уже реализованного приложения (или где-то посередине), возможность просто, чисто и эффективно протестировать код JavaScript является необходимой функцией. Код, который нельзя протестировать, будет переписан.
Хотя JavaScript уникален из-за множества сред, в которых он работает, существует несколько проверенных и верных «тестируемых» методологий из других языков, которые также применимы к JavaScript. И, конечно же, остаются уникальные проблемы, с которыми приходится сталкиваться разработчикам JavaScript при написании и тестировании своего кода.
Какие шаблоны делают код тестируемым? Какие антипаттерны мешают тестированию? Какие показатели и ориентиры здравого смысла можно использовать для измерения тестируемости нашего кода? Что делать после того, как процесс создания тестируемого кода начался?
Присоединяйтесь ко мне, чтобы разобрать процесс написания тестируемого JavaScript. Мы будем исследовать идеи, шаблоны и методологии, которые значительно улучшат тестируемость и, следовательно, удобство сопровождения, правильность и долговечность вашего кода. Независимо от того, пишете ли вы клиентский или серверный JavaScript, освоение этого процесса значительно повысит качество вашего кода.
Разрушая матрицу — масштабируемое тестирование Android
Томас Кныч (Google), Стефан Рамзауэр (Google) и Валера Захаров (Google)
Вы готовы принять красную таблетку?
Мобильные устройства изменили то, как люди взаимодействуют с компьютерами. Это здорово, но как инженеры мы сталкиваемся с постоянно растущей матрицей сред, в которых работает наш код. Дни рассмотрения только нескольких браузеров и разрешений экрана не возвращаются. Как инженеры могут справиться с Матрицей? Мы расскажем, как Google борется с этой проблемой тестирования на рабочих станциях, в облаке и в вашей голове...
«Я пытаюсь освободить твой разум, Нео. Но я могу только показать тебе дверь. Ты тот, кто должен пройти через нее».
Автоматизация пользовательского интерфейса Android
Гуан Чжу (朱光) (Google) и Адам Момтаз (Google)
По мере того, как Android набирает популярность в мобильном мире, разработчики приложений и OEM-поставщики изучают способы выполнения сквозного тестирования приложений или всей платформы на основе пользовательского интерфейса. С кратким обзором существующих решений для автоматизации пользовательского интерфейса на Android в этом докладе представлена недавно выпущенная платформа Android UI Automator, а также представлен внутренний взгляд на структуру, типичные варианты использования и рабочие процессы.
Appium: автоматизация мобильных приложений
Джонатан Липпс (Sauce Labs)
Appium — это сервер Node.js, который автоматизирует нативные и гибридные мобильные приложения (как для iOS, так и для Android). Философия Appium диктует, что приложения не должны модифицироваться для автоматизации, и что вы должны иметь возможность писать свой тестовый код на любом языке или платформе. Результатом стал сервер Selenium WebDriver, который говорит по-мобильному, как родной. Appium работает на реальных устройствах и эмуляторах и имеет полностью открытый исходный код, что делает его удивительно удобным способом начать работу с мобильной автоматизацией тестирования. В этом докладе я расскажу о принципах, лежащих в основе дизайна Appium, расскажу об Appium в пространстве других сред мобильной автоматизации и представлю архитектуру, которая делает волшебство возможным. Наконец, я покопаюсь в коде простого теста совершенно нового мобильного приложения и продемонстрирую, как Appium запускает этот тест на iPhone и Android.
Создание масштабируемой мобильной тестовой инфраструктуры для Google+ Mobile
Эдуардо Браво (Google)
Тестирование нативных приложений осмысленным, стабильным и масштабируемым способом — непростая задача. G+ разработала эффективные решения для решения этих проблем, предоставив правильную инфраструктуру для каждого из сложных тестовых сценариев, которые представляют мобильные устройства. Наша текущая тестовая инфраструктура предоставляет правильные инструменты для приложений iOS и Android, чтобы дать нашей команде разработчиков уверенность в том, что новые изменения не нарушат работу существующих клиентов.
Эспрессо: новый старт для тестирования пользовательского интерфейса Android
Валера Захаров (Google)
Разработка надежного теста для Android должна быть такой же быстрой и легкой, как приготовление чашки эспрессо. К сожалению, с существующими инструментами это может больше походить на приготовление двойной порции карамельного соуса, перевернутого вверх дном, одного взбивания, наполовину без кофеина, — запутанно и редко последовательно. Espresso — это новая среда тестирования Android, которая позволяет быстро писать лаконичные, красивые и надежные тесты пользовательского интерфейса. Основной API небольшой, предсказуемый и простой в освоении, но он также открыт для настройки. Эспрессо-тесты четко формулируют свои ожидания, взаимодействия и утверждения, не отвлекая внимание от шаблонов, пользовательской инфраструктуры или запутанных деталей реализации, которые мешают. Тесты выполняются оптимально быстро — оставьте ожидания, синхронизацию, спящий режим и опросы позади и позвольте фреймворку изящно манипулировать и утверждать ваш пользовательский интерфейс, когда он находится в состоянии покоя. Начните получать удовольствие от написания и выполнения тестов пользовательского интерфейса — попробуйте чашку эспрессо.
Веб-тестирование производительности с помощью WebDriver
Михаил Клепиков (Google)
В веб-тестировании производительности мы довольно хорошо знаем, как анализировать загрузку страницы. Однако нам нужно выйти за рамки загрузки страницы: современные приложения очень интерактивны, и операции, как правило, не перезагружают всю страницу, а скорее обновляют ее. Различные люди, в том числе и я, интегрировали WebDriver в наборы веб-тестов производительности, что помогает, но все же позволяет отделить тесты производительности от остальной части набора тестов пользовательского интерфейса. Я предлагаю встроить функции тестирования производительности прямо в сам WebDriver, используя недавно добавленный Logging API. Это позволяет собирать метрики производительности во время выполнения регулярных функциональных тестов, обеспечивая более плавную интеграцию тестов производительности в общий процесс разработки и тестирования. Это также гораздо менее разрушительно для пользовательских цепочек инструментов сборки/тестирования, которые создает почти каждая крупная организация.
Я продемонстрирую это с помощью ChromeDriver нового поколения (WebDriver для браузера Chromium).
Непрерывное тестирование данных карт
Иветт Намет (Google) и Брендан Дейн (Google)
Непрерывное тестирование обычно заключается в выполнении модульных и интеграционных тестов. Но когда данные, которые обрабатывает ваш сервер, на самом деле являются самой большой причиной изменений, как вы гарантируете, что потребители данных по-прежнему находят их пригодными для использования и что ничто не дает сбоев из-за скорости изменений или плохих изменений? Мы обсудим методы непрерывного тестирования данных на примерах из Google Maps.
Автоматический поиск виновных в неудачных сборках — т.е. кто сломал сборку?
Джелал Зифтчи (UCSD) и Вивек Рамаваджала (UCSD)
Непрерывная сборка — одна из ключевых инфраструктур Google. Когда сборка завершается сбоем, очень важно быстро определить виноватый список изменений (CL)/списки изменений, чтобы его можно было исправить, чтобы вернуть сборке зеленый цвет.
Решения для обнаружения преступников существуют для небольших и средних сборок, но не для крупных интеграционных сборок.
Наша программа поиска виновных нацелена на автоматический поиск виновного CL для больших сборок в очень короткие сроки с большим успехом. На основе производственного использования в нескольких проектах за последние 9 месяцев средство поиска виновных дает очень многообещающие результаты. Приходите на наш доклад, чтобы узнать, как мы внедрили средство поиска виновных, насколько оно успешно в производстве и как оно выглядит и ощущается.
Эмпирическое исследование качества линейки программных продуктов
Катерина Госева-Попстоянова (Университет Западной Вирджинии)
Линии программных продуктов демонстрируют высокую степень общности среди систем в линейке продуктов и хорошо определенное количество возможных вариаций. Основываясь на данных, извлеченных из двух тематических исследований — линейки промышленных продуктов среднего размера и крупной, развивающейся линейки продуктов с открытым исходным кодом — мы эмпирически исследовали, улучшает ли систематическое повторное использование качество и поддерживает ли успешное предсказание потенциальных будущих сбоев на основе ранее обнаруженных сбоев, исходного кода. метрики и изменить метрики. Результаты нашего исследования подтвердили, что в отношении линейки программных продуктов выводы других авторов о том, что сбои в большей степени коррелируют с метриками изменения, чем с метриками статического кода. Результаты оценки качества показали, что хотя старые пакеты (включая общие черты) постоянно менялись, они сохраняли низкую плотность ошибок. Кроме того, качество линейки продуктов с открытым исходным кодом улучшалось по мере ее развития за счет выпусков. Прогноз, основанный на обобщенных моделях линейной регрессии, точно ранжировал пакеты в соответствии с их ошибками после выпуска, используя модели, построенные на предыдущем выпуске. Результаты также показали, что прогнозирование отказов после выпуска выигрывает от дополнительной информации о линейке продуктов.
AddressSanitizer, ThreadSanitizer и MemorySanitizer — инструменты динамического тестирования для C++
Костя Серебряный (Google)
AddressSanitizer (ASan) — это инструмент, который находит переполнения буфера (в стеке, куче и глобальных переменных) и ошибки use-after-free в программах на C/C++. ThreadSanitizer (TSan) обнаруживает гонки данных в программах C/C++ и Go. MemorySanitizer (MSan) — это незавершенный инструмент, который находит применение неинициализированной памяти (C++). Эти инструменты основаны на инструментарии компилятора (LLVM и GCC), что делает их очень быстрыми (например, ASan замедляется всего в 2 раза). Мы поделимся нашим опытом масштабного тестирования с использованием этих инструментов.
Заключительный доклад — Пить океан — Поиск XSS по шкале Google
Клаудио Крисционе (Google)
Межсайтовый скриптинг, или XSS, является современным эквивалентом средневековой черной чумы в мире веб-приложений: он широко распространен, это плохо, и практически нет технических способов обнаружить его, пока не станет слишком поздно. DOM XSS является особенно неприятным вариантом из них, поскольку для его обнаружения требуется настоящий браузер или его эквивалент: сложная проблема с небольшим доступным автоматизированным решением.
Нам нужны были мощные самоуправляемые инструменты для идентификации DOM XSS на ранних этапах жизненного цикла разработки, которые могли бы использовать инженеры, не входящие в группу безопасности: все, что нам было нужно, — это продукт, который мог бы сканировать наш огромный, быстро меняющийся, очень сложный и загадочный набор приложений. .. и, конечно же, мы не нашли ни одного. Поэтому мы создали собственный: сканер веб-приложений, ориентированный на DOM XSS, разработанный на основе стандартных технологий Google. Он работает в App Engine и использует мощный браузер Chrome и несколько сотен процессоров в качестве платформы для сканирования безопасности.
Он также является хорошим гражданином арсенала тестирования в Google: он живет внутри нашей инфраструктуры тестирования, а не является инструментом команды безопасности.
В этом выступлении мы расскажем о нашем новом подходе, проблемах, с которыми мы столкнулись при масштабировании нашей системы до размера Google, и идеях, лежащих в основе наших моделей обнаружения и сканирования приложений, интенсивно использующих JavaScript.