1、軟件測試軟件測試 掌握有效測試軟件的方法與技術掌握有效測試軟件的方法與技術Page 2目錄目錄1. 測試的常識與道理測試的常識與道理 2. 測試的分類與比較測試的分類與比較3. 測試人員的組織測試人員的組織4. 企業的測試策略企業的測試策略5. 測試規范測試規范6. 軟件產品的主要測試內容及技術軟件產品的主要測試內容及技術Page 31. 測試的常識與道理測試的常識與道理1.1 你真的懂測試嗎你真的懂測試嗎 u編程大師說：沒有錯誤的程序世間難求。 （編程之道）u你在學校里學過測試嗎？（讀到博士可能也不懂測試）u你所在的企業重視測試嗎？ （小公司程序員的技能更加全面）u臨時抱佛腳行嗎？你以為有文

2、檔模板就會測試了嗎？ u如果不懂得有效地進行測試，你不僅得不到功勞，也沒人欣賞你的苦勞，你擁有最多的將只是疲勞。 u職業軟件工程師應當掌握需求開發、系統設計、編程、測試、維護 所有技能。1.2 測試的目的是什么測試的目的是什么u測試的目的是為了發現盡可能多的缺陷，不是為了說明軟件中沒有缺陷。 u推論：推論：成功的測試在于發現了迄今尚未發現的缺陷。所以測試人員的職責是設計這樣的測試用例，它能有效地揭示潛伏在軟件里的缺陷。 u千萬不要將“測試”與“演示”混為一談。例如科研鑒定會。u如果產品通過了嚴格的測試，大家不要不吭氣，應當好好地宣傳一把 。Page 41. 測試的常識與道理測試的常識與道理1.

3、3 一些常識和經驗之談一些常識和經驗之談u測試能提高軟件的質量，但是提高質量不能依賴測試。 u測試只能證明缺陷存在，不能證明缺陷不存在。“徹底地測試”難以成為現實，要考慮時間、費用等限制，不允許無休止地測試。我們應當祈禱：軟件的缺陷在產品被淘汰之前一直沒有機會發作。 u測試的主要困難是不知道如何進行有效地測試，也不知道什么時候可以放心地結束測試。 u每個開發人員應當測試自己的程序（份內之事），但是不能作為該程序已經通過測試的依據（所以項目需要獨立測試人員）。 u80-20原則：80的缺陷聚集在20的模塊中，經常出錯的模塊改錯后還會經常出錯u測試應當循序漸進，不要企圖一次性干完，注意“欲速則不達

4、”。 Page 52. 測試的分類與比較測試的分類與比較2.1 測試方式測試方式u白盒測試：關心軟件內部設計和程序實現，主要測試依據是設計文檔u黑盒測試：不關心軟件內部，只關心輸入輸出，主要測試依據是需求文檔2.2 測試階段測試階段u單元測試、集成測試、系統測試、驗收測試。是“從小到大”、“由內至外”、“循序漸進”的測試過程，體現了“分而治之”的思想。 u單元測試的粒度最小，一般由開發小組采用白盒方式來測試，主要測試單元是否符合“設計”。 u集成測試界于單元測試和系統測試之間，起到“橋梁作用”，一般由開發小組采用白盒加黑盒的方式來測試，既要驗證“設計”又要驗證“需求”。 u系統測試的粒度最大，

5、一般由獨立測試小組采用黑盒方式來測試，主要測試系統是否符合“需求規格說明書”。 u驗收測試與系統測試非常相似，主要區別是測試人員不同，驗收測試由用戶執行。 Page 62. 測試的分類與比較測試的分類與比較2.3 開發與測試的開發與測試的 V 型關系型關系u如果軟件開發過程采用嚴格的瀑布模型，那么開發與測試有“V”型的對應關系 。需求開發 高層設計詳細設計編程單元測試集成測試系統測試驗收測試Page 72. 測試的分類與比較測試的分類與比較2.4 測試內容測試內容u接口與路徑測試。 u功能測試、健壯性測試、性能測試、用戶界面測試、安全性測試、壓力測試、可靠性測試、安裝/反安裝測試 測試階段測試

