測試工具

靜態程式碼掃描工具 自動化測試工具（selenuim，appuim，robort framwork， testng， xunit） 效能測試工具（jmeter， gatling， abe， loadrunner） aitest（facebook 開源工具 自動分析程式碼，測試，生成fix） 探索測試工具（狀態機 exploer） diff測試工具 （twitter diffy） 安全測試工具（fuzze testing） 8. 終端測試技術（ android ios 自動化測試， qta， appuim， xctest， 耗電量，效能專項）

周邊配合開源平臺

elk kafka /zookeeper Jenkins Docker Kuberneters Django Flask 8. bubble /redias

工程知識

持續整合/持續釋出 軟體釋出/運維監控 過程質量管理 專案過程控制 devops工程文化 各角色特點，協同 程式碼管理，研發方式 軟體配置管理專員 研發團隊現狀/工程重點識別

基礎通識技能

程式語言（python node.js java c++）
自動化框架開發能力（b/s)
測試設計能力（大型/中型/小型測試能力）

4. 測試工具理解，應用能力（） 5. 網路理解（unix 網路程式設計 /bs. Socket 二進位制通訊， pb協議） 6. 架構理解（展示，邏輯， 儲存，快取， 有狀態/無狀態， 容災， 魯棒，效能，rpc框架） 7. 產品理解（行業背景，業務現狀） 8. 資料庫技能 9. unix網路程式設計/客戶端程式設計/web程式設計研發基礎： 1. 研發流程。 2. 使用工具,平臺。3. 語言特性，技術特徵

測試體系搭建前的三個問題

1.為什麼有測試這個職業？

我自己從06年進入測試行業到18年中間有12年的測試經驗。結合個人經歷，以時間維度來看看。 早期階段：使用者質量角度主導。 軟體釋出後是否好用，易用，及使用者心聲建議。測試行為聚焦在：功能測試，競品分析，自動化迴歸，效能等各類質量建設。各類建設逐漸需要形成特別的技能，知識，專業性，測試單獨形成一個職業。 通常單獨設定測試崗位的公司，都是有一定使用者基礎，公司穩步執行的公司。初創型公司，未必有測試崗位，但測試行為是恆古不變的，通常會有小團隊，研發，產品自己分擔。 這一時期的測試，普遍價值存在感不高，會寫自動化，做效能等專項才被認為是技術人員。

專項技能沉澱階段：技術技能主導： 自動化，效能，安全，記憶體洩漏等各類專項檢驗更多開展，測試的專業性有更多體現。 系統測試從業務系統的維度，把自動化，研發效能提升工具引入，結合專案工程優化實踐方案，在業務團隊更被認識到價值。測試開始分成更多有專注點的崗位， 專項技術測試，系統測試，遊戲測試，客戶端測試等等分類提出。

測試延伸階段： 豐富利用產出主導：隨著測試分工更清晰，各自專業性的發揮也被更多人認可和利用，業界devops理念逐步完善，各類工程實踐，都趨於從研發過程生命週期整體看待問題，測試行為和技能沉澱， 開始擴充套件應用， 持續整合引入，持續測試實踐有更多測試元素進入，測試這個階段，和測試行為的執行從有極強的邊界，到逐步模糊。 人人測試，提前測試，線上監控，質量意識應該有全員保證，質量不是測試出來的，等討論更多了起來。docker， jenkins pipeline等公共，和各類開源技術，讓devops，雲， 讓研發團隊各工種邊界有了更多的跨越和重合。

認知理論延伸階段： 測試-》測試開發-〉公共基礎生成力建設。在大家都對齊應該做測試， 怎麼做測試的方法論統一之後，公共生產力平臺建設成為階段性的重點。這類團隊有很好的工程師文化， 程式碼走讀， 靜態程式碼掃描，程式碼倉庫管理，編譯優化， 公共知識管理，持續整合能力建設，產品架構設計，線上運營部署，運維管理， sre ,過程控制管理，基礎平臺生產力演進都屬於齊頭並進的階段。到後面甚至會有公共知識文件管理員， 配置管理員等多類角色出來。

於此對應的是在各類公司對測試成員崗位的組織架構命名就能得到體現： xxxx測試組， xxxx質量架構組， xxx測試開發組， xxxx生產效能組， 各組上面的中心： xxxx測試中心， xxxx支援中心，多中心的部門： 研發管理部， 研發質量部， 研發效能部， 研發生產力團隊等等。

如前所述，測試的行為是更古不變的。 在經歷過功能測試-》自動化->專項->測試開發-〉基礎生成力-》研發效能等多個環節，能力逐步演進後，以及過程中， 新的短板又會從新成為新的要求。誰能知道，如果哪天大家都具備了前面提到的各類知識掌握後， 最原始的功能，和產品的理解功能測試不會變成一種新的稀缺能力？

總結： 從測試時間線回顧所有做過的事情， 測試存在的本質，是兩個維度： 1. 對外使用者質量負責。 2. 對內研發體系支撐。更古不變。

2. 什麼是質量體系

一套成熟的方法論，並且有配套的工具平臺。 涵蓋研發，測試，運維多角色。涵蓋研發全生命週期賦能。 統一的度量資料反饋系統。針對研發，測試，運維，產品多角色的生成效率提高工具。各類質量檢測方法和手段能力庫。 總結： 能促進產品質量效率提高的一套涉及人員，方法，運轉標準的方法論及工具平臺總稱。涵蓋研發全生命週期過程及人員的賦能。以工具平臺和標準規範作為賦能方式。有完整的度量體系幫助組織進一步優化。

3. 為什麼要搭建質量測試體系？

這就跟問為什麼足球場上要派兵部陣一樣。為了贏得比賽。 組織形成共同的目標和最大化組織能力，完成公司戰略任務。在軟體研發領域 1+1 != 2 的現象尤其突出。有可能10個一樣的人做出來的事情，不如1個人完成的。 專家把自己做事的方式形成知識結構體系，甚至有可能形成組織結構體系， 讓目標得以實現。 測試體系體現了對待通識問題的解決手段和方案，避免資源浪費，促進組織能力建設。

怎麼搭建測試體系

理解業務《兩個視角》

技術特點：

業務特點是偏向哪一類技術？（綜合看要具備的哪類測試能力，重終端，重後臺，重運營等等） 現有架構可能變化的部分，可能瓶頸部分？（可能會產生變化的地方）

業務特點

業務擴充套件將會有的挑戰和重點方向是？（技術佈局的方向） 現有業務最需要研發保證的地方

理解方式《兩個視角》

從現實著手應對當下

定義問題《目前亟待測試解決的問題是？目前研發側的痛點是？目前產品的階段是，重點是？組織的目標是？》 找到問題關鍵路徑《找到最核心問題和解決手段》 確定目標《以量化資料確認目標，最好一句話能說明白》

面向未來

多問未來問題 佈局能力：可能的質量風險（功能，安全，效能，品牌風險） 人力配比：可以預見研發會增加的資源，將會有的產品形態 3. 基礎能力： 可能的研發模式（技術棧，研發方式，迭代情況） 一樣的未來的關鍵問題是什麼，找到問題關鍵路徑

構建組織個人能力圖譜

理解清楚業務，及可能的方向後，對問題解決能力構建清晰圖譜。 啟用組織成員中對自身能力及組織目標的認識，有清晰圖譜可以參照員工個人成長

構建組織演進roadmap

 各成員對自身能力和組織發展方向理解一致

搭建執行方式

專項能力拆分成專案
專案方式，切香腸運作方式（不同的團隊不同促進，有的提供模版，有的自發形成）
構建共同目標，共同利益權責分擔