測試入門總結

什麼是測試
顧名思義，就是在規定的條件下對一個產品或程式進行操作，以發現程式錯誤，衡量軟體質量，並對其是否能滿足設計要求進行評估的過程。

軟體測試背景

軟體測試在軟體生命週期中佔據重要的地位，軟體測試慢慢的獨立發展成為一個行業，並且在迅猛發展，軟體測試主要是發現問題定位問題，配合開發解決問題，如果公司中沒有測試崗位可能存在很大的風險。
例如：

1. 軟體缺陷與軟體故障

跨世紀前年蟲洞問題
2000年之前由於時間表示是用YYMMDD這種方式，用二位10進製表示的，但是到了2000年，兩位數出現了爭議，00到底表示的是1900年還是2000年，後來使用了YYYYMMDD的方法表示，這是由於系統bug造成的

2. 軟體的缺陷產生的原因

軟體缺陷一般有兩種原因，第一大原因就是軟體產品規格說明書，很多情況下，說明書沒有寫，或寫的不夠全面，經常更改，或者開發小組沒有很好的溝通，造成對說明書理解的不一致。第二大原因是軟體設計，沒有做設計或設計不好，經常變動等和產品規格說明書一樣的問題，第三個原因才是編寫程式碼和其它原因；前兩個原因至少佔了 80%以上。

3.軟體測試和修復的代價

缺陷發現的越早，則修復這個缺陷的代價就越小，在需求、設計、編碼、測試、釋出等不同的階段，發現缺陷後修復的代價都會比在前一個階段修復的代價提高10倍

測試流程

立項——產品說明書——寫需求文件——需求評審{程式碼開發自測（開發環境），編寫測試用例——測試用例評審——提測（環境部署）測試環境——冒煙測試——提交bug到禪道——迴歸測試——驗收測試——上線}

1. 立項
   這是由開發、測試、需求、經理和主管參加開會討論，從使用者角度提供設計，開發角度是否能完成，聯絡其他模組分析是否設計存在風險或缺陷
2. 產品（產品說明書）
   由產品完成產品說明書，有些公司沒有產品。
3. 需求文件
   由需求定製需求文件
4. 需求評審
   由開發、測試、產品、經理開會探討需求是否合理
   4.1 開發自測
   需求評審通過後，開發設計一份概要設計再進行編碼到自測完成後提測
   4.2 需求評審通過，測試人員寫測試用例，可用思維導圖
   4.2.1 用例評審
   1測試用例設計
   2測試用例評審，和測試時間估計
   3測試資源申請
   4測試人員分配
   4.2.3 提測一般在linux
   4.2.4冒煙測試
   測試主要功能是否完成
   4.2.5提交bug到禪道
   4.2.6迴歸測試
   測試上個版本的bug是否還存在，是否引發新的bug
   4.2.7驗收測試
   交由客戶驗收是否達到想要的效果，或者有無其他問題
   4.2.8上線

軟體測試分類

黑盒測試和白盒測試

黑盒測試指將被測試的軟體看做為一個黑盒子，不關注盒子裡面的結構，即不需要了解程式原始碼，通使用整個軟體驗證程式是否滿足需求和測試方法
白盒測試是按照程式內部邏輯結構和編碼結構設計測試資料並完成測試的測試方法

軟體的生命週期

1.1. 邊做邊改模型
許多產品都是使用“邊做邊改”模型來開發的。在這種模型中，既沒有規格說明，也沒有經過設計，軟體隨著客戶的需要一次又一次地不斷被修改。但這種方法對任何規模的開發來說都是不能令人滿意的，

其主要問題在於：
（1） 缺少規劃和設計環節，軟體的結構隨著不斷的修改越來越糟，導致無法繼續修改；
（2） 忽略需求環節，給軟體開發帶來很大的風險；
（3） 沒有考慮測試和程式的可維護性，也沒有任何文件，軟體的維護十分困難。

1.2. 瀑布模型
瀑布模型是最早出現的軟體開發模型，在軟體工程中佔有重要的地位，它提供了軟體開發的基本框架。其過程是從上一項活動接收該項活動的工作物件作為輸入，利用這一輸入實施該項活動應完成的內容給出該項活動的工作成果，並作為輸出傳給下一項活動。同時評審該項活動的實施，若確認，則繼續下一項活動；否則返回前面，甚至更前面的活動。對於經常變化的專案而言，瀑布模型毫無價值。

瀑布型簡單地說就是按照需求、設計、編碼、測試、軟體維護這個基本的順序來研發軟體，前面一個步驟不完成，後面的步驟不能開始，否則問題會滾到下個階段，帶來更多的問題
優點：

1. 為專案提供了按階段劃分的檢查點
2. 當前一階段完成後，只需要去關注後續階段。
   缺點：
   1）各個階段的劃分完全固定，階段之間產生大量的文件，極大地增加了工作量。
   2）由於開發模型是線性的，使用者只有等到整個過程的末期才能見到開發成果，從而增加了開發風險。
   3）通過過多的強制完成日期和里程碑來跟蹤各個專案階段。
   4）瀑布模型的突出缺點是不適應使用者需求的變化。

1.3. 原型化模型

