經典問題二、培訓熱度過高。為了確保腳本周遞交轉移速度，我們在每周末需要對接應團隊做一定培訓，很多人(非合作團隊)都想增加自己在這方面的知識，所以原來的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/
