目錄

1. 什么是軟體測驗？

2. 測驗與除錯的區別

3. 軟體測驗的目的和原則

4. 什么是需求

5. 什么是bug

5.1 如何描述一個bug

5.2 如何定義bug的級別

5.3 bug的生命周期

6. 什么是測驗用例

7. 開發模型和測驗模型

7.1 軟體的生命周期

7.2 瀑布模型

7.3 螺旋模型

7.4 增量、迭代

7.5 敏捷

7.5.1 scrum

7.5.2 敏捷中的測驗

8. 軟體測驗v模型

9. 軟體測驗W模型

10. 配置管理和軟體測驗

10.1 什么是配置管理

10.2 軟體配置管理的應用

10.3 實施軟體配置管理的好處

10.4 配置管理與軟體測驗

---

1. 什么是軟體測驗？

軟體測驗就是證明軟體不存在錯誤的程序

軟體測驗就是為了證明程式能夠正確運行

2. 測驗與除錯的區別

（1）目的不同：① 測驗的任務是發現程式中的缺陷

② 除錯的任務是定位并且解決程式中的問題

（2）參與角色不同：① 測驗主要是由測驗人員和開發人員來執行，黑盒測驗主要由測驗人員完 成、單元/集成測驗主要是由開發人員執行

② 除錯由開發人員完成

（3）執行的階段不同：① 測驗貫穿整個軟體開發生命周期

② 除錯一般在開發階段

3. 軟體測驗的目的和原則

目的：驗證軟體有或沒有問題

原則：以客戶為中心，遵循軟體測驗的規范、流程、標準和要求

1. 好的測驗方案是極可能發現迄今為止尚未發現的錯誤的測驗方案

2. 成功的測驗是發現了至今為止尚未發現的錯誤的測驗

3. 測驗并不僅僅是為了找出錯誤，通過分析錯誤產生的原因、階段及錯誤發生的趨勢 ① 幫助專案管理者了 解當前軟體開發程序中的缺陷，以便及時糾錯、改進 ② 幫助測驗人員設計出有針對性的測驗方法，改善 測驗的效率和有效性 ③ 讓開發人員知道錯誤產生的重災區，加強自測驗 ④ 讓客戶清楚我們專業的質 量保證團隊，可以向他們提交一份滿意的答卷

4. 沒有發現錯誤的測驗也是有價值的，完整的測驗是評定軟體質量的一種方法

5. 根據測驗目的的不同，還有回歸測驗、壓力測驗、性能測驗、安全測驗等，分別為了檢驗修改或優化程序是 否引發新的問題、軟體所能達到處理能力和是否達到預期的處理能力等

6. 軟體測驗為了建立軟體的信心

7. 從測驗的目的出發，大概可以分為兩類：為了驗證程式能正常作業的測驗 為了驗證程式不能正常運行的測驗

4. 什么是需求

IEEE定義：軟體需求是

(1)用戶解決問題或達到目標所需條件或權能(Capability)

(2)系統或系統部件要滿足合同、 標準、規范或其它正式規定檔案所需具有的條件或權能

(3)一種反映上面(1)或(2)所述條件或權能的檔案說明，它包括功能性需求及非功能性需求，非功能性需求對設計和實作提出了限制，比如性能要求，質量標準，或者設計限制

在多數軟體公司，會有兩部分需求，一部分是用戶需求，一部分是軟體需求

用戶需求：可以簡單理解為甲方提出的需求，如果沒有甲方，那么就是終端用戶使用產品時必須要完成的任務，該需求一般比較簡略

軟體需求：或者叫功能需求，該需求會詳細描述開發人員必須實作的軟體功能， 軟體需求是測驗人員進行測驗作業的基本依據

5. 什么是bug

準確的來說：① 當且僅當規格說明是存在的并且正確，程式與規格說明之間的不匹配才是錯誤

② 當沒有需求規格說明書時，判斷標準以最終用戶為準：當程式沒有實作其最終用 戶合理預期的功能要求時，就是軟體錯誤

5.1 如何描述一個bug

一個合格的bug描述應該包括以下幾個部分：

1、發現問題的版本

開發人員需要知道出現問題的版本，才能夠獲取對應版本的代碼來重現故障，并且版本的標識也有利于統計和分析每個版本的質量

2、問題出現的環境

環境分為硬體環境和軟體環境，如果是web專案，需要描述瀏覽器版本，客戶機作業系統等，如果是app專案，需要描述機型、解析度、作業系統版本等，詳細的環境描述有利于故障的定位

3、錯誤重現的步驟

描述問題重現的最短步驟

4、預期行為的描述