6、階段 主要依據主要依據 測試人員、測試方式測試人員、測試方式 主要測試內容主要測試內容 單元測試系統設計文檔由開發小組執行白盒測試 接口測試、路徑測試 集成測試系統設計文檔需求文檔由開發小組執行白盒測試和黑盒測試 接口測試、路徑測試功能測試、性能測試 系統測試需求文檔由獨立測試小組執行黑盒測試 功能測試、健壯性測試、性能測試、用戶界面測試、安全性測試、壓力測試、可靠性測試、安裝/反安裝測試 驗收測試需求文檔由用戶執行黑盒測試 Page 82. 測試的分類與比較測試的分類與比較2.5 問題問題u問題1：有了“黑盒”測試為什么還要“白盒”測試？黑盒測試只能觀察軟件的外部表現，即使軟件的輸入輸出都是

7、正確的，卻并不能說明軟件就是正確的。因為程序有可能用錯誤的運算方式得出正確的結果，例如“負負得正，錯錯得對”，只有白盒測試才能發現真正的原因。白盒測試能發現程序里的隱患，象內存泄漏、誤差累計問題。在這方面，黑盒測試存在嚴重的不足。 u問題2：由于單元測試要寫測試驅動程序，非常麻煩，能否等到整個系統全部開發完后，再集中精力進行一次性地單元測試呢？ 如果這樣做，在開發過程中，缺陷會越積越多并且分布得更廣、隱藏得更深，反而導致測試與改錯的代價大大增加。最糟糕的是無法估計測試與改錯的工作量，使進度失去控制。因此為圖眼前省事而省略單元測試或者“偷工減料”，是“得不償失”的做法。 u問題3：如果每個單元都

8、通過了測試，把它們集成一起難道會有什么不妥嗎？集成測試是否多此一舉？要把N個單元集成一起肯定靠接口耦合，這時可能會產生在單元測試中無法發現的問題。例如：數據通過不同的接口時可能出錯；幾個函數關聯在一起時可能達不到預期的功能；在某個單元里可以接受的誤差可能在集成后被擴大到無法接受的程度。所以集成測試是必要的，不是多此一舉。Page 92. 測試的分類與比較測試的分類與比較2.5 問題問題u問題4：在集成測試的時候，已經對一些子系統進行了功能測試、性能測試等等，那么在系統測試時能否跳過相同內容的測試? 不能！因為集成測試是在仿真環境中開展的，那不是真正的目標系統。再者，單元測試和集成測試通常由開發

9、小組執行。根據測試心理學的分析，開發人員測試自己的工作成果雖然是必要的，但不能作為成果已經通過測試的依據。 u問題5：既然系統測試與驗收測試的內容幾乎是相同的，為什么還要驗收測試？ 首先是“信任”問題。對于合同項目而言，如果測試小組是開發方的人員，客戶怎么能夠輕易相信“別人”呢? 所以當項目進行系統測試之后，客戶再進行驗收測試是情理之中的事。否則，那是客戶失職。 不論是合同項目還是非合同項目，軟件的最終用戶各色各樣（如受教育程度不同、使用習慣不同等等）。測試小組至多能夠模仿小部分用戶的行為，但并不具有普遍的代表性。 u問題6：能否將系統測試和驗收測試“合二為一”？ 系統測試不是一會兒就能做完的

10、，比較長時間的用戶測試很難組織。用戶還有自己的事情要做，他們為什么要為別人測試呢？即使用戶愿意做系統測試，他們消耗的時間、花費的金錢大多比測試小組的高。 系統測試時會找出相當多的軟件缺陷，軟件需要反反復復地改錯。如果讓用戶發現“內幕”，一是丟臉，二是會嚇跑買主。所以還是關起門來，先讓測試小組做完系統測試的好。 Page 103. 測試人員的組織測試人員的組織3.1 了解開發人員的測試心理了解開發人員的測試心理u測試的目的是找出盡可能多的缺陷。所以測試是“破壞性”的，而開發卻是“建設性”的。開發人員總是喜歡欣賞程序的成功之處，而不愿看到失敗之處。讓開發者去做“蓄意破壞”的測試，就象殺自己的孩子一

