你所理解的軟件測試到底是什么？(2)

　　每個流程絕對獨立，不能夠通過條件去判斷數據類型而向不同分支延伸，也就是不允許存在樹狀流程設計，只允許平行的流程設計;

　　有幾個測試組分別演示了自己的selenium自動化設計方法，其中有兩個讓我印象非常深刻。一個是把數據和操作拼接為一個字符串作為一個xml節點或者csv單元格來存儲，測試執行的時候通過外層的方法去加載命令執行;另一個組是把每個頁面組件封裝成一個VO，內含一組get和set的方法，將操作封裝為一系列的BO，測試用例中直接引用這一堆的VO和BO去組裝成測試腳本。這些很與眾不同的方法都是來自于他們各自的實踐和總結，不能說不好或者不實用，但是我想說的是：技術手段雖好，但是設計方法遺漏了最根本的效益因子和對一些基本原則的遵守。很明顯，第一個雖然號稱在模仿RF，但是錯誤的理解了關鍵字驅動是怎么回事，綁定了測試數據和操作，不夠靈活：維護不便、重構不便、轉平臺不便。而第二個則明顯復雜化了自動化測試腳本設計，要知道測試人員在做測試，而并非去寫一套很高明的、需要交付給客戶的代碼。這么做耗費的人力成本是很高的，被測應用邏輯的變更造成的維護成本翻倍，而且這種做法讓腳本的可讀性嚴重降低。

　　我原以為那些粗淺的設計原則都是公理一樣被所有人所遵從，但是這次會議真的讓我見識到了人的思維意識差別之大。恕我不厚道的猜想，大家并非不知道這些簡單的規則，只不過這些行為都是基于主動創新為出發點的，所以忘記了一些基本的、必須遵守的原則。前面說了，測試自動化不是創新活動，而且可以說測試工作不需要以創新活動來保持活力，所以還是要強調一下，請不要為了一些沒有意義的目標去違背一些簡單的原則。

　　重復建設——測試部門的災難

　　無論團隊組建是還是人員發展，無論是自動化體系建設還是得到自動化測試收益，都不是一朝一夕的事情，這些行為一旦開始以進度為主，急于得到回報的時候，質量問題就會在不遠的前方等待著你。由此開始的問題暴露和新的快速修復就會導致反反復復的重復建設、重復開發，讓人身心俱疲并且找不到問題所在：到底是工具不好還是人員素質不夠高呢?顯然都不是!我們測試部門方方面面的發展都是點滴積累的過程，無論是技術積累還是管理方法的摸索，都要切中當前的測試需求。測試經理和所有的工程師都要記得時刻提醒自己：我們是做軟件測試的，我們應該為軟件質量買單，這些先進的技術如果無法一時半會得以應用，那么我們要先以測試為主，這華麗的技術現階段能用多少就用多少，不能一蹴而就。

　　——摘自《軟件測試自動化的探索與管理》2009

　　這個問題最初體現在我們的QTP自動化測試建設上，花兩年時間逐步完善自動化的系統，他們的測試腳本質量遠遠高過那些為了完成指標在3個月內匆匆趕工做出來的系統。無論測試腳本可用性、正常情況下的運行通過率，還是測試腳本本身的可信程度，都有著質的差別。不過，這都是過去的事情了，測試部門為了迎合規劃部門對整個公司的持續集成體系的規劃，要丟棄歷時近5年建設而成的QTP自動化測試平臺體系、測試框架和近2萬回歸測試腳本，全部從頭開始重新建設。這種行為太野蠻了，實在是荒誕不經，我本無意在你們玩過家家玩得正High的時候說這些，但是我覺得你們慣于玩一刀切，你們已經嚴重傷害到我個人的利益了。即便我無力改變你們的想法、做法，但我還是得說兩句：

　　應該搞清楚哪些系統必須要參與持續集成，而哪些不需要，哪些不能夠，如果一定要堅持認為整齊劃一，那我們就只能選擇沉默不語、被動配合，坐等你的決策帶領我們走向失敗;

