軟件測試的核心價值是什么？

　　Philonis高在微博上發起了軟件測試的價值體現在何處的討論，蛙蛙王子則向大家提問：如何在實際工作中更好的重構?

　　測試的價值

　　Philonis高在微博上表達了對軟件測試價值取向的看法：

　　很多人都說質量不是測出來的，這句話沒錯。不過，測試存在的意義其實有兩點，創造價值和守護價值。質量要靠測試者來守護，而不是創造出來。“守護價值”存在于傳統測試工作中;而“創造價值”，正是我們現在正在探索的。

　　對于測試如何創造價值，或者說測試創造的價值是什么，很多人也有自己的看法。我預設的前提是，靜態測試、需求評審等工作被劃入“守護價值”，也就是將“創造價值”的范圍縮小了，免得有哲學帝說一切工作都是創造價值。

　　朱少民老師：

　　守護價值和創造價值說得好!創造價值體現在基于客戶的立場提出積極的質量反饋意見，以及對缺陷的分類、分析，總結出缺陷模式，回饋到前期過程，預防缺陷。

　　原草莫莫：

　　認同。我們現在搞的故障模式測試就是這樣的一個實踐。測試不依賴于開發的上游輸入，通過反向驗證推動產品質量改進。測試在產品也愈來愈有話語權。

　　還有就是，當質量標準往往很難定義的時候，這個時候往往測試標準就成了產品潛在的質量標準。通過測試對產品質量作出詮釋，這實際上也是一個引領開發、創造價值的過程。當然前提是測試對質量標準有足夠的理解。

　　Ang-Ani：

　　測試當然創造價值。如在V model 中所謂的靜態測試，review用戶需求，及早發現需求中的defect，就是創造價值。如在敏捷測試中，測試結果反饋到下一個iteration,也是創造價值。再如測試驅動開發中，測試主導著開發過程，當然創造價值。

　　質量就是測出來的。但是要知道何時測，測什么，如何測。不能把測試局限于后期的execution。從項目開始的最初，測試作為一個activity就應該存在，測試包括，靜態的review 用戶需求、技術文檔及代碼，動態的單元測試及非功能測試..如果腦海里只有waterfall模式：design code test，那么質量只能靠天收。

　　梅萬龍：

　　"質量不是測出來的"——質量主要是靠設計的，有些產品還是得靠測試去發現，這也可以說質量是測出來的，而通過設計分析預防，測試維度分析預防成本更低，我們更樂于說，來通過預防來保證質量，而不是傻呼呼的都靠去測。

　　"質量要靠測試者來守護"——質量是靠整個團隊來守護，測試只是其中比較大的"發動機"。產品有比同行更好的質量，不就是要探索的價值嗎?否則，不能從崗位角度看價值，得從人的職責和能力角度找價值了。

　　Aullyxiao：

　　這種情況也遇到不少，最后是項目經理確認某需求問題不找需求人員，而是找測試人員了，而測試人員直接找用例庫，可想而知用例庫的重要性和作用。這樣思考之，探索式測試由于在事先沒用例，事后補充的測試記錄比較有限，也是一個限制。

　　陳尚義：

　　質量不是測出來的，這句話對傳統產品是無可挑剔的正確，我見過紡織廠的質量檢測人員，他們發現了錯誤就不能改，質量檢測員當然不能提高質量。但對軟件產品情形就不太一樣，測試發現了問題馬上就得到改正，這就提高了質量。另外，軟件測試涵蓋的范圍很廣，測試還可以建立對產品質量的信心。

　　讓測試飛起來：

　　軟件的歷史是隱藏細節的歷史。從routine到子程序，到procedure，到函數，到類(抽象類、接口)、到SOA，再到今天的云，無一不是將簡單留給用戶或后來的調用者，將細節隱藏。云計算將資源調度、管理、運維、安全保障、應用開發等細節隱藏，用戶按需使用即可，一種到目前為止最高級別的細節隱藏。

　　Frank-Lin：

　　分析用戶及其習慣，從用戶角度進行測試和評估系統，從而，測試不僅僅是守護價值，推動了價值的創造。

　　重構之惑

　　蛙蛙王子在微博中向大家提問：

　　看到代碼中的壞味道，做到立刻重構，感覺太難了。書上說一個敏捷開發的人，從來不說稍后再重構，稍后等于永遠不，他們不會看著軟件走向腐化。認同是非常認同，實際中做的話，感覺哪兒都需要重構，坑太大了，而且還得先補測試，大家怎么來按部就班重構沒測試的老系統的?

　　樂淘網丁學：

　　我一般是不會要求大家去做重構，但是會要求遵守童子軍規則：永遠保持離開時的露營地比你發現它時更整潔。

　　軟軟的胖糖：

　　如果是一個新系統，大家按照這個原則去做就不會有這個問題了。當然如果個別人做，坑太大了那也是沒辦法的事情。

　　橫刀天笑：

　　除非你有一個非常能接受這種做法的團隊，不然這種看見不爽就重構只會死的很慘。當然，如果你要染指某塊代碼，你可以乘機重構～

　　wolvever：

　　我們花了2年重構，邊重構邊開發新功能。所謂高速列車上換輪子，外科手術式重構。不分支，先易后難，影響小依賴少的優先，還要考慮業務發展，保證每次重構部分隨時可以上線。時機很重要，不是看見就改，修改代碼必須立項;不是一次改徹底，一定得容易可控周期短;不是純技術問題，要與業務充分溝通。

　　飛林沙:

　　我覺得更現實的做法是當出現新需求時，如果原有代碼無法適應需求，那么則為了適應這個需求重構。

　　TW張逸：

　　我認為重構必須把握幾個原則：

　　1、重構需要有測試的保護網，每次重構后必須跑一下測試;

　　2、代碼庫的集體所有權;

　　3、最好能有CI，至少保證頻繁提交，避免因為重構引起的大量沖突;

　　4、重構應隨時進行;

　　此外，還有一些比較好的實踐，例如每日的Code Review;嘗試盡量使用工具進行重構。

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