11、樣難以接受。 u開發者對自己的程序印象深刻，并總以為是正確的（自信是應該的）。倘若在設計時就存在理解錯誤，或因不良的編程習慣而流下了隱患，他本人很難發現這類錯誤.u開發者對自己的程序的功能、接口十分熟悉，他自己幾乎不可能因為使用不當而引發錯誤，這與大眾用戶的情況不太相似，所以測試自己的程序不具備典型性。 u結論：結論：開發人員應當測試自己的程序，這是他分內的工作。但是開發人員在測試自己的程序時，很難做到客觀、公正，所以自我測試不具有說服力。 3.2 如何組織測試人員：應當視企業的人力資源而定如何組織測試人員：應當視企業的人力資源而定u條件特別好的公司，可以為每一個開發人員分配一名獨立的測試人員

12、。這樣的測試人員職業化程度很高，可以完成單元測試、集成測試和系統測試工作，能夠實現開發與測試同步進行。u條件比較好的公司，可以設置一個獨立的測試小組，該測試小組輪流參加各個項目的系統測試。而單元測試、集成測試工作由項目的開發小組承擔。 u條件一般的公司，養不起獨立的測試小組。單元測試、集成測試工作由項目開發小組承擔。當項目進展到系統測試階段，可以從項目外抽調一些人員，加上開發人員，臨時組織系統測試小組。 u條件比較差的公司，也許只有一個項目和為數不多的一些開發人員。那么就讓開發人員一直兼任測試人員的角色，相互測試對方的程序。如果人員實在太少了，只好讓開發者測試自己的程序，有測試總比沒有測試好吧

13、！ Page 113. 測試人員的組織測試人員的組織3.3 避免開發人員與測試人員產生矛盾避免開發人員與測試人員產生矛盾u開發人員的注意事項： 不要敵視測試人員。要理解測試的目的就是發現缺陷，是測試人員的工作職責。不要以為測試人員吃飽了沒事干，存心找茬。 不要輕視測試人員，別說人家技術水平差，不配搞開發只好搞測試。 u測試人員的注意事項： 發現缺陷時不要嘲笑開發人員，別說他的程序真臭、到處是Bug。 在開發人員壓力太大時或心情不好時不要火上澆油，發現缺陷時別大聲嚷嚷。 u請留意另一種極端：請留意另一種極端：如果測試人員與開發人員的關系非常好，可能會導致在測試的時候“手下留情”，這對項目也是一種

14、傷害。 Page 124. 企業的測試策略企業的測試策略4.1 理念：理念：u企業的主要目的是獲取利潤，降低測試成本也是盈利的一種方式。 u用較低的代價實現有效的測試，不應為了追求完美的測試而不失一切代價。4.2 如何合理地減少測試工作量如何合理地減少測試工作量u減少冗余的測試 白盒測試與黑盒測試的方式雖然不同，但往往有“異曲同工”之妙。在很多地方，白盒測試與黑盒測試會產生一模一樣的效果（或者能推理出來），這樣的測試是冗余的。 在集成測試、系統測試階段，可能要執行多次“回歸測試”。每一次“回歸測試”都會存在不少的冗余，應當設法剔除不必要的重復測試工作。 u減少無價值的測試 無價值的測試通常是由

15、于不懂得測試技術引起的。例如功能測試，在等價區間之中，本來只要測試一個典型的輸入就行了，如果有人在此區間測試了100次，那么其中99次就是無價值的。 u如何“偷工減料” 有一些“短、平、快”的項目，經費本來就少，用戶對質量要求也馬馬虎虎。為了能多掙一點錢，開發方不得不采用“偷工減料”的方式來降低測試代價。偷工減料的途徑無非就是減少測試的內容和頻度。但不能砍得太狠，否則軟件拿不出手。基本方法是找出軟件中需要優先測試的部分（見下表），其它次要部分可以忽略或將來再測試。 Page 134. 企業的測試策略企業的測試策略u“偷工減料”方法的測試優先級：哪些功能是軟件的特色？ 哪些功能是用戶最常用的？

16、如果系統可以分塊賣的話，哪些功能塊在銷售時最昂貴？ 哪些功能出錯將導致用戶不滿或索賠？哪些程序是最復雜、最容易出錯的？哪些程序是相對獨立，應當提前測試的？哪些程序最容易擴散錯誤？哪些程序是全系統的性能瓶頸所在？哪些程序是開發者最沒有信心的？ 4.3 測試何時結束測試何時結束u基于測試用例的規則 u基于“測試期缺陷密度”的規則u基于“運行期缺陷密度”的規則4.4 測試獎勵機制測試獎勵機制u根據缺陷的危害程度，把獎金分等級。每個新缺陷對應一份獎金，把獎金發給第一個發現該缺陷的人。獎金額要適當，太低了人們不感興趣，太高了會讓項目破產的。 Page 145. 測試規范測試規范5.1 測試流程測試流程u

