[科技見談] 關於自動化測試

前言
自動化測試是結合 程式開發 與 品質管理的一項領域技術
有鑑於無人自動化的開發 電腦可以取代人
做營運管理的項目越多 -- 品質測試與管理 也被拿來評估與討論

濫觴
2015年底，我進入了自動化測試領域
因為客戶的需求及老闆的建議下 我開始了Python之路
而我也因此認識了Python 跟它談了 "一整年的戀愛"
Python  強調程式應優美、簡單、明瞭，像佛教的"禪"

禪的意境
禪是種意境，像風一樣，雖看不見但卻無所不在，我很嚮往 -- 逃離紛擾 邁向空無。
心靈的禪學=>我還在追尋，但至少Python的藝術 讓我領略到了這種意境。
至此之後，我認為概念式或邏輯的開發上我應該使用Python來開發並驗證
不管是在自動化系統開發或是物聯網的領域上，甚至是機器學習 大數據分析等等
Python已經提供了完整的API包 -- 讓我們站在巨人的肩膀上看世界!!!


開始的一切是如此原始
有別於一般iOS的自動化測試使用Selenium for iOS 或是 Android app的自動化測試使用 Selendroid (Selendroid for Android)

一開始的自動化測試，我使用的是 "腳本化開發方法"從Serial的驗證 到 IEEE488規範的儀器(GPIB，如電源供應器)的控制我用的是一條腸子通到底的腳本式語言很快我遇到了瓶頸 ~~ => 非常不好維護我開始分門別類地將不同的模組寫在不同的.py檔內
到了第二階段的類 C語言的開發 =>程式開始有點規模了
使用這樣的方式開發 除了乾淨外，之後的擴充或是維護 都是很好管理的

系統化的架構思維
在自動化測試系統的開發中，很多時候需要將架構開發與測試行為發展進行切割
我認為需要更好的分工模式來進行 自動化 及 測試兩個功能
所以RD專心自動化   QA專心寫測試腳本(Test cases) -- 合作無間。
這時候我認為系統還介於第二階段與第三階段之間 -- Stage 2.5 of Auto-test system.
第三代的完成 我認為除了導入了SW-QA撰寫的xml檔(test cases)機制外，還有test command與check command兩邊的分工，我將測試步驟分兩塊 -- 步驟測試(Tester)與步驟確認(Checker)

何謂步驟測試(Tester)??
SW-QA將測試程式分成很多個小步驟 除了前期判斷Pre-condition外，就是測試步驟的進行
測試步驟會分為很多模組
Charging test、Hardkey test、Touch Pannel test等等
tp我們會先在產品端埋入老化程式(大陸朋友的理解) 我跟德國佬 都稱它為 Test Proxy
Test Proxy它是代理人 會接收我們送給它的訊息從UART或是I2C...等等溝通的介面接口(Interface)，它會將我們送給它的指令轉送給產品端的其他介面或是 -- 直接控制!!!
這邊很多測試都是非常直觀的，在這裏我們還會導入Arduino去幫我們控制一些電源輸入等等透過Relay的控制來決定產品是否充電...

rejection test(排除測試)為在RD端測試過程需要確認測試手法能否付現、經由付現率從100%降至0%以確保問題解決的過程，以車用產品來說，我們使用V model來對應整個產品從RD開發到最後產品到使用者手上的測試‧

何謂步驟確認(Checker)???
我們需要透過步驟確認這個動作，來完成測試的目的
如何確認 方法很多 除了Log checker外 我們可以透過DumpUI 以及外拍存圖比對的手法達到

疑惑、迷惑還是迷失??
很多RD很輕易地傲慢，認為他們創造了一切，如此一廂情願，從一開始的疑惑到熟稔技術後會變成迷惑，最後我迷失了自己   中止迷失最重要的是 他們要認清  一切的一切應該以人為本

我們太過相信電腦處理程式的速度與能力，總認為技術與架構上能夠駕馭 我們能夠駕馭一切
但實際上的狀況是  -- 電腦還是會出錯，至少在我們教會它們學會自我學習之前。
程式開發以人為本的概念就是，想辦法讓電腦像個人

在這個階段我獲得了一些指導跟方向
我們不能 一廂情願 更不能"射後不理"
在此向資深的同事們學習 車用電子的精隨 -- 嚴謹
需要透過狀態的確認 我認為這是第四代的自動化測試
即使是我所知道的 其他團隊開發的自動化測試 雖然是不同的寫法 OO
但那始終是Coding style的不同，對於自動化測試中代數的演進，我認為是無差別。


下一個里程碑
2016~2017 我們在自動化的浪潮之上時而被新的資訊與技術 淹沒 但又像勇敢冒險的衝浪客 克服技術(湧浪)的困難與瓶頸 爬上浪尖
我認為自動化測試，應該結合人工智慧(機器學習)並透過類神經網路模組去學習行為
這樣的配置或許過於豪華 但我認為是必須的弊
在我跟同事們合作的過程中，我們花了大部份的時間 分析test cases行為的合理性並Debug
我始終認為好的程式 應該是幫助人類 而非證人入罪
之所以會自動化是因為 人需要休息並且人會出錯
我們給了機器思考跟學習的能力 我們除了一開始教他之外，剩下的時間
我們應該把時間花在教它更多新的事物 而非 找尋跟修正我們自己的錯誤

只是 那條路...還很漫長~~~ 那是最後一哩路