自動化測試中的測試執行自動化

Bradshaw ： 關于這點，我建議每個人都去讀一下James Bach及Michael Bolton寫的 精析測試與檢查 這篇文章，形成下自己的看法，我的觀點目前和兩位作者在文章中所闡述的一致。對我來說，測試和檢查的主要區別在于是否以學習為中心。學習是知識的獲取。我們通過測試軟件來獲得軟件自身的知識，這些知識實質是業務需求，后面做出明智的決策均基于此基礎上。在測試的時候，我們可以自由隨意地研究系統，遵循啟發式思路，在已有結果的基礎上進行研究，去探尋新的信息。在這個過程中，我們在不斷學習。而檢查，確切地說，就是只有檢查。我們依靠某些模型來檢查系統，去檢測有違模型的變化之處。我們所執行的只不過是一系列的算法步驟。這中間沒有學習。我們還得評估所有這些檢查的結果，為了找出其中是否存在問題。而這些只有人方能辦到。

Bradshaw ： 它們二者互相補充。在我看來，二者若缺其一，剩下的一個也將獨木難支。我們需要對系統的關鍵行為進行檢查，尤其是那些會消耗商業資源或破壞商業聲譽的行為。當然了，你也可以說所有的bug都會造成這樣的后果，所以我說的是諸如不能在亞馬遜上下單，或者不能在Slack里發送信息之類的重要事件。與此同時，還要測試系統的新功能，盡管從業務層面能夠理解系統行為，但我們的測試還是要做，得弄清楚這些新功能是怎樣影響系統其它部分的。檢查有助于引導此類測試活動，檢查活動就像當檢測到了某一部分的變化時，對外發出公開邀請，以對變化部分做進一步的探索和測試。

Bradshaw ： 在以前的工作里，別人告訴我，自動化的目標是替代測試活動，主要是替代回歸測試。好幾次我甚至還碰到過這樣的討論，說自動化實際上能夠替代測試工程師。這當然不過是空談。講演中提及這個觀點的主要原因，是為了保持我在測試和檢查上的觀點的一致性。在我看來，大多數人口中的自動化測試，實際上只是自動化檢查。他們為系統制定了一個模型，照著這個模型做檢查。但正如前面所說的，我們還需要測試，所以需要理解的是，這些自動化檢查支撐了我們的測試成果，而不是替代測試成果。另外，如果認可測試是必需的話，我們應當去研究怎樣才能讓測試變得更快、更深入，或者研究如何才能進一步延拓測試范圍。什么樣的工具我們能用來支撐測試，完成像數據管理、狀態控制以及日志文件解析等事務。

Bradshaw ： 我喜歡用類似于拼出來的架構，拼圖性質的架構。用拼圖來描述抽象和解耦比較朗朗上口。在架構設計時，我一般會把它們設計為一個個獨立的部分。比如說，GUI自動化檢查方法通常是這樣的，有一部分代碼用做數據管理，從電子表格程序中讀數據或者在數據庫里創建數據，另一部分代碼用于創建瀏覽器實例，供測試人員使用，還有一部分代碼用于管理測試人員和頁面的交互，最常見的就是PageObjects，最后還有一部分代碼用于處理報告結果。把所有這些部分拼在一起，就組成了一個能用于自動化檢查GUI的工具了。既然設計出來的架構的粒度小，那么現在在整個測試過程中這些模塊都可被我們利用了。我們可以為數據生成代碼創建一個GUI，或甚至是命令行接口，團隊成員在測試的時候就可以用這部分代碼來生成數據，而不用自己一頭扎進DB里。另外一個例子是我目前正在做的，通過使用終端自動化架構中的部分內容，將app部署在1-N設備上，啟動app，執行登錄和停止。這樣我一下子就能完成手機批量更新，每個版本節省了大概15~30分鐘的時間，多出的時間我可以去做測試。

Bradshaw ： 我們對自動化的看法及其討論都需要改變。應牢記我們所要解決的是測試問題，而不是“我們需要自動化”的問題。嚴肅認真地思考下你面臨的測試問題，在最適合的環節使用工具，同時別忘了工具自有其局限性。

我想要表達的觀點是，我目睹了很多公司盲目追求自動化，自動化好像是它非要不可的玩具一樣。我也遇到過團隊將自動化單純地視為端到端的腳本，其中包含了一些啟動項、一些動作項和一些斷言語句。應破除這些模子。以批判性的眼光來審視測試過程中需要改進的部分，如果自動化對此能有所幫助，就加入相應部分的自動化。分析測試方法中的瓶頸之處，深入的挖掘分析，不要止步于比如回歸測試耗時太長這種層次的分析。究竟是哪一部分的回歸測試耗時過長？別只盯著瓶頸自動化，很多時候這遠不是事情的全部。

最后一點，別忘了自動化本質上是笨呆的，實現自動化需要持續不斷的培訓。這會花費很多時間，你確定有這么多的時間嗎？而測試人員作為一個鮮活的人，時刻都在不停學習，想象下，如果你手頭上有一些趁手好使的工具，那該能對你的測試起到多么大的改善作用啊？