開場白
Yvette Nameth (Google)
正在開啟主題演講
Jürgen Allgayer (Google)
Uber 跨應用程式/跨裝置測試的挑戰
Apple Chow (Uber) 和 Bian Jiang (Uber)
2015 年 3 月加入 Uber 不久之後，我們測試了 Uber 的獨特挑戰，同時調查行動應用程式的 UI 測試工具。我們進行多項完整性測試時，都需要乘客和駕駛應用程式相互通訊/協調其動作，才能完成端對端測試情境。這場演講將介紹名為 Octopus 的跨平台解決方案，並討論其如何針對不同裝置上執行的不同應用程式協調通訊。任何需要針對不同應用程式或裝置進行協調/通訊的測試 (例如多人遊戲、多人通訊/通訊應用程式等) 都可採用這個解決方案。
漫遊器輔助測試自動化
Hans Kuosmanen (OptoFidelity) 和 Natalia Leinonen (OptoFidelity)
OptoFidelity 是一間芬蘭的高科技公司，擁有 10 年的開發及研發研發自動化解決方案經驗。這場座談會包括我們的經驗，以及未來針對行動裝置 UI 效能測試採用非干擾性測試方式的看法。您知道 Chrome OS 團隊使用 OptoFidelity 的機器人解決方案來評估 Android 和 Chrome OS 裝置的端對端延遲時間嗎？
結合處理各種趣味和獲利的鏈結：我們從行動跨平台整合測試中學到的經驗
Dan Giovannelli (Google)
行動開發不容易。建構測試基礎架構並不容易。跨平台作業並非易事，只要把這三種做法結合起來，就能獲得災難的食譜。在這場演講中，Dan Giovannelli 將分享自己在跨平台行動測試基礎架構專案中工作的經驗。他會討論哪些事情得以順利執行、發生什麼事 (是很差的)，以及他希望自己一開始就知道的是什麼。歡迎瞭解為非行動裝置工程師設計行動工具的深入見解。歡迎繼續探索《The Matrix 》是什麼，瞭解該遊戲如何運用自己的遊戲。
利用真實裝置自動化行動測試
Jouko Kaasila (Bitbar/Testdroid)
行動遊戲是現今應用程式商店中收益最高的類別，因此確保遊戲中的每一款遊戲都能有效支援任何使用者的裝置。儘管驗證實在相當重要，但只有極少數的範例或架構需要針對行動遊戲進行自動化測試。其中一個主要原因就是，遊戲是行動應用程式的獨特性質，因為他們可以直接存取螢幕，並略過作業系統提供的所有 UI 服務，並轉譯大多數測試自動化自動化架構，因為傳統物件不會顯示，
幸好，我們有能力使用標準行動測試自動化架構，運用一些創意且可公開存取的程式庫，針對遊戲在實體行動裝置上測試測試自動化。他的簡報中，Testdroid 的 Jouko Kaasila 將探討三種實際的範例和一些程式碼範例。
如何組裝測試湯品
Toni Chang (Google)
如果使用者花費太多時間穩定不穩定的測試，就會同意我們需要分解測試。然而，有些人並不容易，但也有些有些人可能覺得，有些企業需要我們進行 E2E 測試，以驗證所有情況。您不習慣在組件中檢視產品時，很難取得這些概念，因此我會使用湯品傾印的抽象範例來說明如何解析看似元件的分離部分，並對這些元件套用測試。
我將帶大家進行有趣的過程，將 E2E 測試翻譯成元件測試，讓您對最終產品有信心。希望您能在查看自己的產品時，從新的角度瞭解。
Chromecast 測試自動化
Brian Gogan (Google)
物聯網造成連線裝置的普及。驗證不同裝置間的行為，是一項重大的測試。如要測試 Chromecast，我們採用了多種做法。我們概略介紹了為該產品開發可靠的品質信號而開發的測試架構、研究室基礎架構和測試工具。我們詳細說明在吵雜的網路環境中測試產品時面臨的挑戰。我們提議為 Chromecast 等裝置提供測試工具相當繁瑣，為軟體測試工程帶來創新的機會。
使用機器人進行 Android 應用程式測試
Dr.Shauvik Roy Choudhary (Georgia Tech/Checkdroid)
您可以使用 Monkey 等軟體漫遊器來測試 Android 應用程式，而不必花費太多心力。學術工具中有數種這類工具建議，目標是自動產生測試輸入內容以提升 Android 應用程式。在這場演講中，我將介紹一套代表性測試輸入產生工具，並提出比較性研究，以強調這些優勢。您將會瞭解這些工具的內部運作，以及如何使用這些工具測試您的應用程式。如要瞭解這項研究詳細資訊和 VM 設定，請前往 http://bear.cc.gatech.edu/~shauvik/androtest/
您的測試並非不穩定
Alister Scott (自動英文)
常態性測試是指任何自動化測試工程師的錯誤。只要有人說「瘋狂不斷反覆執行相同的測試，從而得到不同結果」；這類測試可能會讓斷網造成負面影響。比起建構彈性的持續性測試，我們應花更多時間建立更具確定性、更測試的系統。Alister 會提供一些範例，說明測試不穩定性在系統下隱藏問題時會如何，以及如何透過建構更優質的系統來解決測試問題。
大規模的自動化影像測試
Adam Carmi (Applitools)
自動化的視覺測試是開發 / 測試社群的新興趨勢。這場講座會說明什麼是視覺測試，以及應採用自動化功能的原因。我們會深入探討視覺測試自動化的一些技術性挑戰，並說明新工具如何解決這些難題。我們會示範如何使用先進的技術，透過跨瀏覽器和跨裝置視覺測試執行，並提供成功大規模大規模視覺測試的重要秘訣。
實作迴歸測試
Karin Lundberg (Twitter) 和 Puneet Khanduri (Twitter)
您的團隊剛完成某項服務的重大重構作業，而且您的所有單元和整合測試都通過了。大功告成！不過你還沒完成這個步驟。現在，您必須進一步確認自己並未中斷任何錯誤，而且不會有任何尚未發現的沉默錯誤。是時候讓 Diffy 開始運作了。
與確保程式碼完善的音效 (例如單元或整合測試) 不同，Diffy 將新服務的執行個體與舊服務並排在同一位置，同時將各要求的要求轉送、比較回應，以及提供從這些比較結果中傳回的任何迴歸，藉此比較修改後的服務行為。
此外，我們也剛採用這項開放原始碼工具，且很快成為 Twitter 開放原始碼計畫中最受歡迎的工具之一。
Android 應用程式的自動化無障礙測試
Casey Burkhardt (Google)
這場演講會介紹 Android 平台上的核心無障礙預設用途，並說明一些與無障礙功能相關的開發人員常見問題。您將會瞭解全新的 Android 無障礙功能測試架構，以及這個架構如何與 Espresso 與 Robolectric 測試架構整合。最後，您將學習如何在現有的 Android 專案測試中加入自動化無障礙功能檢查。
統計資料取樣
Celal Ziftci (Google) 和 Ben Greenberg (MIT 研究生)
常見的做法是在測試中使用實際工作環境資料樣本。例如：
- 三度測試：將生產環境中的樣本資料匯入您的系統，看看是否發生失敗。
- A/B 測試：取得大量生產資料，透過目前版本及新版系統執行資料，並比較輸出結果以供檢查。
為了取得實際工作環境的資料樣本，團隊通常會使用臨時解決方案，例如：
- 手動查看特定欄位的分佈情形 (例如數字欄位)
- 選擇隨機隨機樣本
然而，這些方法有重大缺點：可能會遺漏罕見事件 (例如極端案件)，進而增加實際工作環境中未發現的錯誤。為降低這項風險，團隊選擇了龐大的樣本。但是，這種大型樣本還有更多缺點：
- 鮮少的活動仍會錯過。
- 測試的執行時間大幅增加
- 差異太大，讓人無法理解，且會重複計算。
這場演講中，我們提出了一種新的統計資料取樣技術，能夠「聰明」地選擇實際工作環境資料中的「良好」樣本，其：
- 保證不會錯過罕見的活動，
- 移除重複的樣本，藉此減少所選樣本的大小。
我們的技術可偵測罕見/邊界的情況，將樣本大小降到最低，並隱含檢視開發人員輸出測試/差異時的手動負擔。此外，這項工具也支援平行執行 (例如 MapReduce)，可在短時間內處理大量資料來選擇樣本。
Nest 自動化基礎架構
Usman Abdullah (Nest)、Giulia Guidi (Nest) 和 Sam Gordon (Nest)
Nest 對 Thoughtful Home 的願景，都包括相互連網的智慧型裝置，讓住家更安全、更節能且更加清楚。這場講座的重點在於自動化基礎架構和測試工具，旨在實現這個願景。Nest 的許多團隊都正在跨平台和裝置/功能專用的系統進行自動迴歸測試和分析。我們會參考實際產品測試中的具體範例，在迴圈測試基礎架構和電源迴歸分析工具中，涵蓋相機和動作偵測的特定工具組，讓您瞭解跨產品硬體。
事件產生器
Roussi Roussev (Splunk)
這場演講介紹了我們在 Splunk 開發及使用軟體活動產生器的經驗。受到粒子物理學的啟發，這類活動產生器在不執行大型實驗機器的情況下，能夠有效理解實體世界，因此記錄產生器改善了我們與新舊版第三方軟體的整合能力測試方式。這場講座介紹了基本特色與產生實際記錄檔的挑戰。
多執行緒測試合成
Murali Krishna Ramanathan (班加羅爾印度科學學院)
在多執行緒程式庫中發生細微並行錯誤，由於同步處理不準確或不夠同步，因此通常難以只使用靜態技術精確地定位。另一方面，動態偵測器的效能主要取決於多執行緒測試套件，其用途可用於找出並觸發並行錯誤，包括資料競爭、死結以及發生違規事件。這類多執行緒測試通常需要叫用特定方法組合，並搭配妥善共用的叫用物件以公開錯誤。如未事先掌握這個錯誤，建構這類測試可能並不容易。
我會在這場演講中介紹一種輕量式、可擴充的技術，可用來偵測出執行緒安全違反的測試。在多執行緒程式庫和依序測試套件中，我將說明全自動化的分析作業，以檢查依序執行追蹤，並產生並行用戶端程式，透過程式庫方法呼叫共用物件，而觸發對並行錯誤造成的狀態。多種經過測試的 Java 程式庫實驗結果，展現出我們如何有效呈現許多複雜的錯誤。
在 Netflix 中啟用串流實驗
Minal Mishra (Netflix)
超過 6900 萬名使用者的串流體驗對 Netflix 來說至關重要。為了快速改善這一點，我們將自動調整串流演算法移至 JavaScript 層。而這也成為了一項獨特的挑戰，經常推出用戶端 JavaScript 軟體，因而直接影響消費者的串流體驗。採用持續推送軟體更新模式，這個模式已廣泛且成功地用於服務應用程式，因此我們利用這個架構，在客戶檢查生命週期時及時降低風險，並頻繁提供更新。在這場演講中，我們將說明此模式的一個關鍵組成部分，以啟用軟體更新。我們會深入探討 JavaScript 用戶端和工具的推出程序，以準確比較健康狀態與目前版本。此外，我們也會分享過程中面臨的挑戰。
模擬網際網路
Yabin Kang (LinkedIn)
連結網際網路，討論 Linkedin 這種新的模擬系統，協助模擬所有傳出流量，以便進行服務層級整合測試。此外，我也會介紹 Linkedin Mocking 策略的總覽。與大家分享知識和學習經驗。
有效測試 GPS 監控站接收器
Andrew Knodt (Lockheed Martin)
空軍使用的現有 GPS 監控站變得越來越不容易維護，並且正努力將心力換成採用 GPU 加速軟體定義無線電 (SDR) 方法。我們將提供這個專門的 GPS 接收器專屬的測試難題，以及多個測試方法的考驗。雖然著重於 GPS 應用程式，但這些測試方法可輕鬆套用至其他實際工作環境等級的 SDR 工作。
穿戴式裝置上的自動化功能
Anurag Routroy (Intel)
隨著穿戴式科技日益普及，個人和企業的使用日益普及，所有在 Android 市場中擁有穩固空間的公司都將重心放在這項即將推出的技術。因此，使用穿戴式裝置支援建構應用程式，這也有助於增加在穿戴式裝置上測試應用程式的努力。因此穿戴式裝置自動化作業將變得越來越少，可以減少測試工作並提高效率。
統一基礎架構與持續整合整合 (Docker/Vagrant)
Maxim Guenis (超音波)
開發團隊在開發、偵錯及持續進行整合整合作業的過程中，每天都難以適應到可以正常運作的本機開發環境。我們將整合 Docker 與 vagrant 整合至持續整合工具，以解決這個問題。這個組合可讓開發機器的堆疊層級控管應用程式，也能在整合測試中使用相同的堆疊。本次討論會包括：
- 在 CI 整合測試中使用 Docker
- 堆疊方式而非單一 Docker 或應用程式。
- 使用 Git 和 Docker 工具輕鬆發行開發與測試環境的版本。
- 支援在 Mac 和 Windows 上執行 Docker 的流暢支援。
消除無用的測試碼
Patrick Lam (滑鐵盧大學)
專門針對測試套件採用靜態分析技術，可產生有趣的結果。我們之前已瞭解到，大多數測試都是簡單的直線程式碼，也就是一系列的設定陳述式，後面接著由宣告組成的酬載。我們會說明靜態分析如何辨識無用的設定陳述式，讓開發人員得以簡化測試案例，並加快其處理速度。
測試涵蓋範圍與測試套件成效不相關
Laura Inozemtseva (Waterloo 大學)
測試套件的涵蓋範圍通常會用來當做 Proxy 的偵測能力。然而，經過調查，我們研究了程式碼涵蓋範圍和測試套件成效之間的關聯性，卻無法達到這些測試套件特性之間關係的性質與強度。此外，許多研究都是透過小型或合成程式進行，因此不確定結果是否適用於較大型的計畫，而且部分研究並未考慮測試套件規模的複雜影響。我們藉由評估這些技術，針對可評估 Java 程式的測試套件大小、涵蓋範圍和有效性之間的關係進行擴充；這項研究是文獻規模最大的研究。我們評估了這些套件的陳述式涵蓋範圍、決策範圍和修改後的涵蓋範圍，並使用變異測試來評估這些錯誤偵測效能。我們發現，如果套件中的測試案例數量受到控管，那麼涵蓋範圍和有效性之間就會有低度到中等的關係。此外，我們也發現到更強大的涵蓋率，無法進一步解析這個套件的成效。
使用 RpcReplay 模擬假後端
Matt Garrett (Google)
確保測試快速、穩定。如果伺服器依賴許多後端，就會發生這種情況。開發人員必須在長時間測試和不穩定的測試之間選擇，或是撰寫和維護假實作。您可使用這些後端的記錄流量執行測試。如此一來，開發人員就能同時享有兩種技術的優勢，讓開發人員能夠對實際後端快速進行測試。
Chrome OS 測試自動化研究室
Simran Basi (Google) 和 Chris Sosa (Google)
Chrome OS 目前為超過 60 款各種 Chromebook/Box 執行軟體。而客戶每 6 週就會收到新的系統。如果沒有強大的持續整合系統，請檢查 200 多位開發人員的簽到機制即可。這場講座會介紹整體架構，並特別強調測試自動化研究室。此外，我們也討論了 Moblab (行動版 (測試版) 研究室) 研究室。我們透過單一 Chromebox 執行了整個測試自動化基礎架構，我們的許多合作夥伴都使用這個系統，因此他們也能以我們的方式執行測試。