自動化測試方式政策分析

序言：上篇文章說的“自動化例行測試有效性政策”，在又一次進行例行測試的時候，安排了一個不懂腳本的測試人員進行了例行測試操作，結果這是最迅速的一次，而且還發現了一些産品問題，效果不錯，驗證發現，其有效性還是得到了一些提高。是以說，有時候，做自動化測試很害怕的是“完美主義”與“盲目主義”，局限于一些誤區，是以一定要以“測試價值”為導向，不時的跳出來看一看其自動化測試的應用價值是不是進入了誤區。這次，對一些不同的自動化測試方式的應用進行了政策分析，不同的自動化測試方式應用不同的場景，不管如何應用，提高效率則是最佳應用。

　　一、自動化幾種測試方式

　　這次，自動化測試幾種方式，我暫時按測試類型分成：

　　1、界面自動化測試

　　c/s架構（或者桌面類型）界面自動化測試：包括桌面界面測試類型，當然有windows方面的軟體界面、跑在windows作業系統上的虛拟機方式的界面，例如java swing。前者采取的方式可以調用作業系統本身的api來建構自動化測試、後者可以采用虛拟機内的事件處理機制來完成了。

　　b/s架構（或者web類型）界面自動化測試：其實作原理之一可以依靠js來進行用戶端的操作，然後尋找對象是采用了dom解析技術，将web方面的節點進行解析定位。

　　手機方面（嵌入式産品）界面自動化測試：其實作原理之一也是可以依靠其相關系統提供的api來完成。例如：安卓的monkey就是安卓提供的一個提供動作操作的一個工具。

　　2、指令行自動化測試

　　cli自動化測試：即嵌入式的産品很都基于嵌入式作業系統完成，例如：電信産品中的ciso路由器就是最早的代表，而系統測試人員的測試大都應用指令行進行測試，是以，其自動化測試實作可以基于cli的腳本控制實作。當然，對資料庫sql指令行的操作也可以歸為此類。

　　3、api自動化測試

　　api（application programming interface，應用程式程式設計接口）是一些預先定義的函數，目的是提供應用程式與開發人員基于某軟體或硬體的以通路一組例程的能力，而又無需通路源碼，或了解内部工作機制的細節，其實就是軟體中的封裝性的思想。個人認為，api測試是用來驗證組成軟體的那些單個方法的正确性，其可以包括為單元測試、單個元件測試以及接口測試。一者是對單個子產品功能測試、另外一者是對測試系統元件間接口的一種測試。但本質上都是調用其api來驗證相應相應功能實作或者互動。

　　二、自動化測試不同方式政策分析

　　以前總在思考如何能夠最大化的應用界面自動化測試與cli自動化測試或者api自動化測試的不同特點去實作各自的自動化測試最大使用率：

　　1、界面自動化測試的特點在于：

　　1）操作方式複雜，需模拟出不同的手工操作。

　　2）其界面元素結構層次變動性較大。

3）其容錯性查，如果某單個測試用例中途遇到問題，則造成其單個測試用例無法進行下去。且與軟體性能關系較大，容易造成軟體測試中斷。

　　4）錯誤定位方面，需要靠直覺的方式進行定位。

　　是以，綜上，政策為：

　　1）界面自動化測試需要進行架構的分層，對于界面控件的查找需要基于一定的屬性搜尋定位，而常用的錄制方式一般是依靠結構層次定位。

　　2）盡量将測試用例按測試子產品細分，在中途出現問題，則可以進行down掉，再進行下一個測試用例即可，而且測試用例越細厘清楚，則錯誤定位越簡單。

　　3）當然，大範圍做的話需采用架構，但小範圍回歸測試的話，則采用錄制+二次開發的方式會比較高效。是以，不同的方式采用不同的政策是很重要的。

　　2、指令行或者api測試特點在于：

　　1）操作方式單一，都是進行指令行的輸入。

　　2）其指令行變化小，但是不同裝置有不同指令行內建，腳本數量多，指令行更改也容易造成維護量大。

　　3）容錯性較好，一般指令行自動化測試都是采用輸入+回顯判斷的方式，是以，不易造成測試中斷。

　　4）錯誤定位方面，靠日志記錄的方式即可。

　　1）由于其單一操作性，對于一些簡單的回歸測試，則可以采用cli錄制的方式，生成一些簡單的回歸腳本，這樣，測試人員也可以進行簡單的自動化測試回歸設計，輔助提高測試人員的測試效率。

　　2）對于需要大規模進行例行環境建設方面，更多的是考慮維護量方面的問題，則可以采用關鍵字驅動的思想，将裝置映射成一系列的關鍵字對象，将其屬性進行封裝，這樣，可以提高重用性和降低維護量。

　　總之，個人覺得，自動化測試應用的最大政策就是“因地制宜”，主要是抓住其測試方式的特點，然後以不同的政策去對待，這樣，才能真正快速應用自動化測試提高測試效率。否則，很容易陷入了“為做自動化測試而自動化測試”的陷阱。