這些文字是公司一次培訓所用的PP資料，覺得講得很有道理，真正好的軟件就必須要這樣做，所以抄錄了一些記載在自己的Blog上面。

?

一、對軟件測試的誤解

?

1. 如果發布出去的軟件有質量問題,那是軟件測試人員的錯.

2. 軟件測試技術要求不高,至少比編程容易多了

?

3. 軟件測試隨便找一個能力差的人就能做.

4. 軟件測試是測試人員的事,與開發人員無關.

?

5.? 設計-實現-測試,軟件測試是開發后期的一個階段

?

二、如何理解軟件測試

?

軟件測試是一種有效的提高軟件質量的手段,但即使在投入上有所保證,測試也不能百分為百發現所有質量隱患.況且軟件質量并不僅僅是測試出來的.
很多人認為軟件測試就是運行一下軟件,看看結果對不對.但實際上,如何在有限的投入下,提高軟件測試的效率和產出是一件很見功底的事.好的測試人員不僅要掌握各種測試技術,還要具備豐富的編程經驗和對BUG的敏感.測試的復雜之處,除了測試技術問題之外,還有測試管理問題.
測試不是可有可無,隨心所欲的.規范化的軟件開發需要對軟件測試早做計劃,分配必要的時間,人力和財力等資源,并將其作為項目管理的一個部分加以控制和協調.
開發和測試是軟件項目相輔相成的兩個過程,人員間的交流,協作和配合是提高整體效率的重要因素.

?

?軟件產品開發完畢,再進行測試的觀念是有悖于生命周期理論的.軟件產品質量問題越晚發現,修復的代價越大.

?

?

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

?

?三、軟件測試的定義

?

軟件測試是為了發現錯誤而執行程序的過程
軟件測試是根據軟件開發各階段的規格說明和程序的內部結構而精心設計一批測試用例(即輸入數據及其預期的輸出結果),并利用這些測試用例去運行程序,以發現程序錯誤的過程.

?

四、軟件測試的對象

?

軟件測試不等于程序測試.軟件測試貫穿于軟件定義和開發的整個期間.需求分析,概要設計,詳細設計,以及程序編碼等各個階段所得到的文檔,包括需求規格說明,概要設計規格說明,詳細設計規格說明以及源程序,都是軟件測試的對象.

?

軟件生存各個階段間的確認和驗證

?

?

?

?

?

?

??? 軟件配置：包括軟件需求規格說明、軟件設計規格說明、源代碼 等；
??? 測試配置：包括測試計劃、測試用例、測試驅動程序等。實際上，在整個軟件工程過程中，測試配置只是軟件配置的一個子集。
??? 測試工具：為提高軟件測試效率，可使用測試工具支持測試工具。例如：測試數據自動生成程序、測試結果分析程序等。

?

五、測試的目的

?

測試是程序的執行過程,目的在于發現錯誤;
一個好的測試用例在于發現至今未發現的錯誤;
一個成功的測試是發現了至今的錯誤的測試.

?

六、測試的種類?

?

?

?

?

?

?

?

七、測試的分類與比較

?

測試方式
白盒測試：關心軟件內部設計和程序實現，主要測試依據是設計文檔
黑盒測試：不關心軟件內部，只關心輸入輸出，主要測試依據是需求文檔
?

測試階段
單元測試、集成測試、系統測試、驗收測試。是“從小到大”、“由內至外”、“循序漸進”的測試過程，體現了“分而治之”的思想。
單元測試的粒度最小，一般由開發小組采用白盒方式來測試，主要測試單元是否符合“設計”。
集成測試界于單元測試和系統測試之間，起到“橋梁作用”，一般由開發小組采用白盒加黑盒的方式來測試，既要驗證“設計”又要驗證“需求”。
系統測試的粒度最大，一般由獨立測試小組采用黑盒方式來測試，主要測試系統是否符合“需求規格說明書”。
驗收測試與系統測試非常相似，主要區別是測試人員不同，驗收測試由用戶執行。

?

開發與測試的 V 型關系
如果軟件開發過程采用嚴格的瀑布模型，那么開發與測試有“V”型的對應關系 。

?

?

