孔子說“人無遠(yuǎn)慮，必有近憂”，用在軟件測試上，是什么意思呢？可以這樣理解，如果我們不從發(fā)生問題的根源上解決問題，認(rèn)為測試僅僅是找Bug，千方百計(jì)找Bug，覺得Bug總是找不完，意識中就會陷入“永無天日”的狀態(tài)。然而，有小部分測試人員還真希望軟件存在多一些問題（唯恐天下不亂），這樣可以多提交Bug，認(rèn)為業(yè)績比沒有提交多少Bug肯定要好。無獨(dú)有偶，有小部分開發(fā)人員也把自己犯下的程序錯(cuò)誤視為理所當(dāng)然，甚至還有個(gè)別人會戲虐地說“軟件如果沒有Bug的話，測試人員不就失業(yè)了”。這好像在唱一出雙簧戲。軟件開發(fā)的整個(gè)過程中，Bug是理所當(dāng)然要存在的，是這樣嗎？軟件工程中軟件危機(jī)的根源問題只能通過找到Bug的手段來控制嗎？
實(shí)際上，我們都很清楚，任何一個(gè)Bug的產(chǎn)生都是有來源的，來源包括需求的設(shè)計(jì)、軟件的設(shè)計(jì)（含代碼的編寫）等。相對于前端的設(shè)計(jì)，測試是事后的驗(yàn)證，是一種“堵”漏洞的措施。然而，在實(shí)際工作中，時(shí)間與成本并不允許我們?nèi)ザ伦∷械腂ug。日本質(zhì)量大師田口玄一說得好“質(zhì)量是設(shè)計(jì)出來的，而不是測試出來的”。如果我們能變被動(dòng)為主動(dòng)，在設(shè)計(jì)之前，就做好設(shè)計(jì)的防患措施，為設(shè)計(jì)高質(zhì)量的軟件打下堅(jiān)實(shí)的基礎(chǔ)，這便是本節(jié)打算向讀者介紹的測試的第三重境界：挑戰(zhàn)零缺陷。
缺陷的防與堵
幾乎在每次面試測試工程師時(shí)，筆者都會問一個(gè)這樣的問題：“你所負(fù)責(zé)測試過的模塊，是否存在漏測的情況”，幾乎每個(gè)應(yīng)聘者都回答說“有”。面對復(fù)雜的軟件，紛繁復(fù)雜的運(yùn)行環(huán)境，在有限時(shí)間內(nèi)進(jìn)行的測試活動(dòng)，做到真正的零Bug是 不可能的，也是不現(xiàn)實(shí)的。但這些都不是理由，所有的測試活動(dòng)是有目的的商業(yè)活動(dòng)，每個(gè)公司有自己測試通過的一套標(biāo)準(zhǔn)或原則。雖然漏測不可避免，但并不是說 漏測是一種正常現(xiàn)象或應(yīng)該的現(xiàn)象，出現(xiàn)的漏測問題如果超出公司所能接受的原則，就屬于不正常的現(xiàn)象，很有必要進(jìn)行漏測分析。進(jìn)行漏測分析活動(dòng)（需要特別注 意的是它絕不是對漏測人員的批斗會），它的主要目的是通過分析過去的教訓(xùn)，找出問題的根源，分析測試中哪個(gè)環(huán)節(jié)工作存在缺失，以拿出規(guī)避的可操作的措施出 來。
測試人員進(jìn)行漏測分析時(shí)，免不了對問題進(jìn)行追本溯源。軟件是由開發(fā)人員設(shè)計(jì)出來的，所以漏測分析活動(dòng)少不了開發(fā)人員在場，甚至有時(shí)還會涉及需求設(shè)計(jì)人員。關(guān)于漏測分析的追本溯源，這里有一個(gè)關(guān)于開發(fā)與測試之間的工作關(guān)系像修筑堤壩一樣的有趣比喻，如圖2？11所示。開發(fā)人員設(shè)計(jì)軟件就像修筑一道堤壩，如果堤壩在結(jié)構(gòu)上存在問題，當(dāng)洪水沖擊時(shí)，可能不只是局部的泄漏，而是直接的決堤，猶如軟件的崩潰。高高的堤壩，難免會存在漏水的小洞，或滲水的小孔，就好像軟件中存在的小Bug。越是在堤壩基部的漏水或滲水問題越難發(fā)現(xiàn)，解決的代價(jià)也越大。
在設(shè)計(jì)時(shí)要把結(jié)構(gòu)建牢，不存在漏洞當(dāng)然更好，這是一種防范。如果超越防范界線，把設(shè)計(jì)帶出的大洞小孔遺留到測試環(huán)節(jié)，它只好拿著各種放大鏡（使用各種方法）來檢測，以網(wǎng)羅各種深深淺淺、大大小小的問題，最后通過“打補(bǔ)丁”的方式，堵住堤壩上的“百孔千瘡”。
在對缺陷的防與堵方面，測試是發(fā)現(xiàn)問題的中間角色，告訴開發(fā)人員哪里漏水或滲水了。防與堵的工作是由建堤者來做的。當(dāng)然，防是主動(dòng)的，堵是被動(dòng)的，主動(dòng)變?yōu)楸粍?dòng)后，中間經(jīng)歷了資源與時(shí)間的投入，誠然即使是同一個(gè)Bug，它們的代價(jià)也是完全不一樣的。這種堵越在后面，影響越大，代價(jià)也就越大，如表2-6所示（摘自《代碼大全》）是一個(gè)根據(jù)缺陷出現(xiàn)的階段來增加測試成本的例子。
表2-6 根據(jù)缺陷的引入和檢測時(shí)間，修正同一缺陷所需的平均成本
引 入 時(shí) 間 | 需 求 | 體 系 結(jié) 構(gòu) | 建 設(shè) | 系 統(tǒng) 測 試 | 發(fā) 布 之 后 |
需求 | 1 | 3 | 5～10 | 10 | 10～100 |
體系結(jié)構(gòu) | -- | 1 | 10 | 15 | 25～100 |
建設(shè) | -- | -- | 1 | 1 | 10～25 |
如表2-6所示為在需求階段引入的一個(gè)缺陷。如果立即發(fā)現(xiàn)了此問題，修改成本只需要1美元，但如果在系統(tǒng)測試階段發(fā)現(xiàn)它，修改成本就增加了10倍。更為嚴(yán)重的是，如果在版本發(fā)布后用戶端發(fā)現(xiàn)了此問題，則需付出10倍以上甚至是100倍的代價(jià)。缺陷在系統(tǒng)中的時(shí)間越長，解決它的代價(jià)就越大，因?yàn)闀r(shí)間越長，開發(fā)與測試人員修改的成本就越高，還將影響大面積的用戶端升級。
相關(guān)鏈接：
軟件測試的第一重境界：圍著Bug轉(zhuǎn)
軟件測試的第二重境界：站在Bug之上