重讀《從菜鳥到測試架構師》-- 如何把黑盒子分塊

上一章節咱們說到，小艾在導師深刻淺出的介紹下，終於明白了測試的策略，流程並着手本身寫了一條測試用例，而在執行的過程當中，小艾也終於使用本身的手電發現了第一個bug。然而一個大的Java EE產品或者應用，一般代碼量巨大，業務邏輯及體系架構都很是複雜，對於這樣的產品或應用，若是採用簡單的方式從總體上測試其功能，是沒辦法面面俱到的。

小艾能夠理解把產品或者應用進行模塊化或基於解決方案的分解的好處，但並不知道該如何將產品或應用進行模塊化。就這個問題，小艾找到了組長，組長告訴小艾，其實分塊沒有固定的原則，不過從操做層面上，通常有如下考慮因素：

    產品或應用的天然模塊劃分

    產品或應用中功能的類似性，把類似的功能分到一個小盒子中

    功能測試團隊的資源（主要是人員）狀況，實際的項目中要考慮資源情況，對其進行粒度合適的功能模塊分解。

其中，合適粒度很是重要，並不是模塊分的越多越細就越好。粒度過大會帶來在同一個功能測試計劃書中涵蓋的細節過多，功能測試用例的量級也越大，易讀性、可控性變差。而粒度太小會形成總體功能測試計劃書的量級太多，人員分配凌亂，可控性變差，後續迴歸的複雜度也會提高。

 

如何精準找尋某一種bug —— 分而治之

從原理上講，按照必定的標準把須要測試的產品分紅不一樣的模塊後，功能測試團隊就能夠對小的模塊按照功能測試流程進行完整的測試。把大黑盒子分塊後，對每一個小盒子分而治之，因爲小盒子模塊更小，更靈活，下降了功能測試的複雜度，更容易在小盒子裏面抓到蟲子，這將大大下降定位蟲子的時間和難度。

每個迭代過程，要確保該迭代過程交付的功能點都被功能測試覆蓋到，同時確保隨着迭代過程的深刻，全部的功能點都可以被有效地經過迴歸測試覆蓋，保證小盒子交付的質量。

客戶的反饋——蟲子依然存在麼？

按理說，咱們分而治之更容易抓到蟲子，這樣交付的產品應該是完美的，但真的是這樣麼？

經過客戶的試用，依然發現了一些bug，而經過對客戶尋找的bug進行分析發現，比較典型的是功能測試團隊只考慮了模塊測試，而忽略了對業務的端到端的功能測試場景的設計，這種功能測試每每是跨幾個不一樣的功能測試模塊，或者不一樣的解決方案之間的集成。

 

 

尾聲

組長告訴小艾，一個完整的功能測試必定是在進行了單元測試以後，對產品進行基於模塊化或基於解決方案的測試，對產品進行分而治之，而後進行跨多個不一樣模塊，或解決方案的跨模塊/解決方案功能測試(Cross Component/Solution Testing)，或稱爲功能集成測試，從而達到對小盒子內部及盒子間的徹底的功能測試覆蓋。

小艾這才明白爲何將模塊細化測試卻依然還會有bug可以跑到客戶手裏。組長接下來會告訴小艾如何作來完善功能測試呢？請聽下回分解。

 

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