測試內容
接口與路徑測試。
功能測試、健壯性測試、性能測試、用戶界面測試、安全性測試、壓力測試、可靠性測試、安裝/反安裝測試…

?

?

?

黑盒測試與白盒測試的比較

?

?

?

?

問題1：有了“黑盒”測試為什么還要“白盒”測試？
黑盒測試只能觀察軟件的外部表現，即使軟件的輸入輸出都是正確的，卻并不能說明軟件就是正確的。因為程序有可能用錯誤的運算方式得出正確的結果，例如“負負得正，錯錯得對”，只有白盒測試才能發現真正的原因。
白盒測試能發現程序里的隱患，象內存泄漏、誤差累計問題。在這方面，黑盒測試存在嚴重的不足。
問題2：由于單元測試要寫測試驅動程序，非常麻煩，能否等到整個系統全部開發完后，再集中精力進行一次性地單元測試呢？
如果這樣做，在開發過程中，缺陷會越積越多并且分布得更廣、隱藏得更深，反而導致測試與改錯的代價大大增加。最糟糕的是無法估計測試與改錯的工作量，使進度失去控制。因此為圖眼前省事而省略單元測試或者“偷工減料”，是“得不償失”的做法。
問題3：如果每個單元都通過了測試，把它們集成一起難道會有什么不妥嗎？集成測試是否多此一舉？
要把N個單元集成一起肯定靠接口耦合，這時可能會產生在單元測試中無法發現的問題。例如：數據通過不同的接口時可能出錯；幾個函數關聯在一起時可能達不到預期的功能；在某個單元里可以接受的誤差可能在集成后被擴大到無法接受的程度。所以集成測試是必要的，不是多此一舉。

?

問題4：在集成測試的時候，已經對一些子系統進行了功能測試、性能測試等等，那么在系統測試時能否跳過相同內容的測試?
不能！因為集成測試是在仿真環境中開展的，那不是真正的目標系統。再者，單元測試和集成測試通常由開發小組執行。根據測試心理學的分析，開發人員測試自己的工作成果雖然是必要的，但不能作為成果已經通過測試的依據。
問題5：既然系統測試與驗收測試的內容幾乎是相同的，為什么還要驗收測試？
首先是“信任”問題。對于合同項目而言，如果測試小組是開發方的人員，客戶怎么能夠輕易相信“別人”呢? 所以當項目進行系統測試之后，客戶再進行驗收測試是情理之中的事。否則，那是客戶失職。
不論是合同項目還是非合同項目，軟件的最終用戶各色各樣（如受教育程度不同、使用習慣不同等等）。測試小組至多能夠模仿小部分用戶的行為，但并不具有普遍的代表性。
問題6：能否將系統測試和驗收測試“合二為一”？
系統測試不是一會兒就能做完的，比較長時間的用戶測試很難組織。用戶還有自己的事情要做，他們為什么要為別人測試呢？即使用戶愿意做系統測試，他們消耗的時間、花費的金錢大多比測試小組的高。
系統測試時會找出相當多的軟件缺陷，軟件需要反反復復地改錯。如果讓用戶發現“內幕”，一是丟臉，二是會嚇跑買主。所以還是關起門來，先讓測試小組做完系統測試的好。

?

回歸測試
回歸測試是指對某些已經被測試過的內容進行重新測試。每當軟件增加了新的功能，或者軟件中的缺陷被修正，這些變更都有可能影響軟件原有的功能和結構。為了防止軟件的變更產生無法預料的副作用，不僅要對新內容進行測試，還要對某些老內容進行回歸測試。

?

測試人員的組織

?

了解開發人員的測試心理
測試的目的是找出盡可能多的缺陷。所以測試是“破壞性”的，而開發卻是“建設性”的。開發人員總是喜歡欣賞程序的成功之處，而不愿看到失敗之處。讓開發者去做“蓄意破壞”的測試，就象殺自己的孩子一樣難以接受。?
開發者對自己的程序印象深刻，并總以為是正確的（自信是應該的）。倘若在設計時就存在理解錯誤，或因不良的編程習慣而流下了隱患，他本人很難發現這類錯誤.
開發者對自己的程序的功能、接口十分熟悉，他自己幾乎不可能因為使用不當而引發錯誤，這與大眾用戶的情況不太相似，所以測試自己的程序不具備典型性。
結論：開發人員應當測試自己的程序，這是他分內的工作。但是開發人員在測試自己的程序時，很難做到客觀、公正，所以自我測試不具有說服力。

