1、軟體測試的背景

1、缺陷是什麼（缺陷的官方定義）

產品說明書：對開發的產品進行定義，給出產品的細節、如何做、做什麼、不做什麼。

只有至少滿足下列5個規則之一才稱發生了一個軟體缺陷：

1. 軟體未實現產品說明書要求的功能
2. 軟體出現了產品說明書指明不會出現的錯誤
3. 軟體實現了產品說明書未提到的功能
4. 軟體未實現產品說明書雖未明確提出但應該實現的目標
5. 軟體難以理解，不易使用，執行緩慢或者--從測試員的角度看--終端使用者會認為不好

注意：軟體測試員在運用第5條測試規則時，要全面，最重要的是要客觀評價，並非所有測試發現的缺陷都要修改。

2、缺陷產生的原因

最大原因：產品說明書（說明書--沒有寫或者不夠全面、經常更改、溝通不足）；

第二：設計（程式設計師規劃軟體的過程--隨意、易變、溝通不足）；

其次：把本來正確的當成缺陷、測試錯誤。這類缺陷只佔極小的比例，不必擔心。

最大原因：需求規格說明書；第二：設計方案；其次：編寫程式碼，其他

1） 需求理解錯誤，編寫過程中引起的錯誤

2） 需求不斷變更：專案失敗的最大殺手，會引起重新設計，工程重新安排

3） 開發過程中缺乏有效的溝通，或沒有進行溝通：導致設計不正確

4） 程式設計中產生錯誤

5） 軟體開發工具本身隱藏的問題：選擇較為成熟的產品

6） 不重視開發文件

7） 軟體複雜度越來越高

8） 專案進度的壓力

3、軟體測試員的目標

儘可能早地找出軟體缺陷、並確保其得以修復。（注意：修復缺陷並非一定要改正軟體。可以是指在使用者手冊中增加一段註釋或為使用者提供特殊的p）

4、測驗

1、在千年蟲例子中，dave有錯嗎？

如果dave是個好的程式設計師，他應該對這個‘顯然的’疏忽產生疑問而不是僅僅將程式涉及到只能有效工作到1999年，由於他沒有這樣做，軟體測試源就應該測試並發現該缺陷，然後又開發小組確定是否修正。

2、判斷是非：公司或開發小組使用者稱呼軟體問題的術語很重要。

錯。這雖然不重要，但使用什麼術語常常反映了小組的個性及其尋找、報告、確定問題的方法。他們提及軟體問題的方式反映出他們處理整個開發過程的方式。他們是謹慎、小心、直接，還是簡單生硬。

3、僅僅測試程式是否按預期方式執行有何問題？

這最多隻能算測試問題的一半。使用者不一定遵守規則，軟體測試員需要證實不按標準操作有何後果。此為，如果測試員進行測試沒有打破砂鍋問到底的態度就會遺漏某些軟體缺陷。

4、產品發行後修復軟體缺陷比專案開發早期這樣做的費用要高出多少？

10~100倍，甚至更高。

5、軟體測試員的目標是什麼？

儘可能早一些找出軟體缺陷，並確保其得以修復

6、判斷是非：好的測試員堅持不懈地追求完美。

錯。他們力求完美，但當知道某些無法企及時，不去苛求，而是盡力接近目標。好的測試員知道何時完美無法企及，何時達到‘夠好’。

7、給出幾個理由說明產品說明書為什麼通常是軟體產品中製造缺陷的最大來源。

產品說明書常常沒寫。不要忘了，說不出來就做不出來。其他原因是產品說明書雖然有，但是不完整，不停更改，或者產品說明書內容沒有通開發小組其他成員溝通過。

2、軟體開發的過程

1、軟體產品的組成部分

在軟體行業中，用於描述製造出來並交付給他人的軟體產品元件的術語是可交付部分。

軟體產品需要的投入：客戶需求、產品說明書、進度表、軟體設計文件、測試文件。

