現代軟體工程 第十三章 練習與討論

標籤：des   blog   http   使用   os   檔案   

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.cnblogs.com/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，砍掉一些功能，慢慢升高“必須修複的小強”這個標杆，等等。

13.5.9  練習——學習和使用多個平台上的測試載入器

在本章中，我們介紹了不少VSTS的 軟體測試載入器，請使用一些其他平台上的測試載入器，並寫部落格介紹如何在你的項目中具體使用。