軟件測試的核心價(jià)值是什么？

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

　　測試的價(jià)值

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

　　很多人都說(shuō)質(zhì)量不是測出來(lái)的，這句話(huà)沒(méi)錯。不過(guò)，測試存在的意義其實(shí)有兩點(diǎn)，創(chuàng )造價(jià)值和守護價(jià)值。質(zhì)量要靠測試者來(lái)守護，而不是創(chuàng )造出來(lái)。“守護價(jià)值”存在于傳統測試工作中;而“創(chuàng )造價(jià)值”，正是我們現在正在探索的。

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

　　朱少民老師：

　　守護價(jià)值和創(chuàng )造價(jià)值說(shuō)得好!創(chuàng )造價(jià)值體現在基于客戶(hù)的立場(chǎng)提出積極的質(zhì)量反饋意見(jiàn)，以及對缺陷的分類(lèi)、分析，總結出缺陷模式，回饋到前期過(guò)程，預防缺陷。

　　原草莫莫：

　　認同。我們現在搞的故障模式測試就是這樣的一個(gè)實(shí)踐。測試不依賴(lài)于開(kāi)發(fā)的上游輸入，通過(guò)反向驗證推動(dòng)產(chǎn)品質(zhì)量改進(jìn)。測試在產(chǎn)品也愈來(lái)愈有話(huà)語(yǔ)權。

　　還有就是，當質(zhì)量標準往往很難定義的時(shí)候，這個(gè)時(shí)候往往測試標準就成了產(chǎn)品潛在的質(zhì)量標準。通過(guò)測試對產(chǎn)品質(zhì)量作出詮釋?zhuān)@實(shí)際上也是一個(gè)引領(lǐng)開(kāi)發(fā)、創(chuàng )造價(jià)值的過(guò)程。當然前提是測試對質(zhì)量標準有足夠的理解。

　　Ang-Ani：

　　測試當然創(chuàng )造價(jià)值。如在V model 中所謂的靜態(tài)測試，review用戶(hù)需求，及早發(fā)現需求中的defect，就是創(chuàng )造價(jià)值。如在敏捷測試中，測試結果反饋到下一個(gè)iteration,也是創(chuàng )造價(jià)值。再如測試驅動(dòng)開(kāi)發(fā)中，測試主導著(zhù)開(kāi)發(fā)過(guò)程，當然創(chuàng )造價(jià)值。

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

　　梅萬(wàn)龍：

　　"質(zhì)量不是測出來(lái)的"——質(zhì)量主要是靠設計的，有些產(chǎn)品還是得靠測試去發(fā)現，這也可以說(shuō)質(zhì)量是測出來(lái)的，而通過(guò)設計分析預防，測試維度分析預防成本更低，我們更樂(lè )于說(shuō)，來(lái)通過(guò)預防來(lái)保證質(zhì)量，而不是傻呼呼的都靠去測。

　　"質(zhì)量要靠測試者來(lái)守護"——質(zhì)量是靠整個(gè)團隊來(lái)守護，測試只是其中比較大的"發(fā)動(dòng)機"。產(chǎn)品有比同行更好的質(zhì)量，不就是要探索的價(jià)值嗎?否則，不能從崗位角度看價(jià)值，得從人的職責和能力角度找價(jià)值了。

　　Aullyxiao：

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

　　陳尚義：

　　質(zhì)量不是測出來(lái)的，這句話(huà)對傳統產(chǎn)品是無(wú)可挑剔的正確，我見(jiàn)過(guò)紡織廠(chǎng)的質(zhì)量檢測人員，他們發(fā)現了錯誤就不能改，質(zhì)量檢測員當然不能提高質(zhì)量。但對軟件產(chǎn)品情形就不太一樣，測試發(fā)現了問(wèn)題馬上就得到改正，這就提高了質(zhì)量。另外，軟件測試涵蓋的范圍很廣，測試還可以建立對產(chǎn)品質(zhì)量的信心。

　　讓測試飛起來(lái)：

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

　　Frank-Lin：

　　分析用戶(hù)及其習慣，從用戶(hù)角度進(jìn)行測試和評估系統，從而，測試不僅僅是守護價(jià)值，推動(dòng)了價(jià)值的創(chuàng )造。

　　重構之惑

　　蛙蛙王子在微博中向大家提問(wèn)：

　　看到代碼中的壞味道，做到立刻重構，感覺(jué)太難了。書(shū)上說(shuō)一個(gè)敏捷開(kāi)發(fā)的人，從來(lái)不說(shuō)稍后再重構，稍后等于永遠不，他們不會(huì )看著(zhù)軟件走向腐化。認同是非常認同，實(shí)際中做的話(huà)，感覺(jué)哪兒都需要重構，坑太大了，而且還得先補測試，大家怎么來(lái)按部就班重構沒(méi)測試的老系統的?

　　樂(lè )淘網(wǎng)丁學(xué)：

　　我一般是不會(huì )要求大家去做重構，但是會(huì )要求遵守童子軍規則：永遠保持離開(kāi)時(shí)的露營(yíng)地比你發(fā)現它時(shí)更整潔。

　　軟軟的胖糖：

　　如果是一個(gè)新系統，大家按照這個(gè)原則去做就不會(huì )有這個(gè)問(wèn)題了。當然如果個(gè)別人做，坑太大了那也是沒(méi)辦法的事情。

　　橫刀天笑：

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

　　wolvever：

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

　　飛林沙:

　　我覺(jué)得更現實(shí)的做法是當出現新需求時(shí)，如果原有代碼無(wú)法適應需求，那么則為了適應這個(gè)需求重構。

　　TW張逸：

　　我認為重構必須把握幾個(gè)原則：

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

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

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

　　4、重構應隨時(shí)進(jìn)行;

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

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