軟件測試就是挑Bug?也許你有認知偏差

“什么是軟件測試？”這個看似簡單的一個問題，其實也是最難的問題。說它簡單，是因為這是一個基本的問題，做軟件測試工作多年的小伙伴，自然知道什么是軟件測試。說它難，是因為“軟件測試”有很多內涵，要了解其全部內涵，并非那么容易。如果我們去問軟件研發人員什么是軟件測試，得到的答案可能五花八門，人們對軟件測試有不同的理解。現在最常見的理解就是:軟件測試就是找bug、發現缺陷。

但也有人會認為軟件測試就是：

檢查軟件產品是否符合設計要求；

驗證軟件產品需求、設計和實現的一致性；

確認軟件產品是否滿足用戶的實際需求；

對軟件產品質量的全面評估；

提供軟件產品質量信息；

揭示軟件產品的質量風險；

投入較低的保障性成本極大地降低劣質成本；

驗證與確認；

調查、分析和比較；

不斷探索；

……

有太多的理解，而且都沒有錯，只是看問題的角度不一樣。雖然回答問題時，也容易脫口而出，不會仔細斟酌，只看到軟件測試的一面，沒有系統地分析“什么是軟件測試”。

下面我們就好好討論“什么是軟件測試”，因為有什么理解就有什么行動。有正確的理解，就有正確的操作；相反，有錯誤的理解，就有錯誤的操作。所以，先幫助讀者對“軟件測試”建立正確、全面的認識，構建起一個完整的“軟件測試”輪廓，不至于陷入“盲人摸象”的困境，對軟件測試有片面的理解。然后，我們再展開流程、方法、技術和實踐的討論。也就是在全面討論“全程軟件測試”之前，咱們需要找到共同語言，即對軟件測試的一些基本概念達成共識，為后面的溝通掃除障礙。

軟件測試基本認知——正反思維

什么是軟件測試？人們常?；卮穑很浖y試就是發現軟件產品中的bug（缺陷）。也有人說，不對，軟件測試是驗證軟件產品特性是否滿足用戶的需求。實際上，上述回答都沒錯，是對軟件測試的正反兩個方面的解釋。

早期，人們更多的是將“測試”看作是對產品的“檢驗”，檢查軟件的每個功能是否運行正常。正如1983年Bill Hetzel將軟件測試定義為：“軟件測試就是一系列活動，這些活動是為了評估一個程序或軟件系統的特性或能力，并確定其是否達到了預期結果。”從這個定義中，至少我們可以看到以下兩點。

測試試圖驗證軟件是“工作的”，也就是驗證軟件功能執行的正確性。

測試的活動是以人們的“設想”或“預期的結果”為依據。這里的“設想”或“預期的結果”是指需求定義、軟件設計的結果。

從這個定義延伸出去，一個成功的測試是發現了軟件問題的測試，否則測試就沒有價值。這就如同一個病人（因為是病人，假定確實有?。结t院去做相應的檢查，結果沒有發現問題，那說明這次體檢是失敗的，浪費了病人的時間和金錢。以逆向思維方式引導人們證明軟件是“不工作的”，會促進我們不斷思考開發人員對需求理解的誤區、不良的習慣、程序代碼的邊界、無效數據的輸入等，找到系統的薄弱環節或識別出系統復雜的區域，目標就是發現系統中各種各樣的問題。

人類的活動具有高度的目的性，建立適當的目標具有顯著的心理作用。如果測試目的是為了證明程序里面沒有錯誤，潛意識里就可能不自覺地朝這個方向去做。在進行測試的過程中，就不會刻意選擇一些盡量使程序出錯的測試數據，而選擇一些常用的數據，測試容易通過，而不容易發現問題。如果測試的目的是要證明程序中有錯，那我們會設法選擇一些易于發現程序錯誤的測試數據，這樣，更早、更快地發現缺陷。畢竟開發人員力求構造軟件，以正向思維方式為主，所以逆向思維方式可以提升我們的測試效率。

逆向思維也有不利的一面，容易陷于局部的深度測試，缺乏廣度。因為覺得某個地方有缺陷，就對這個地方進行測試，然后不斷深入下去，這樣容易忽視一些區域。雖然那些地方產生的缺陷不多，但如果產生了嚴重缺陷，也是我們不能承受的。所以正向思維也是有價值的，它會督促針對軟件系統的所有功能點，逐個驗證其正確性，哪個功能越重要越要進行檢驗。正向思維會讓我們的測試更有廣度——良好的測試覆蓋面。

