可實施技術分析、評估人/時分析、預測實際人/時分析、評估腳本價值、預測實際腳本價值、可能遇到的問題警告等，這些條目都必須一一做出詳實而且準確的描述。
實驗性評估結束后，需要確定自動化測試實施項目的時間及周期里程碑，我們采用12周為一個周期里程碑，快速發布快速遞交的方式以確保整個測試項目的實施成功。在開始的1周內，管理專家需要快速定義對象控制表、項目跟蹤表、需求跟蹤表、周/發布項目進度、日/問題跟蹤表、配置管理須知，腳本專家需要快速定義代碼規范、腳本設計維護手冊、數據作用說明及填寫規范，環境專家需要快速定義虛擬環境配置手冊、維護與復制手冊，培訓專家需要制定實施階段課程培訓體系等，專家都是角色可復用，工作都是實打實的，需要認真對待，缺一不可。
我們通常將項目在快要接近380個可操作對象或者腳本代碼接近25000行的時候稱之為一個“混亂點”，之所以稱為“混亂點”完全是這種項目執行過程中的必然現象，如同飛機速度超過音速時產生的音障一樣，正確的對待和處理有助于后續項目實施的健康成長，否則后果不堪設想。
● 經典問題一、文檔混亂了。這里的文檔混亂并非指文檔丟失、殘缺或者缺少維護這些低級錯誤，事實上這里的文檔混亂是多個文檔內產生了部分內容相同的冗余數據，且這些冗余數據在可控制范圍內�！叭哂嗉磻卸琛�，所以對應的解決方案就是將所有文檔轉交EPG團隊，由專人看管做日終處理，只要不增加本團隊的成本我們是非常樂于這么做的。
● 經典問題二、培訓熱度過高。為了確保腳本周遞交轉移速度，我們在每周末需要對接應團隊做一定培訓，很多人(非合作團隊)都想增加自己在這方面的知識，所以原來的2小時培訓時間被延長到4小時，原來一場25人小團隊培訓被擴展為二場各180人的培訓，很累。直接造成的后果就是很多人要內部轉崗來我們團隊，這也違背了“簡單既是美”。
● 經典問題三、腳本的增加突出了性能的缺失。一旦對象突破380 個(不包含描述性對象)，腳本突破25000行(不包含注釋及空行)，不優化，那么在一臺機器上的綜合運行時間超過了4個小時，所以對代碼優化的工作在后續幾周的實施中急待解決。對于腳本性能調優，需要綜合考慮語言特性、數據結構、外調和對象識別處理，這里需要對TestPackage – TestSuite – TestCase的組合模式進行事務級的時間分析，精確到毫秒。調優的處理有多種，每個團隊的方法各不一樣，經過綜合處理，現在我們能做到35532行腳本、451個對象、37個虛擬對象，合計78個綜合處理包全部一臺機器上運行，時間可控制在2小時之內。繼續壓縮時間的資源投入大于產出，這不符合成本控制團隊的初衷，所以最終放棄。
● 經典問題四、原來工具的函數有BUG。實際上大規模的代碼運用對測試工具本身也是一種考驗，一切軟件皆有問題，隨著時間的推移會逐漸暴露出來。我們發現了測試工具部分函數的會在某些特定環境下出現問題，所以替換這些函數是非常必要的。替換的方法是，使用第三方開發工具(例如VC)開發出可被腳本直接調用的函數(例如各種動態庫技術)，以替換原自帶問題函數，這樣既增加了整體代碼的穩定性，又提升了團隊的研發能力。例如Winrunner偶爾出現的菜單丟失的問題，都可用自研發函數給予解決。
另外測試工具本身提供的語言也可能存在某些局限性，所以測試團隊具備自我開發能力也關系著項目是否能被順利實施。
● 經典問題五、腳本不動了。實際上這是最讓人討厭的問題，可能涉及的方面非常多，例如系統交互、網絡環境、本機環境、軟件沖突等等，我們總結了一條處理該類型事件的方法，先排除系統本身，排除干擾軟件，再分析比和對卡死位置數據，最后分析腳本本身，例如我們發現部分問題跟字符處理函數有關，這對提高腳本本身的健壯，提出了很高的要求。
項目進行到距離里程碑最后一周，大部分的問題列表需要被提前被關閉，相關遞交工件需要被整理評審，腳本經過驗證被最終集成轉交，這里都需要配置管理來提供良好的控制環境。必須指明的是，日腳本構建和測試是貫穿整個項目周期的，這種做法能使腳本的開發狀態得到頻繁的更新，以及盡早發現設計和集成的缺陷。為了充分利用時間與設備資源，夜晚21點后，腳本的自動執行測試(這里多數指的是系統測試或回歸測試)是一個非常行之有效的方法。一切都順利的話，等到第二天上班時，測試結果就已經在相關人員的郵箱里面了，通過這份報告，你可以知道那些腳本是必須修改的，如果不太清楚還有一份更詳細的截圖列表輔助定位，準確告訴你當時軟件究竟出現了什么現象導致了問題的產生。
最終該項目第一階段在12周且延長6個小時后被準確的關閉，并且通過了嚴格的部門驗收，6人參與到這個項目中，合計2916個有效工作時。經過計算每行代碼價值為1.77元，總的來說還算是成功的，那么接下來第二個階段里面，我們能否將每行代碼價值控制在1元以下，請各位拭目以待。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
