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

2022-01-11 19:40:19 字數 3756 閱讀 4514

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的軟體 要點是 的保質量 自生...