大公司做自動化測試一般都會有一個大的框架。就好比一般大公司規章制度比較全，你只要按照規章制度去做就可以了。自動化測試框架也是如此，一般測試人員只要在現有框架編寫自動化測試指令碼就可以了。

         這樣的好處，節省了時間和精力，便於複用，對測試人員的要求也就降低了。不好的地方，如果框架設計的不好，靈活性可能會差些。

        自動化測試框架都包含什麼內容呢？

        主程式 首先要有一個主程式，一個指令碼從最開始執行到最後生成報告執行完畢都離不開主程式。就好比C語言中有個main函式。設計主程式時可以採用面向物件的思想。

        測試資料 資料包括哪些？一般測試指令碼都是跟測試用例對應的，一個用例對應一個測試指令碼。這些測試用例的總集就是一個數據，可以把這些測試用例集放入一個或多個檔案。如果測試用例比較少，1個檔案就OK了。如果測試用例功能模組比較多，可以把不同功能模組用例分別放在不同檔案。另外，測試用例中使用的一些測試資料，也可以抽象成測試指令碼中的變數。採用“資料驅動自動化”要求資料和測試指令碼儘量分離。

        庫函式   把測試中常用的操作抽象出來，寫成一些函式，然後把這些函式放在一個庫中。寫測試指令碼時直接呼叫就可以了，不需要自己動手寫了。這樣的好處可以降低指令碼的維護成本。同樣一個功能A和B站在各自的角度分別寫了一個函式，後面C也需要用這個功能函式，他可能就不太清楚用哪個好。

        記錄日誌 測試指令碼執行，不可能都是成功的，即便成功，也最好能把日誌記錄下來，以便後續對測試執行情況的分析、追蹤。具體要記錄哪些東西，跟被測物件關係很大。這個要研究、分析被測物件、被測功能後確定。能夠把日誌記錄分等級就更好了，畢竟記錄日誌也是耗資源的，列印日誌太多對被測物件的正常功能也會造成影響。

        生成測試報告 手工測試完成後，要寫一個測試記錄，把測試執行情況（例如，哪些成功、哪些失敗、失敗原因等）記錄下來。自動化測試執行完成後也要生成一個測試記錄，只不過它是自動生成的。測試記錄要做成什麼格式？Word？Excel？txt？記錄哪些內容？這就看測試管理者或專案管理者的要求了。一般生成一個Excel能夠開啟的表格比較好，便於統計分析。