什麼是軟體測試？

廣義的概念

指軟體生存週期中所有的檢查、評審和確認工作，其中包括了對分析、設計階段，以及完成開發後維護階段的各類文件、程式碼的審查和確認。

狹義概念

識別軟體缺陷的過程，即實際結果與預期結果的不一致。軟體測試通常包括驗證(verification)和確認(validation)

軟體測試的目的

測試的目的就是發現軟體中的各種缺陷,以較少的用例、時間和人力找出軟體中的各種錯誤和缺陷，以確保軟體的質量。
測試只能證明軟體存在缺陷，不能證明軟體不存在缺陷。
測試可以使軟體中缺陷降低到一定程度，而不是徹底消滅。

產品質量的關鍵因素是分析、設計和實現，測試應該是融於其中的補充檢查手段，其他管理、支援、甚至文化因素也會影響最終產品的質量。
應該說，測試是提高產品質量的必要條件，也是提高產品質量最直接、最快捷的手段，但決不是一種根本手段。
反過來說，如果將提高產品質量的砝碼全部押在測試上，那將是一個恐怖而漫長的災難。

軟體測試原則

Good-enough

1 Good-enough原則就是一種權衡投入/產出比的原則：
不充分的測試是不負責任的；過分的測試是一種資源的浪費，同樣也是一種不負責任的表現。
我們的操作困難在於：如何界定什麼樣的測試是不充分的，什麼樣的測試是過分的。
目前狀況唯一可用的答案是：制定最低測試通過標準和測試內容，然後具體問題具體分析

2 越早測試越好，測試過程與開發過程應是相結合的。測試的規模由小而大，從單元測試到系統測試。

3 Bug的80-20原則。
實踐證明,80%的bug往往隱含在20%的軟體區域。所以一旦在某處發現了bug，多找找周圍。這也是有經驗的測試員的一種方式。
一般情況下，在分析、設計、實現階段的複審和測試工作能夠發現和避免80%的Bug，而系統測試又能找出其餘Bug中的80%，最後的5%的Bug可能只有在使用者的大範圍、長時間使用後才會曝露出來。因為測試只能夠保證儘可能多地發現錯誤，無法保證能夠發現所有的錯誤。

軟體測試質量與產品質量軟體產品質量六屬性

功能性、可靠性、易使用性、效率、可維護性、可移值性

1.功能性：軟體所實現的功能滿足使用者需求的程度．功能性反映了所開發的軟體滿足使用者稱述的或蘊涵的需求的程度，即使用者要求的功能是否全部實現了。
2.可靠性：在規定的時間和條件下，軟體所能維持其效能水平的程度。可靠性對某些軟體是重要的質量要求，它除了反映軟體滿足使用者需求正常執行的程度，且反映了在故障發生時能繼續執行的程度。
3.易使用性：對於一個軟體，使用者學習、操作、準備輸入和理解輸出時，所做努力的程度。易使用性反映了與使用者的友善性，即使用者在使用本軟體時是否方便。
4.效率：在指定的條件下，用軟體實現某種功能所需的計算機資源（包括時間）的有效程度。效率反映了在完成功能要求時，有沒有浪費資源，此外”資源”;這個術語有比較廣泛的含義， 它包括了記憶體、外存的使用，通道能力及處理時間。
5.可維修性：在一個可執行軟體中，為了滿足使用者需求、環境改變或軟體錯誤發生時，進行相應修改所做的努力程度。可維修性反映了在使用者需求改變或軟體環境發生變更時，對軟體系統進行相應修改的容易程度。一個易於維護的軟體系統也是一個易理解、易測試和易修改的軟體，以便糾正或增加新的功能，或允許在不同軟體環境上進行操作。
6.可移植性：從一個計算機系統或環境轉移到另一個計算機系統或環境的容易程度。

產品質量與程式碼質量

軟體測試度量

測試覆蓋率

測試覆蓋率是每個測試都關心的問題，它一方面可以衡量測試工作本身的有效性，也可以輔助增強管理者對於軟體產品質量的信心水平。
只是，它的實施會有一定難度，關鍵在於如何去度量?
常規而言，覆蓋率會包含兩個層面：
　　程式碼層面，從執行後代碼的被執行比率、被執行頻度等來體現這個指標。當然，除了直接了當的程式碼行覆蓋以外，還有“高階”一點的控制流/資料流路徑覆蓋。在單元測試級別，這一覆蓋指標相對容易獲取；而在系統黑盒測試中，這一覆蓋率就沒有很好的推廣，主要是支援的工具很少，支援非入侵的方式則更少。
　　需求功能層面，即執行的測試用例覆蓋了多少Use Case、多少頁面、多少場景、多少需求點、多少頁面元素等等。這一部分的主觀性就相對會比較強，因為對於需求功能，並沒有一個公平量化的度量，從而被人為利用的概率也就大增了。所以很多時候，基於需求功能的覆蓋率更多變成了紙面上的東西，即業務和管理者如何需要，則這個覆蓋率就會如何形成
關於測試覆蓋率，還有一層含義，即已經/計劃執行的測試用例相比測試用例總集的比例。我們冠之以“執行覆蓋率”之名，這個資訊可以給測試的迴歸比率、測試方案的充分性等一個比較直觀的訊號。

