Testing with KK
我們時常能看到 Google 和 Apple 在每年的 Google IO 或 WWDC 上都會發佈一些測試相關的框架，且在目前 Mobile 裝置趨近飽和的驅使下，各家測試人員肯定會針對自家產品開發自動化測試來加速出版前測試，也因此讓這些框架的使用普及率大幅上升，網路上也能找到非常多相關的文章或部落格提供開發者參考。
反觀 Microsoft 這邊，我們卻較少看到官方釋出的一些測試框架新消息，難道 Microsoft 真的沒有官方的自動化測試框架嗎？其實 Microsoft 官方一直有一套名為 WinAppDriver 的自動化測試框架，但因為在前期時提供的支援度及效能較低，也鮮少被廣泛使用，直到去年中微軟釋出的最新的更新，不但在 API 支援度上有大幅提升，而且準確度及執行速度甚至比想像中的快速，今天就讓我們來趟 WinAppDriver 之旅吧！
繼續閱讀 “Windows Automation 沒有想像中的難"
在測試工程師的世界裡，Defect 像是勳章、獎狀，是在無數個版本裡殺進殺出後取得的輝煌功績。而 Defect Tracking System 是展示區，各種大大小小的問題都被陳列在這裡，供團隊追溯與回憶。
但東西放久了會生灰塵，Defect 放久了則會出現 破窗效應，於是展示區成了高亮區，團隊成員開始踢皮球或是無視這些 Defect，如何管理好 Defect 成了個難題。
繼續閱讀 “庫存 Defect 對於團隊生產力是有害的"
Listview 和 Recyclerview 都是可以上下滑動的頁面。差異在 Listview 是一次性把所有的 view 建好，當要呈現的資料量過大時會吃掉大量的記憶體和儲存空間，可能導致 App 運行緩慢或當機。Recyclerview 則是建立適當數量的 view，再根據情況對未使用的 view 回收再利用。
在 「Appium With UiAutomator 2.0 實際運用及原理介紹」 我們了解了如何在 Appium 搭載 UiAutomator 2.0 執行自動化測試，但是若我們今天想要讓測試時程再次縮短，我們會需要使用到多裝置且運行 Multiple Session，但是根據我們實際運行 Multiple Session 後卻發現了一個嚴重性的問題，那就是 Appium UiAutomator 2.0 Proxy Server Port 會出現 「互搶互讓」 的狀態。
繼續閱讀 “Appium With UiAutomator 2.0 運行 Multiple Session"
在 「UiAutomator 1.0 與 UiAutomator 2.0 差異以及 Appium 實作」 我們瞭解了使用 UiAutomator 2.0 的好處之後，那我們該如何在 Appium 實際使用 UiAutomator 2.0 框架呢？
在實作之前我們先來看看個有趣的實驗，簡易的列出了 appium-android-bootstrap 與 appium-uiautomator2-server 兩者做同一件動作的 Appium Log 的差異，可以明顯的觀察到 appium-uiautomator2-server 分工的狀況，而 appium-android-bootstrap 則耗費許多時間在處理元件。
繼續閱讀 “Appium With UiAutomator 2.0 實作及原理介紹"
Google Android Developers 在 2015 年 3 月 13 日時公開發表了 UiAutomator 2.0，v2.0 相較於 v1.0 最明顯的優勢在於其 在 v1.0 的基礎上增加了許多實用性高的 API 。包含：
另外還有一最主要的差異為 UiAutomator 2.0 測試產出由 Java Base 更改為 Android Base ，讓 UiAutomator 2.0 可以完整的在 Android Instrumentation 上運行，這是個優勢能讓此框架更完善的被終端使用者運用。
繼續閱讀 “UiAutomator 1.0 與 UiAutomator 2.0 差異"
在上一篇初步學習撰寫 Android Espresso Test 時，發現裡面有一行程式碼建構子 ActivityTestRule ，好像只有被宣告，但能在背景內執行。
public ActivityTestRule mActivityTestRule = new ActivityTestRule(NotesActivity.class);
好似 App 是透過 ActivityTestRule 叫起來就可以運行似的，查了才知道 ActivityTestRule 是屬於 android.support.test.rule Family 內的元件。
於是好奇想知道 ActivityTestRule & android.support.test.rule 是什麼東西？ 他為何而生？ 他可以做什麼？
繼續閱讀 “android.support.test.rule"
自動化測試時常會遇到需要 等待 元件出現，而自動化常被使用到的工具，Selenium 內等待元件出現的方式分成 3 種，Implicit Wait, Explicit Wait 及 Fluent Wait，其中最常被使用到的是 Implicit Wait 與 Explicit Wait，本篇文章會著重在比較 Implicit Wait 與 Explicit Wait 的差異上。
為了因應市場快速的需求變化，採用敏捷開發作為軟體研發流程已不再是新聞。但快速的發佈頻率也讓 迴歸測試 時間大幅地增加，大量的測試讓測試部門成為專案開發裡的拖油瓶。
在 KKBOX 我們認為這樣的情況必須被改變。
測試遇到 BUG 時，除了回報重製步驟外，也需要提供 Log 給開發工程師，我們可以從 Log 看到一些非必發 BUG 的關鍵與事發的線索。iOS Device 觀看 Log 的方式，可以參考 如何觀看 iOS Device Log？。
上述文章查看 Log 的方式是使用 Apple 提供的工具 Xcode，但如果想觀看長時間的 Log，Xcode 能記錄的 Log 時間長度約 15 分鐘，時間一長，前面的 Log 紀錄就會被洗掉，顯然使用 Xcode 來長時間記錄 Log 是不可行的，因此我們可以使用以下兩種方法來實現需求。
科科和測試 
你必須登入才能發表留言。