重讀《從菜鳥到測試架構師》--黑色的盒子裏有什麼（中）

上一章說到小艾在功能測試組開始了功能測試的學習，然而對產品知識、軟件技能和客戶意識有了必定了解的小艾，對整個測試依然有着不解之處，這時，導師爲他深刻淺出的解讀了功能測試，導師是怎麼解讀的呢？

關於黑盒測試與白盒測試，儘管小艾已經知道了些許區別，但仍是免不了老生常談一番：

黑盒測試是軟件測試的主要方法之一，也稱爲功能測試、數據驅動測試、基於規格說明的測試。測試者不瞭解程序的內部狀況，只知道程序的輸入、輸出及系統的功能，它是從用戶的角度針對軟件界面、功能及外部結構進行的一種測試，不須要考慮程序內部邏輯結構。

白盒測試一樣做爲軟件測試的主要方法之一，被稱爲結構測試、邏輯驅動測試、基於程序自己的測試。測試者瞭解待測程序的內部結構、算法等信息，是從程序設計者的角度對程序進行的測試。

在黑盒測試中，對測試人員的基本要求是他要知道軟件的外在行爲，但沒必要清楚軟件內部是如何運做的。

 

對應的白盒測試就是測試人員知道白盒子的內部邏輯，知道該測什麼，怎麼測，會獲得什麼樣的結果。

所以IBM將功能測試作了以下的定義：

    1. 基於軟件功能模塊的技術設計 - 需求 - 規格說明文檔，來驗證軟件功能模塊知足用戶對其功能的要求。

    2. 目標是測試軟件產品的單個功能正確地實現規定的需求和設計文檔。同時發現各個功能模塊的bug，包括新增代碼的錯誤及修改代碼產生的錯誤。 

導師告訴小艾，一個好的功能測試人員要成長爲測試專家，甚至測試架構師，除了要從執行層面找到本身的手電，可以按照測試計劃書及用例找到bug以外，還須要可以制定或理解：

    1. 功能測試策略：這是整個功能測試如何進行的基本準則

    2. 功能測試在整個軟件開發流程中的生命週期

    3. 測試計劃書，測試場景及場景對應的測試用例。

 

策略

測試策略一般是描述測試工程的整體方法和目標，用於規定測試的範圍、種類、每一個測試活動該如何制定計劃，以及具體測試活動該如何進行等。測試策略是從測試目標、計劃、實施、分析全方位給測試人員以方向性指導，用於保證項目的進度和質量符合市場和客戶對產品和服務的要求。

功能測試策略做爲整個測試策略的一個重要組成部分，其目的是給功能測試人員提供一套策略做爲方向指導，通常功能測試策略應該包含但不限於如下方面：

 

功能測試的範圍

具體而言，功能測試策略描述並規定功能測試應該在產品測試中覆蓋的範圍，其中功能測試場景及功能測試用例的重要性須要特別關注。

 

功能測試與其餘測試種類的邊界及先後承接的條件

對於功能測試和其餘測試類型的邊界關係，測試中的承接關係必定要描述清楚，這樣既能夠避免測試漏洞，又能夠避免資源的浪費。

 

功能測試中不一樣的測試用例的定義與選取

在功能測試中定義功能測試用例時要有不一樣的策略考慮，哪些做爲可接受性測試的測試用例，哪些做爲當前及後續版本的迴歸測試用例，通常都要描述清楚如何選取及選取的比例。

 

針對於某個產品，或者某個產品的某個版本中的功能模塊，或者具體功能解決方案的功能測試策略的描述

產品的不一樣功能模塊所涉及的技術、實現的原理都有所不一樣，所以制定一個比較大的產品的功能測試策略時，要針對不一樣的功能模塊，制定具體的功能測試策略。

對於功能測試中涉及的諸如訪問控制、異常條件、全球化等的策略

功能測試策略對上述都須要有所考慮，才能保證測試覆蓋率。

 

功能測試中的自動化測試相關的策略

