成熟的軟體測試是確保軟體質量的一種重要手段，自動化測試技術的出現，對於提高測試單位績效比起了重要作用，被廣泛應用於回歸測試中，但是由於被測試系統的不確定性和複雜性，使得軟體自動化測試變得異常困難。本文基於商業工具結合實際專案，分析自動化測試實施期間出現的各種問題，以提高大家對自動化測試專案的真正認識與理解。
現在自動化測試工具很多，商業的或者開源的，以物件識別為基礎的或者以語言特性為基礎的等等。在挑選的時候，首先我們要明確被操作軟體的範疇和特性，可預知風險，培訓潛在成本及是否具備被虛擬化等一系列問題，這些問題可製成標準檢查列表，以便確定乙個解決乙個。在本次自動化測試實施中，首先可知的是被測試軟體屬於行業金融軟體，使用borland c++builder語言開發，測試範疇鎖定在軟體前台需配對後台資料驗證，前台由redhat linux服務端、自研發中介軟體和oracle資料庫支撐。一般來說，這種軟體應用架構比較清晰，但是gui層使用了大量的非標準第三方控制項，有可能會導致部分物件無法捕獲造成實施困難，所以在進入真正的實施前作充分、快速的實驗性評估是非常重要的。
職業化的自動化測試團隊，應當非常熟悉當前主流的商業或者開源測試工具，這種團隊的定義是：技術讓位與成本控制，快速實施且能快速遞交，精確控制每12週為一週期，專案延時誤差小於2天。考慮到指令碼會被移交給其他團隊執行，所以我們選擇了目前在國內應用範圍比較廣、相關技術資料比較豐富的hp winrunner和hp quicktestpro。第乙個被評估的是quicktestpro 9.5版本不帶任何外掛程式，結果大量的gui物件無法**捉，不能捕捉意味著不能被操作，所以團隊快速轉換到winrunner 9.2版本不帶任何外掛程式，實驗結果是基本可以正確識別和捕獲我們所要操作的gui物件，滿足了對工具的需求。其實quicktestpro 9.5版本帶delphi外掛程式也可大大增加捕獲率，但是使用外掛程式違反了團隊定義的工具應用管理規範，也不符合「有物件即可操作」的強硬程式設計作風。
在工具定義後，需要立刻選擇2組典型業務進行試驗性測試，這時需要業務專家和指令碼專家一起工作。帶gui介面軟體測試用例的設計核心問題是：需要精確區分正常測試用例和異常測試用例，按照先異常後正常的實際執行方式，組織最終的測試資料存放關係，一般合適的比例控制在異常75%—正常25%範圍內。指令碼專家需要快速處理物件識別庫，如果涉及到重定義則需要在指定檔案中加以註明，因為這部分工作可被復用到後續的專案實施中，避免造**力成本重複投入。通常實驗性階段主要產生的問題是：
● 該階段是否會產生指令碼框架?答案是否定的，首先自動化測試不一定要有框架，框架產生的唯一目的就是犧牲一部分指令碼效能，而對測試資料進行高效、有序的管理。不過在試驗性階段可以考慮這個問題，如果框架是個平台，那麼我們可以在這個平台上放置一些我們需要的單位指令碼效能監視器或者其他一些東西。由於 winrunner的描述性程式設計機能不夠，那麼在後續正常專案實施中，框架更多被定位於為可測量、可伸縮、可動態、可智慧型解析測試資料的執行管理。
● 該階段是否需要考慮測試資料存放問題?答案是否定的，沒有必要浪費太多的時間在這種地方，乙個文字檔案或者乾脆不要檔案的資料存放形式都可以，關鍵是成本。
該階段對於人員的要求是什麼?答案是人員需要精幹，乙個業務專家，乙個指令碼專家，乙個統計專家足夠，自動化測試實施非常注重績效比，績效比不夠根本沒必要執行後續的專案，你必須通過實驗性測試得出乙個準確的結論，就是重複執行多少次指令碼，總績效才可以由負轉正。
● 該階段是否需要考慮環境的問題?答案是的，在這之前就應該安裝好虛擬系統了，如果指令碼專家的一邊開著即時通訊工具一邊錄製指令碼，我們認為這是非常不專業的。系統環境的清潔程度如同醫院的手術室，需要提前對各種必須的軟體(例如防毒軟體，網管軟體等)做好適應性選擇，有干擾的，或者影響系統機能的堅決解除安裝掉。
● 該階段的硬體是怎麼規劃的?前端的測試主機需要有同時承受開2—3個虛擬系統的準備，不能產生明顯的切換和操作停頓甚至系統假死。雖然 32位的 windows xp系統不支援4g物理記憶體，但是經驗告訴我們記憶體容量多多益善，至於cpu和顯示卡處於正常水平即可。後端使用的硬體需要穩定，因為不是效能測試所以不作太多要求，一切為了成本。
● 該階段的管理模式和輸出是什麼?答案是沒有太複雜的管理模式，實驗性評估一般都會在1週內被關閉，唯一重要的就是實施評估報告，報告內容大致包含：週期定義、工具定型描述、應用軟體描述、系統框架描述、可能採用的框架描述、可能遞交工件描述、可加入業務列表、**指令碼規模、
可實施技術分析、評估人/時分析、**實際人/時分析、評估指令碼價值、**實際指令碼價值、可能遇到的問題警告等，這些條目都必須一一做出詳實而且準確的描述。
實驗性評估結束後，需要確定自動化測試實施專案的時間及週期里程碑，我們採用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元以下，請各位拭目以待。
制定自動化測試實施計畫
自動化測試實施計畫根據不同公司的情況也許很簡單 也許很複雜，簡單到可以是幾個事項，複雜到也許可以自動化測試可行性分析報告。無論怎樣，自動化測試實施計畫應該有乙個清晰的自動化測試目標。為了成功實施自動化測試，您需要對您的自動化測試成功需要達成的條件進行合理的 可測量的定義。滿足這些成功條件，您的自動化...
自動化測試實施的幾個idea
ui檢查 測試的乙個idea 在電子商務 中，為達到較好的使用者體驗，可能頁面上會有大量的ui設計，一堆css ajax效果等，敏捷開發中，ui變動更是帶來了測試的苦惱。對於回歸組catch ui bug，需要有一些策略 1 回歸指令碼中，通過檢查特定css元素 color 等是否存在，可以覆蓋一些...
自動化測試成功的關鍵
來自 ibm 在本文中，我們要討論為什麼進行測試，尤其是自動化測試，是必需的。然後，我們將介紹制定計畫的概念 為什麼制定計畫是如此的重要？在隨後的文章中，我們將分解測試計畫中的不同因素，並且研究如何進行制定計畫的過程才能最大程度地增加成功的機會。現代客戶端 伺服器應用程式是非常複雜的，因此測試也就成...