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的 軟件測試工具，請使用一些其他平臺上的測試工具，并寫博客介紹如何在你的項目中具體使用。

13.5.10? 歷史上的20 大bug

??? http://www.devtopics.com/20-famous-software-disasters/

??? http://www.devtopics.com/20-famous-software-disasters-part-2/?

??? http://www.devtopics.com/20-famous-software-disasters-part-3/?

??? http://www.devtopics.com/20-famous-software-disasters-part-4/?

如果你在這些項目中負責測試工作，你要設計什么樣的測試用例才能發現這些bug?? 還有什么樣的改進能避免bug 的發生?

豐田公司是一個世界著名的汽車公司，汽車上有不少軟件，有些軟件對行車安全起著至關重要的作用，這些軟件有bug么？ 請看這個報道：

　　http://www.safetyresearch.net/blog/articles/toyota-unintended-acceleration-and-big-bowl-%E2%80%9Cspaghetti%E2%80%9D-code

技術分析：

　　http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUBBED.pdf?

13.5.11 歷史悠久的bug

這是什么樣的bug？ 要過37 年才修復?

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/head/head.c?rev=1.18&content-type=text%2Fx-cvsweb-markup

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/head/head.c.diff?r1=1.17&r2=1.18&f=h

http://www.reddit.com/r/programming/comments/2ind4f/fix_a_37_year_old_bug_introduced_by_bill_joy_on/

源代碼作者是 Bill Joy,? 他最初寫這個程序的時候犯錯誤了么?? 還是因為外界的變化是原來沒有bug 的程序產生了bug?

13.5.12 經驗分享 - TPS 和 并發用戶數

?http://hitest.aliyun.com/front/share/shareDetail.htm?spm=0.0.0.0.hoDObJ&shareId=194011410749727463

總結

以上是生活随笔為你收集整理的现代软件工程 第十三章 【软件测试】 练习与讨论的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。