　　必須要參與持續集成的系統可以優先安排開源自動化的轉平臺;

　　無需持續集成的系統，不要強制，讓開發和測試分析、協商如何選擇后續的做法;

　　不能夠參與持續集成或者說做持續集成沒有價值的系統，絕對不要強制他們去參與這項活動，同時自動化測試腳本可以根據現有的自動化水平去選擇是要保持原有的建設成果還是推翻重來;

　　通過一些網上的材料可以知道，五年前，我們基本和百度、騰訊測試部門在同一水平線上，甚至有些方面比他們建設得要好一些;而現在他們站在QCon的演講臺上為同行布道，我們只能在臺下唏噓自己的原地轉圈圈。這看起來是每一個測試人員的責任——但是測試經理們你們認真反省過沒有：每次接受一條新的政令，你們是否站在測試目標達成的角度上去考慮過，自己將要做的是不是有益于測試部門的長期建設呢?你們如果沒有勇氣抵制不正當作風和來自其他部門的錯誤決策，你們有什么資格來帶領大家，有什么資格給大家宣導SCC理念!眼下的那點靠“講故事”達成的KPI，靠“講故事”贏得的差強人意的考核結果對你個人、對你的下屬、對你的分組、對你的測試部門能有什么長遠的價值?

　　順便提一下，不要反復的請顧問或者咨詢師，別人再強，知識都是自己的;再說一個人再強，也無法摸清整個公司所有部門的情況，他們所能做的事情也非常有限。所以靠外力來推動內部因不受認可而阻滯的政令不會產生多大影響的。如果請顧問只是為了借一兩個強人之口來推行自己無法推行的政策，那么最終面臨的還是失敗，過幾年如果諸位還記得今天看到的，可以回過頭來數一數自己被顧問了多少次。

　　質量意識——測試工作的靈魂

　　前幾天微薄上爭論測試到底是以技術為主還是以工具為主，是以人為主還是以流程為主;其實我認為測試工作應該以達成需求為根本目標，而達成需求靠人，人要擁有做好測試工作的意識，然后才是通過掌握必須的技術或者工具來完成具體的工作。做好測試工作的意識是什么?意識就是無論做什么事情都要本著以達成測試需求為根本目標，無論采用什么手段都是以做好測試工作為核心目標。

　　我們常常面臨的問題是，動輒被要求按照某種規范和流程統一去做某件事情。至于為什么要按照這種做法去做一般是問不得的，因為一旦知道背后哪些真實的目的，很多人都要被氣得肝膽俱裂、七竅生煙!所以我曾對同事戲言：有些事情不要理解太透徹，否則你就不想做了。

　　就拿測試支持組來說，我們需要知道測試平臺的使用規范和框架遠景設計目標，問其索要;可能他們剛開始還不明白規范應該界定哪些內容去管理，就會產生不知出于什么目的的規范來。我想知道Jenkins上如何規范能便于管理測試日志、測試報告，如何能夠提供集群的報表，如何能提供最便捷的測試分析方法讓測試人員去了解構建結果;如何定義將來運行的串、并行調度模式，而由此決定我們私有的框架下如何選擇工具的使用方法。但是得到的答復是：不允許使用TestNG，只能用JUnit;不允許修改selenium的核心Jar包去加入用戶自定義方法;不允許引入平臺上不存在的第三方工具包……在我質疑之下，便得出了真正的原因：要支持測試支持組的工作!可是測試支持的一個兄弟說：“測試支持組，是應該最大可能的支持測試工作、滿足測試的需求，而不是成為測試工作的瓶頸!”看到他同我一樣很郁悶，我竟有十分開心的感覺：并不只是因為有個人能夠認同我的看法，也是因為還有人在堅持，還有人在為了測試工作，而不是了形式上的建設而隨波逐流。

原文轉自：http://www.kjueaiud.com