Playground通過動態定義和探索由window和widget的特性建立的模型，來驅動智慧機應用的使用者介面。我們從展示的使用者介面提取特性來迭代定義一個近似應用邏輯的模型。舉個例子，當一個應用啟動時，它會展示一個有一個或多個button的window。當選中一個button，一個新的window會出現。該模型會捕獲視窗之間的轉換。要注意的是，這種方法是基於智慧機應用具有高度互動性的直覺和所得的模型提供了一個對應用邏輯狀態很好的近似。

圖4展示了智慧執行的概述。對於每一次迭代，Playground檢查focus是否變到了一個不同的window。為了避免重複的探索，一個window的等效模組採用試探性地來檢測新展示的window是否和前一個觀察到的window類似。如果是，將這個window併入一個存在的狀態。然後Playground提取相關的特性來驅動GUI。這些特性包括widget所容納的文字，可編輯的文字欄位，按鈕，和滑動容器等。然後建立當前特性和先前跟蹤widget而取得的特性之間的聯絡（下面會介紹為什麼這麼做的原因）。之後運用一些搜尋優化來削減搜尋的空間。接下來，Playground採用序列策略來決定下一個GUI動作（例如選擇一個button，向下滾動，填充文字欄位）。用上下文決定模組的定義的試探地來填充問文字。隨著一個動作結束當前迭代。本節的其餘模組詳細的描述了圖4中的其餘模組。

Widget Tracking

當瀏覽windows時，widget可能消失然後再出現。當一個widget再次出現時識別錯誤了，會導致將相同的狀態判定為不同的狀態，從而導致多餘的探索。舉個例子，假設windowA有兩個buttonA和B。當點選buttonA，window會關閉。為了完成這個探索，window會再次開啟，如果每個widget都有一個唯一識別符號，那麼這個問題是微不足道的。遺憾的是安卓並不是這樣的。

Playground跟蹤widge的方法和人類使用者類似。我們為widget跟蹤定義瞭如下的widget屬性。（1）有text的widget。widget通常都有與之相關聯的使用者可見的文字，例如，button的文字標籤。在許多情況下，這個文字就足夠區分widget的身份了。然而並不是所有的widget都有文字。另外，可能多個widget有相同的文字。（2）有image的widget。GUI的佈局經常會讓widget包含圖片。這種情況下，圖片可以唯一標識widget。(3）在window中的位置。結合之前的，widget在window中的位置是有用的標識。（4）在GUI層次中的位置。widget往往有固定的長輩鏈。一個button，舉個例子，在同一個window中往往有相同的長輩鏈。使用者感知方面就是widget的相對定位。

Sequencing Policies

每個window都能有很多允許輸入事件的widget。除了button，window還可以包含editable text box， check box， spinner等。選擇一個button的結果可能會直接影響其他widget 的互動。check box 可以啟用/禁用其他widget。最後，可滑動的widget向用戶隱藏了其他widget。執行所有widget可能的順序是不可行的。所以我們只能執行最有意義的活動執行方式。

在一個window中有相互作用的widget的順序需要考慮。基於觀察，我們將GUI分為兩類：（a）那些輸入引數或變數進入應用程式的，如將文字輸入可編輯的文字框或下拉選單，和（b）那些提供動作的，如button。首先，接受輸入的widget應該在動作widget之前接受操作。第二，滾動容器中包含的widget應該在滾動容器錢進行操作。第三，可滾動容器的內容和容器本身，要先於容器外的widget執行，除非和第一條矛盾。這一設計遵循這樣的直覺：滾動器外的widget（如果存在的話），通常是控制button，例如：“OK”，“提交”，“取消”。這一設計遵循這樣的直覺，滾動部件外的部件（如果存在的話）通常是控制按鈕，例如“OK”，“提交”，和“取消”。

需要注意的是這些策略的選擇有重要的影響。
如果widget的行為依賴於另一widget，Playground可能無法觸發整組行為。雖然我們在單個視窗中討論這個問題，很容易看到這樣的問題也出現在交叉視窗中。

Search Optimization

出於實用性，我們試探地削減可能多餘的瀏覽路徑。將所有的專案組織成一個列表，設定探索的閾值。除了減少探索次數，閾值有時候也能用於終止程式。例如安卓列表可以動態擴充套件，從而無線深入。我們設定的閾值也和同一個widget被作用的次數有關（完整探索一個widget所引導的狀態，肯能要多次與這個widget互動）。

Window Equivalence

當探索一個App時，一個window可能會由不同的引數多次呼叫。舉個例子，考慮一個一個地址簿應用程式。一個顯示的聯絡人的列表的視窗。當選擇一個聯絡人時，“編輯聯絡人”的視窗被開啟。選擇不同的聯絡人時，所得到的window雖然不完全相同，但是是類似的。相似的window通常意味著相似的功能和底層程式碼。Palyground通過註解此類相同的window來降低搜尋空間。

遊樂場使用視窗等價試探法來確定當前視窗狀態是充分類似於以前訪問過的視窗狀態。對於安卓的實現，我們利用了活動元件和window設計之間的關係。也就是我們試探性地將屬於相同元件的window分為相同的一類。GUI Ripper用window的標題來判斷window是否等價。

Contexr Detemination

如前所述，應用程式經常有需要正確填充文字的文字框以示他們到達正確的狀態。Playground會搜尋提示的關鍵字和與文字框相關聯的旁邊的可見的文字例如，字串“電子郵件”，可能立即出現到文字框的左側，表明它應該被填入一個電子郵件地址。

確定關鍵字的規則需要實證調查。我們分析了超過500個Android應用程式的字串資源，以確定程式開發人員在特定領域使用哪些字串。為了做到這一點，我們首先將所有的字串提取成應用程式字串資原始檔。然後，我們轉換字串成一個規範形式（小寫，去複數）。接下來，我們按照頻為所有的應用程式字串排序。其結果用來人工將字串分類成各種語義的儲存桶，如電子郵件，名稱和電話。最後基於關鍵字的原則為每個語義桶編碼。我們的最終的正規化包括了電子郵件，地址，日期，電話號碼，密碼，使用者名稱，取消和OK，和其他一些規則。 自動填充的方法也可以用來完成網頁表單。這些技術都比較複雜，包括自我學習。我們將會將其整合到Palyground中。

我們解決賬戶註冊和登入的策略是根據關鍵詞的做法來判定上下文環境。有時候一個應用需要註冊，也會包含一個註冊窗來服務。在註冊窗中需要輸入的文字框有：電子郵件，使用者名稱和密碼。通過識別這些欄位，Playground可以自動註冊一個帳戶，如果應用程式內可以註冊賬戶的話。目前，Playground總是使用相同的郵箱地址，使用者名稱和密碼，之後的應用的測試將通過填充相同的憑據自動登入。將來，Playground將能檢測是否成功登入了。Playground可以用人類測試員建立的賬戶自動檢測應用程式的未來版本。