談到測試框架，很多人都趨之若鶩，自己也不例外。但最近發現自己對測試框架的理解一直存在誤解。很長時間對框架的理解，一直存在于如何組織腳本，如何寫出高質量的腳本這個層次，整個框架好像就是針對腳本這個層面。其實這個理解很局限也很片面。一個好的測試框架，應該包含整個測試靜止的各個方面，以及對各個環節的規范、管理等等，所以腳本只是框架當中的一個環節，不應把腳本看的很重(當然不是說不主要)。腳本是用工具寫的，工具永遠是工具，整個測試過程起關鍵作用的還是人。
一個合理的框架應該包含流程、團隊、技術這三個基礎要素，再用管理把這三個要素諧和起來。
如圖，這三個要素是相輔相成互相依賴。
流程
首先談一下流程。這個要素，在整個測試靜止周期中是用時最長的一個，大部分的測試靜止都是在流程中進行。一個好的流程能夠節約成本，延出息度，提高測試質量。設計流程，不能為了自動化而自動化，要結合項目狀態、目前測試部門開展狀態來計劃功能自動化測試流程。
流程的計劃應該掩飾自動化測試分析，業務流程的分析與組織，腳本的設計與開發。
拿到項目責任書后，首先要進行的就是自動化測試分析。這時要結合手上有的測試資源，如待測系統，測試需求，測試用例庫，功能說明等等，對系統來個綜合分析。這些作為分析階段的輸入。有輸入就要有輸入，也就是分析效果了。分析過程就是對業務的分析，對怎么計劃腳本的分析。對業務的分析最終要得出本次或本論測試需要測試范圍、內容，以及測試內容對需求的掩飾狀態等內容，最終形成業務跟蹤表，作為輸入。對于計劃腳本，就是要肯定哪些功能能夠做自動化，哪些不能做;哪些功能需要單獨作為一個腳本來寫，哪些功能相宜合并成一個腳本來寫;參數的定義，主要是針對多個腳本都要用到的變量給出定義;其他能夠定義一些腳本的相關信息。最終也要形成腳本分析跟蹤表，作為分析階段的輸入，納入測試資產統一管理。有了這些作為基礎，能夠最大限度保證后續責任在可控范圍內進行。
做完分析責任，就能夠繼續業務的組織和腳本的開發責任了，這兩個能夠并行開展。把分析階段的輸入做為輸入，有序開展后續靜止。
對于業務的分析組織，主要加入者是熟悉系統業務的人員�，F在的應用系統越來越復雜，如果沒有業務人員加入進來恐怕很難把測試做到位。這個過程就是由熟悉業務的人員來組織需要測試內容。包含測試功能點，業務邏輯，業務范圍等等。同時針對特殊業務規則，數據規則提出相應的需求，諧和其他資源滿足特殊需求。這個過程也是組織測試案例、測試數據的過程，為測試執行做準備責任。這個過程的輸入就是測試內容的跟蹤表了。
與業務并行開展的就是腳本的設計與開發了。它不會受限與測試流程、測試邏輯的限制，完全能夠遵循分析過程的跟蹤表進行腳本的開發。這個過程腳本的設計和開發是兩個獨立的過程，設計是以文檔的方式展現腳本，包含腳本信息、輸入÷輸入參數、調用說明、腳本流程圖等內容，這樣做能夠讓團隊成員之間很好的協作，避免出現紊亂、失控的狀態。而且腳本的設計人員不用推敲具體的業務邏輯，只要遵循既定規則把劃分好的腳本設計好就完成了責任。然后腳本的開發人員嚴肅遵循設計文檔進行開發，最終形成腳本集，供其他環節調用。
以上各個靜止都會有管理或是QA加入，進行靜止的評審，確保各個環節都是遵循規范進行的，保證自動化實施過程是在可控范圍內進行的靜止，避免某個環節的隨意性。
技術
技術角度，主要是選擇采用什么樣的工具，腳本開發工具，配置管理工具。還有就是要制定針對在工具的應用過程中要遵循的規范，如何讓工具之間配合，發揮最大的作用。
功能自動化測試用的最多的莫過于QTP了，由于它的簡單、易用，隨意上手很是受大家的追捧。當然還有它能夠破解，這也為它廣泛推廣打下很好的基礎。
技術環節需要對腳本的開發做出清楚的說明。底層函數的定義，功能函數的開發，函數庫的計劃，參數、腳本的開發規范等這些都要形成文檔。最后腳本的運行也是一個很關鍵的環節，包含運行的穩定性，效率，日志，失敗的解決這些都是需要解決的問題。如果條件許可能夠自己開發工具來解決這些問題，但相應帶來的成本也是非常高的。這樣做的公司都是有單獨的團隊來掩護測試工具這一塊的，所以在人力、技術資源很有限的狀態下不要隨意嘗試這種方式。同行用的最多的好像就是用Excel來組織，然后通過讀取Excel來控制腳本的運行，這種方式簡單，易行，但對于過于復雜的系統不適用。還有一種方式就是用QTP+QC的方式，QC有單獨的模塊來管理，組織這些內容。并且會自動記錄執行日志，效果文件等。這種方式是最方便，成本最低的一種方式，掩護起來也很隨意，而且沒有不兼容的狀態，很隨意見到效果。如果公司不希圖組建專門的測試開發團隊，用這個是最有效的一種方式。缺點是在組織數據時的靈活性欠佳。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