為了做好測試，既要有深度，又要有廣度；既要有效率，又要有測試工作自身完整的質量。所以，我們應該將正向思維和逆向思維有機地結合起來，做到效率和質量的平衡。換句話說，當我們需要效率時，更多采用逆向思維，當我們需要測試廣度來確保完整的測試質量時，則多采用正向思維。這種平衡還體現在不同的應用領域，例如國防、航天、銀行等關鍵性軟件系統，承受不了系統的任何一次失效。因為這些失效完全有可能導致災難性的事件，所以強調驗證（verify），以保證非常高的軟件質量。而一般的商業應用軟件或服務，質量目標設置在“用戶可接受水平”，以降低軟件開發成本，加快軟件發布速度，有利于市場的擴張，則可以強調逆向思維，盡快找出大部分缺陷。

從狹義測試到廣義測試

前面提到Glenford J. Myers，他早期給軟件測試的簡單定義是：“程序測試是為了發現錯誤而執行程序的過程”，也體現出當時對軟件測試的認識非常具有局限性。這也是受軟件開發瀑布模型的影響，認為軟件測試是編程之后的一個階段。只有等待代碼開發出來之后，通過執行程序，像用戶那樣操作軟件發現問題，這就是“動態測試”。

對于需求階段產生的缺陷，在不同階段發現和修復的成本是不一樣的。如果在需求階段發現需求方面的缺陷并進行修復，只要修改需求文檔，其成本很低。需求階段產生的缺陷，如果在需求階段沒有發現，等待設計完成之后才被發現，就需要修改需求和設計，成本增大。需求階段產生的缺陷，如果在需求和設計階段都沒有發現，等待代碼寫完之后才被發現，就需要修改需求、設計、代碼，成本就更大。設計上的問題，在設計階段被發現，只要修改設計，如果在后期發現，返工的路徑就變長了，其修復的成本自然就增大。缺陷發現得越遲，其修復的成本就越高，如圖1-1所示，呈現了不同階段產生的缺陷在不同階段修復的成本，所以這要求我們盡早發現缺陷。

圖1-1　不同階段產生的缺陷在不同階段修復的成本

為了盡早發現缺陷，我們有必要將軟件測試延伸到需求、設計階段，即對軟件產品的階段性成果——需求定義文檔、設計技術文檔進行評審或驗證。這不同于軟件質量保證（Quality Assurance，QA），雖然QA側重評審，但它重點評審流程、評審管理，包括對需求、設計、編碼和測試過程規范性的評審。而這里提到的需求和設計的評審依舊是對軟件產品的檢驗或驗證，只是需求文檔和設計文檔只是軟件產品的階段性產品。如果按照“軟件=程序+文檔+數據結構”這樣的定義，需求文檔和設計文檔等也屬于軟件的組成部分，軟件測試自然也包括需求和設計的驗證。

基于上述考慮，將早期的動態測試延伸到靜態測試，即從狹義的軟件測試發展到廣義的軟件測試。

狹義的軟件測試：動態測試——運行程序而進行的測試，測試只是編程之后的階段，這也是由傳統的瀑布模型而決定的。

廣義的軟件測試：動態測試+靜態測試，將需求評審、設計評審、代碼評審（含代碼的靜態分析）等也納入軟件測試工作之中。這也使“軟件測試”不再停留在編程之后的某個階段上，而成為貫穿整個軟件研發周期的質量保證活動，這也是本書“全程軟件測試”的最早立意所在。

靜態測試就是在不運行軟件系統時對軟件或階段性成果進行評審，包括需求評審、設計評審、代碼評審等。引入靜態測試，就可以盡早地發現問題，把問題消滅在萌芽之中，將每個階段產生的缺陷及時清除，極大地提高產品的質量，有效地降低企業的成本。

基于質量的認知

軟件測試雖然不能等同于軟件質量保證（SQA），但它是軟件質量保證的主要手段之一。當我們討論軟件測試時，絕對離不開“質量”?；谫|量的認識，軟件測試就是對軟件產品的質量評估，提高軟件產品有關的質量信息。即使從1.1節中我們認為軟件測試就是發現軟件產品中的bug（缺陷），哪什么是“缺陷”呢？簡單地說，缺陷就是質量的對立面，一切違背質量的問題都可以看作軟件缺陷（雖然從專業術語來仔細辨析的話，會將問題分為“內在錯誤，外部失效”等）。所以要理解軟件測試，就必須理解軟件質量。

