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

　　細細算起來，在部落格里面前前后后寫了約10萬字關于測試或者自動化方面的看法，雖然看法未必成熟，但是回頭看看都還挺有意思的。這一坨坨啰嗦的文字倒是記錄了一個測試工程師的成長歷程，我不想再拿新的觀點和說法來博取諸君眼球，下面只簡單摘抄一些以前寫過的內容，補充點例子進去，再次強調并且與大家分享一下我對我測試工作的看法。

　　質量效益來自管理

　　質量大師約瑟夫·朱蘭說過：80%的缺陷來自管理層的決策失誤而并非工作技巧問題，筆者認為這種觀點對我們所關注的軟件質量來說也是一樣的，所以管理層的觀念和做法不但會影響到我們測試的ROI，甚至更可能會從根本上決定我們的行為是否能夠獲得成功。

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

　　一個浮夸的、作風不踏實的主管，無論如何都不會把他的團隊建設的很好。這種人擅長的工作是：事前想好退路，做好免責聲明，而并不去仔細調研分析工作本身。就像你要幫助他的團隊引進一種新的技術去解決他們工作中的某些不足，他會不痛不癢的寒暄……繞了半天他會“委婉地”告訴你：做不好就是你們給的方案不給力。

　　我們有很多測試經理都是做技術出身的，之前做開發也好、測試也罷，自身的水平絕對不落后與大多數同事。但是他們屁股坐到分組經理的位置之后考慮的就只是眼前的KPI和考核結果，根本就不考慮從長遠來看，培養一個能站在行業高度看問題的技術仔或者說測試架構師能對自己的分組乃至整個部門有多大作用!那你說經理竟然不會比小弟們更加高瞻遠矚?那是因為所處的位置不同，關注點也就變了：之前自己做測試的時候是關注如何測試快速有效;而現在卻關注如何做讓大家都能不犯大錯，甚至連自己之前推崇的技術、方法都被遺棄了。簡而言之就是從關心技術變成了關心政治，而且凡事向上匯報的時候總要加個渲染的效果進去——在我們這被通俗的叫做：說故事。是不是只有測試經理是這樣的呢?當然不是，這是大環境使然哪，那測試經理們是不是一定都要跟著學呢?咱測試部門是紐帶部門，難道都不能改改?!建議找一些信仰堅定、不喜歡隨波逐流的人來帶隊伍吧。

　　測試模式之拿來主義

　　筆者發現有很多同行、同事喜歡照搬別人的“先進經驗”，比較信奉Microsoft、Google或者Facebook的經驗和理論，總喜歡討論“別人這么做都怎么樣了，我們這么做也應該會怎么樣”之類的事情，基本把自己公司實際情況拋在一邊。例如，有人說Microsoft開發測試的比例是1：1甚至1：2應該是最合理的，是重視測試的真正體現;有人說Google在開發測試比例1：15的情況下能夠完成自動化測試對敏捷開發的支持，說明人家的測試技術才真正是一流的;也有人說我們要引進Microsoft的測試理念、Google的測試技術，改一改我們的規范制度，也嘗試一下別人的方法……等等，諸如此類。

　　大家想想，在說這些話的時候之前有沒有理清楚自己測試的產品是做什么的，與其他產品有什么不同呢?稍微動點腦子就知道，有些公司是做產品的，有些是做人力外包的，有的是做運營服務的;有些是電信行業，有些是金融行業，有些是互聯網、電子商務什么的;有些是做瀑布型開發的，有些是做敏捷開發的……不能一概而論。雖然可能這些不同類型的公司所做的事情有交集，但是要學別人做事的方法先要搞清楚別人和你做的是不是一件事情。

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

　　舉個例子：我們的一些保險核心業務系統，傳統的J2EE模式，業務邏輯描述大部分都在DB層，Java的Service層基本什么邏輯都沒有;在公司統一的要求下，強推持續集成。大家知道這種系統package代碼動輒上百萬行，單元測試在這方面的投入是非常高的，尤其在系統已經建設已經完成的情況下，做這件事情需要較多的工作量去重構代碼，同時還伴隨著較高的業務風險。那么在DB層的單元測試方案沒有確定的時候是不是要學別人也去做持續集成呢?規范定義的Java代碼覆蓋率即便達到100%又能有什么意義?徒增人力浪費而得不到一點質量提升!這種情況下我建議開發和測試一起坐下來討論一下：大家合力探索一條快速可行的單元測試的方法，如果實在得不出成本效益平衡的辦法，就放棄底層測試，從業務邏輯分支上去做詳盡的分析，將UI層的測試作為主要的測試手段。做不了敏捷測試會死人么?不會，只以敏捷為榮的人可恥!做不了持續集成會死人么?不會，只以持續集成為榮的人可恥!做了公司的特例很丟人么?不會，而且我覺得挺光榮，至少你做的事情是切合實際的，有效果的——跟風玩過家家沒啥好處!

　　測試不依賴創新活動

　　創新是什么?創新是在日常工作中不斷冥思苦想如何比現有方法更好地去解決問題，以達到提高工作效率乃至生產力的效果，它的真諦并不是靈感突發帶來的奇思妙想。測試自動化只是測試的一個發展階段，而并不是創新，只是在自動化實施過程中可能會有創新行為而已，并且創新行為必須要有一些基本的準則。

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

　　今天下午被拉去參加部門例會，一個讓我哭笑不得而又讓我深思的會議，感覺很不好。在我看來，UI自動化測試設計至少要遵守如下準則：

　　框架設計要做到能夠有效降低測試開發的時間和技術成本，而且支持的要足夠靈活，不做過多無畏的封裝，不能夠成為系統測試的使用需求瓶頸;

　　測試操作與測試數據絕對分離，測試組件屬性和測試操作盡可能分離以達到關鍵字驅動;

　　以最少的代碼維護量換取最大的功用，基于業務組件的一致性(UI)來判斷是否進行復用;

　　盡可能少的數據維護量，提高數據靈活性，降低對測試數據健康度的依賴：拋開運行速度，基礎數據足夠的情況下如果一天需要跑800次，那么也必須得能夠支持，也就是說要有一套自動化數據構造的方法來支持自動化業務測試的運行;

　　要做到使用盡可能少的數據覆蓋盡可能多的場景或流程，降低整體測試的消耗與對數據的依賴性;

　　徹底mock掉對關聯系統的依賴，即使是同一個開發組的系統也不可以;

　　測試業務邏輯必須與框架和工具自身的邏輯完全剝離，不允許存在混雜;

原文轉自：http://www.anti-gravitydesign.com