最近發現自己對測試框架的理解一直存在誤解。我對測試框架的理解很長時間內，一直存在于如何組織腳本，如何寫出高質量的腳本這個層次，整個框架好像就是針對腳本這個層面�，F在發現這個理解很局限也很片面。
一個好的測試框架，應該包括整個測試活動的各個方面，以及對各個環節的規范、管理等等，所以腳本只是框架當中的一個環節，不應把腳本看的很重(當然不是說不重要)。腳本是用工具寫的，工具永遠是工具，整個測試過程起關鍵作用的還是人。
一個合理的框架應該包括流程、團隊、技術這三個基本要素，再用管理把這三個要素協調起來。
如圖，這三個要素是相輔相成互相依賴。
流程
首先談一下流程。這個要素，在整個測試活動周期中是用時最長的一個，大部分的測試活動都是在流程中進行。一個好的流程可以節約成本，縮短進度，提高測試質量。設計流程，不能為了自動化而自動化，要結合項目情況、目前測試部門發展情況來規劃功能自動化測試流程。
流程的規劃應該覆蓋自動化測試分析，業務流程的分析與組織，腳本的設計與開發。
拿到項目任務書后，首先要進行的就是自動化測試分析。這時要結合手上有的測試資源，如待測系統，測試需求，測試用例庫，功能說明等等，對系統來個綜合分析。這些作為分析階段的輸入。有輸入就要有輸出，也就是分析結果了。分析過程就是對業務的分析，對怎么規劃腳本的分析。對業務的分析最終要得出本次或本論測試需要測試范圍、內容，以及測試內容對需求的覆蓋情況等內容，最終形成業務跟蹤表，作為輸出。對于規劃腳本，就是要確定哪些功能可以做自動化，哪些不能做;哪些功能需要單獨作為一個腳本來寫，哪些功能適合合并成一個腳本來寫;參數的定義，主要是針對多個腳本都要用到的變量給出定義;其他可以定義一些腳本的相關信息。最終也要形成腳本分析跟蹤表，作為分析階段的輸出，納入測試資產統一管理。有了這些作為基礎，可以最大限度保證后續工作在可控范圍內進行。
做完分析工作，就可以繼續業務的組織和腳本的開發工作了，這兩個可以并行開展。把分析階段的輸出做為輸入，有序開展后續活動。
對于業務的分析組織，主要參與者是熟悉系統業務的人員�，F在的應用系統越來越復雜，如果沒有業務人員參與進來恐怕很難把測試做到位。這個過程就是由熟悉業務的人員來組織需要測試內容。包括測試功能點，業務邏輯，業務范圍等等。同時針對特殊業務規則，數據規則提出相應的需求，協調其他資源滿足特殊需求。這個過程也是組織測試案例、測試數據的過程，為測試執行做準備工作。這個過程的輸出就是測試內容的跟蹤表了。
文章來源于領測軟件測試網 http://www.k11sc111.com/