要讓開發人員指導怎么樣才是正確的，尤其要以用戶的角度來描述程式的行為是怎樣的，如果是依據需求提出的故障，能寫明需求的來源是最好的， 要相信：測驗人員是最懂需求的

5、錯誤行為的描述

描述錯誤的現象，crash等可以上傳log，UI問題可以有截圖

6、其他某些公司會有一些其他的要求，例如故障的分類：功能故障，界面故障，兼容性故障等，有些有優先級的分類，嚴重影響測驗需要開發人員優先修改的，可以設定優先級為高

7、不要把多個bug放到一起

在無法確認是同一段代碼造成的故障時，不要將bug放在一起提交

案例：

提交了如下bug：

1、在短信串列，選擇一條短信，進行洗掉，洗掉失敗

2、在短信串列，選擇一條短信，進行查看，在查看頁面，進行洗掉，洗掉失敗

故障發現版本：VPS20180226_01

故障類別：兼容性

故障優先級：中

故障標題:ie下界面顯示例外，界面文字有重疊

故障描述：

測驗環境：win7+IE8

測驗步驟：1、打開vps首頁，點擊“通知”鏈接，進入通知頁面

預期結果：通知頁面顯示正確，一頁顯示10條通知，按時間順序倒序排列

實際結果：頁面顯示10條通知，通知順序正確，但是頁面文字有重疊

附件：上傳截圖

5.2 如何定義bug的級別

在開發和測驗的爭執中，一部分是究竟是不是bug？一部分是bug的級別有點高吧？那么如何定義bug的級別？

bug的定義每個公司都不一致，在定義級別之前需要查看公司規范，

以下為樣例：

1、Blocker（崩潰）：

阻礙開發或測驗作業的問題；造成系統崩潰、死機、死回圈，導致資料庫資料丟失，與資料庫連接錯誤，主要功能 喪失，基本模塊缺失等問題，如：代碼錯誤、死回圈、資料庫發生死鎖、重要的一級選單功能不能使用等（該問題 在測驗中較少出現，一旦出現應立即中止當前版本測驗）

2、Critical（嚴重）：

系統主要功能部分喪失、資料庫保存呼叫錯誤、用戶資料丟失，一級功能選單不能使用但是不影響其他功能的測 試，功能設計與需求嚴重不符，模塊無法啟動或呼叫，程式重啟、自動退出，關聯程式間呼叫沖突，安全問題、穩 定性等，如：軟體中資料保存后資料庫中顯示錯誤，用戶所要求的功能缺失，程式介面錯誤，數值計算統計錯誤等 （該等級問題出現在不影響其他功能測驗的情況下可以繼續該版本測驗）

3、Major（一般）：

功能沒有完全實作但是不影響使用，功能選單存在缺陷但不會影響系統穩定性，如：操作時間長、查詢時間長、格 式錯誤、邊界條件錯誤，洗掉沒有確認框、資料庫表中欄位過多等(該問題實際測驗中存在最多）

4、Minor（次要）：

界面、性能缺陷，建議類問題，不影響操作功能的執行，可以優化性能的方案等，如：錯別字、界面格式不規范， 頁面顯示重疊、不該顯示的要隱藏，描述不清楚，提示語丟失，文字排列不整齊，游標位置不正確，用戶體驗感受 不好，可以優化性能的方案等（此類問題在測驗初期較多，優先程度較低；在測驗后期出現較少，應及時處理）

5.3 bug的生命周期

每個公司、每一個工具對bug生命周期的定義都是不一致的，下面僅是一個常見的例子

測驗人員應該跟蹤一個Bug的整個生命周期，從Open到Closed的所有狀態

● New:新發現的Bug，未經評審決定是否指派給開發人員進行修改

● Open：確認是Bug，并且認為需要進行修改，指派給相應的開發人員

● Fixed:開發人員進行修改后標識成修改狀態，有待測驗人員的回歸測驗驗證

● Rejected：如果認為不是Bug，則拒絕修改

● Delay:如果認為暫時不需要修改或暫時不能修改，則延后修改

● Closed：修改狀態的Bug經測驗人員的回歸測斌驗證通過，則關閉Bug

● Reopen：如果經驗證Bug仍然存在，則需要重新打開Bug，開發人員重新修改

無效的bug：open->closed open-rejected-closed

缺陷狀態變更流程每個專案團隊的實際做法可能不大一樣，并且需要結合實際的開發流程和協作流程來使用

例如，測驗人員新發現的Bug，必須由測驗組長評審后才決定是否Open并分派給開發人員，測驗人員Open的Bug 可以直接分派給Bug對應的程式模塊的負責人，也可以要求都先統一提交給開發主管，由開發主管審核后再決定是否分派給開發人員進行修改， Bug的跟蹤以及狀態變更應該遵循一些基本原則：

測驗人員對每一個缺陷的修改必須重新取一個包含更改后的代碼的新版本進行回歸測驗，確保相同的問題不 再出現，才能關閉缺陷

對于拒絕修改和延遲修改的Bug，需要經過包含測驗人員代表和開發人員代表、用戶方面的代表（或代表用戶角度的人）的評審

6. 什么是測驗用例

測驗用例（Test Case）是為了實施測驗而向被測驗的系統提供的一組集合，這組集合包含：測驗環境、操作步驟、測驗資料、預期結果等要素

測驗程序中可能會遇到以下問題：

① 不知道是否較全面的測驗了所有功能

② 測驗的覆寫率無法衡量

③ 對新版本的重復測驗很難實施

④ 存在大量冗余測驗影響測驗效率

測驗用例的產生就是為了解決上述的問題

7. 開發模型和測驗模型

隨著軟體工程學科的發展，人們對計算機軟體的認識逐漸深入，軟體作業的范圍不僅僅局限在程式撰寫，而是擴展到了整個軟體生命周期，如軟體基本概念的形成、需求分析、設計、實作、測驗、安裝部署、運行維護，直到軟體被更新和替換新的版本，軟體工程還包括很多技術性的管理作業，例如程序管理、產品管理、資源管理和質量管理，在這些方面也逐步地建立起了標準或規范，

7.1 軟體的生命周期

軟體生命周期是指從軟體產品的設想開始到軟體不再使用而結束的時間

如果把軟體看成是有生命的事物，那么軟體的生命周期可以分成6個階段，即需求分析、計劃、設計、編碼、測驗、運行維護

???????

a) 需求階段