缺陷發現率

每輪測試產生的缺陷數目,從理論上來講應該是降低的趨勢,或者是收斂的趨勢,但是實際情況往往並非如此,提高缺陷發現率，更多的不在測試這裡，是一個整體流程才能更好的保證。測試人員不保證軟體質量，那是QA的事情，測試的責任在發現程式存在的缺陷。

軟體可測試性

軟體容易被測試的程度，包括下面幾個指標：
可確認性：可以明確確認軟體是否符合要求，例如有明確的要求和指標。
可觀察性：用於確認的結果可以進行有效的觀察。
可控制性：相對應的測試環境可以進行控制，從而保證測試的有效性。
可分解性：軟體可以進行分解，對分解的結構進行測試。

軟體測試過程

擬定軟體測試計劃。
設計軟體測試策略。
設計和生成測試用例、準備測試資料。
執行測試，記錄原始資料，對缺陷進行管理。
生成軟體測試報告、缺陷的統計和報表。
迴歸測試。

軟體開發流程（軟體生命週期）：

計劃-》需求分析-》設計-》程式編寫-》測試-》執行/維護對應的軟體測試流程：
測試計劃-》需求分析-》測試用例-》測試用例執行-》提交bug-》迴歸測試

軟體測試計劃

時間進度和人員安排、風險管理。
測試範圍的確定、測試資料的生成。測試工具、方法的選擇和工具開發。
測試完成標準。
影響資源分配的特殊考慮等。

軟體測試策略

定義被測軟體功能以及相關的測試，並詳細說明的測試方法和策略。
測試方案的定義應當基於需求分析和設計文件，並遵從測試計劃文件。

軟體測試用例

為實施一次測試而向被測系統提供的輸入資料、操作或各種環境設定。
控制著軟體測試的執行步驟。
是對測試方案中每個測試項的進一步例項化。

軟體測試的執行

執行測試用例。
記錄原始測試資料。記錄缺陷。
對所發現的缺陷進行跟蹤、管理和監控。

軟體測試報告

總結測試的結果，通過與未通過的測試用例，並對被測軟體物件進行評估測試總結：

評價軟體質量

分析提交客戶後的缺陷預測分析，以及維護成本分析。對測試工作進行經驗、教訓、建議總結。

軟體開發模型與測試模型

軟體開發模型：

瀑布模型：適用於需求很明確的專案，分階段向下進行，無法回溯。
迭代模型：需求不明確，迭代版本系統。
敏捷開發模型： 敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。 在敏捷開發中，軟體專案被切分成多個子專案，各個子專案的成果都經過測試，具備整合和可執行的特徵。換言之，就是把一個大專案分為多個相互聯絡，但也可獨立執行的小項 目，並分別完成，在此過程中軟體一直處於可使用狀態。
測試驅動開發模型：先編寫測試程式碼，再寫開發程式碼。

軟體測試模型-V模型

在軟體測試方面，V模型是最廣為人知的模型，儘管很多富有實際經驗的測試人員還是不太熟悉V模型，或者其它的模型。
V模型已存在了很長時間，和瀑布開發模型有著一些共同的特性，由此也和瀑布模型一樣地受到了批評和質疑。
V模型中的過程從左到右，描述了基本的開發 過程和測試行為。
V模型的價值在於它非常明確地標明瞭測試過程中存在的不同級別，並且清楚地描述了這些測試階段和開發過程期間各階段的對應關係。
V模型的侷限性：
把測試作為編碼之後的最後一個活動，需求分析等前期產生的錯誤直到後期的驗收測試才能發現.

軟體測試模型-W模型

V模型的侷限性在於沒有明確地說明早期的測試,無法體現“儘早地和不斷地進行軟體測試” 的原則。在V模型中增加軟體各開發階段應同步進行的測試，演化為W模型（如下圖）。在模型中不難看出，開發是“V”，測試是與此並行的“V”。基於“儘早地和不斷地進行軟體測試”的原則
W模型相對於V模型，W模型更科學。W模型是V模型的發展，強調的是測試伴隨著整個軟體開發週期，而且測試的物件不僅僅是程式，需求、功能和設計同樣要測試。測試與開發是同步進行的，從而有利於儘早地發現問題。

