現代軟件工程第十三章【軟件測試】練習與討論

13.5.2 有錯不改

果凍：微軟的產品經過這么多版本的不斷完善，應該是把所有問題都搞定，“止于至善”了吧？

阿超：那也不一定，在非常有名的電子表格軟件Excel中，就有這樣一個Bug：Excel 的日期計算功能認為1900年是一個閏年，這是不對的，但是它愣是一直沒有改正這個錯誤。

眾人：真的？為什么屢教不改呢？

阿超：故事是這樣的，當時這類電子表格軟件的市場領頭羊是Lotus 1-2-3這一款軟件。它的日期計算功能有一個Bug，就是把1900年當作閏年。這類軟件在內部把日期保存為“從1900/1/1到當前日期的天數”這樣的一個整數。Excel作為后來者，要支持Lotus 1-2-3的數據文件格式，這樣才能正確處理別的軟件產生的格式文件。于是，這個Bug就這么延續下來了，每一版本都有人報告，但是都沒有改正。我們可以在Excel中試試看：

在任意格子（Cell）中輸入“=DATE(1900,2,28)”，并且定義這個格子的格式為數字。大家可以看到數值變為59。表明1900/2/28是1900/1/1開始后的第59天。

輸入“=DATE(1900,2,29)”，可以看到60！這是一個不存在的日期！

輸入“=DATE(1900,3,1)”，數值是61，事實上，這應該是60。從這一天開始的所有日期都錯了一天。

果凍：還是可以抓住機遇，促成飛躍，在某一個版本徹底改好，不就是一個數字嘛。

阿超：改這個問題，技術上一點問題都沒有。但是在現實中會出現下列問題：

1）幾乎所有現存文件的日期數據都要減少一天，所有依賴于日期的Excel公式也要做檢查和修改。這在現實生活中是很難辦到的。

2）Excel的日期問題解決了，但是其他軟件還是有這個Bug，數據文件在不同軟件中使用，就會有很頭痛的兼容性問題。

總之，這個問題就這樣一直留下來了。中間也有人想改過，你要注意看Excel的Options設置，就會發現有這樣一個設置——使用1904年開始的日期計算系統（use 1904 date system）（如圖13-9所示），但是一般的用戶誰沒事在這里打一個勾？

圖13-9 Excel的Options設置

計算機程序在處理閏年這個問題上出現過很多bug，請看相關的博客：
http://www.rzrgm.cn/xinz/archive/2011/11/29/2267022.html

13.5.3 侵官之害甚于寒

昔者韓昭候醉而寢，典冠者見君之寒也，故加衣于君之上，覺寢而說，問左右曰：“誰加衣者？”左右對曰：“典冠。”君因兼罪典衣與典冠。其罪典衣，以為失其事也；其罪典冠，以為越其職也。非不惡寒也，以為侵官之害甚于寒。

——《韓非子·二柄第七》

九條：（來找阿超）我最近新建了不少Bug，今天發現它們的狀態都變成了closed，本來要測試的Bug 都變成了關閉狀態，我還用測試么?

阿超：是別的測試人員替你測試了么？

九條：沒有，從記錄上看是果凍修改了這些缺陷，然后把狀態變成resolved，過了兩天他又把狀態變成 closed，但是我還沒有運行驗證測試呢。

他們把果凍找來了。

果凍：我是看著我的Bug 老是沒有關閉，心里很著急，然后昨天我就認真地把所有Bug 都驗證了一遍，確信沒有問題后，就把它們順手關閉了。

九條：是不是你的領導在統計你的Bug 數目了？呵呵。

阿超：不同的角色在開發過程中有相互合作、相互制約的作用，不能替代。測試人員在做驗證測試時，需要做多方面、多平臺的測試，這些工作量，也許遠遠超過了開發人員的能力范圍。因此，必須要由測試人員來驗證并處理已經修理好的Bug。

侵官之害甚于寒——我們不是不鼓勵開發人員主動幫助測試，我們是要避免導致職責不清的越界行為。