產品打包分發時，不僅分發的是程式碼，許多支援包含在內。支援包括：幫助檔案、使用者手冊、樣本和示例、標籤和不乾膠、產品支援資訊、圖示和標誌、錯誤資訊、廣告和宣傳材料、安裝、說明檔案。

2、軟體開發生命週期

軟體產品從最初構思到公開發行的過程稱為軟體開發生命週期模式。以下是4中最常用的模式。

1、大爆炸模式

優點是簡單。計劃、進度安排和正規開發過程幾乎沒有，所有精力都花在開發軟體和編寫程式碼上。如果產品需求無需很好理解，且最終釋出日期可隨便更改，這樣的開發過程很理想。

2、邊寫邊改模式

是專案小組在未刻意採用其他開發模式時預設的開發模式。通常最初只有粗略的專案，接著進行一些簡單的設計，然後開始漫長的來回編寫、測試和修改缺陷的過程。等到覺得足夠了，就釋出產品。

3、瀑布模式

構思、分析、設計、開發、測試、最終產品。採用該模式的專案從最初的構思到最終的產品要經過一系列步驟。每個步驟結束時，專案小組組織審查，並決定是否進入下一步。如果專案未準備好進入下一步，就停滯下來，直到準備好。有三點需要強調：

• 瀑布模式非常強調產品的定義。注意，開發或程式碼編制階段只是其中單獨的一塊。
• 瀑布模式各步驟時分立的，沒有交叉。
• 瀑布模式無法回溯。一旦進入某一個步驟，就要完成該步驟的任務，然後才能向下繼續。

4、螺旋模式

總體思想是一開始不必詳細定義所有細節。從小開始，定義重要功能，努力實現這些功能，接受客戶反饋，然後進入下一階段。重複上訴過程，直到得到最終產品。每次迴圈包括6個步驟：

• ​確定目標、可選方案和限制條件。
• 明確並化解風險。
• 評估可選方案。
• 當前階段開發和測試。
• 計劃下一階段。
• 確定進入下一階段的方法。

3、測驗

1、說出在程式設計師開始編寫程式碼之前要完成哪些任務？

開發小組需要了解客戶的要求，在產品說明書中定義功能特性。應該建立詳細的進度，是小組程式知道哪些工作已經完成，哪些工作還要做。軟體應該形成體系，經過設計，測試小組應該開始計劃工作。

2、正式並被鎖定不能修改的產品說明書有何缺點？

如果軟體開發過程中市場轉移到不同的方向上或者客戶要求改變，就沒有調整軟體的靈活性。

3、軟體開發大爆炸模式的最大優點是什麼？

簡單。僅此而已。

4、採用邊寫邊改模式時，如何得知軟體釋出的時間？

邊寫邊改模式沒有真正的退出標準，除非某人或進度決定該結束了。

5、瀑布模式為什麼不好用？

像大馬哈魚一樣，很難向上流。每一步都是跟著上一步的獨立、離散的過程。如果走到頭髮現有些事情應該早些做時，想退回來就來不及了。

6、軟體測試員為什麼最喜歡螺旋模式？

他們很早就參與開發過程，有機會盡早發現問題，為專案節省時間和金錢。

3、軟體測試的實質

1、測試的原則

1、完全測試程式是不可能的

原因：輸入量太大、輸出結果太多、軟體執行路徑太多、軟體說明書是主觀的。

如果覺得某些測試條件是重複的、無必要的，或者為了節省空間，而將其剔除，那麼採用的就是不完全測試。

2、軟體測試是有風險的行為

如果決定不去測試所有的情況，那就是選擇了冒險。軟體測試員要學會的一個關鍵思想，如何把數量巨大的可能測試減少到可以控制的方位，以及如何針對風險做出明智的抉擇，哪些測試重要，哪些不重要。每一個軟體專案都有一個最優的測試量，如圖：

該圖說明了測試量和發現的軟體缺陷數量之間的關係。如果試圖測試所有情況，費用將大幅增加，而缺陷漏掉的數量在到達某一點後沒有顯著變化。如果減少測試或錯誤地確定測試物件，雖然費用很低，但會漏掉大量缺陷。我們的目標是，找到最優的測試量，使測試不多不少。