測試用例自動化開發可以幫助測試人員在整個開發過程當中不斷地重複執行測試用例，能夠在很大程度上減小測試人員花在迴歸測試上的工做量。

 

對於功能測試在不一樣的環境下進行的策略描述

爲了最大限度地在軟件交付給客戶以前發現問題，使得客戶獲得一個保障質量的軟件，功能測試要在不一樣的環境下去實施、驗證。這裏也涉及爲提升測試效率而在不一樣環境下按比例分拆功能測試用例的比例。

 

對於所測試的軟件的支撐環境的選擇和測試用例的比例分配

在功能測試策略中，要對軟件的上述支撐環境進行合理而有效的選擇，並考慮到測試成本和測試效率及風險。

 

對於軟件產品的不一樣版本的測試

通常產品都會有不一樣的版本：企業版、專業版、我的版……所以功能測試策略中必定要針對不一樣的版本作相應的測試策略。

小艾聽到導師講述的策略問題以後，發現功能測試的坑還真蠻深的，目前要想從容應用這些可不容易，仍是先踏踏實實循序漸進作事情吧~ 因而在這時，導師又開始和小艾談起了流程的問題……

 

流程

一個熟悉各類流程的人，纔可以按照正確的方式作事情。功能測試的流程主要用來規範功能測試是如何進行的，它的進入、退出標準是什麼。

 

功能測試流程的輸入元素

通常而言，對於功能測試，輸入的元素主要包含需求說明書、設計文檔、代碼、產品的構建版本，及產品的文檔等，有了這些，功能測試纔可以開始最初的計劃階段。

 

功能測試流程的輸出元素

功能測試計劃書、功能測試場景、測試用例、測試總結、執行記錄、缺陷記錄、分析報告、交付的產品等。

 

功能測試計劃書的準備

不一樣功能測試階段的測試目標、達成目標的總體策略、鑑別功能測試依賴關係及風險、明確各類資源的可用性、創建計劃、執行和報告的過程和約定、創建功能測試的重要里程碑及功能測試完成，測試階段成果的進入/退出標準。

功能測試用例的設計

具體功能測試最細化的信息。一個測試用例是一系列相關的測試條件的邏輯化的拼裝。應考慮有效的輸入/輸出，及無效的、不指望的輸入/輸出。

 

功能測試計劃書的審閱和批准

獲得批准的功能測試計劃書是功能測試進行的惟一指導，流程包括：計劃--準備--審閱--修改--追蹤--批准。

 

功能測試的執行

驗證產品的所用功能特徵都符合產品設計說明書的要求。功能執行的環境必須和產品的創建及用戶所使用的環境一致。原則上，任何問題都要在產品發佈以前被解決，除非產品發佈管理團隊批准某一bug能夠不在當前版本解決。

 

功能測試狀態的報告

狀態報告必須是基於客觀的事實，要對重要的里程碑、產品質量等作好評估。

功能測試的流程

在需求階段，測試人員以本身的理解，站在客戶的角度上闡述本身的觀點，與項目組的不一樣角色進行交流與討論，在學習理解產品功能的同時，將本身做爲「客戶」的感覺反饋給開發設計人員。

在設計開發階段，功能測試人員扮演開發人員和「客戶」的雙重角色，一方面根據需求規格說明書等文檔設計測試計劃、測試場景，測試用例，並進行測試發現問題，一方面站在客戶角度與設計開發人員進行溝通，及時提供軟件質量反饋。

在成品測試階段，功能測試人員要對產品進行充分的迴歸測試，以確保沒有問題遺留或新問題的引入。

功能測試團隊必須嚴格遵循制定的流程，以功能策略爲指導，才能保障功能測試的任務可以高質量地完成，交付給市場和客戶一個高質量的軟件產品。

尾聲

在導師的講解下，小艾明白了測試的策略及流程，但依然不知道應該如何作以及具體作什麼，這時候導師又會如何教導小艾呢？請聽下回分解~

 

想要第一時間看到這一系列文章的更新及更多精彩內容能夠掃描下面二維碼關注微信公衆號: 倚樓聽風雨的如月