說起“質量”這個概念，我們都很熟悉，會說“壞的質量會怎樣怎樣，好的質量會怎樣怎樣”，但讓我們給出質量的正式定義，可能不是容易的事情。我們也可以查國際標準，了解如何給質量下定義。例如IEEE Std 829-2008定義質量就是系統、組件或過程滿足特定需求的程度，滿足客戶/用戶需求或期望的程度。滿足程度越高，質量就越好。例如，從軟件需求定義文檔來看，它所描述的需求和客戶實際業務需求越吻合，將來實現的軟件越有可能滿足客戶的業務需求，也意味著需求文檔的質量越高。但這樣說，還是比較寬泛，很難衡量質量。那究竟如何評估質量？從哪些維度來衡量質量呢？這就引出質量模型?；谫|量模型，我們可以清楚質量有哪些屬性（或維度），然后針對這些屬性逐個地進行評估，不需要對軟件質量進行整體評估，相當于按質量的各個維度來進行評估、各個擊破。

過去將軟件質量分為內部質量、外部質量和使用質量，像代碼的規范性、復雜度、耦合性等可以看作是內部質量，內部質量和外部質量共用一個質量模型?，F在國際/國家標準將內部質量和外部質量合并為產品質量。產品質量可以認為是軟件系統自身固有的內在特征和外部表現，而使用質量是從客戶或用戶使用的角度去感知到的質量。因為質量是相對客戶而存在，沒有客戶就沒有質量，質量是客戶的滿意度。過去認為，內部質量影響外部質量、外部質量影響使用質量，而使用質量依賴外部質量、外部質量依賴內部質量。今天可以理解為產品質量影響使用質量，而使用質量依賴產品質量。

1．產品質量

根據國際標準IEEE 24765-2010，產品質量是指在特定的使用條件下產品滿足明示的和隱含的需求所明確具備能力的全部固有特性。而根據ISO 25010:2011標準，質量模型從原來的6個特性增加到8個特性，新增加了“安全性、兼容性”。如圖1-2所示，藍色標注的內容屬于新增加或改動的內容。這里的安全性是指信息安全性（Security），原來放在“功能性”下面，但現在絕大部分產品都是網絡產品，安全性越來越重要，所以有必要作為單獨的一個維度來度量。今天系統互聯互通已經很普遍，其次終端設備越來越多，除了傳統的PC機，還有許多智能移動設備，如手機、平板電腦、智能手環、智能手表等，這些都要求系統具有良好的兼容性。這些特性就對應著測試類型，如功能測試、性能測試（效率）、兼容性測試、安全性測試等。

圖1-2　ISO 25010 2016 產品質量模型

功能適應性（functional suitability）：軟件所實現的功能達到其設計規范和滿足用戶需求的程度，強調正確性、完備性、適合性等。

效率（efficiency）：在指定條件下，軟件對操作所表現出的時間特性（如響應速度）以及實現某種功能有效利用計算機資源（包括內存大小、CPU占用時間等）的程度，局部資源占用高通常是性能瓶頸存在；系統可承受的并發用戶數、連接數量等，需要考慮系統的可伸縮性。

兼容性（compatibility），涉及共存和互操作性，共存要求軟件能給與系統平臺、子系統、第三方軟件等兼容，同時針對國際化和本地化進行合適的處理。 互操作性要求系統功能之間的有效對接，涉及API和文件格式等。

易用性（usability）：對于一個軟件，用戶學習、操作、準備輸入和理解輸出所做努力的程度，如安裝簡單方便、容易使用、界面友好，并能適用于不同特點的用戶，包括對殘疾人、有缺陷的人能提供產品使用的有效途徑或手段（即可達性）。

可靠性（reliability）：在規定的時間和條件下，軟件所能維持其正常的功能操作、性能水平的程度／概率，如成熟性越高，可靠性就越高；用平均失效前時間（Mean Time To Failure，MTTF）或平均故障間隔時間（Mean Time Between Failures，MTBF）來衡量可靠性。

安全性（security）：要求其數據傳輸和存儲等方面能確保其安全，包括對用戶身份的認證、對數據進行加密和完整性校驗，所有關鍵性的操作都有記錄（log），能夠審查不同用戶角色所做的操作。它涉及保密性、完整性、不可抗抵賴性、可審核性、真實性。

可維護性（maintainability）：當一個軟件投入運行應用后，需求發生變化、環境改變或軟件發生錯誤時，進行相應修改所做努力的程度。它涉及模塊化、可復用性、易分析性、易修改性、易測試性等

