重讀《從菜鳥到測試架構師》-- 對黑盒子的全方位照明

上回說到，小艾學會了分而治之的方式來將模塊細化作功能測試，這樣的好處是更容易找到bug，但儘管容易找bug，並不表示bug就能徹底被找到，而不被交付到客戶手裏。也出於對客戶發現的bug進行分析，組長告訴小艾，不只僅須要分而治之，也須要合而治之。

上一章咱們也提到一個名詞：跨模塊/解決方案的功能測試，即功能集成測試，其實這就是爲了確保全部的功能特徵，或者User Story在一個產品或應用的開發過程當中可以被完全測試，而對產品的各個模塊或者解決方案，按照用戶的使用方式，根據模塊/解決方案間的邏輯關係，設計跨越多個模塊/解決方案的端到端的功能測試場景和功能測試用例，利用其對系統進行全面的功能測試。

找到小盒子間的蟲子——合而治之

在開發跨模塊/解決方案的功能測試場景時，一個重要的策略是對商業邏輯的梳理，明確可能的實際商業場景，經過對實際商業場景的理解，開發出跨不一樣模塊/解決方案的端到端的功能測試場景。

另一種就是基於模塊之間的消息傳遞，進行技術層面的驗證，確保技術上的正確性，還有就是基於不一樣產品之間的集成，作產品集成的跨產品的集成測試。

跨模塊/解決方案功能測試的測試場景應該被定義爲：經過一個模塊或者解決方案的不一樣的輸出及這些輸出是怎麼做爲其餘模塊或者解決方案的輸入，而定義的可以體現這種整合或者合併的功能測試場景。

說完上述的定義以後，組長告訴小艾這麼作的目的是可以確保基於實際的商業流程，以及數據流程的測試完備性。

舉個栗子

在跨模塊/解決方案的情景下，有一個很典型的例子，假設某電商網站有兩個模塊，其一用做產品管理，其二實現搜索功能，兩個模塊是不一樣的測試人員進行測試且經過的，會不會有一種狀況，當咱們在產品管理模塊將某產品進行刪除操做，但依然可以被用戶搜索出被刪除的產品？ 

答案是有可能的。緣由多是同步機制沒作好，可能搜索產品使用了緩存技術，因爲緩存緣由即便產品被刪除，也一樣可以被搜索。 

有的產品是基於模塊開發，其自己就是由若干個小的產品組成的，所以進入集成開發階段時作的測試也是一種常見的「合而治之」的例子。 

有些產品會須要與不一樣產品進行集成來互相取長補短，完成真正的用戶商業流程，在這樣的應用開發場景中，須要作充分的產品集成測試來確保功能、性能的可靠性。

 

不管是上述哪一種狀況，都要充分理解實際的商業需求和流程，進而定義完備而準確的功能測試和測試用例來作到對黑盒子的徹底照明。

 

策略高手

經過這段時間對功能測試項目的完整參與，小艾不只積累了豐富的執行經驗和各類功能測試技能，同時在組長的幫助和本身的努力下，對功能測試的測試策略也有了比較深入的體會，因而，小艾作出了以下的總結：

功能測試範圍

在定義功能測試範圍時，要兼顧功能測試的各個不一樣層面，如UI Testing（界面測試）,與API/Command level Testing（API或者命令層的測試）的測試用例的比例關係。 

與其餘類型的關係

一個大型產品的測試都是複雜的，會涉及不一樣的測試類型。在考慮功能測試的時候，必定要考慮到和其餘測試類型的交叉與依賴關係，這裏須要提到的是，被選爲迴歸測試的功能測試用例的經過，每每是性能測試開始的標誌。而從測試環境的選擇上考慮的話，除了要在純粹的運行時環境中測試產品的功能以外，還要考慮在客戶化的環境及移植後的環境去測試產品的功能來保證在這些環境裏功能可以正常運行。

 

測試覆蓋率和測試效率

從功能測試的目的來講，一方面要保證測試d完整性，達到最大的測試覆蓋率，另外一方面，從實際項目開發的角度看，作到100%的沒有任何bug的測試是不可能的，所以要充分考慮測試的效率。

功能測試用例自動化開發的策略考慮

自動化對於功能測試是否重複執行是很是關鍵的。在功能測試策略的層面必定要定義自動化開發的範圍，方法，標準，這是功能測試用例重複執行的基線。

功能bug的問題分析

策略層面要明確問題分析的一些具體要求，如提供一系列標準信息來幫助開發人員更好地理解問題、發現問題，找到解決方法。 

工具和模板

定義合適的功能測試工具和各類測試模板是功能測試可以高效進行的策略考慮之一

尾聲

迄今爲止談到的功能測試能夠說是小艾親自參與的，關於在大型應用的某版本中對於新功能在開發流程中各個不一樣階段，如何發現隱藏的bug，保證軟件質量來進行的針對這些新功能的功能性檢查，其實對於一個大型應用的功能測試，從策略的角度，要考查的東西遠不止這些。下一章咱們就來看看小艾還學到了哪些與功能測試相關的內容~

 

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