?

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

?

避免開發人員與測試人員產生矛盾
開發人員不能很好地測試自己的程序是因為做不到“無情”。但如果測試人員真的做到了“無情”卻會引起開發人員的憤怒，遭人白眼。由于開發與測試存在“對立”關系，開發人員與測試人員很容易產生矛盾，這對項目而言是一種傷害。
開發人員的注意事項：
（1）不要敵視測試人員。要理解測試的目的就是發現缺陷，是測試人員的工作職責。不要以為測試人員吃飽了沒事干，存心找茬。
（2）不要輕視測試人員，別說人家技術水平差，不配搞開發只好搞測試。
測試人員的注意事項：
（1）發現缺陷時不要嘲笑開發人員，別說他的程序真臭、到處是Bug。
（2）在開發人員壓力太大時或心情不好時不要火上澆油，發現缺陷時別大聲嚷嚷。
盡量不要相互諷刺對方，例如：
A對B說：你唯一的特點就是無能。
B對A說：你唯一的特點就是粗魯。
還要注意的是，如果測試人員與開發人員的關系非常好，可能會導致在測試的時候“手下留情”，這對項目也是一種傷害。

?

?

企業的測試策略

?

理念：
企業的主要目的是獲取利潤，降低測試成本也是盈利的一種方式。
用較低的代價實現有效的測試，不應為了追求完美的測試而不失一切代價。
?如何合理地減少測試工作量
減少冗余的測試
白盒測試與黑盒測試的方式雖然不同，但往往有“異曲同工”之妙。在很多地方，白盒測試與黑盒測試會產生一模一樣的效果（或者能推理出來），這樣的測試是冗余的。
在集成測試、系統測試階段，可能要執行多次“回歸測試”。每一次“回歸測試”都會存在不少的冗余，應當設法剔除不必要的重復測試工作。
減少無價值的測試
無價值的測試通常是由于不懂得測試技術引起的。例如功能測試，在等價區間之中，本來只要測試一個典型的輸入就行了，如果有人在此區間測試了100次，那么其中99次就是無價值的。
如何“偷工減料”
有一些“短、平、快”的項目，經費本來就少，用戶對質量要求也馬馬虎虎。為了能多掙一點錢，開發方不得不采用“偷工減料”的方式來降低測試代價。偷工減料的途徑無非就是減少測試的內容和頻度。但不能砍得太狠，否則軟件拿不出手。基本方法是找出軟件中需要優先測試的部分，其它次要部分可以忽略或將來再測試。
?

?

“偷工減料”方法的測試優先級：
哪些功能是軟件的特色？
哪些功能是用戶最常用的？
如果系統可以分塊賣的話，哪些功能塊在銷售時最昂貴？
哪些功能出錯將導致用戶不滿或索賠？
哪些程序是最復雜、最容易出錯的？
哪些程序是相對獨立，應當提前測試的？
哪些程序最容易擴散錯誤？
哪些程序是全系統的性能瓶頸所在？
哪些程序是開發者最沒有信心的？

?

測試何時結束？
一、基于測試用例的規則
（1）先構造測試用例（并請有關人員進行評審）。
（2）在測試過程中，當測試用例的不通過率達到20％時，則拒絕繼續測試，待開發人員修正軟件后再進行測試。
（3）當功能性測試用例通過率達到100％，非功能性測試用例通過率達到90％時，允許正常結束測試。
?該規則的優點是適用于所有的測試階段，缺點是太依賴于測試用例。如果測試用例非常糟糕，那么該規則就失效了。
二、基于“測試期缺陷密度”的規則
把測試一個CPU小時發現的缺陷數稱為“測試期缺陷密度”。繪制“測試時間－缺陷數”的關系圖，如果在相鄰n個CPU小時內“測試期缺陷密度”全部低于某個值m時，則允許正常結束測試。例如n大于10，m小于等于1。該規則比較適用于系統測試階段。
三、基于“運行期缺陷密度”的規則
把軟件運行一個CPU小時發現的缺陷數稱為“運行期缺陷密度”。繪制“運行時間－缺陷數”的關系圖，如果在相鄰n個CPU小時內“運行期缺陷密度”全部低于某個值m時，則允許正常結束測試。例如n大于100，m小于等于1。該規則比較適用于驗收測試階段，即客戶試運行軟件期間。

