測試1：測試相關概念

1.測試相關概念

---

1.1.測試概念

1.1.1.需求

符合正式文檔規定的條件和權能，包括用戶需求和軟件需求

它們之間的的轉換是：溝通

用戶需求和軟件需求的區別：

可否指導開發人員開發，測試人員編寫測試用例

1.1.2.缺陷Bug

與正確的需求規格說明書不一致或與用戶合理的指望不相同

缺陷的狀態：

new、open、fixed、closed、reopen、rejected、delay

1.1.3.測試用例

向被測程序輸入的一組集合，包括要素：

測試環境、測試數據、測試步驟、測試預期結果、測試版本、備註

思路：

1.對核心主要功能進行測試

2.進行異常（逆向、擴展、發散）--容錯性測試

3.寫功能測試以外的測試點（安全、性能、界面、易用）

存在的問題：

1.設計測試用例是費時費力的工做，比執行時間長

2.測試的覆蓋率沒法衡量，對新版本的重複測設很難實施

2.開發模型和測試模型

1.軟件生命週期

軟件生命週期是指軟件的產生直到報廢的生命週期。從軟件產品的設想開始到軟件再也不使用而結束的時間

具體包括：
問題的定義及規劃，需求分析，軟件設計（概要，詳細），軟件編碼，軟件測試（單元測試，集成測試，系統測試，驗收測試），運行維護

2.測試生命週期

測試周期是指從測試項目計劃創建到BUG提交的整個測試過程。 軟件測試周期並行與軟件生命週期，存在於軟件生命週期的各個階段。

參考 ：軟件測試的流程

一、需求分析階段：閱讀需求、對需求進行分解、分析，主要就是對業務的學習，分析需求點，參與需求評審會議

二、測試計劃階段：主要任務就是編寫測試計劃、測試方案，參考軟件需求規格說明書，項目整體計劃，內容包括測試範圍（來自需求文檔），進度安排，人力物力的分配，總體測試策略的制定。風險評估與規避措施有一個制定。

三、測試設計、測試開發階段：測試人員適當的瞭解設計，對於設計測試用例是頗有幫助的，測試人員搭建測試用例框架，根據需求和設計編寫一部分測試用例。

四、測試執行階段：測試執行階段是軟件測試人員最爲重要的工做階段，根據測試用例和計劃執行測試。

​ 搭建環境，執行冒煙測試（預測試）-而後進入正式測試，bug管理直到測試結束

五、測試評估階段：執行的過程當中記錄、管理缺陷，測試完成後編寫測試報告，進行測試評估，確認是否能夠上線

• 測試報告包含哪些內容

  測試概況--測試過程分析--缺陷分析--測試結論--測試清單

3.開發模型

3.1 瀑布模型：串行

適用：項目需求穩定，需求變動較少的項目或是以前已有的作過的產品

優勢：

分步清晰，階段性強：測試階段單獨分出來

缺陷：集成之日就是爆炸之時

（1）測試階段靠後，發現問題的時機晚，修改爲本高，風險大。

（2）測試階段靠後，誤認爲測試不重要

（3）項目成果不能及時分享其它項目

（4）不能適應需求變化

瀑布模型：

把軟件開發模型分爲好幾個階段，包括軟件計劃、需求分析、設計、實現、軟件測試、軟件運行維護。

具備一種比較明顯的分層，每一階段的結果文檔會做爲下一階段的輸入，強調文檔，整個週期完成的差很少了才能看到結果；

沒有迭代和反饋，只能一步一步來，流程沒有回頭路。不能適應客戶不斷變化的需求，後期須要改動時成本也比較大

測試比較晚，基本上是在軟件完成以後進行的測試

3.2 螺旋模型：漸進式

適用：複雜度高、風險大、規格大，作一點測一點，測試必須跟隨開發。沒有獨立的測試時間和階段

強調：風險，保證各個階段的質量

缺陷點：對人員的要求比較高，投入時間多，人力成本高，進度緩慢

3.3 增量和迭代：

目的：大型項目，爲減小項目的風險

增量：顯著下降項目風險，逐塊建造，一部分一部分的作，新版本、新加功能對軟件其餘功能沒有影響

迭代：反覆求精，先輪廓再細化，新版本、新加、刪除功能對軟件其餘功能有影響，原來功能須要修改

3.4敏捷開發模型：快速迭代，若干小迭代

敏捷宣言4條：（敏捷開發與傳統開發的區別）

（1）輕文檔，對文檔依賴度低，但仍是須要。強調軟件的可用性

（2）強調人與人之間的溝通

（3）客戶參與

（4）在正式發佈以前擁抱變化，

敏捷開發有不少方式，SCRUM是比較流行的一種

特色：

（1）三種角色：產品經理、項目經理、研發團隊

（2）不超過10人（5-9人）

（3）天天有站立會不超過15分鐘，回答昨天作了什麼，今天要作什麼，有什麼問題

（4）迭代時間1-4周。每次迭代產生必定的交付（會作出一點功能，即便還不完善）

流程：

po整理USER STORY --開會學習USER STORY，肯定每次迭代完成的USER STORY

----分配USER STORY，肯定完成時間--開發完成--測試中--測試完成--待發布上線--發佈上線

敏捷開發：

按一個短的迭代週期工做，強調「快」，每次迭代交付一些成果，（或者說先作出一個不完美但能實現必定的功能的版本）；讓客戶參與進來，有新需求就，快速響應變化，迭代產生新版本，縮短軟件版本的週期。

強調開發軟件而不是文檔。

