（一）軟體測驗的定義
在規定的條件下對程式進行操作，以發現程式錯誤，衡量軟體質量，并對其是否能滿足設計要求進行評估的程序，
（二）軟體測驗方法的分類
按開發階段劃分：
-
單元測驗（Unit Testing）
又稱
模塊測驗，對軟體的組成單位進行測驗，其目的是檢驗軟體基本組成單位的正確性，測驗的物件是軟體測驗的最小單位：模塊，【例如：登錄測驗】 -
集成測驗（Integration Testing）
集成測驗也稱
聯合測驗（聯調）、組裝測驗：將程式模塊采用適當的集成策略組裝起來，對系統的介面及集成后的功能進行正確性檢測的測驗作業，集成主要目的是檢查軟體單位之間的介面是否正確，【例如：京東購物用微信支付】 -
系統測驗（System Testing）
將軟體系統看成是一個系統的測驗，包括
對功能、性能以及軟體所運行的軟硬體環境進行測驗，時間大部分在系統測驗執行階段，包括回歸測驗和冒煙測驗，【例如：房子能不能住人（功能） 房子抗不抗臺風（性能）；
? QQ能不能注冊，能不能登錄，能不能聊天發訊息（功能） 人數太多會不會卡頓（性能）】
??Tips：系統測驗如何開展？
需求評審（功能需求、性能需求、介面需求） - 測驗計劃 - 測驗用例 - 用例評審 - 測驗環境搭建（平臺、架構、web服務器、資料庫） - 執行用例 - 提交問題 - 缺陷的跟蹤和回歸測驗 - 測驗報告
-
驗收測驗（Acceptance Testing）
是部署軟體前的最后一個測驗操作，它是技術測驗的最后一個階段，也稱為
交付測驗，向軟體購買者展示該軟體系統滿足原始需求，實施驗收測驗的策略有三種：
正式驗收測驗- 非正式驗收測驗或
α測驗 β測驗
按是否手工執行劃分：
-
手工測驗（Manual Testing）
手工測驗是
由人一個一個的輸入用例，然后觀察結果，和機器測驗（指使用機器去測驗，例如：手機、電腦）相對應，屬于比較原始但是必須的一種， -
自動化測驗（Automation Testing）
所謂自動化測驗，就是
在預設條件下運行系統或應用程式，評估運行結果，（預先條件包括：正常條件和例外條件），簡單來說，自動化測驗就是把人為驅動的測驗行為，轉化為機器執行的一種程序，
按是否查看代碼劃分：
-
黑色測驗（Black-Box Testing）
黑盒測驗也是功能測驗，測驗中把被測的軟體當做一個黑盒子，不關心盒子的內部結構是什么，只關心軟體的
輸入資料和輸出資料， -
白盒測驗（White-Box Testing）
白盒測驗又稱結構測驗、透明盒測驗、邏輯驅動測驗或基于代碼的測驗，白盒測驗是指打開盒子，去研究里面的
源代碼和程式結果， -
灰盒測驗（Gray-Box Testing）
灰盒測驗是介于白盒測驗和黑盒測驗之間的一種，灰盒測驗多用于集成測驗階段，
不僅關注輸入、輸出的正確性，同時也關注程式內部的情況，
按是否運行劃分：
-
靜態測驗（Static Testing）
靜態方法是指
不運行被測程式本身，僅通過分析或檢查源程式的語法、結構、程序、介面等來檢查程式的正確性，對需求規格說明書、軟體設計說明書、源程式做結構分析、流程圖分析、符號執行來找錯，【靜態測驗屬于白盒測驗】 -
動態測驗（Dynamic Testing）
動態測驗是指通過
運行被測程式，檢查運行結果與預期結果的差異，【黑盒測驗屬于動態測驗】
按測驗物件劃分：
（一）非功能測驗
-
性能測驗（Performance Testing）
檢查系統是否滿足需求規格說明書中規定的性能，
通常表現在以下方面：
- 穩定性【例如：一萬人的時候和十萬人的時候，甚至一百萬的時候系統會不會卡頓】
- 回應時間【例如：等待相應的時間是否過慢】
- 吞吐量（TPS）
-
安全測驗（Safety Testing）
安全測驗是一個相對獨立的領域，需要更多的專業知識，
如：WEB的安全測驗、需要熟悉各種網路協議、防火墻、CDN、熟悉各種作業系統的漏洞、熟悉路由器等，
-
兼容性測驗（Compatibility Testing）
兼容性測驗主要指軟體之間能否很好的運作，會不會有影響、軟體和硬體之間能否發揮很好的效率作業，會不會影響導致系統的崩潰，
- 平臺測驗【例如：各種不同品牌型號、不同作業系統（如：android、iOS）的手機是否兼容】
- 瀏覽器測驗【例如：不同瀏覽器兼容性測驗（火狐、谷歌、360等）】
- 軟體本身是否向前或向后兼容【例如：本版本和上一版本是否兼容】
- 測驗軟體是否與其他相關軟體兼容【例如：同時下載兩款軟體是否都能正常使用】
- 資料兼容性測驗【資料之間有一定的隔離性，兩個軟體里面的資料不會串、相互隔離、兼容】
-
檔案測驗（Document Testing）
- 開發檔案：可行性研究報告、
軟體需求說明書、資料要求說明書、概要設計說明書、詳細設計說明書、資料庫設計說明書、模塊開發卷宗， - 用戶檔案：用戶手冊、操作手冊，用戶檔案的作用：改善易安裝性；改善軟體的易學性與易用性；改善軟體可靠性；降低技術支持成本，
- 管理檔案：專案開發計劃、測驗計劃、測驗分析報告、開發進度月報、專案開發總結報告，
在實際的測驗中，最常見的就是用戶檔案的測驗，例如：用戶操作說明書等，
檔案測驗關注的點：
- ? 檔案的術語
- ? 檔案的正確性
- ? 檔案的完整性
- ? 檔案的一致性
- ? 檔案的易用性
- 開發檔案：可行性研究報告、
-
易用性（用戶體驗性測驗）（User Ability Testing）
易用性是
互動的適應性、功能性和有效性的集中體現，又叫用戶體驗測驗， -
界面測驗（User Interface Testing）
界面測驗（簡稱UI測驗），測驗用戶界面的功能模塊的布局是否合理、整體風格是否一致、各個控制元件的放置位置是否符合客戶使用習慣，此外還要測驗界面操作便捷性、導航簡單易懂性，頁面元素的可用性，界面中文字是否正確，命名是否統一，頁面是否美觀，文字、圖片組合是否完美等，
-
安裝測驗（Installation Testing）
安裝測驗是指：測驗程式的安裝、卸載，最經典的就是APP的安裝、卸載，
（二）功能測驗（Functional Testing）
按測驗實施的組織劃分：
-
α測驗（Alpha Testing）
-
β測驗（Beta Testing）
??α測驗與β測驗區別：
-
測驗的
場所不同：Alpha測驗是指把用戶請到開發方的場所來測驗，Beta測驗是指在一個或多個用戶的場所進行的測驗，【例如：游戲內測版本】 -
Alpha測驗的
環境是受開發方控制的，用戶的數量相對比較少，時間比較集中，Beta測驗的
環境是不受開發方控制的，用戶數量相對比較多，時間不集中， -
Alpha測驗
先于Beta測驗執行，通用的軟體產品需要較大規模的Beta測驗，測驗周期比較長，
-
-
第三方測驗（Third-party Testing）
介于開發方和用戶之前的測驗組織，【例如：眾測網】
按測驗地域劃分：
-
國際化測驗（International Testing）
軟體的國際化和軟體的本地化是開發面向全球不同地區用戶使用的軟體系統的兩個程序，而本地化測驗和國際化測驗則是針對這類軟體產品進行的測驗，由于軟體的全球化普及，還有軟體外包行業的興起，軟體的本地化和國際化測驗儼然成為一個獨特的測驗專門領域，
-
本地化測驗（Localization Testing）
本地化測驗的物件是軟體的本地化版本，
（三）軟體測驗的原則
-
測驗應該
盡早進行，最好在需求階段就開始介入，因為最嚴重的錯誤不外乎是系統不能滿足用戶的需求， -
程式員
（開發）應該避免檢查自己的程式，軟體測驗應該由第三方（測驗人員）來負責， -
設計測驗用例時應考慮到
合法的輸入和不合法的輸入， -
在測驗程式時，不僅要檢驗程式是否做了該做的事，
還要檢驗程式是否做了不該做的事，多余的作業會帶來副作用，影響程式的效率，有時會帶來潛在的危害或錯誤， -
應
長期保留所有測驗用例，保留測驗用例有助于以后修改程式后的回歸測驗，
（四）軟體測驗策略
-
選擇測驗方法：選擇
最合適當前專案的測驗方法（比如專案緊急的時候？專案頻繁發版）（例如：重復測驗的作業可以采用自動化測驗） -
角色和職責：需要在測驗策略里面
明確定義各個角色，以及該角色的職責，比如專案經理、測驗組長、測驗工程師， -
環境需求：這一點非常重要，它將描述測驗時需要的系統環境（軟體，服務器Linux，windows，資料庫MySQL），包括
軟硬體以及網路環境等等，在澄清環境需求的時候，測驗組織可以識別出資源方面的風險， -
風險分析：影響測驗程序的風險都應該盡早被識別出來，而且必須有相應的解決辦法以便消除或減輕這些風險，（例如：人員休假、軟體是否完成）
-
測驗進度評估：測驗進度將會評估完成測驗
所需要的時間，在設定進度的時候，首先需要明測驗范圍（比如說這次增加一個D模塊，部分功能會影響原來已經上線的B模塊的功能）然后根據測驗資源的多少來指定能被各方面認可的測驗進度計劃， -
回歸測驗（Regression Testing）策略：回歸測驗用來保證之前fix bug的代碼不會影響軟體的其他部分，這樣需要我們選擇已經執行過的測驗用例重新運行，測驗人員需要找到一個方法來確定哪些測驗用例應該在回歸測驗中運行，用例不能太多，因為資源有限，用例也不能太少，否則會達不到必須的測驗強度，
-
優先級：測驗范圍內的東西不會都是一樣重要的，加上測驗資源各種有限，所以為測驗的模塊排定優先級是十分的必要，
（五）軟體測驗模型
-
瀑布模型
瀑布模型適合于結構化方法，
軟體專案或產品選擇瀑布模型必須滿足下列條件：
- 在開發時間內需求沒有或很少變化
- 分析設計人員應對應用領域很熟悉
- 低風險專案（對目標、環境很熟悉）
- 用戶使用環境很穩定
- 用戶除提出需求以外，很少參答與開發作業
-
V模型
-
優點：包含了底層測驗（單元測驗）和高層測驗（系統測驗）；清楚的標識了開發和測驗的各個階段；自上而下逐步求精，每個階段分工明確，便于整體專案的把控，
-
缺點：自上而下的順序導致測驗作業在編碼后，不能及時的進行修改；實際作業中，需求經常變化，導致V模型步驟反復執行，返工量很大，靈活度較低，
V模型和瀑布模型有一些共同的特性，V模型中的程序從左到右，描述了基本的開發程序和測驗行為，
- 優點：V模型的價值在于它非常明確地標明了測驗程序中存在的不同級別，并且清楚地描述了這些測驗階段和開發程序期間各個階段的對應關系， - 局限性：（測驗介入太晚）把測驗作為編碼之后的最后一個活動，需求分析等前期產生的錯誤知道后期的驗收測驗才能發現，
-
-
敏捷模型
-
W模型
定義：開發一個v，測驗一個v，組合起來的模型（w模型也叫雙v模型），
-
H模型
相對于V模型和W模型，H模型將測驗活動完全獨立出來，形成了一個完全獨立的流程，將測驗準備活動和測驗執行活動清晰地體現出來，
-
探索性測驗
探索性測驗可以說是
一種測驗思維模式，他沒有很多實際的測驗方法、技術和工具，但是卻是所有測驗人員都應該掌握的一種測驗思維方式，
探索性測驗強調測驗人員的主觀能動性，拋棄繁雜的測驗計劃和測驗用例設計程序，強調在碰到問題時及時改變測驗策略，
（六）軟體測驗生命周期
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/244151.html
標籤：其他
上一篇：練習筆記-思科交換機2960新設備啟用等配置20201230
下一篇：幾個在線檔案介面生成工具