可移植性（portability）：軟件從一個計算機系統或環境移植到另一個系統或環境的容易程度，或者是一個系統和外部條件共同工作的容易程度。它涉及適應性、可安裝性、可替換性。

2．使用質量

從ISO/IEC 25010標準看，軟件測試還要關注使用質量，如圖1-3所示。在使用質量中，不僅包含基本的功能和非功能特性，如功能（有效與有用）、效率（性能）、安全性等，還要求用戶在使用軟件產品過程中獲得愉悅，對產品信任，產品也不應該給用戶帶來經濟、健康和環境等風險，并能處理好業務的上下文關系，覆蓋完整的業務領域。

圖1-3　使用質量的屬性描述

為了便于理解使用質量，下面舉3個例子。

【例1-1】我自己親身經歷的例子。我在手機上安裝了一個英語學習軟件，自動下載該款軟件用到的多個語音庫（如新概念英語、六級英語等），它在我講課時，但并沒有判斷我手機連接的是Wi-Fi還是3G/4G，造成我的流量大大超過套餐額度，產生了額外的300元流量費。從功能上看，自動下載是一個不錯的功能，但有很大的經濟風險，在使用質量上有明顯缺陷。

【例1-2】當我們玩游戲，沉醉于某款游戲，從產品本身質量屬性看。是一個好產品，沒有問題。但從使用質量看，會有損于玩家的健康，有健康風險，所以需要設置防沉迷功能。

【例1-3】當我們使用百度地圖、滴滴打車等軟件時，往往是在大街上。如果站在人行道或安全地方使用沒問題，但是如果一面橫穿馬路一面還在使用，就有安全風險。這類軟件應該給予提示，否則它們要承擔相應的風險責任。

基于風險的認知

因為沒有辦法證明軟件是正確的，軟件測試本身總是具有一定的風險性，所以軟件測試被認為是對軟件系統中潛在的各種風險進行評估的活動。從風險的觀點看，軟件測試就是對軟件產品質量風險的不斷評估，引導軟件開發工作，進而將最終發布的軟件所存在的風險降到最低?；陲L險的軟件測試認知主要體現在兩點上：

軟件測試不僅僅停留在單個缺陷上，要從所發現的問題看到（分析出）某類質量風險或某個具有潛在風險的區域。

軟件測試被看作是一個動態的質量監控過程，對軟件開發全過程進行檢測，隨時發現不健康的征兆，及時評估新的風險，設置新的監控基準，不斷地持續下去。

基于風險對測試的認知，會強調測試的持續性，持續地進行測試，寫幾行代碼就要做測試、實現一個功能就要對這個功能進行測試，開發和測試相伴而行。這種認知特別適合敏捷開發模式下的測試——敏捷測試。在敏捷開發中，軟件測試就能被解釋為對軟件產品質量的持續評估。在敏捷方法中，不僅提倡持續集成，而且提倡持續測試，持續集成實際上也是為了持續測試。

基于風險對測試的認知還不斷提醒我們：在盡力做好測試工作的前提下，工作有所側重，在風險和開發周期限制上獲得平衡。首先評估測試的風險，每個功能出問題的概率有多大？根據Pareto原則（也叫80/20原則），哪些功能是用戶最常用的20％功能？如果某個功能有問題，其對用戶的影響又有多大？然后根據風險大小確定測試的優先級。優先級高的功能特性，測試優先得到執行。一般來講，針對用戶最常用的20％功能（優先級高）的測試會得到完全地、充分地執行，而低優先級功能的測試（另外用戶不常用的80％功能）就可能由于時間或經費的限制，測試的要求降低、減少測試工作量。

基于社會的認知

軟件不同于硬件，軟件一般都是應用系統，常常和人們的娛樂、事務處理、商業活動、社區交流等緊密聯系在一起，所以軟件具有很強的社會性，所以有必要把心理學、人類學和社會學等引入到軟件測試中。軟件測試不僅僅是技術活動，而且是社會、心理等綜合性活動，軟件測試是跨學科的（inter-disciplinary）活動，以系統為焦點（systems-focused），通過不斷調查（investigative）和講故事（storytelling）的方式完成軟件質量的評估。

通過軟件測試的社會性認知，強調測試人員的思維能力和探索能力，強調測試的有效性和可靠性，在測試中要理解用戶的行為、人們活動的背景和目的（上下文關系），不斷觀察，不斷學習，發現和質量相關的信息（差異或質疑），從客戶利益、業務特性出發來守護產品的價值。

