1 學習軟件測試前的思考

• 軟件測試就是測試程序嗎？
• 測試是不是裝上軟件後點鼠标、敲鍵盤？
• 怎麼開始測試工作？第一個任務是什麼？
• 測試早做好還是晚些做好？
• 測試需要謀劃或者規劃嗎？
• 測試要做到非常全面嗎？盡善盡美？
• 誰會參與測試？誰做最合适？
• 測試的最終任務是什麼？測試是為了證明軟件很棒嗎？
• 如果你找到一個缺陷，你該怎麼辦？
• 找到的缺陷一定要修改嗎？你要不要去修改缺陷？
• 你希望發現的缺陷越多還是越少？
• 缺陷修改後一定會對軟件帶來有益的影響嗎？
• 測試是一次性的任務嗎？
• 公司中開發和測試人數上哪種應該更多些？

2 回顧軟件的概念與分類

2.1 軟件的概念

軟件是計算機系統中與硬件相互依存的一部分，包括程序、數據以及與其相關文檔的完整集合。

1. 程序是按事先設計的功能和性能要求執行的指令序列；
2. 數據是使程序能正常操作信息的數據結構；
3. 文檔是與程序開發、維護和使用有關的圖文材料。

2.2 軟件的分類

按重要性

• 系統軟件
• 支持軟件
• 應用軟件

按架構

• 單機版軟件
• 分布式軟件

C/S 架構

B/S 架構

3 軟件失效

3.1 軟件都是安全的嗎？軟件中有錯誤嗎？

1991 年，愛國者導彈防禦系統

美國愛國者導彈防禦系統是裡根總統提出的戰硌防禦計劃（即星球大戰計劃），海灣戰争中，用于攔截伊拉克飛毛腿導彈，但在沙特阿拉伯的多哈中失利，28名美國士兵喪生。分析發現症結在于一個軟件缺陷，系統時鐘的一個很小的計時錯誤積累起來到14 小時後，跟蹤系統不再準确。在多哈的這次襲擊中，系統已經運行了 100多個小時。

1994 年，迪斯尼獅子王遊戲

迪斯尼公司發布了第一個面向兒童的多媒體光盤遊戲：獅子王動畫遊戲，迪斯尼公司進行了大量促銷宣傳，結果，銷售額非常可觀，該遊戲成為孩子們那年節假日的“必買遊戲”。12 月 26 日聖誕節的後一夭，迪斯尼公司的電話支持技術員們淹沒在來自于憤怒的家長并伴随着玩不成遊戲的孩子們哭叫的電話之中，報紙和電視新聞進行了大量的報道。後來證實，迪斯尼公司的軟件在極少數系統中工作正常（如在迪斯尼程序員用來開發遊戲的系統中），但在大多數公衆使用的系統中卻不能運行。

2000 年，千年蟲問題

20C70S，美國一程序員位公司開發工資系統，當時的計算機存儲空間很小，為了節省存儲空間，把 4 位數日期縮減為 2 位數，如 1973—73。他簡單地認為，隻有在到達 2000 年他的程序計算 00 或 01 這樣的年份時問題才會發生問題，他認定在 25 年之内程序肯定會升級或替換，而且眼前的任務比現在計劃遙不可及的未來更加重要。後來，程序員退休了，程序仍然在使用，誰也不會想到如何深入到程序中檢查 2000 年兼容問題，更不用說去修改了。據估計，世界各地檢查和解決 2000 年兼容問題和錯誤花費了數千億美元

2006 年，ATM 機故障，男子惡意取款事件

2009 年，廣州火車站售票系統癱瘓 2 個半小時

3.2 軟件危機（software crisis）

20 世紀六七十年代，出現了軟件數量急劇增長，但軟件失敗率高速上升的現象。1968 年初，北大西洋公約組織的在聯邦德國召開的國際學術會議上，計算機科學家們正式提出了“軟件危機”（Softwre Crisis）。

• 對進度和成本估計不準确，開發成本遠遠超出預算，項目進度和軟件開發效率嚴重滞後；
• 用戶對提交的産品經常會不滿意；
• 産品的質量不可靠，缺陷很多，維護成本非常高；
• 軟件開發過程的文檔匮乏。

