閱讀本文大概需要 4.1 分鐘。
上周，我懷着無比忐忑的心情推送了《再談軟體測試經驗圖譜》，本以為純理論的東西會引起大家的排斥，沒想到閱讀量特别好，隻是留言數并不多，是以沒法準确知道大家的回報。
今天我就趁熱打鐵，繼續聊聊這個圖譜的第二層級之硬技能，希望能繼續引起共鳴。
先上幹貨，下圖是我對硬技能做得分類：
今天我主要想聊聊硬技能之業務邏輯。
業務邏輯的重要性再怎麼強調都不為過，可以直白的說，
我們所有的工作都是為業務目标服務的
，是以一定要明白這個前提。
既然業務目标是重中之重，那麼對業務邏輯的熟悉程度當然是越高越好了，隻是這麼去形容，沒法量化，是以今天我提供兩個量化的标準。
1、一個标準是從廣度方面去衡量。
廣度又可以分成
體、面、線、點
這麼幾個級别。
體，就是從公司層面去考慮對業務了解的廣度。
比如北境是一個大公司，臨冬城和絕境長城是兩個業務，我是臨冬城的大廚，我到南境後，不管我告訴别人我是大廚，還是臨冬城來的，在對方眼裡，我都是北境的人，那麼關于北境公司的一切問題都可能襲來，比如：
你們老闆身價多少？
你們那個路由器有内部價不？
你們公司招保潔不？
龍媽是囧恩·雪諾的姑姑不？
記住，這時候千萬不要去抗拒、去解釋，事實證明所有的狡辯都是徒勞，我們給出答複就行了，對于自己不清楚的，就是自己需要搞清楚的。
面，就是從業務部門層面去考慮對業務了解的廣度。
比如我是北境公司絕境長城部門的學士，那麼對于北境臨冬城的人來說，才不管你是學士還是戰士，反正你是長城的人，你代表的就是長城這個部門，他們會問一切和這個部門業務相關的問題，比如：
你們新版的主界面好醜，是測試設計的吧？
你們那個可以搶錢的功能搶的錢太少了，可以增加十倍麼？
你們功能是不是沒經過測試？我經常點點點然後就崩潰了。
長城能擋住夜王不？
記住，千萬不要解釋說你不是設計師，不是産品經理，你就默默的記下他們的問題去跟進解決就是了，你這時候就代表的是這個業務。
線，就是從職能層面去考慮對業務了解的廣度。
比如我是測試工程師，那麼對于同一個業務内的人來說，測試相關的問題我都多少知道一些，其他角色的人會問你一切和測試相關的問題，比如：
這個子產品現在測試進度如何？
這個性能測試做了麼？
為什麼這個 bug 又漏出了？
為什麼這個項目還沒安排人測試？
千萬不要去解釋說這個子產品不是你測的，你就去找對應的測試去确認問題就好了，或者讓對應測試負責人過來對接，因為你這時候代表的就是測試部門。
點，就是從個人工作職責去考慮對業務了解的廣度。
這次終于到自己最擅長的事情了，這個指的就是自己日常工作所負責的具體項目，所有自己經手的項目邏輯都要非常熟悉，所有經手過的項目之間的内在關聯關系要進行清晰的梳理，在出現任何問題時，都會有人去找你問各種問題，比如：
我這個功能怎麼和預期不符，你看下是不是你的邏輯影響的？
外網出現了一個回報，你要看下是設計如此還是确實邏輯 bug？
使用者這樣的操作場景，咱們當時為啥沒考慮到？
這個場景操作下，不是因為得到 A 的值麼，為啥傳回的是 B？
這次當然更沒法解釋了，自己職責範圍内的事，必須要比任何人都更加的清楚，不會的趕緊加把勁搞明白。
總之，我們可以通過
體、面、線、點
的層次劃分，去分别衡量自己對業務了解的廣度（不出意外，大部分人都是集中在點的層次，并且還不一定達到熟練，是以要做的事情很多）。
2、另一個标準是從深度方面去衡量。
深度可以分為
表示層、邏輯層和資料層
這三個層次。
具體的解釋，我之前在文章《如何利用分層測試概念設計針對性測試用例》已經做了詳盡的說明，可以點選連結再回去回顧下。
總之，我們可以借助這三個層次的概念，去評估我們對業務邏輯的挖掘到底夠不夠徹底，到底夠不夠深入，這也就是我說的
深度
。
以上，其實我本來打算一次性把硬技能的五個方面全都說完呢，回頭一看已經寫了 1000+ 字了，剩下的還是等下次再詳聊吧。對于本次提到的廣度和深度分析的兩個理論工具，不知道你是否認可？或者你都是用什麼标準來進行衡量的呢？歡迎給我留言說說你的想法。