기조연설 - 테스트 가능한 자바스크립트 - 테스트 가능성을 위한 애플리케이션 설계
마크 트로슬러 (Google)
테스트 가능한 자바스크립트는 프로세스입니다. 빈 슬레이트로 시작하든, 이미 구현된 애플리케이션 (또는 그 사이에 있는 앱)이든 자바스크립트 코드를 간단하고 깔끔하며 효과적으로 테스트하는 것은 필수 기능입니다. 테스트할 수 없는 코드는 재작성됩니다.
자바스크립트는 실행되는 환경이 매우 다양하기 때문에 고유하지만, 자바스크립트에도 적용되는 다른 언어에서 시도되었으며 실제로 '테스트 가능한' 방법론이 많이 있습니다. 물론 자바스크립트 개발자가 코드를 작성하고 테스트할 때 직면해야 하는 고유한 과제도 있습니다.
어떤 패턴으로 코드를 테스트할 수 있나요? 어떤 안티패턴이 테스트를 방해하나요? 코드의 테스트 가능성을 측정하기 위해 어떤 측정항목과 상식 가이드 게시물을 사용할 수 있나요? 테스트 가능한 코드를 만드는 프로세스가 시작된 다음에는 어떻게 해야 할까요?
저와 함께 테스트 가능한 자바스크립트를 작성하는 프로세스를 자세히 알아보세요. Google은 테스트 가능성을 크게 증가시키는 아이디어, 패턴, 방법론을 조사하여 코드의 유지관리성, 정확성, 수명을 조사합니다. 클라이언트 측의 서버 작성이든 서버 측 자바스크립트 작성이든 상관없이 이 프로세스를 통해 코드의 품질이 크게 향상됩니다.
매트릭스 분석 - 대규모 Android 테스트
토마스 키니 (Google), 스테판 람사우어 (Google), 발라라 자카로프 (Google)
빨간 약을 복용할 준비가 되셨나요?
모바일은 인간이 컴퓨터와 상호작용하는 방식을 변화시켰습니다. 이는 좋은 일이지만, 엔지니어 입장에서는 코드가 실행되는 환경이 점점 더 많아지고 있습니다. 소수의 브라우저와 화면 해상도만 고려하는 시대는 지났습니다. 엔지니어는 매트릭스에 어떻게 대처할 수 있을까요? 워크스테이션, 클라우드 및 머리에서 Google이 이 테스트 문제를 해결하는 방법을 살펴보겠습니다.
"Neo에서 마음을 돌리고자 합니다. 하지만 문은 보여드릴 수 있습니다. 그 길을 통과해야 합니다."
Android UI 자동화
Guang Zhu (朱韦) (Google) 및 Adam Momtaz (Google)
모바일 세상에서 Android의 인기가 높아지면서 애플리케이션 개발자와 OEM 공급업체는 애플리케이션이나 전체 플랫폼에 대한 엔드 투 엔드 UI 기반 테스트를 실행하는 방법을 모색하고 있습니다. 이 강연에서는 Android의 기존 UI 자동화 솔루션에 대한 최근 검토를 통해 최근 출시된 Android UI Automator 프레임워크를 소개하고 계속해서 프레임워크, 일반적인 사용 사례 및 워크플로에 대해 자세히 살펴봅니다.
Appium: 모바일 앱 자동화
Jonathan Lipps (Sauce Labs)
Appium은 네이티브 및 하이브리드 모바일 애플리케이션 (iOS 및 Android 모두)을 자동화하는 Node.js 서버입니다. Appium은 철학에 따라 앱을 자동화하기 위해 수정하면 안 되며, 테스트 코드를 원하는 언어 또는 프레임워크로 작성할 수 있어야 한다고 규정하고 있습니다. 그 결과 모바일처럼 네이티브 언어를 사용하는 Selenium WebDriver 서버가 생성됩니다. Appium은 실제 기기와 에뮬레이터에서 실행되며 완전히 오픈소스이므로 모바일 테스트 자동화를 시작하는 데 매우 유용합니다. 이 강연에서는 Appium의 설계에 영향을 주는 원칙을 간략하게 설명하고, 다른 모바일 자동화 프레임워크 분야에서 Appium에 대해 이야기하고, 마법을 실현할 수 있는 아키텍처를 소개합니다. 마지막으로, 새로운 모바일 앱의 간단한 테스트용 코드를 자세히 살펴보고 이 테스트를 iPhone 및 Android에서 실행하는 Appium을 보여드리겠습니다.
Google+ 모바일을 위한 확장 가능한 모바일 테스트 인프라 구축
에두아르두 브라보 (Google)
유의미하고 안정적이며 확장 가능한 방식으로 네이티브 앱을 테스트하는 것은 쉬운 일이 아닙니다. Google+는 모바일이 제시하는 복잡한 테스트 시나리오 각각에 적합한 인프라를 제공하여 이러한 문제를 해결할 수 있는 효율적인 솔루션을 개발했습니다. 현재 테스트 인프라는 iOS 및 Android 앱 모두에 적합한 도구를 제공하여 개발팀에 새로운 변경 사항이 기존 고객을 방해하지 않는다고 확신할 수 있습니다.
Espresso: Android UI 테스트를 새로 시작
발레라 자카로프 (Google)
신뢰할 수 있는 Android 테스트 개발은 에스프레소를 잡는 것만큼 쉽고 빠르게 개발할 수 있어야 합니다. 안타깝게도 기존 도구를 사용할 때 카라멜 소시지 두 개를 넣은 듯한 단일 샷 - 반 디카페인 라떼를 만드는 것처럼 느껴질 수 있습니다. 이렇게 하면 혼란스럽고 일관성이 거의 없어집니다. Espresso는 간결하고 아름답고 안정적인 UI 테스트를 빠르게 작성할 수 있는 새로운 Android 테스트 프레임워크입니다. 핵심 API는 작고 예측 가능하며 배우기 쉽지만 맞춤설정도 가능합니다. Espresso 테스트는 방해가 되는 상용구, 커스텀 인프라 또는 복잡한 구현 세부정보를 방해하지 않고 기대치, 상호작용 및 어설션을 명확하게 설명합니다. 테스트는 최적의 속도로 실행됩니다. 대기 시간, 동기화 시간, 절전 모드, 설문조사를 그대로 두고 UI가 안정적으로 UI를 조작하며 어설션할 수 있도록 합니다. UI 테스트를 작성하고 실행해 보세요. Espresso 장면을 시도해 보세요.
WebDriver를 사용한 웹 성능 테스트
마이클 클레피코프 (Google)
웹 성능 테스트에서는 페이지 로드를 분석하는 방법을 잘 이해하고 있습니다. 하지만 페이지 로드 이상의 작업을 수행해야 합니다. 최신 앱은 상호작용이 활발하고 운영 시 페이지 전체를 새로고침하는 것이 아니라 업데이트하는 경향이 있기 때문입니다. 저를 포함한 많은 분들이 WebDriver를 웹 성능 테스트 하네스에 통합하여, 다른 UI 테스트 모음과 별도로 성능 테스트를 유지하고 있습니다. 최근에 추가된 Logging API를 활용하여 WebDriver 자체에 성능 테스트 기능을 빌드할 것을 제안합니다. 이렇게 하면 정기적인 기능 테스트를 실행하는 동안 성능 측정항목을 수집하여 전체 개발 및 테스트 흐름에 성능 테스트를 훨씬 더 원활하게 통합할 수 있습니다. 또한 거의 모든 대규모 조직에서 만드는 커스텀 빌드/테스트 도구 모음도 크게 지장을 받지 않습니다.
차세대 ChromeDriver (Chromium 브라우저용 WebDriver)로 이를 보여드리겠습니다.
연속 지도 데이터 테스트
이베트 네임스 (Google) 및 브렌든 데인 (Google)
지속적 테스트는 일반적으로 단위 테스트와 통합 테스트를 실행합니다. 하지만 서버가 처리하는 데이터가 실제로 가장 큰 변화의 원인이라면 어떻게 해야 이 데이터의 소비자에게 여전히 사용 가능한 데이터가 있고 변경 속도나 나쁜 변화로 인해 비정상 종료가 발생하지 않도록 할 수 있을까요? Google 지도의 사례를 통해 지속적 데이터 테스트 기법을 설명합니다.
실패한 빌드에서 자동으로 원인 찾기 - 즉 누가 빌드를 손상시켰나요?
Calal Ziftci (UCSD) 및 Vivek Ramavajjala (UCSD)
지속적 빌드는 Google의 핵심 인프라 중 하나입니다. 빌드가 실패할 경우 문제의 변경 목록 (CL)/변경 목록을 신속하게 파악하여 빌드를 녹색으로 되돌리는 것이 중요합니다.
원인 감지 솔루션은 중소규모 빌드에는 있지만 대규모 통합 빌드에는 존재하지 않습니다.
Google의 범인 파인더는 큰 성공을 거둔 매우 짧은 기간 동안 대규모 빌드의 원인인 CL을 자동으로 찾는 것을 목표로 삼습니다. 지난 9개월 동안 여러 프로젝트의 프로덕션 사용량을 기준으로 한 범죄자 발견 가능성은 매우 유망합니다. 이 대담을 통해 범인 찾기 도구가 어떻게 구현되었는지, 프로덕션 환경에서 얼마나 성공적이었는지, 어떤 느낌인지에 대해 알아보세요.
소프트웨어 제품 라인 품질에 대한 실증적 조사
카테리나 고세바-팝스토자노바 (웨스트버지니아 대학)
소프트웨어 제품 라인은 제품 라인의 시스템 간에 높은 수준의 공통성과 가능한 수의 다양한 변형을 나타냅니다. 중간 규모 산업 제품 라인과 진화하는 대규모 오픈소스 제품 라인이라는 두 가지 우수사례에서 추출한 데이터를 토대로 Google은 체계적인 재사용으로 품질을 개선하고 이전에 경험했던 결함, 소스 코드 측정항목, 변경 측정항목을 통해 향후 발생할 수 있는 장애를 성공적으로 예측할 수 있는지 여부를 실험적으로 살펴봤습니다. 연구 결과에 따르면 소프트웨어 제품 라인 설정에서 결함이 있는 항목이 정적 코드 측정항목보다 변화 측정항목과 더 상관관계가 높은 것으로 확인되었습니다. 품질 평가 결과, 이전 패키지 (공통성 포함)가 지속적으로 변경되었지만 오류 밀도가 낮았습니다. 또한 오픈소스 제품 라인은 출시를 통해 발전하면서 품질도 개선되었습니다. 일반화된 선형 회귀 모델을 기반으로 한 예측은 이전 출시에서 빌드된 모델을 사용하여 출시 후 오류에 따라 패키지의 순위를 정확하게 매겼습니다. 그 결과 또한 출시 후 오류 예측이 제품 라인 정보를 추가로 얻을 수 있다는 사실이 드러났습니다.
AddressSanitizer, ThreadSanitizer 및 MemorySanitizer -- C++용 동적 테스트 도구
Kostya Serebryany (Google)
AddressSanitizer (ASan)는 C/C++ 프로그램에서 버퍼 오버플로 (스택, 힙 및 전역) 및 use-after-free 버그를 찾는 도구입니다. ThreadSanitizer (TSan)는 C/C++ 및 Go 프로그램에서 데이터 경합을 찾습니다. MemorySanitizer (MSan)는 초기화되지 않은 메모리 (C++)의 사용을 찾는 진행 중인 도구입니다. 이러한 도구는 매우 빠르게 실행되는 컴파일러 계측 (LLVM 및 GCC)을 기반으로 합니다 (예: ASan은 속도가 2배만 느려짐). 이러한 도구를 사용하여 대규모 테스트의 경험을 공유할 예정입니다.
기조연설 - 바다를 마셔보세요 - Google 규모의 XSS 찾기
Claudio Criscione (Google)
교차 사이트 스크립팅(XSS)은 웹 애플리케이션 세상에서 중년층의 흑사병에 맞먹는 최신 기술로, 널리 보급되고 나쁜 것이며 늦을 때까지는 감지할 수 있는 기술적 방법이 거의 또는 전혀 없습니다. DOM XSS는 특히 심각한 문제이며, 이를 감지하려면 실제 브라우저 또는 이에 상응하는 기능이 필요합니다. 사용 가능한 자동화된 솔루션이 거의 없는 어려운 문제입니다.
개발 주기 초반에 DOM XSS를 식별할 수 있는 강력한 자율 주행 도구가 필요했는데, 보안 팀 외부의 엔지니어가 사용할 수 있는 제품이 필요했습니다. 빠르고, 복잡하고, 매우 복잡한 이 거대한 애플리케이션 자료를 스캔할 수 있는 제품이 필요했습니다. 그래서 Google은 표준 Google 기술을 기반으로 설계된 DOM XSS를 대상으로 하는 웹 애플리케이션 스캐너를 만들었습니다. App Engine에서 실행되며 강력한 Chrome 브라우저와 수백 개의 CPU를 보안 스캔 플랫폼으로 활용합니다.
또한 Google의 테스트 무기가 되기에 안전합니다. 보안팀의 도구가 아닌 테스트 인프라 내에 상주합니다.
이 강연에서는 새로운 접근 방식, 시스템을 Google 크기로 확장하는 데 직면한 문제, 자바스크립트 집약적인 애플리케이션에서 감지 및 크롤링 모델을 개발할 때의 아이디어를 간략하게 설명합니다.