也正是由于軟件測試的社會性，需要對軟件產品的易用性、免于風險的程度、上下文覆蓋等進行驗證。在易用性測試中，人們常常進行A/B測試，給出不同的解決方案（UI布局、功能設計等），向不同的用戶群發布產品，來檢測哪個解決方案更受用戶喜歡。

基于經濟的認知

一般來說，一個軟件產品沒有經過測試是不會發布（release）、不會部署(deploy)到產品線上，或者說，不敢發布、不敢上線。因為在當前的開發模式和開發技術情況下，人們開發的軟件存在嚴重的缺陷絕對是大概率事件。如果沒有經過測試，就發布出去，可能軟件根本不能用、不好用，或者用起來出現各種各樣的問題，用戶滿意度很低，給產品造成負面影響，甚至給客戶帶來嚴重的經濟損失或影響到用戶的生命安全。

從經濟觀點看，軟件缺陷會給企業帶來成本，這個成本就叫劣質成本（Cost of Poor Quality，COPQ）。基于經濟的認知，軟件測試就是通過投入較低的保障性成本來降低劣質成本，幫助企業獲得利潤。高質量不僅是有競爭力，而且是帶來良好的經濟收益的。例如蘋果手機就是以其高質量獲得比其他品牌手機更高的利潤率。據相關媒體統計數據看，蘋果智能手機在高端手機市場只占四分之一，但利潤占到一半。

測試的經濟觀點就是如何以最小的代價獲得更高的收益，這也要求軟件測試盡早開展工作，發現缺陷越早，返工的工作量就越小，所造成的損失就越小。所以，從經濟觀點出發，測試不能在軟件代碼寫完之后才開始，而是從項目啟動的第一天起，測試人員就參與進去，盡快盡早地發現更多的缺陷，并督促和幫助開發人員修正缺陷。

基于標準的認知

軟件測試被視為“驗證（Verification）”和“有效性確認（Validation）”這兩類活動構成的整體，缺一不可。如果只做到其中一項，測試是不完整的。

“驗證”是檢驗軟件是否已正確地實現了產品規格書所定義的系統功能和特性。驗證過程提供證據表明軟件相關產品與所有生命周期活動的要求相一致，即驗證軟件實現（即交付給客戶的產品）是否達到了軟件需求定義和設計目標。

“有效性確認”是確認所開發的軟件是否滿足用戶實際需求的活動。因為軟件需求定義和設計可能就不對，上述一致性不能保證軟件產品符合客戶的實際需求，而且客戶的需求也是在變化的，當需求定義是半年前確定的，這種變化的可能性就比較大。

對驗證和確認有不同的解釋。簡單地說，單元測試、集成測試和系統測試都可以理解為“驗證”，都是基于需求定義文檔和設計規格說明書文檔來進行驗證；而驗收測試則在用戶現場、由用戶共同參與進行，可以理解為“有效性確認”，因為之前的需求定義和設計都可能存在錯誤，研發團隊沒有正確理解用戶的原意（用戶的真實期望），僅僅根據需求定義文檔和設計規格說明書文檔來完成測試，并不能代表所實現的功能特性是用戶真正想要的。而在驗收測試中，用戶參與進來，是可以確認所實現的功能特性是否是用戶真正想要的。

另一種解釋是根據圖1-4所示的V模型，驗證是架構設計評審、詳細設計評審和代碼評審/單元測試，分別驗證架構設計是否和需求一致、詳細設計是否和架構設計一致、代碼是否和詳細設計一致，用左邊帶箭頭的粗虛線表示。而有效性確認則是集成測試、系統測試、驗收測試，如中間帶箭頭的細虛線表示。

圖1-4　軟件研發的V模型

圖1-4　軟件研發的V模型

另一種解釋是根據圖1-4所示的V模型，驗證是架構設計評審、詳細設計評審和代碼評審/單元測試，分別驗證架構設計是否和需求一致、詳細設計是否和架構設計一致、代碼是否和詳細設計一致，用左邊帶箭頭的粗虛線表示。而有效性確認則是集成測試、系統測試、驗收測試，如中間帶箭頭的細虛線表示。

《全程軟件測試（第3版）》

[美]?朱少民?著

本書適合軟件測試人員閱讀，也可作為相關專業人士的參考指南

本文轉載自異步社區。

原文鏈接：https://www.epubit.com/articleDetails?id=N433ecb71-ddf9-4950-b48a-81f4694f049e

軟件開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。