Вступительное слово
Тони Воэллм (Google)
Ссылки: Видео
Вступительный доклад - Эволюция от обеспечения качества к тестированию
Ари Шамаш (Google)
Вы создали приложение. Вы его запустили. Вы полагали, что получите это там, нарастите объем, получите финансирование, выбросите все это, а затем начнете с нуля, чтобы вы могли «сделать это правильно». Но требования к новым функциям невероятно высоки, теперь вас просят продвигаться к беспрецедентному масштабу с неслыханной скоростью. Ой! Что теперь?
Вы не можете выбросить его и начать с нуля, вам просто нужно развивать то, что у вас есть, продолжая добавлять высококачественные функции с захватывающей дух скоростью. Кроме того, вам нужно убедиться, что то, что уже есть, не сломается. Как ты делаешь это? К счастью, в индустрии разработки программного обеспечения формируется новая область, которая занимается этим распространенным сценарием: в Google мы называем это «инженерией тестирования».
В этом докладе основное внимание будет уделено тому, что такое разработка тестов, как она развилась из системы обеспечения качества и как индустрия в целом внедрила разработку тестов (с конкретными примерами того, как это реализовано в Google).
Тестирование систем в масштабе @Twitter
Джеймс Уолдроп (Твиттер)
Джеймс расскажет об инструментах, процессах и философии тестирования производительности в Twitter. Особое внимание будет уделено библиотеке нагрузочного тестирования с открытым исходным кодом Iago, которую он написал, чтобы инженеры Twitter могли выполнять нагрузочные тесты перед развертыванием кода в рабочей среде. В докладе будут подробно рассмотрены детали реализации некоторых из этих тестов (включая исходный код) и способы управления усложняющими факторами, такими как OAuth и произвольные протоколы Thrift.
Как вы тестируете мобильную ОС?
Дэвид Бернс (Mozilla) и Малини Дас (Mozilla)
Это проблема, с которой столкнулась Mozilla, когда мы решили окунуться в мир FirefoxOS. С чего начать и как это сделать предстояло доказать интересную задачу. Приходите послушать, как мы решили эту проблему и как создали новый фреймворк.
Мобильная автоматизация в конвейере непрерывной доставки
Игорь Доровских (Expedia) и Каустубх Гаванде (Expedia)
Expedia начала инвестировать в мобильные веб-приложения и приложения для iOS/Android в начале 2012 года. В то же время инженеры по тестированию начали разрабатывать решения для автоматизации тестирования, чтобы с самого начала обеспечить качество и тестируемость продуктов. В этом выступлении мы поделимся нашим опытом и знаниями об использовании инструментов с открытым исходным кодом для создания автоматизированного тестирования в гибкой среде Expedia для разработки и непрерывной доставки. Мы поговорим о Test Pyramid и более подробно расскажем о конкретных инструментах с открытым исходным кодом, которые хорошо сработали для нас. Некоторые из инструментов с открытым исходным кодом, которые мы используем, — это инструменты BDD, такие как Cucumber, инструмент веб-автоматизации Selenium-WebDriver, инструмент автоматизации iOS Frank, инструменты автоматизации Android Robotium и Calabash, а также система непрерывной интеграции Jenkins. Кроме того, мы поделимся некоторыми принципами доставки Agile, которые мы стремимся внедрить, такими как TDD, парное программирование, сборка и тестирование радиаторов. Наконец, мы расскажем о некоторых преимуществах, которые мы получили от наших инвестиций в Agile и автоматизацию тестирования, и о том, как это приводит нас к нашим целям непрерывной доставки.
Автоматизированное тестирование телевизионных приставок с помощью GStreamer и OpenCV
Дэвид Ротлисбергер (YouView)
Мы создадим систему распознавания изображений для захвата видео за 3 минуты, используя инструменты командной строки GStreamer и OpenCV. (GStreamer — это платформа для обработки мультимедиа с открытым исходным кодом; OpenCV — «Open Computer Vision» — библиотека для обработки изображений с открытым исходным кодом.)
Ярким примером такой системы является http://stb-tester.com, инструмент с открытым исходным кодом, разработанный YouView для автоматизации тестирования пользовательского интерфейса наших телевизионных приставок. Мы опишем stb-tester, гибкость, которую предлагает его основа GStreamer, некоторые возможности, которые он открывает, и предстоящие задачи.
Ссылки: Видео
Веб-драйвер для Chrome
Кен Каниа (Google)
С момента своего появления в качестве браузера только для Windows Chrome расширился до Mac, Linux, ChromeOS, а совсем недавно — до Android и iOS. Тестирование веб-приложений на этих платформах на уровне пользователя было сложным и требовало различных подходов к автоматизации. В этом докладе будет рассказано о работе, которую команда Chrome делает, чтобы сделать WebDriver доступным для Chrome на всех платформах. Это будет включать в себя технический взгляд на базовый подход, но основное внимание будет уделено тому, как разработчики могут использовать новый ChromeDriver для написания тестов для различных платформ Chrome. Также будет освещено текущее состояние проекта и дорожная карта на его будущее.
Karma — средство запуска тестов для JavaScript
Войта Джина (Google)
Введение в Karma — средство запуска тестов, которое делает тестирование приложений JavaScript в реальных браузерах легким и приятным.
Тестирование не является обязательным, когда вы создаете приложение JavaScript, которое должно работать во многих браузерах и на многих устройствах. Однако выполнять тесты во всех этих различных средах сложно. Карма превращает эту обычно кропотливую задачу в кусок пирога. Это позволяет вам выполнять тесты JavaScript в реальных браузерах или устройствах, таких как ваш телефон или планшет, прямо из вашего терминала или вашей любимой IDE.
Ссылки: Видео
Автоматические измерения качества видео
Патрик Хеглунд (Google)
Да, можно автоматически тестировать сложные субъективные измерения, такие как качество видео! В этом докладе будет показано, как мы создали непрерывный автоматизированный сквозной тест видеозвонка WebRTC. Мы рассмотрим цепочку инструментов на высоком уровне и с какими проблемами мы столкнулись при ее создании. Это идеально, если вам нужно вдохновение для того, чтобы вывести тестирование медиа на новый уровень.
Когда плохие вещи случаются с хорошими приложениями...
Минал Мишра (Netflix)
Бум мобильных и планшетных компьютеров наводнил индустрию программного обеспечения платформами для разработки приложений. Разработка потребительских приложений на вычислительных платформах приносит конечным пользователям особый волшебный опыт. Компании-разработчики программного обеспечения, ориентированные на потребителя, всегда стараются сделать все возможное, когда разрабатывают приложения для этих платформ. Однако самая большая проблема в разработке приложений начинается только после того, как компании выпустят первую версию приложения. Потребители и компании-разработчики программного обеспечения хотят, чтобы новейшие функции и функциональные возможности были выведены из разработки как можно скорее с высочайшим качеством. Это приводит к постоянному обновлению кода на каждом уровне стека. Мы, инженеры по автоматизации пользовательского интерфейса, создаем различные системы обнаружения, чтобы обнаруживать проблемы с приложениями раньше, чем позже. В этом докладе я расскажу о некоторых наших проблемах и успехах, связанных с одной такой системой обнаружения, которая помогла найти проблемы за пределами прикладного уровня, но все же негативно повлияла на взаимодействие с пользователем.
Тестирование для образовательных игр и Образовательные игры для тестирования
Тао Се (Университет штата Северная Каролина)
В этом докладе рассказывается о Pex4Fun ( http://www.pexforfun.com/ ), который использует автоматическую генерацию тестов для поддержки автоматической оценки в онлайн-системе программирования, которая может масштабироваться до сотен тысяч пользователей. Он предоставляет игровой опыт, ориентированный на программирование, за пределами классной комнаты, обучая пользователей различным навыкам программирования и разработки программного обеспечения, включая навыки тестирования, такие как написание параметризованных модульных тестов. Pex4Fun вносит значительный вклад в решение известной проблемы оценивания заданий, а также предоставляет увлекательный опыт обучения на основе интерактивных игр. Pex4Fun завоевывает большую популярность в сообществе: с тех пор, как он был выпущен для публики в июне 2010 года, количество кликов на кнопку «Спроси Pex!» Кнопка (указывающая на попытки пользователей решать игры в Pex4Fun) достигла более миллиона на начало 2013 года.
Заключительный доклад: как Facebook тестирует Facebook на Android
Саймон Стюарт (Facebook)
Facebook — одно из самых популярных приложений для Android. В этом выступлении вы узнаете, что делает Facebook, чтобы каждый выпуск был максимально качественным. Мы рассмотрим все, от того, как мы управляем нашим кодом, через наши подходы к тестированию и вплоть до тестирования.
Вступительный доклад - Тестируемый 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)
Обновление [октябрь 2013 г.]: эспрессо теперь с открытым исходным кодом. См. https://code.google.com/p/android-test-kit/ .
Разработка надежного теста для Android должна быть такой же быстрой и легкой, как приготовление чашки эспрессо. К сожалению, с существующими инструментами это может больше походить на приготовление двойной порции карамельного соуса, перевернутого вверх дном, одного взбивания, наполовину без кофеина, — запутанно и редко последовательно. Espresso — это новая среда тестирования Android, которая позволяет быстро писать лаконичные, красивые и надежные тесты пользовательского интерфейса. Основной API небольшой, предсказуемый и простой в освоении, но он также открыт для настройки. Эспрессо-тесты четко формулируют свои ожидания, взаимодействия и утверждения, не отвлекая внимание от шаблонов, пользовательской инфраструктуры или запутанных деталей реализации, которые мешают. Тесты выполняются оптимально быстро — оставьте ожидания, синхронизацию, спящий режим и опросы позади и позвольте фреймворку изящно манипулировать и утверждать ваш пользовательский интерфейс, когда он находится в состоянии покоя. Начните получать удовольствие от написания и выполнения тестов пользовательского интерфейса — попробуйте чашку эспрессо.
Веб-тестирование производительности с помощью WebDriver
Михаил Клепиков (Google)
В веб-тестировании производительности мы довольно хорошо знаем, как анализировать загрузку страницы. Однако нам нужно выйти за рамки загрузки страницы: современные приложения очень интерактивны, и операции, как правило, не перезагружают всю страницу, а скорее обновляют ее. Различные люди, в том числе и я, интегрировали WebDriver в наборы веб-тестов производительности, что помогает, но все же позволяет отделить тесты производительности от остальной части набора тестов пользовательского интерфейса. Я предлагаю встроить функции тестирования производительности прямо в сам WebDriver, используя недавно добавленный Logging API. Это позволяет собирать метрики производительности во время выполнения регулярных функциональных тестов, обеспечивая более плавную интеграцию тестов производительности в общий процесс разработки и тестирования. Это также гораздо менее разрушительно для пользовательских цепочек инструментов сборки/тестирования, которые создает почти каждая крупная организация.
Я продемонстрирую это с помощью ChromeDriver нового поколения (WebDriver для браузера Chromium).
Непрерывное тестирование данных карт
Иветт Намет (Google) и Брендан Дейн (Google)
Непрерывное тестирование обычно заключается в выполнении модульных и интеграционных тестов. Но когда данные, которые обрабатывает ваш сервер, на самом деле являются самой большой причиной изменений, как вы гарантируете, что потребители данных по-прежнему находят их пригодными для использования и что ничто не дает сбоев из-за скорости изменений или плохих изменений? Мы обсудим методы непрерывного тестирования данных на примерах из Google Maps.
Автоматический поиск виновных в неудачных сборках — т.е. кто сломал сборку?
Джелал Зифтчи (UCSD) и Вивек Рамаваджала (Google)
Непрерывная сборка — одна из ключевых инфраструктур 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.