13.5.2 有錯不改
果凍： 微軟的產品經過這麼多版本的不斷完善，應該是把所有問題都搞定，「止於至善」了吧？
阿超： 那也不一定，在非常有名的電子**軟體excel中，就有這樣乙個bug：excel 的日期計算功能認為2023年是乙個閏年，這是不對的，但是它愣是一直沒有改正這個錯誤。
眾人： 真的？為什麼屢教不改呢？
阿超： 故事是這樣的，當時這類電子**軟體的市場領頭羊是lotus 1-2-3這一款軟體。它的日期計算功能有乙個bug，就是把2023年當作閏年。這類軟體在內部把日期儲存為「從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設定，就會發現有這樣乙個設定——使用2023年開始的日期計算系統（use 1904 date system）（如圖13-9所示），但是一般的使用者誰沒事在這裡打乙個勾？
圖13-9 excel的options設定
電腦程式在處理閏年這個問題上出現過很多bug，請看相關的部落格：
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的 軟體測試工具，請使用一些其他平台上的測試工具，並寫部落格介紹如何在你的專案中具體使用。
13.5.10 歷史上的20 大bug
如果你在這些專案中負責測試工作，你要設計什麼樣的測試用例才能發現這些bug? 還有什麼樣的改進能避免bug 的發生?
豐田公司是乙個世界著名的汽車公司，汽車上有不少軟體，有些軟體對行車安全起著至關重要的作用，這些軟體有bug麼？ 請看這個報道：
技術分析：
13.5.11 歷史悠久的bug
這是什麼樣的bug？ 要過37 年才修復?
源**作者是 bill joy, 他最初寫這個程式的時候犯錯誤了麼? 還是因為外界的變化是原來沒有bug 的程式產生了bug?
13.5.12 經驗分享 - tps 和 併發使用者數
現代軟體工程 第十三章 軟體測試 練習與討論
13.5.2 有錯不改 果凍 微軟的產品經過這麼多版本的不斷完善，應該是把所有問題都搞定，止於至善 了吧？阿超 那也不一定，在非常有名的電子 軟體excel中，就有這樣乙個bug excel 的日期計算功能認為1900年是乙個閏年，這是不對的，但是它愣是一直沒有改正這個錯誤。眾人 真的？為什麼屢教不...
《軟體工程》第十三章 軟體專案管理 作業
軟體專案管理是指軟體生存週期中軟體管理者所進行的一系列活動，其目的是在一定的時間和預設範圍內，有效地利用人力 資源 技術和工具，使軟體系統或軟體產品按原定計畫和質量要求如期完成。根據目標 成本 進度三個要素，軟體專案管理的任務可歸納為 為了估算專案的工作量和完成期限，首先需要估算軟體的規模，有 行技...
經典軟體工程對照現代軟體工程
本文 五級的目錄及簡單分析 一 初始級 二 可重複級 計畫及 跟進 合理化建議 會議 工餘 願者參加 所用工具軟體 網路版db軟體 如erp之用sql oracle 開源版db軟體，及從此基本點自行開發具有data mining knowledge management的軟體 要點是 的保質量 自生...