軟件測試就只能挑Bug？絕對遠遠不止

「什麼是軟件測試？」這個看似簡單的一個問題，其實也是最難的問題。說它簡單，是由於這是一個基本的問題，作軟件測試工做多年的小夥伴，天然知道什麼是軟件測試。說它難，是由於「軟件測試」有不少內涵，要了解其所有內涵，並不是那麼容易。若是咱們去問軟件研發人員什麼是軟件測試，獲得的答案可能五花八門，人們對軟件測試有不一樣的理解。如今最多見的理解就是:軟件測試就是找bug、發現缺陷。

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

• 檢查軟件產品是否符合設計要求；
• 驗證軟件產品需求、設計和實現的一致性；
• 確認軟件產品是否知足用戶的實際需求；
• 對軟件產品質量的全面評估；
• 提供軟件產品質量信息；
• 揭示軟件產品的質量風險；
• 投入較低的保障性成本極大地下降劣質成本；
• 驗證與確認；
• 調查、分析和比較；
• 不斷探索；

……

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

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

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

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

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

測試試圖驗證軟件是「工做的」，也就是驗證軟件功能執行的正確性。

測試的活動是以人們的「設想」或「預期的結果」爲依據。這裏的「設想」或「預期的結果」是指需求定義、軟件設計的結果。

但同時咱們知道，軟件測試有一條原則：測試是不能窮盡的。測試會面對大量的測試數據、測試場景或代碼路徑等，測試也只是一個樣本實驗，不能證實軟件是正確的，只能說明發現的缺陷的確是缺陷。但若是沒有發現問題，並不能說明問題就不存在，而是至今未發現軟件中所潛在的問題。正如《軟件測試的藝術》一書做者Glenford J. Myers所說，測試不該該着眼於驗證軟件是工做的，相反，應該用逆向思惟去發現儘量多的錯誤。他認爲，從心理學的角度看，若是將 「驗證軟件是工做的」做爲測試的目的，很是不利於測試人員發現軟件的錯誤。所以，1979年他給出了軟件測試的不一樣的定義：「測試是爲了發現錯誤而執行一個程序或者系統的過程。」從這個定義能夠看出，假定軟件老是存在缺陷的（事實上也是如此）、有錯誤的，測試就是爲了發現缺陷，而不是證實程序無錯誤。

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

人類的活動具備高度的目的性，創建適當的目標具備顯著的心理做用。若是測試目的是爲了證實程序裏面沒有錯誤，潛意識裏就可能不自覺地朝這個方向去作。在進行測試的過程當中，就不會刻意選擇一些儘可能使程序出錯的測試數據，而選擇一些經常使用的數據，測試容易經過，而不容易發現問題。若是測試的目的是要證實程序中有錯，那咱們會設法選擇一些易於發現程序錯誤的測試數據，這樣，更早、更快地發現缺陷。畢竟開發人員力求構造軟件，以正向思惟方式爲主，因此逆向思惟方式能夠提高咱們的測試效率。

逆向思惟也有不利的一面，容易陷於局部的深度測試，缺少廣度。由於以爲某個地方有缺陷，就對這個地方進行測試，而後不斷深刻下去，這樣容易忽視一些區域。雖然那些地方產生的缺陷很少，但若是產生了嚴重缺陷，也是咱們不能承受的。因此正向思惟也是有價值的，它會督促針對軟件系統的全部功能點，逐個驗證其正確性，哪一個功能越重要越要進行檢驗。正向思惟會讓咱們的測試更有廣度——良好的測試覆蓋面。

爲了作好測試，既要有深度，又要有廣度；既要有效率，又要有測試工做自身完整的質量。因此，咱們應該將正向思惟和逆向思惟有機地結合起來，作到效率和質量的平衡。換句話說，當咱們須要效率時，更多采用逆向思惟，當咱們須要測試廣度來確保完整的測試質量時，則多采用正向思惟。這種平衡還體如今不一樣的應用領域，例如國防、航天、銀行等關鍵性軟件系統，承受不了系統的任何一次失效。由於這些失效徹底有可能致使災難性的事件，因此強調驗證（verify），以保證很是高的軟件質量。而通常的商業應用軟件或服務，質量目標設置在「用戶可接受水平」，以下降軟件開發成本，加快軟件發佈速度，有利於市場的擴張，則能夠強調逆向思惟，儘快找出大部分缺陷。

從狹義測試到廣義測試

前面提到Glenford J. Myers，他早期給軟件測試的簡單定義是：「程序測試是爲了發現錯誤而執行程序的過程」，也體現出當時對軟件測試的認識很是具備侷限性。這也是受軟件開發瀑布模型的影響，認爲軟件測試是編程以後的一個階段。只有等待代碼開發出來以後，經過執行程序，像用戶那樣操做軟件發現問題，這就是「動態測試」。

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

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

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

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