3.3 軟件為什麼會失效？

缺陷産生的原因

1 軟件測試的起源與曆史

早期軟件開發中，沒有測試的概念，開發所做的是調試，目的是發現并糾正軟件中的故障。

1957 年，測試與調試被區别開來。但認為測試工作應該往後推，潛意識裡認為，測試的目的驗證産品能工作。

1972 年，在美國北卡羅來納大學舉行了首屆軟件測試正式會議，Bill Hetzel（比爾•海澤爾）在會上正式定義軟件測試概念。

1979 年，Glenford J.Myers（邁爾斯）在《軟件測試藝術》中給出測試的經典定義：測試是為了發現錯誤而執行程序的過程。

1983 年，IEEE（Institute of Electrical and Electronic Engineers）給出了軟件測試的标準定義，并制定了測試的标準。

1996 年，Kent Beck（肯特•貝克）在極限編程 XP 方法論中提出 TDD 測試驅動開發理論。

2009 年，James A.Whittaker（惠特克）提出探索式測試理論。

2 早期測試如何進行？

3 軟件測試的定義

3.1 經典定義

1979，Myers，《軟件測試藝術》：測試是為發現錯誤而執行程序的過程。

理解：

• 測試是為了證明程序有錯，而不是證明程序無錯誤。
• 一個成功的測試是發現了至今未發現的錯誤的測試。

3.2 标準定義

1983，IEEE使用人工或自動手段來運行或測定某個系統的過程，其目的在于檢驗它是否滿足規定的需求或是弄清預期結果與實際結果之間的差别。

理解：

• 測試是在用戶需求和開發技術之間找一個平衡點。

3.3 國内定義

GB/T 11457依據規範的軟件檢測過程和檢測方法，按照測試計劃和測試需求對被檢測軟件的文檔、程序和數據進行測試的技術活動。

• 軟件測試是一個過程，測試不隻是測試執行，它包括從計劃開始到測試結束的一系列活動。軟件測試需要測試方法和技術，或者說技巧。
• 軟件包括程序、數據和文檔，除了執行程序，數據和文檔也需要測試。

3.4 其他理解

不同時期關于測試的其他定義

• 确信程序做了它應該做的事(Hetzel,1973)。
• 确認程序正确實現了所要求的功能。
• 查出規格說明中錯誤，以及與規格說明不符的地方。
• 測試是一切以評價程序或系統的屬性、能力為目的的活動；測試是對軟件質量的度量(Hetzel,1983)。
• 評價程序或系統的過程。
• 測試是與軟件開發或維護工作并行進行的一個過程。
• 測試是一個獲取信息，降低決策風險的過程。通過測試，向整個團隊提供關于産品質量和項目環境的信息，幫助他們做出決定。

1 分析測試需求

測試人員對用戶的需求進行分析，了解軟件要做什麼，怎麼做，進而确定将來怎麼測試。

2 編寫測試計劃

測試負責人編寫測試計劃；

測試計劃的内容：

包含産品概述、測試範圍/測試區域/測試項、 測試目标/被測特征、測試優先級、測試配置/測試資源（硬件、軟件、人力、技術等）、測試周期、進度安排（測試任務、人員安排）、 測試策略、測試方法/途徑、測試交流、風險分析、測試标準、需交付文檔等内容。

3 設計與編寫測試用例

設計用例主要反映在編寫測試點上；

根據公司格式或者選擇一些模闆編寫測試用例。

4 執行測試

搭建測試環境；

執行測試用例，記錄測試事件；

提交和跟蹤缺陷。

5 評估與總結

分析實際測試與計劃的偏差；

收集并提交各種測試文檔和數據，對數據進行分析；

給出是否繼續測試還是終止測試結論；

總結經驗教訓。

1 測試 & 調試

在目前的開發和測試中，誰去尋找軟件中潛在的問題？發現缺陷後誰去修改？

2 軟件質量保證 & 軟件測試

軟件質量保證（SQA，Software Quality Assurance）