17、第一步：制定測試計劃。該計劃被批準后轉向第二步。 u第二步：設計測試用例。該用例被批準后轉向第三步。 u第三步：如果滿足“啟動準則” ，那么執行測試。 u第四步：撰寫測試報告。 u第五步：消除軟件缺陷。如果滿足“完成準則”，那么正常結束測試。制定測試計劃設計測試用例執行測試撰寫測試報告消除軟件缺陷審批審批回歸測試完成測試完成準則啟動準則Page 155. 測試規范測試規范5.2 測試啟動準則測試啟動準則u同時滿足以下條件，允許開始測試： （1）測試計劃已經制定并且通過了審批； （2）測試用例已經設計并且通過了審批； （3）被測試對象已經開發完畢并等待測試。 5.3 測試完成準則測試完成準則u對

18、于非嚴格系統可以采用“基于測試用例”的準則。同時滿足以下條件允許結束測試：（1）功能性測試用例通過率達到100；（2）非功能性測試用例通過率達到90時。u對于嚴格系統，應當補充“基于測試期缺陷密度”的規則： （3）相鄰n個CPU小時內“測試期缺陷密度”全部低于某個值m。例如n大于10，m小于等于1。 5.4 測試文檔模板測試文檔模板u測試計劃參考模板 u測試用例參考模板u測試報告參考模板Page 165.5 測試測試計劃的參考模板計劃的參考模板Page 175.6 測試測試用例用例Page 185.7 測試測試報告的參考模板報告的參考模板Page 196. 軟件系統的主要測試內容及技術軟件系統

19、的主要測試內容及技術6.1 接口與路徑測試接口與路徑測試6.2 功能測試功能測試6.3 健壯性測試健壯性測試6.4 性能測試性能測試6.5 用戶界面測試用戶界面測試6.6 信息安全測試信息安全測試6.7 壓力測試壓力測試6.8 可靠性測試可靠性測試6.9 安裝安裝/反安裝測試反安裝測試Page 206. 軟件系統的主要測試內容及技術軟件系統的主要測試內容及技術6.1 接口與路徑測試接口與路徑測試u數據一般通過接口輸入和輸出，所以接口測試是白盒測試的第一步。每個接口可能有多個輸入參數，每個參數有“典型值”、“邊界值”、“異常值”之分，所以輸入的組合數可能并不少。根據接口的定義，可以推斷某種輸入應

20、當產生什么樣的輸出。輸出包括函數的返回值和輸出參數。如果實際輸出與期望的輸出不一致，那么說明程序有錯誤。白盒方式的接口測試和黑盒方式的功能測試，其方法十分相似。 u一個函數體內的語句可能只有十幾條，但邏輯路徑可能有成千上萬條。想遍歷測試幾乎是不可能的，不測試或者胡亂找幾條路徑測試卻又不行。 u對于非嚴格系統而言，在分析路徑方面化費很多精力是不值得的。我認為在構造接口測試的同時已經建立了測試路徑。因為每一種輸入將產生唯一的輸出，輸入與輸出之間的路徑也是唯一的。由于接口測試中的輸入是有代表性的，因此相應的路徑也具有代表性，不用得著費煞苦心地去找測試路徑。u路徑測試的檢查表 數據類型、變量值、邏輯判

21、斷、循環、內存管理、文件I/O、錯誤處理 u由于接口測試是枚舉的，有可能漏掉某些狀況，導致一些重要的路徑沒有被測試。預防措施有：觀察是否有程序語句從來沒有被執行過。如果發生在這種情況，要么是程序有錯誤，存在無用的代碼；要么是接口測試不充分，漏掉了一些路徑。 要特別留意函數體內的錯誤處理程序塊（如果存在的話），這是最易被人疏忽的路徑，隱患最多。 Page 216. 軟件系統的主要測試內容及技術軟件系統的主要測試內容及技術u接口與路徑測試用例的參考模板Page 226. 軟件系統的主要測試內容及技術軟件系統的主要測試內容及技術6.2 功能測試功能測試u功能測試的基本方法是構造一些合理輸入（在需求范