3、測試無法顯示潛伏的軟體缺陷

軟體測試工作，可以報告軟體缺陷存在，卻不能報告缺陷不存在。你可以進行測試，發現並報告軟體缺陷，但是任何情況下都不能保證軟體缺陷沒有了。唯一的方法使繼續進行的是，可能還會找到一些。

4、找到的軟體缺陷越多，就說明軟體缺陷越多

通常，軟體測試員會在很長時間內找不到軟體缺陷。接著找到一個，之後很快就會接二連三地找到更多。原因是：

• 程式設計師也有心情不好的時候。
• 程式設計師往往犯同樣的錯誤。
• 某些軟體缺陷實乃冰山一角。

5、殺蟲劑怪事

軟體測試的越多，其對測試的免疫力越強。為了克服殺蟲劑怪事，軟體測試員必須不斷編寫不同的、新的測試程式，對程式的不同部分進行測試，以找出更多軟體缺陷。

6、並非所有軟體缺陷都要修復

軟體測試員需要進行良好的判斷，搞清楚在什麼情況下不能追求完美。專案小組需要進行取捨，根據風險決定哪些缺陷需要修復，哪些不需要修復。不需要修復的原因：

• 沒有足夠的時間。軟體功能太多，進度沒有足夠的開發和測試人員來完成專案，但必須按時完成交付軟體。
• 不算真正的軟體缺陷。很多情況下，理解錯誤、測試錯誤和說明書變更，會把可能的軟體缺陷當作功能來對待。
• 修復的風險太大。這些情形很常見。修復一個缺陷可能導致其他軟體缺陷出現。在緊迫的產品釋出進度壓力下，修復軟體將冒很大的風險。不去理睬已知的軟體缺陷，以避免造成新的、未知的缺陷的做法也許是安全知道。
• 不值得修復。不常出現的缺陷和在不常用功能中出現的缺陷是可以放多的，可以躲過和使用者有辦法預防或避免的缺陷通常不用修復。這些都要歸結為商業風險決策。決策過程通常由測試員、專案經理和程式設計師共同參與，他們站在各自的立場看待缺陷，對缺陷是否應該修復都有自己的觀點和看法。

7、什麼時候才叫缺陷難以說清

遵守軟體缺陷定義規則，有助於澄清什麼樣的缺陷才算缺陷這個問題。注意：尚未發現或未觀察到的缺陷只能說是潛在缺陷。

8、產品說明書從沒有最終版本

測試員必須想到產品說明書可能改變。未曾計劃測試的功能會增加，經過測試並報告缺陷的功能可能發生變化甚至被刪除。

9、軟體測試員在產品小組不受歡迎

測試員的工作是檢查和批評同事的工作、挑毛病、公佈發現的問題。下面是保持小組成員和睦的建議：

• 早點找出缺陷。在三個月之前而不是在產品即將釋出前夕找出嚴重的缺陷，會產生更小的影響，更容易讓人接受。
• 控制情緒。測試員喜愛自己的工作，發現嚴重的缺陷時很興奮。但是，如果興沖沖地跑到開發面前告訴他程式碼中存在缺陷，他是不會高興的。
• 不要總是報告壞訊息。加入發現某段程式碼沒有缺陷，就大聲宣揚。花一點時間找程式設計師聊聊天。

10、軟體測試是一項講究調理的技術專業

不少計算機遊戲和短期開發專案公司依然採用相當鬆散的開發模式--大爆炸模式或邊寫邊改模式。但是大多數軟體都採用井然有序的方式開發，把測試員當做必不可少的核心小組成員。現在軟體測試成為一個職業選擇--需要訓練和規範，而且有發展空間。

2、軟體測試的術語和定義

1、精確和準確

軟體測試要精度還是準度很大程度上取決於產品是什麼，最終取決於開發小組的目標。計算器軟體需要兩者都達到，正確答案就是正確的，錯誤的就是錯誤的。但是，可能會決定計算只精確到5位十進位制數，那麼，精度可以有所偏差。下圖演示了精確和準確之間的區別：