原型化模型的第一步是建造一個快速原型，實現客戶或未來的使用者與系統的互動，經過和使用者針對原型的討論和交流，弄清需求以便真正把握使用者需要的軟體產品是什麼樣子的。充分了解後，再在原型基礎上開發出使用者滿意的產品。

如圖所示：原型嚴格來說不算一種軟體生命週期模型，它只是一種獲取需求的方法，在實際工作中該方法是相當重要的方法。模型要點：瀑布和原型模型相結合，強調版本升級。

1.4. 增量模型
增量模型也是原型化開發方法。如圖所示

1.5. 螺旋模型
螺旋模型是一個演化軟體過程模型，將原型實現的迭代特徵與線性順序（瀑布）模型中控制的和系統化的方面結合起來。使得軟體的增量版本的快速開發成為可能。在螺旋模型中，軟體開發是一系列的增量釋出。螺旋模型的整個開發過程如圖所示。
4個象限分別標誌每個週期所劃分的4 個階段：制定計劃、風險分析、實施工程和客戶評估。螺旋模型要點：統一了瀑布模型與原型模型，與增量模型相似，更強調風險分析。
1.軟體分多個版本開發，每個版本就是一次螺旋。
2.每個版本按照這樣的順序進行：
1）確定軟體目標，選取定實施方案，弄清專案開發的限制條件；（圖中左上象限）
2）分析所選取方案，考慮如何識別和消除風險；（圖中右上象限）
3）實施軟體開發；（圖中右下象限）
4）評價開發工作，提出修正建議，調整計劃。（圖中右下象限、左下象限）
3.需求不是一次獲取和實現的，通過多個螺旋來完善。
4.計劃也不是一次成型的，每次螺旋都需要調整。

優點：
1）設計上很靈活，可以在專案的各個階段進行變更；
2）以小的分段來構建大型系統，使成本計算變得簡單容易；(國企專案)
3）客戶始終參與每個階段的開發，保證了專案不偏離正確方向以及專案的可控性；
4）隨著專案推進，客戶始終掌握專案的最新資訊 , 從而能夠和管理層有效地互動；
5）客戶認可這種公司內部的開發方式帶來的良好的溝通和高質量的產品。

缺點：
螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，並做出相關反應是不容易的。
因此，這種模型往往適應於內部的大規模軟體開發。該模型建設週期長，而軟體技術發展比較快，所以經常出現軟體開發完畢後，和當前的技術水平有了較大的差距，無法滿足當前使用者需求。

1.6. Ｖ模型
V 模型的左邊下降的是開發過程各階段，與此相對應的是右邊上升的部分，即各測試過程的各個階段。
V 模型的優點在於它非常明確地標明瞭測試過程中存在的不同級別，並且清楚地描述了這些測試階段和開發各階段的對應關係。
V模型的缺陷及解決思路
V模型僅僅把測試過程作為在需求分析、系統設計及編碼之後的一個階段，忽視了測試對需求分析,系統設計的驗證，需求的滿足情況一直到後期的驗收測試才被驗證。
解決的思路是，當一個軟體開發的時候，研發人員和測試人員需要同時工作，測試在軟體做需求分析的同時就會有測試用例的跟蹤，這樣，可以儘快找出程式錯誤和需求偏離，從而更高效的提高程式質量，最大可能的減少成本，同時滿足使用者的實際軟體需求。

優點：
1 每一個階段都清晰明瞭，便於控制開發的每一個過程。
2 既包含單元測試又包含系統測試。
缺點：
1 測試介入的比較晚，對於前期的一些缺陷無從發現和修改。
2 測試和開發序列。

1.7. Ｗ模型

相對於V模型，W模型更科學。W模型是V模型的發展，強調的是測試伴隨著整個軟體開發週期，而且測試的物件不僅僅是程式，需求、功能和設計同樣要測試。測試與開發是同步進行的，從而有利於儘早地發現問題。

優點
1 測試伴隨著軟體的整個生命週期，例如，在需求分析結束後就可以進行需求分析測試。
2 測試於開發是並行獨立進行的。
缺點
1 對有些專案，開發過程中根本沒有文件產生，故W模型無法使用。
2 對於需求和設計的測試技術要求很高，實踐起來很困難。

以下為例:
1：雙肩揹包的測試用例
功能：是否能裝書，是否能裝其他東西，它最大的容量是否和他的描述一致
效能：書包帶是否結實，是否耐髒，能不能水洗
壓力：最多能裝多少書，超過多少書包會裝不下，超過多少書包會斷
安全：做工是否整齊，是否有開線的地方，縫線的地方會不會扎手
介面：書包外觀是否會引起不適，配色是否合理，設計是否方便，有無文字，圖案

2：椅子的測試用例
功能：是否能坐人，承重多少描述一，是否和需求一致
效能：坐著是否舒服，是成人椅還是兒童椅
壓力：一個人能坐嘛，兩個人呢，最多承重多少斤
安全：椅子的做工是否精細，有沒有釘子外翹，
介面：椅子高度是否符合

3:電梯的測試用例
功能：按鈕是否開門，關門，每一層按鈕是否有效，電梯內燈、電話是否正常
效能：電梯上下速度多快
壓力：多少人，多重超載
安全：手機是否有訊號，有人進門時電梯關閉是否會夾到人，是否會經常故障