W模型的侷限性：仍把開發活動看成是從需求開始到編碼結束的序列活動，只有上一階段完成後，才可以開始下一階段的活動，不能支援迭代，自發性以及變更調整。

軟體測試模型-X模型

X模型也是對V模型的改進,X模型提出針對單獨的程式片段進行相互分離的編碼和測試,此後通過頻繁的交接,通過整合最終合成為可執行的程式
X模型的左邊描述的是針對單獨程式片段所進行的相互分離的編碼和測試，此後將進行頻繁的交接，通過整合最終成為可執行的程式，然後再對這些可執行程式進行測試。己通過整合測試的成品可以進行封裝並提交給使用者，也可以作為更大規模和範圍內整合的一部分。多根並行的曲線表示變更可以在各個部分發生。由圖中可見，X模型還定位了探索性測試，這是不進行事先計劃的特殊型別的測試，這一方式往往能幫助有經驗的測試人員在測試計劃之外發現更多的軟體錯誤。但這樣可能對測試造成人力、物力和財力的浪費，對測試員的熟練程度要求比較高。

軟體測試模型-H模型

H模型中,軟體測試過程活動完全獨立,貫穿於整個產品的週期,與其他流程併發地進行,某個測試點準備就緒時,就可以從測試準備階段進行到測試執行階段。軟體測試可以儘早的進行,並且可以根據被測物的不同而分層次進行。
這個示意圖演示了在整個生產週期中某個層次上的一次測試“微迴圈”。圖中標註的其它流程可以是任意的開發流程,例如設計流程或者編碼流程。也就是說,只要測試條件成熟了,測試準備活動完成了,測試執行活動就可以進行了。
H模型揭示了一個原理:軟體測試是一個獨立的流程,貫穿產品整個生命週期,與其他流程併發地進行。H模型指出軟體測試要儘早準備,儘早執行。不同的測試活動可以是按照某個次序先後進行的,但也可能是反覆的,只要某個測試達到準備就緒點,測試執行活動就可以開展

探索性軟體測試

選取業務和技術領域上的測試專家，按照制定好的測試主題對應用進行自由測試，從普通使用者的視角上，結合自身的專業知識找出應用中的缺陷。包括自由式、反饋式、策略與場景式測試。
目前大多數的探索測試是作為傳統測試的補充，補充分支與異常的測試用例。理想狀態下，隨著探索性測試的成熟，通過探索性測試替代分支與異常測試，漫遊測試代替基本的測試用例。

探索性軟體測試與其它測試的比較

Monkey測試
動手不動腦、無需IT和業務知識；完全隨機、不用培訓。
傳統測試
動手也動腦、需要IT和業務知識。
依據功能點測試正常、異常分支，容易有場景遺漏。
基於經驗，很難積累和技能傳遞，部分隨機、很難培訓。
探索性軟體測試
有計劃和有目的的開展，需要IT和業務知識。
有抽象的方法論便於積累和技能傳遞，很容易培訓。
單位時間內，發現的bug數和取得的程式碼覆蓋率高。
儘早發現更多軟體質量風險的測試手段。
來源使用者行為模式和軟體出錯模式的抽象。基於使用者場景，通過模擬使用者操作，接近真實的複雜使用者行為啟發測試人員的思維。
是對傳統測試設計方法的一個顛覆。是一般性測試的重要補充。

測試階段-漫遊類

基於功能，全面驗證需求。
作用：預測試和功能基本路徑驗證。
衡量指標：程式碼覆蓋率。

測試階段-探索類

基於使用者場景 發現更深層次的bug，MRD(市場需求文件-marketing requirements document)不一定有提及 ，衡量指標是使用者場景覆蓋情況。

測試方法

極限測試法：在上下邊界附近進行測試，只為尋找一個突破點。
場景插入法：場景插入法描述的是一個從一個場景跳到另一個場景的方式。從而把兩個或者更多場景結合為一個具有混合目的的場景。比如在使用使用應用過程中，突然來 電。
測一送一法：重複某個操作or操作的組合反覆連續執行10次以上。
反叛法：要求輸入最不可能的資料，或者已知的惡意輸入。
計程車法：測試所有能到達同一目的的操作序列。
快遞測試法：輸入一個數據後，觀察所有顯示地方是否都正確顯示。
懶漢測試法：以軟體的預設值為測試資料執行測試。

競品測試

選取與被測應用功能、非功能設計指標相近的同類應用，對各個指標進行定量對比。

流程：

競品分析（競品範圍制定及選擇具體競品） 制訂競品測試策略
設定指標，如功能、相容性、可靠性、使用者體驗、安全性等（每項具體子項可根據業務來進行指定）
設定測試場景（相同環境&執行類似路徑） 設定執行策略（次數&時間）
設定結果策略（均值&對比） 執行測試並記錄結果