果凍：韓昭候真過分！我很好心地幫助別的同事，沒有功勞也有苦勞，他怎么能說“甚于寒”？這樣我的心都寒了。

阿超：果凍，你不是有“各司其職”的筆記么，好好看看。

九條：果凍，謝謝你的幫助，你如果急需驗證某些問題，可以告訴我，我會安排盡量早日完成。

13.5.7 測試經驗交流

測試進行了一段時間后，大家發現小飛報告的Bug比較多，九條其次，小燕最少。阿超讓測試人員交流一下各自的經驗。

小飛：我的原則是“如果問題看起來像一個Bug，那我就要報告這個Bug”。寧可多報一千，也不放過一個。這個原則也導致了我的Bug 有不少被歸為“As Design”。

阿超： “As Design”也不是什么壞事，至少我們明確了Design是什么。這樣以后就有依據了。

小燕：我發現了一個問題，都是先跑去找開發人員商量是什么情況。或者自己研究，想找到問題的根源，有時自己想到如何修復，之后再報告Bug。

九條：小燕的做法，似乎越界到了開發人員的職責范圍了。我們的職責就是找到足夠多的Bug，讓開發人員有事可干。

阿超：可以選定一個典型用戶（Persona），然后按照典型人物的思路和看問題的角度，把整個系統的各項功能都經歷一遍。如果有什么你覺得典型用戶不滿意的，那就可以考慮開一個Bug。我有時知道這個功能的設計想法，但是在測試的時候沒必要替別人考慮太多，要把自己當成用戶，而不是設計者。

小飛：測試的時候，要各個角度都試試看，一些犄角旮旯也得用一些隨機的數據去搗搗亂。黑箱、白箱都可以換著玩。就像對軟件一竅不通的用戶在使用軟件一樣。

阿超：小飛的這一個經驗，用正式的語言描述就是——保證測試方法的多樣化。

九條：我拿到一個測試任務，就想——這個功能最可能出問題的會是在什么地方？然后就集中火力，在容易出問題的地方測試。比如，如果一個產品的標題長度規定是32個字符，那我就測試31、32、33個字符，看看在這種邊界條件下是否會出問題。

小飛：測試的時候還要舉一反三，看到產品標題字段出了問題，我就會檢查一下別的字段有沒有類似的問題。

阿超：對，我們要注重從產品的風險出發進行測試。還有，我們要根據當前的產品特性來決定測試的策略，不必強求一律，舉一反三很重要。

小飛：有時候我測試自己負責的功能比較多了，就想和別人換一換，有點新鮮感。不料小燕拒絕了我的交換請求，說是沒經過領導批準，是侵官之害。我只好和九條交換。

阿超：我批準這樣的交換，關鍵是找到Bug。我們都是同一類工作人員，在事先通知和安排好的情況下，不存在“侵官之害”的問題。

小飛：我發現隨著Bug的增多，我既要驗證以前的Bug，又要發現新的Bug，工作量越來越大，你們都是怎么做到的？

九條：我一般都把一些比較穩定的測試寫成自動測試，這樣就減輕了我手工測試的壓力。

13.5.8 傳說中的拐點

小飛：我聽說在軟件項目中，有這樣一個拐點存在——在這一點之前，新的Bug產生的數量大于Bug解決的數量；在這一點之后，Bug的解決數量大于新的Bug產生的數量。這樣Bug的曲線就向下移動。我們移山項目的拐點到了么？

阿超：我也聽說過，不過這是在大型復雜項目中，測試人員和開發人員全部通過一個系統管理bug才會出現的現象。我們不能等待拐點的到來，對于我們這樣的日期驅動型的小項目，拐點必須在發布日之前的若干時間發生，如果我們的Bug數量還是繼續向上攀升，則無法保證以后曲線會像懸崖一樣掉下來。我們就得主動讓拐點發生，例如推遲一些Bug，砍掉一些功能，慢慢升高“必須修復的小強”這個標桿，等等。