特色：讓客戶參與進來，客戶需求的變更和軟件有些不符合需求的地方能夠第一時間進行了解和改動； 縮短版本週期； 每隔一段時間（一個迭代週期），團隊能夠在工做方面進行檢討和改進，調整本身的行爲； 強調開發軟件而不是文檔，提升編程人員的積極性。

敏捷測試：

以用戶需求爲中心，在每個迭代週期都須要進行測試，

基於自動化測試->速度快、敏捷

更強調測試的速度和適應性，側重計劃的不斷調整以適應需求的變化

強調面對面的溝通、協做，強調團隊的責任，不太關注對缺陷的記錄與跟蹤。缺陷修復的成本也較低

4. 軟件測試V模型

目的：改進軟件開發的效率和效果

是瀑布模型的變種

單元和集成測試：檢測程序的執行是否知足設計的要求

系統測試：檢測系統功能和性能的質量特性是否達到系統要求的指標

驗收測試：肯定軟件的實現是否知足用戶需求、合同要求

侷限性：測試階段在編碼以後，未在許愛u階段就進入測試

4.2 W模型（雙V）

解決V的缺點，每一個階段都有測試工做，不必定是測試人員參與

特色：

1.測試與開發並行

2.測試的對象不只是程序，好包括需求、設計等

3.能儘早全面發現問題

侷限性：測試盒開發保存一種線性的先後關係，上一階段徹底結束，纔可開始下一階段，不能支持敏捷開發模式

V模型和W模型的比較：

V模型：把測試過程做爲在需求分析、系統設計及編碼以後的一個階段，忽視了測試對需求分析，系統設計的驗證，需求的知足狀況一直到後期的驗收測試才被驗證。（應該比較多包括系統測試和驗收測試）

W模型：測試的活動與軟件開發同步進行，測試的對象不只僅是程序，還包括需求和設計。由於在需求階段測試就已經介入了，後面每一階段的開發都須要通過測試，可以儘早發現軟件的缺陷，下降debug的成本

4.3 敏捷測試（解決V\W的缺陷）：

溝通、適應

文檔能夠寫粗略，能夠畫思惟導圖，藉助自動化

3.如何描述一個缺陷

對bug的描述儘可能簡短但要求清晰，對bug出現的條件進行詳細的描述，包括輸入的測試用例、使用的環境、有沒有和其餘軟件同時運行，以及須要寫清bug出現的位置，幫助開發更好定位。

按照用戶體驗（bug是否很嚴重的影響用戶體驗）、影響系統的程度進行評級。

3.1 要素（一條bug記錄的組成）

測試環境、測試數據（內容）、測試步驟、預期結果、實際結果、缺陷級別、測試版本、前提條件、發生的位置

3.2 缺陷的級別（如何對一個bug評級）

3.2.1 簡單版

崩潰 嚴重 通常 次要 建議

A B C D E

崩潰：直接形成軟件不能使用，形成死機、數據丟失等

嚴重：功能不能使用，數據丟失。與需求嚴重不符，不影響其餘功能測試的狀況下能夠繼續版本測試

通常：功能沒有徹底實現但不影響使用，不影響系統的穩定性

次要：界面、性能缺陷，建議類問題，文字錯誤等

3.2.2 詳細描述

Bug的priority（）和severity（）是兩個重要屬性，一般人員在提交bug的時候，只定義severity，而將priority交給leader定義，一般bug管理中，severity分爲四個等級blocker、critical、major、minor/trivial，而priority分爲五個等級immediate、urgent、high、normal、low。 Severity：

一、blocker：即系統沒法執行，崩潰，或嚴重資源不足，應用模塊沒法啓動或異常退出，沒法測試，形成系統不穩定。常見的有嚴重花屏、內存泄漏、用戶數據丟失或破壞、系統崩潰/死機/凍結、模塊沒法啓動或異常退出、嚴重的數值計算錯誤、功能設計與需求嚴重不符、其它致使沒法測試的錯誤， 如服務器500錯誤。

二、critical：即映像系統功能或操做，主要功能存在嚴重缺陷，但不會映像到系統穩定性。常見的有：功能未實現，功能錯誤、系統刷新錯誤、數據通信錯誤、輕微的數值計算錯誤、影響功能及界面的錯誤字或拼寫錯誤。

三、major：即界面、性能缺陷、兼容性，常見的有：操做界面錯誤，邊界條件錯誤，提示信息錯誤，長時間操做無進度提示，系統未優化，兼容性問題。

四、minor/trivial：即易用性及建議性問題。 Priority 一、immediate：即立刻解決， 二、urgent：急需解決 三、high：高度重視，有時間要立刻解決

五、low：在系統發佈前解決，或確承認以不用解決。

3.3 bug的生命週期

Start--New :測試人員發現bug，提交到平臺後的狀態爲new

New--Open:測試人員將bug提交給某個研發人員的狀態爲Open

Open--Regected:研發人員驗證不是缺陷，將狀態改成rejected，返回給測試

Open--Delay:研發人員驗證是缺陷，但不影響使用，等下個版本在修改，Delay

Open--Fixed：研發人員驗證是bug，進行修改

Fixed--Closed：研發人員修改完成，測試人員驗證經過，就Closed改bug

Fixed--Reopen:研發人員修改後，測試人員沒有驗證經過，就是Reopen再到Fixed

無效的bug:

open--closed open--rejected--closed

3.4bug都有哪些週期，請你描述不一樣類別的bug？

3.5 如何發現更多的缺陷

1.二八原則--人員、模塊

2.逆向思惟、擴展性思惟

3.不要依賴需求和測試用例

4.測試儘早介入