測驗人員了解需求、對需求進行分解，得出測驗需求

b) 計劃階段

根據需求撰寫測驗計劃/測驗方案

c) 設計階段

測驗人員適當的了解設計，對于設計測驗用例是很有幫助的，測驗人員搭建測驗用例框架，根據需求和設計撰寫一部分測驗用例

d) 編碼階段

測驗人員一般是不需要編碼的，但已經編碼的模塊，專業的白盒測驗人員可以計劃執行單元測驗，完善、細化測驗用例以及調整測驗計劃和方案

e) 測驗階段

測驗階段是軟體測驗人員最為重要的作業階段，根據測驗用例和計劃執行測驗，在執行的程序中記錄、管理 缺陷，測驗完成后撰寫測驗報告

f) 運行維護

測驗人員需要參與專案的實施作業，測驗人員對專案產品的業務和操作非常了解，加上測驗人員的溝通表達 能力一般都比較強，所以測驗人員可以參與用戶使用軟體的培訓，在試運行專案時收集問題并及時反饋給相關負責人

7.2 瀑布模型

瀑布模型在軟體工程中占有重要地位，是所有其他模型的基礎框架，瀑布模型的每一個階段都只執行一次，因此是 線性順序進行的軟體開發模式

優點：

①強調開發的階段性；

②強調早期計劃及需求調查；

③強調產品測驗，

缺點：

①依賴于早期進行的唯一一次 需求調查，不能適應需求的變化；

②由于是單一流程，開發中的經驗教訓不能反饋應用于本產品的程序；

③風險往往遲至后期的測驗階段才顯露，因而失去及早糾正的機會，

瀑布模型的一個最大缺陷在于，可以運行的產品很遲才能被看到，這會給專案帶來很大的風險，尤其是集成的風險，因為如果在需求引入的一個缺陷要到測驗階段甚至更后的階段才發現，通常會導致前面階段的作業大面積返 工，業界流行的說法是：“集成之日就是爆炸之日”，盡管瀑布模型存在很大的缺陷，例如，在前期階段未發現的錯 誤會傳遞并擴散到后面的階段，而在后面階段發現這些錯誤時，可能已經很難回頭再修正，從而導致專案的失敗， 但是目前很多軟體企業還是沿用了瀑布模型的線性思想，在這個基礎上做出自己的修改，例如細化了各個階段，在 某些重點關注的階段之間摻入迭代的思想，

在瀑布模型中，測驗階段處于軟體實作后，這意味著必須在代碼完成后有足夠的時間預留給測驗活動，否則將導致 測驗不充分，從而把缺陷直接遺留給用戶

7.3 螺旋模型

螺旋模型（Spiral Model）