• 狹義的軟件測試：動態測試——運行程序而進行的測試，測試只是編程以後的階段，這也是由傳統的瀑布模型而決定的。
• 廣義的軟件測試：動態測試+靜態測試，將需求評審、設計評審、代碼評審（含代碼的靜態分析）等也歸入軟件測試工做之中。這也使「軟件測試」再也不停留在編程以後的某個階段上，而成爲貫穿整個軟件研發週期的質量保證活動，這也是本書「全程軟件測試」的最先立意所在。

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

無論你是剛入門的小白、還沒入門的羣衆、已經入門好久的前輩，不知足如今的工做狀況，你想升值加薪，想彎道超車，均可以加個人羣：903217991，我們會提供一套專門的測試學習路線規劃，帶領你實現人生逆襲，財富自由。固然，我們也有免費的資料能夠提供給喜歡自學的小夥伴，因此歡迎你們踊躍加羣~我會一一爲你們經過的。

基於質量的認知

軟件測試雖然不能等同於軟件質量保證（SQA），但它是軟件質量保證的主要手段之一。當咱們討論軟件測試時，絕對離不開「質量」。基於質量的認識，軟件測試就是對軟件產品的質量評估，提升軟件產品有關的質量信息。即便從1.1節中咱們認爲軟件測試就是發現軟件產品中的bug（缺陷），哪什麼是「缺陷」呢？簡單地說，缺陷就是質量的對立面，一切違背質量的問題均可以看做軟件缺陷（雖然從專業術語來仔細辨析的話，會將問題分爲「內在錯誤，外部失效」等）。因此要理解軟件測試，就必須理解軟件質量。

提及「質量」這個概念，咱們都很熟悉，會說「壞的質量會怎樣怎樣，好的質量會怎樣怎樣」，但讓咱們給出質量的正式定義，可能不是容易的事情。咱們也能夠查國際標準，瞭解如何給質量下定義。例如IEEE Std 829-2008定義質量就是系統、組件或過程知足特定需求的程度，知足客戶/用戶需求或指望的程度。知足程度越高，質量就越好。例如，從軟件需求定義文檔來看，它所描述的需求和客戶實際業務需求越吻合，未來實現的軟件越有可能知足客戶的業務需求，也意味着需求文檔的質量越高。但這樣說，仍是比較寬泛，很難衡量質量。那究竟如何評估質量？從哪些維度來衡量質量呢？這就引出質量模型。基於質量模型，咱們能夠清楚質量有哪些屬性（或維度），而後針對這些屬性逐個地進行評估，不須要對軟件質量進行總體評估，至關於按質量的各個維度來進行評估、各個擊破。

過去將軟件質量分爲內部質量、外部質量和使用質量，像代碼的規範性、複雜度、耦合性等能夠看做是內部質量，內部質量和外部質量共用一個質量模型。如今國際/國家標準將內部質量和外部質量合併爲產品質量。產品質量能夠認爲是軟件系統自身固有的內在特徵和外部表現，而使用質量是從客戶或用戶使用的角度去感知到的質量。由於質量是相對客戶而存在，沒有客戶就沒有質量，質量是客戶的滿意度。過去認爲，內部質量影響外部質量、外部質量影響使用質量，而使用質量依賴外部質量、外部質量依賴內部質量。今天能夠理解爲產品質量影響使用質量，而使用質量依賴產品質量。

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】當咱們使用百度地圖、滴滴打車等軟件時，每每是在大街上。若是站在人行道或安全地方使用沒問題，可是若是一面橫穿馬路一面還在使用，就有安全風險。這類軟件應該給予提示，不然它們要承擔相應的風險責任。

基於風險的認知

由於沒有辦法證實軟件是正確的，軟件測試自己老是具備必定的風險性，因此軟件測試被認爲是對軟件系統中潛在的各類風險進行評估的活動。從風險的觀點看，軟件測試就是對軟件產品質量風險的不斷評估，引導軟件開發工做，進而將最終發佈的軟件所存在的風險降到最低。基於風險的軟件測試認知主要體如今兩點上：

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

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

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

基於風險對測試的認知還不斷提醒咱們：在盡力作好測試工做的前提下，工做有所側重，在風險和開發週期限制上得到平衡。首先評估測試的風險，每一個功能出問題的機率有多大？根據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模型，驗證是架構設計評審、詳細設計評審和代碼評審/單元測試，分別驗證架構設計是否和需求一致、詳細設計是否和架構設計一致、代碼是否和詳細設計一致，用左邊帶箭頭的粗虛線表示。而有效性確認則是集成測試、系統測試、驗收測試，如中間帶箭頭的細虛線表示。

結語

無論你是剛入門的小白、還沒入門的羣衆、已經入門好久的前輩，不知足如今的工做狀況，你想升值加薪，想彎道超車，均可以加個人羣：903217991，我們會提供一套專門的測試學習路線規劃，帶領你實現人生逆襲，財富自由。固然，我們也有免費的資料能夠提供給喜歡自學的小夥伴，因此歡迎你們踊躍加羣~我會一一爲你們經過的。