22、圍之內），檢查輸出是否與期望的相同。如果兩者不一致，即表明功能有誤。也有例外的情況，如需求規格說明書中的某個功能寫錯了，而實際上軟件的功能卻是正確的，這時要更改的是需求規格說明書。 u功能測試看起來比較簡單，只要看得懂需求規格說明書，誰都會做。難點在于如何構造有效的輸入。由于輸入空間通常是無限的，窮舉測試顯然行不通。那么隨便輸入一些東西，碰運氣行不行？ u功能測試有兩種比較好的測試方法：等價劃分法和邊界值分析法。 等價劃分是指把輸入空間劃分為幾個“等價區間”，在每個“等價區間”中只需要測試一個典型值就可以了。等價劃分法來源于人們的直覺與經驗，可令測試事半功倍。 “缺陷遺漏在角落里，聚集在邊界上

23、”。邊界值測試法是對等價劃分法的補充。如果A和B是輸入空間的邊界值，那么除了典型值外還要用A和B作為測試用例。 例如測試函數。憑直覺，等價區間應是（0, 1）和（1, +）。可取典型值x=0.5以及x=2.0進行“等價劃分”測試。再取 x=0以及x=1進行“邊界值”測試。 Page 236. 軟件系統的主要測試內容及技術軟件系統的主要測試內容及技術u功能測試用例的參考模板Page 246. 軟件系統的主要測試內容及技術軟件系統的主要測試內容及技術6.3 健壯性測試健壯性測試u健壯性是指在異常情況下，軟件還能正常運行的能力。健壯性有兩層含義：一是容錯能力，二是恢復能力。 u容錯性測試通常構造一些

24、不合理的輸入來引誘軟件出錯，例如：（1）輸入錯誤的數據類型。如“猴”年“馬”月。 （2）輸入定義域之外的數值。如上海人常說的“十三點”u粗暴一些方式俗稱“大猩猩”測試法。除了不能拳打腳踢嘴咬外，什么招術都可以使出來。例如在測試客戶機服務器模式的軟件時，把網絡線拔掉，造成通信異常中斷。 u恢復測試重點考察一下幾項：（1）系統能否重新運行；（2）有無重要的數據丟失； （3）是否毀壞了其它相關的軟件硬件。 Page 256. 軟件系統的主要測試內容及技術軟件系統的主要測試內容及技術u健壯性測試用例的參考模板Page 266. 軟件系統的主要測試內容及技術軟件系統的主要測試內容及技術6.4 性能測試性

25、能測試u性能測試即測試軟件處理事務的速度，一是為了檢驗性能是否符合需求，二是為了得到某些性能數據供人們參考（例如用于宣傳）。 u有時人們關心測試的“絕對值”，如數據送輸速率是每秒多少比特。有時人們關心測試的“相對值”，如某個軟件比另一個軟件快多少倍。u在獲取測試的“絕對值”時，我們要充分考慮并記錄運行環境對測試的影響。例如網絡環境、計算機主頻，總線結構和外部設備都可能影響軟件的運行速度。 u性能測試的一些注意事項： 不要試圖讓人拿著鐘表去測時間，應當編寫一段程序用于計算時間以及相關數據。 應當測試軟件在標準配置和最低配置下的性能。 為了排除干擾，應當關閉那些消耗內存、占用CPU的其它應用軟件（

26、如殺毒軟件）。 不同的輸入情況會得到不同的性能數據，應當分檔記錄。例如傳輸文件的容量從100K到1M可以分成若干等級。 由于環境的波動，同一種輸入情況在不同的時間可能得到不同的性能數據，可以取其平均值。 Page 276. 軟件系統的主要測試內容及技術軟件系統的主要測試內容及技術u性能測試用例的參考模板Page 286. 軟件系統的主要測試內容及技術軟件系統的主要測試內容及技術6.5 用戶界面測試用戶界面測試u絕大多數軟件擁有圖形用戶界面。圖形用戶界面的測試重點是正確性、易用性和視覺效果。在評價易用性和視覺效果時，主觀性非常強，應當考慮多個人的觀點。u用戶界面測試用例的參考模板： Page 296. 軟件系統的主要測試內容及技術軟件系統的主要測試內容及技術6.6 信息安全測試信息安全測試u信息安全性（security）是指防止系統被非法入侵的能力，既