一般在軟體開發初期階段需求不是很明確時，采用漸進式的開發模式，螺旋模型是漸進式開發模型的代表之一， 這對于那些規模龐大、復雜度高、風險大的專案尤其適合，這種迭代開發的模式給軟體測驗帶來了新的要求，它不允許有一段獨立的測驗時間和階段，測驗必須跟隨開發的迭代而迭代，因此，回歸測驗的重要性就不言而喻了

優點：

① 強調嚴格的全程序風險管理，

② 強調各開發階段的質量，

③ 提供機會檢討專案是否有價值繼續下去，

缺點：

① 引入非常嚴格的風險識別、風險分析和風險控制，這對風險管理的技能水平提出了很高的要 求，這需要人員，資金和時間的投入，

7.4 增量、迭代

增量開發能顯著降低專案風險，結合軟體持續構建機制，構成了當今流行的軟體工程最佳實踐之一，增量開發模型，鼓勵用戶反饋，在每個達代程序中，促使開發小組以一種回圈的、可預測的方式驅動產品的開發，因此，在這種開發模式下，每一次的迭代都意味著可能有需求的更改、構建出新的可執行軟體版本，意味著測驗需要頻繁進行，測驗人員需要與開發人員更加緊密地協作，

增量通常和迭代混為一談，但是其實兩者是有區別的，

增量是逐塊建造的概念，例如畫一幅人物畫，我們可以先畫人的頭部，再畫身體，再畫手腳……

而迭代是反復求精的概念，同樣是畫人物畫，我們可以采用先畫整體輪廓，再勾勒出基本雛形，再細化、著色

7.5 敏捷

《敏捷宣言》： 我們通過身體力行和幫助他人來揭示更好的 軟體開發方式，經由這項工怍，我們形成了如下價值觀，

個體與互動重于程序和工具

可用的軟體重于完備的檔案

客戶協作重于合同談判

回應變化重于遵循計劃

在每對比對中，后者并非全無價值，但我們更看重前者，

由敏捷宣言可以看出，敏捷其實是有關軟體開發的社會工程(Social Engineering)的，敏捷的主要貢獻在于他更多地 思考了如何去激發開發人員的作業熱情，這是在軟體工程幾十年的發展程序中相對被忽略的領域，

敏捷開發有很多種方式，其中scrum是比較流行的一種

7.5.1 scrum

scrum里面的角色

scrum由product owner(產品經理)、scrum master(專案經理)和team(研發團隊)組成

① 其中product owner負責整理user story(用戶故事)，定義其商業價值，對其進行排序，制定發布計劃，對產 品負責

② scrum master 負責召開各種會議，協調專案，為研發團隊服務

③ 研發團隊則由不同技能的成員組成，通過緊密協同，完成每一次迭代的目標，交付產品

迭代開發

與瀑布不同，scrum將產品的開發分解為若干個小sprint(迭代)，其周期從1周到4周不等，但不會超過4周，參與的 團隊成員一般是5到9人，每期迭代要完成的user story是固定的，每次迭代會產生一定的交付

scrum的基本流程

a) 產品負責人負責整理user story，形成左側的product backlog

b) 發布計劃會議：product owner負責講解user story，對其進行估算和排序，發布計劃會議的產出就是制定出 這一期迭代要完成的story串列，sprint backlog

c) 迭代計劃會議：專案團隊對每一個story進行任務分解，分解的標準是完成該story的所有任務，每個任務都有明確的負責人，并完成工時的初估計

d) 每日例會：每天scrum master召集站立會議，團隊成員回答昨天做了什么今天計劃做什么，有什么問題

e) 演示會議：迭代結束之后，召開演示會議，相關人員都受邀參加，團隊負責向大家展示本次迭代取得的成果，期間大家的反饋記錄下來，由po整理，形成新的story

f) 回顧會議：專案團隊對本期迭代進行總結，發現不足，制定改進計劃，下一次迭代繼續改進，已達到持續改進的效果

7.5.2 敏捷中的測驗

挑戰1：輕檔案

挑戰2：快速迭代

1、測驗作業的核心內客是沒有變的，就是不斷地找Bug，只是要調整好自己的心態，一切以敏捷的原則為主

2、測驗人員不能依賴檔案，測驗用例作用減弱，更多的采用思維導圖、探索性測驗（強調自由度，設計和執行同 時執行，根據測驗結果不斷調整測驗計劃）、自動化測驗

3、敏捷講求合作，在敏捷專案組中，測驗人員應該更主動點，多向開發人員了解需求、討論設計、一起研究Bug 出現的原因

8. 軟體測驗v模型

V模型最早是由Paul Rook在２０世紀８０年代后期提出的，目的是改進軟體開發的效率和效果，是瀑布模型的變種

