一
前兩天我發了篇鼓勵測試人員學程式設計（思維）的文章《做測試到底要不要學程式設計？》，有不少同學在後台問我，自己底子差，實在跟不上怎麼辦？
看起來，應該是我沒說清楚，導致大家有點誤會，測試人員用不用學程式設計？用，是不是必須學？這個可以看情況而定。
就算是 google 裡面的 te 角色，有些也是很少涉及程式設計的，所以不會程式設計，我們可以發揮自己其他方面的優勢。
比如，業務專家。
二業務是一切的根基，這點大家應該都明白。
產品是為公司目標服務的，業務是為產品服務的，技術是為業務服務的，所以懂業務應該是對技術人員的基本要求。
我在測試經驗圖譜裡面的硬技能分支中，第乙個列出來的就是業務邏輯，業務邏輯的重要性用言語簡直不足以表達，所以也沒有給他定要求，反正就是能搞多熟就把他搞多熟，能盡快把邏輯搞熟就盡量快，絕對有百利而無一害。
當然，要求歸要求，理想很豐滿，現實很骨感。
三技術人員對於業務的問題，第一點主要集中在個人關注點上。
技術人員有自己的工作任務，比如測試人員，更多的是要求專注功能測試、效能測試、相容性測試、自動化測試等等方面，都是很具體且很重要的事情，這部分事情占用我們的主要精力。
那麼用來關注業務本身的時間就比較少，所以經常會出現各種各樣的問題，比如：
我們提供了使用者需要的功能，但是使用者不買賬；
每個使用者有自己的要求並且相互衝突，我們沒法滿足所有人；
看起來需求是滿足了使用者表述的訴求，但是發布後發現使用者並不買賬；
發布前絞盡腦汁想到的所有場景，在發布後才發現我們還是高估了自己的想象力；
這時候，就算有出色的技術，業務目標也會無法達成，最終就是勞民傷財。
四技術人員對於業務的問題，第二點主要集中在業務了解的全面性上。
有的人說了，第乙個問題我們這沒有，我們所有的需求都會過需求評審，確實是解決了使用者原始的需求情況下，技術才上手，嗯，能做到這個程度真的很不錯了。
但是，有人看到過某些產品邏輯內部打架的情況不？比如：
a 邏輯寫了乙個登錄檔值，結果 b 邏輯給刪掉了；
a 介面用了紅色主色調，結果 b 介面用的是綠色主色調；
a 功能做了乙個設定入口，b 功能也做了乙個完全不一樣的設定入口；
是滴，很多人缺少大局觀，看問題只會著眼於具體的問題細節上，一不會擴充套件，二不會從整體上進行考慮，導致區域性最優，而合在一起則是最差。
五問題說完了，作為業務測試，我們的優勢和努力的方向到底是什麼呢？
我的答案依舊是，業務專家。
我理解的業務專家的技能特長包括如下幾點：
1.能夠快速融入專案，理清專案脈絡；看起來是不是和測試沒關係？no，測試即服務，測試是為了質量服務的，只要是能保證質量的事情，測試都可以去推進優化。2.能夠把同乙個產品中各個業務的關聯關係熟悉清楚，並了解核心功能是什麼；
3.能夠從使用者視角出發，提出使用者體驗和使用場景相關的需求問題；
4.能夠清晰的明白業務的優先順序劃分，在投出產出比上做好平衡；
如果能達到上面業務專家的要求，那麼就可以解決因為關注不夠而造成的需求合理性和全面性考慮不周全的問題。
測試是同時離業務和使用者都很近的角色，只有我們能把這個環節打通，也一定能發揮更大更重要的作用。
新技術導向下的IT運維管理
隨著it運維在國內發展了十多年的歷程，企業關注的不再是應該用何種網路管理產品，而是什麼樣的it運維產品能夠真正提高it運維的效率 實現其價值。一套好的it運維軟體必須幫助企業實現網路利用率的最大化。如何能達到利用率的最大化呢？我總結了以下三個方面 通過自動化的流程觸發，方便進行監控和事故處理 對重要...
需求導向的軟體構件技術
在專案開發過程中，由於軟體開發，是乙個不可分割的過程，是一系列連續的活動過程，一環扣一環，包括需求分析，設計，實現，測試，移交，及公升級維護，最終淘汰的過程。我們知道在軟體專案實施過程中，盡量的去重要一些基本庫或是一些構件，因為原來的庫的功能在不斷的迭加，bug在不斷的減少，穩定性有保障，同時開始的...
發展戰略 以技術為導向還是以產品為導向的方向選擇？
提供開源硬體產品 嵌入式軟硬體開發 技術諮詢 店 目前大部分電子類公司分兩種 一種是技術導向型，如方案型公司，典型如 勝科技 另外一種是產品導向型公司，有自己的產品和自己的銷售團隊，這裡分兩種，有些有自己的研發，典型如ae 翰，有些沒有自己研發，如工廠 外貿加工企業。技術導向型 有技術，有方案，但沒...