2、確認和驗證

確認時保證軟體符合剷平說明數的過程；驗證時保證軟體滿足使用者要求的過程。

3、質量和可靠性

如果說軟體產品質量高，是指它能夠滿足客戶要求。客戶會感到該產品效能卓越，由於其他產品。

軟體使用者心中的質量可能包括：軟體功能的多少、在自己的舊PC上執行的能力、軟體公司的服務電話好不好打，以及軟體的價格。產品的可靠性或者產品多長時間崩潰的問題，也許重要，但常常不被考慮到。

測試員常常會錯誤地以為質量和可靠性是一回事。他們認為如果測試程式一直穩定、可靠，就可以認定這是高質量的產品，但這不完全正確，可靠性僅僅是質量的一方面。為了確保程式質量高而且可靠性強，軟體測試員必須在整個開發過程中進行確認和驗證。

4、測試和質量保證（QA）

軟體測試員的目標時儘可能早地找出軟體缺陷，並確保缺陷得以修復。

軟體質量保證人員的主要職責時建立和執行改進軟體開發過程並防止軟體缺陷發生的標準和方法。

當然，他們存在一些交叉之處。軟體測試員會做一些QA工作，QA人員會進行一些測試，雙方的工作和任務是交織在一起的。重要的是瞭解自己的工作職責，並與開發小組的其他成員交流。小組成員如果搞不清楚誰再做測試，誰不做測試的話，將會在許多專案中造成不少麻煩。

3、測驗

1、假定無法完全測試某一程式，在決定是否應該停止測試時要考慮哪些問題？

終止測試沒有一定的時間，每一個專案都會有所不同。決定時需要考慮的因素有：仍然會發現大量軟體缺陷？軟體小組對已執行的測試滿意嗎？報告的軟體缺陷是否經過評估定下來哪些修復，哪些不修復？產品按照客戶的要求驗證了嗎？

2、windows計算機程式，輸入5,000-5=0（逗號被自動轉換未小數點），這是軟體缺陷嗎？為什麼？

要確定這是否是軟體缺陷，就需要根據產品說明書進行合法性檢查，也許在產品說明書上宣告逗號會被轉換為小數點。還要對使用者需求進行驗證，看大多數使用者是接受這點，還是產品迷惑。

3、假如測試模擬飛行或模擬城市之類的模擬遊戲，精確度和準確度哪一個更值得測試？

模擬遊戲的目的是使遊戲者置身於與現實情形接近的虛構環境中。在模擬器中飛行應該感覺想在真飛機上一樣。城市模擬就應該反映真實城市的各種情況。最重要的是如何精確地模擬實際情形。飛機像是波音757一樣還是像一隻小鳥一樣飛行？城市航線與實際路線相仿嗎？軟體有了準確性，才能逃到精確。這是關心建築物中的窗戶位置是否準確以及飛機的移動是否與遊戲杆操作完全協調的第一點。

4、有沒有質量很高但可靠性很差的產品？舉例說明。

有可能，但它取決於客戶對質量的期望。不少人購買高效能跑車，認為提速、時速、式樣、舒適度和裝飾好就是高質量。此類汽車一般可靠性交叉，經常拋錨、修理費用昂貴，而車主不把可靠性當作嚴重的質量問題。

5、為什麼不可能完全測試程式？

除了極短小的簡單程式，完全測試需要太多輸入、輸出和分支組合。此外，軟體說明書也許不客觀，可以用多種方式解釋。

6、假如週一測試軟體的某一功能，每小時發現一個新的軟體缺陷，你認為週二將會以什麼樣的頻率發現軟體缺陷？

這裡有兩個基本要素。首先，餘下的軟體缺陷與發現的軟體缺陷成比例，意味著週二不會比周一的情況好多少。其次，殺蟲劑現象表明，除非增加新的測試，否則反覆執行同樣的測試，不會發現不同的新軟體缺陷。綜合這兩個軟體要素，可能發現軟體缺陷的速度繼續保持原有頻率，甚至更低。