① 明確的標注了測驗程序中存在的不同型別的測驗，并且清楚的描述了這些測驗階段和開發程序期間各階段的 對應關系

② V模型指出，單元和集成測驗應檢測程式的執行是否滿足軟體設計的要求；系統測驗應檢測系統功能、性能的 質量特性是否達到系統要求的指標；驗收測驗確定軟體的實作是否滿足用戶需要或合同的要求

③ 局限性:僅僅把測驗作為在編碼之后的一個階段，未在需求階段就進入測驗

9. 軟體測驗W模型

a) W模型增加了軟體各開發階段中應同步進行的驗證和確認活動，W模型由兩個V字型模型組成，分別代表測驗 與開發程序，圖中明確表示出了測驗與開發的并行關系，

b) W模型特點：測驗的物件不僅是程式，需求、設計等同樣要測驗，測驗與開發是同步進行的

c) W模型優點：有利于盡早地全面的發現問題，例如，需求分析完成后，測驗人員就應該參與到對需求的驗證和確認活動中，以盡早地找出缺陷所在，同時，對需求的測驗也有利于及時了解專案難度和測驗風險，及早制定應對措施，顯著減少總體測驗時間，加快專案進度，

d) 局限性：需求、設計、編碼等活動被視為串行的；測驗和開發活動也保持著一種線性的前后關系，上一階段 完全結束，才可正式開始下一個階段作業，無法支持敏捷開發模式，對于當前軟體開發復雜多變的情況，W模型并不能解除測驗管理面臨著困惑，

10. 配置管理和軟體測驗

是否真正做過專案從對配置管理的熟悉程度來看，是最容易辨別的

SVN &GIT

很多人其實對配置管理并不熟悉，對配置管理的作用也很模糊，存在很多的誤解，認為配置管理是可有可無的東 西，甚至很多測驗人員也對此知之甚少，認為軟體測驗與配置管理的關系不大，實際上，一個配置管理做得好的公 司，它的測驗活動也會開展得比較順利，測驗人員在這種環境下作業也會碰到更少的阻礙和困難

在參與當代軟體開發時，必須具備軟體配置管理方面的基本素養，不懂軟體專案的配置管理，就不懂軟體開發管 理，沒有對軟體專案進行配置管理，其實就沒有進行軟體專案開發管理

10.1 什么是配置管理

配置管理( Configuration Management)是通過對在軟體生命周期不同的時間點上的軟體配置進行標識，并對這些被標識的軟體配置項的更改進行系統控制，從而達到保證軟體產品的完整性和可溯性的程序

10.2 軟體配置管理的應用

軟體開發程序中會產生大量軟體產品（包括檔案、源代碼和資料等），且這些產品之間存在關聯關系，同一軟體產品也會發生變更，從而產生許多版本，軟體開發小組必須清晰地知道會有哪些產品、這些產品會有哪些不同的形式 和版本，開發小組必須清晰地知道如何將產品的變更通知給受影響的小組，如果不能有效地了解軟體產品及其變 更，開發小組將很難組裝這些軟體產品，很難得到所需的軟體產品

10.3 實施軟體配置管理的好處

實施軟體配置管理(SCM)，至少能給專案團隊帶來如下好處

(1)能夠對專案中的檔案、代碼等的變化進行有效管理

(2)能夠方便地重現某個檔案的歷史版本

(3)能夠重新編譯某個歷史版本，使維護作業變得容易

(4)能夠使 異地多團隊開發、并行開發成為現實

(5)從公司級看，實行統一的配置管理流程可提高專案組間人員流動時的作業效率

10.4 配置管理與軟體測驗

測驗人員是SCM中的參與者，有些公司也會把測驗人員和配置管理員合二為一，如果配置管理流程不規范，或者沒有遵循一定的配置管理流程進行軟體測驗活動，也可能導致很嚴重的后果

假設開發人員修正了一個Bug，然后找測驗人員過去討論，測驗人員在開發人員的機器上重新測驗了一下，發現 Bug沒再出現了，修復了，這時候，如果測驗人員把缺陷關閉了，則可能導致缺陷莫名其妙地在用戶那邊又出現了

其實，原因可能僅僅是開發人員把這個Bug修改的代碼沒有提交的到配置管理資料庫中，但是作為測驗人員有沒有責任呢？

當然有，因為測驗人員也沒有按照規范的配置管理流程執行測驗，測驗人員應該從配置庫取源代碼編譯后再測驗，只有看到新的構建版本不再出現那個Bug，才能把缺陷庫中的Bug關閉

如有錯誤還請各位小伙伴批評指正

最后美圖收尾嘻嘻~~（星之守護者 迦娜）