?

需求經常變更怎么辦
?需求變更可能會讓項目所有成員遭殃，如何“預防變更”以及“降低變更的代價”是軟件工程的經典問題。本節僅論述需求變更對測試的影響。
需求變更將導致軟件設計和實現的變更，也導致了測試變更。最讓人難過的是上一次測試有可能白做了，如果軟件變更比較大的話。
?測試人員不要只是自認倒霉，應當主動作些應變：
（1）及時了解需求變更的詳細情況，盡早調整測試計劃，不要悶頭按原計劃測試。
（2）將軟件中穩定的部分與易變的部分區別對待，前者先測試，后者后測試。
（3）向領導反映需求變更對測試造成的影響，為自己爭取余地。
（4）設計一些比較靈活的測試用例，能適應某些變更（不過技術難度比較高）。
引申問題：如果在系統測試時，對照需求文檔，發現軟件多了功能或少了功能，該怎么辦？
如果發現軟件少了功能，測試人員不可為了少干些活而隱瞞事實。如果發現軟件多了功能，測試人員不可認為這些功能反正是“錦上添花”，便自作主張地測試了事。兩種情況都要報告給項目經理，有可能導致一系列的變更。

?

測試規范

?

測試流程
第一步：制定測試計劃。該計劃被批準后轉向第二步。
第二步：設計測試用例。該用例被批準后轉向第三步。
第三步：如果滿足“啟動準則” ，那么執行測試。
第四步：撰寫測試報告。
第五步：消除軟件缺陷。如果滿足“完成準則”，那么正常結束測試。

?

?

?

?

?

測試信息流

?

?

軟件測試的策略

?

在軟件工程中，測試過程應該按4個步驟進行，即單元測試、組裝（集成）測試、確認測試和系統測試。下圖給出了軟件測試經歷的4個步驟。?

?

?

測試規范

?

測試啟動準則
同時滿足以下條件，允許開始測試：
（1）測試計劃已經制定并且通過了審批；
（2）測試用例已經設計并且通過了審批；
（3）被測試對象已經開發完畢并等待測試。
?測試完成準則
對于非嚴格系統可以采用“基于測試用例”的準則。同時滿足以下條件允許結束測試：
（1）功能性測試用例通過率達到100％；
（2）非功能性測試用例通過率達到90％時。
對于嚴格系統，應當補充“基于測試期缺陷密度”的規則：
（3）相鄰n個CPU小時內“測試期缺陷密度”全部低于某個值m。例如n大于10，m小于等于1。

?

《測試計劃》：指明范圍、方法、資源，以及相應測試活動的時間進度安排表的文檔。
《測試方案》：指明為完成軟件或軟件集成特性的測試而進行的設計測試方法的細節文檔。
《測試用例》：指明為完成一個測試項的測試輸入、預期結果、預期執行條件等因素的文檔。
《測試規程》：指明執行測試時測試活動序列的文檔。
《測試報告》：指明執行測試結果的文檔。

?

測試計劃的參考模板

?

?

建立測試計劃

?

定義測試目標
開發測試矩陣
軟件模型
結構特性
批量測試的階段和用例
為在線系統作概念上的測試腳本
軟件測試矩陣
定義測試管理
測試計劃的一般性信息
定義測試里程碑
定義管理上的檢查點
書寫測試計劃

?

評審測試計劃

涉及評審的問題
評審測試的開始時間是否會延期
有沒有抵觸評審的角色
一段時間內是否很難得到工作的檢查信息。
更換工具有可能導致他們反感評審工作
評審結果可能會影響對個人的工作評價
對于最終成品的檢查
項目的需求規格說明書
軟件返工/維護的文檔
升級后的技術文檔
被更改的源程序
測試計劃
用戶手冊（包括在線幫助）
?

?

測試用例

?

?

測試的基本理論與方法