第一，需求穩定，不會頻繁變更。

自動化測試最怕的就是需求不穩定，過高的需求變更頻率會導致自動化測試用例的維護成本直線上升。 剛剛開發完成並調試通過的用例可能因為界面變化，或者是業務流程變化，不得不重新開發調試。所以 自動化測試更適用於需求相對穩定的軟件項目。
第二，研發和維護周期長，需要頻繁執行回歸測試。
1. 在我看來，軟件產品比軟件項目更適合做自動化測試。
首先，軟件產品的生命周期一般都比較長，通常會有多個版本陸續發布，每次版本發布都會有大量的回 歸測試需求。
同時，軟件產品預留給自動化測試開發的時間也比較充裕，可以和產品一起迭代。
其次，自動化測試用例的執行比高於1:5，即開發完成的用例至少可以被有效執行5次以上時，自動化測 試的優勢才可以被更好地體現。
2. 對於軟件項目的自動化測試，就要看項目的具體情況了。
如果短期的一次性項目，就算從技術上講自動化測試的可行性很高，但從投入產出比（ROI）的角度看 並不建議實施自動化，因為千辛萬苦開發完成的自動化用例可能執行一兩次，項目就結束了。我還遇到 過更誇張的情況，自動化測試用例還沒開發完，項目都已經要上線了。
所以，對於這種短期的一次性項目，我覺得你應該選擇手工探索式測試，以發現缺陷為第一要務。而對 於一些中長期項目，我的建議是：對比較穩定的軟件功能進行自動化測試，對變動較大或者需求暫時不 明確的功能進行手工測試，最終目標是用20%的精力去覆蓋80%的回歸測試。
第三，需要在多種平台上重復運行相同測試的場景。
這樣的場景其實有很多，比如：
對於GUI測試，同樣的測試用例需要在多種不同的瀏覽器上執行； 對於移動端應用測試，同樣的測試用例需要在多個不同的Android或者iOS版本上執行，或者是同樣 的測試需要在大量不同的移動終端上執行；
對於一些企業級軟件，如果對於不同的客戶有不同的定制版本，各個定制版本的主體功能絕大多數 是一致的，可能只有個別功能有輕微差別，測試也是需要覆蓋每個定制版本的所有測試； ……
這些都是自動化測試的最佳應用場景，因為單個測試用例都需要被反復執行多次，能夠使自動化測試的 投資回報率最大化。
第四，某些測試項目通過手工測試無法實現，或者手工成本太高。
對於所有的性能和壓力測試，很難通過手工方式實現。
比如，某一個項目要求進行一萬並發用戶的基准性能測試（Benchmark test），難道你真的要找一萬個 用戶按照你的口令來操作被測軟件嗎？又比如，對於7×24小時的穩定性測試，難道你也要找一批用戶 沒日沒夜地操作被測軟件嗎？
這個時候，你就必須借助自動化測試技術了，用機器來模擬大量用戶反復操作被測軟件的場景。當然對 於此類測試是不可能通過GUI操作來模擬大量用戶行為的，你必須基於協議的自動化測試技術，這個我 會在后續的性能測試章節詳細敘述。
第五，被測軟件的開發較為規范，能夠保證系統的可測試性。
從技術上講，如果要實現穩定的自動化測試，被測軟件的開發過程就必須規范。比如，GUI上的控件命 名如果沒有任何規則可尋，就會造成GUI自動化的控件識別與定位不穩定，從而影響自動化測試的效 率。
另外，某些用例的自動化必須要求開發人員在產品中預留可測試性接口，否則后續的自動化會很難開 展。
比如，有些用戶登錄操作，需要圖片驗證碼，如果開發人員沒有提供繞開圖片驗證碼的路徑，那么自動 化測試就必須借助光學字符識別（OCR）技術來對圖片驗證碼進行模式識別，而它的設計初衷是為了防 止機器人操作，可想而知OCR的識別率會很低，就會直接影響用例的穩定性。
第六，測試人員已經具備一定的編程能力。
如果測試團隊的成員沒有任何開發編程的基礎，那你想要推行自動化測試就會有比較大的阻力。這個阻 力會來自於兩個方面：
前期的學習成本通常會比較大，很難在短期內對實際項目產生實質性的幫助，此時如果管理層對自 動化測試沒有正確的預期，很可能會叫停自動化測試； 測試工程師通常會非常熱衷於學習使用自動化測試技術，以至於他們的工作重點會發生錯誤的偏 移，把大量的精力放在自動化測試技術的學習與實踐上，而忽略了測試用例的設計，這將直接降低 軟件整體的質量。

=============================================================================================================

 

PO（Persistent Object）：
persistant object持久對象
最形象的理解就是一個PO就是數據庫中的一條記錄。
好處是可以把一條記錄作為一個對象處理，可以方便的轉為其它對象。
通俗解釋一下就是每個頁面當成一個對象，給這些頁面寫一個類，主要就是完成元素定位和業務操作；至於測試腳本要和ta區別開來，需要什么去這些頁面類去調用即可。這樣的好處就是如果頁面元素發生變化，你去維護頁面類即可，測試類你基本不用管。

所有用到的頁面都定義稱為一個類
把頁面用到的元素定義成方法
把頁面上一些操作定義成方法
PO是什么:
1、頁面對象模型（PO）是一種設計模式，用來管理維護一組web元素的對象庫
2、在PO下，應用程序的每一個頁面都有一個對應的page class
3、每一個page class維護着該web頁的元素集和操作這些元素的方法
4、page class中的方法命名最好根據對應的業務場景進行，例如通常登錄后我們需要等待幾秒鍾，

po的優點
1、PO提供了一種業務流程與頁面元素操作分離的模式，這使得測試代碼變得更加清晰。

2、頁面對象與用例分離，使得我們更好的復用對象。

3、可復用的頁面方法代碼會變得更加優化

4、更加有效的命名方式使得我們更加清晰的知道方法所操作的UI元素。例如我們要回到首頁，