做完分析工作，就可以繼續業務的組織和腳本的開發工作了，這兩個可以并行開展。把分析階段的輸出做為輸入，有序開展后續活動。
對于業務的分析組織，主要參與者是熟悉系統業務的人員�，F在的應用系統越來越復雜，如果沒有業務人員參與進來恐怕很難把測試做到位。這個過程就是由熟悉業務的人員來組織需要測試內容。包括測試功能點，業務邏輯，業務范圍等等。同時針對特殊業務規則，數據規則提出相應的需求，協調其他資源滿足特殊需求。這個過程也是組織測試案例、測試數據的過程，為測試執行做準備工作。這個過程的輸出就是測試內容的跟蹤表了。
與業務并行開展的就是腳本的設計與開發了。它不會受限與測試流程、測試邏輯的限制，完全可以按照分析過程的跟蹤表進行腳本的開發。這個過程腳本的設計和開發是兩個獨立的過程，設計是以文檔的方式展現腳本，包括腳本信息、輸入/輸出參數、調用說明、腳本流程圖等內容，這樣做可以讓團隊成員之間很好的協作，避免出現混亂、失控的狀態。而且腳本的設計人員不用考慮具體的業務邏輯，只要按照既定規則把劃分好的腳本設計好就完成了任務。然后腳本的開發人員嚴格按照設計文檔進行開發，最終形成腳本集，供其他環節調用。
以上各個活動都會有管理或是QA參與，進行活動的評審，確保各個環節都是按照規范進行的，保證自動化實施過程是在可控范圍內進行的活動，避免某個環節的隨意性。
技術
技術角度，主要是決定采用什么樣的工具，腳本開發工具，配置管理工具。還有就是要制定針對在工具的使用過程中要遵循的規范，如何讓工具之間配合，發揮最大的作用。
功能自動化測試用的最多的莫過于QTP了，由于它的簡單、易用，容易上手很是受大家的追捧。當然還有它能夠破解，這也為它廣泛推廣打下很好的基礎。
技術環節需要對腳本的開發做出明確的說明。底層函數的定義，功能函數的開發，函數庫的規劃，參數、腳本的開發規范等這些都要形成文檔。最后腳本的運行也是一個很關鍵的環節，包括運行的穩定性，效率，日志，失敗的處理這些都是需要處理的問題。如果條件允許可以自己開發工具來解決這些問題，但相應帶來的成本也是非常高的。這樣做的公司都是有單獨的團隊來維護測試工具這一塊的，所以在人力、技術資源很有限的情況下不要輕易嘗試這種方式。同行用的最多的好像就是用Excel來組織，然后通過讀取Excel來控制腳本的運行，這種方式簡單，易行，但對于過于復雜的系統不適用。還有一種方式就是用QTP+QC的方式，QC有單獨的模塊來管理，組織這些內容。并且會自動記錄執行日志，結果文件等。這種方式是最方便，成本最低的一種方式，維護起來也很容易，而且沒有不兼容的情況，很容易見到效果。如果公司不打算組建專門的測試開發團隊，用這個是最有效的一種方式。缺點是在組織數據時的靈活性欠佳。
團隊
功能自動化測試肯定是一個團隊協作的過程，單槍匹馬去做自動化是非常不明智的選擇。整個團隊應該包含幾個角色：leader，熟悉業務的人員，腳本設計開發人員，測試執行人員。人員各司其職，互相配合。
根據項目具體情況，酌情增減人員。很理想的情況是公司有很好的測試流程，分工明確，各個崗位都有明確的崗位職責，這樣可以是團隊成員緊密的配合完成工作。但也有很多不理想的狀況，這時作為一個功能自動化測試的實施人員，也要對自己的工作做好規劃，什么階段做什么事情，每個階段的提交物有一個明確的思路。這樣可以使自己很好的控制進度，對上邊也有一個交代，讓領導知道做了什么。
管理
最后簡單說一下管理。這個也是一個重要環節，好的管理可以很好的控制進度，保證質量。管理人員要對測試計劃的執行情況進行監督，參與各種成果物的評審，項目的例行會議并保存會議記錄，對測試流程的不斷改進，對測試方法、技術的不斷探索。在團隊遇到困難時，也要及時的給出友情支持。這些內容有些屬于QA的范圍，具體公司具體配備相應人員。
以上只是自己對功能自動化測試的點滴思考，寫出來算是自己的一個總結。每一個環節還有待完善，補充的地方，測試的博大精深并不是簡單的幾行字能寫出來。希望在工作當中不斷的總結，不斷的提高。
嚴格意義來說，不應該稱之為對框架的思考，框架是一個系統，是一個整體，而以上只是對一部分內容做了點滴體會。是與非，看官自己定奪。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
