軟體測試工程師是一個歷史很悠久的職位，可以說從有軟體開發這個行業以來，就開始有了軟體測試工程師的角色。隨著時代的發展，軟體測試工程師的角色和職責也在悄然發生著變化，從一開始單純的在瀑布式開發流程中擔任測試階段的執行者，到敏捷開發流程中QA（Quality Assurance）角色，為整個團隊和產品的質量負責，測試工程師的職責和邊界不斷的擴大。近年來網際網路行業的很多測試工程師被稱為是測試開發工程師，也就是要具備自動化測試和測試工具開發能力的測試工程師，可以說是對測試工程師的能力要求達到了一個新的高度。
相信有過測試工作經驗的同學都會深有體會，不管是瀑布式還是agile模式，測試人員的工作總是被壓在產品釋出的最後階段，整個團隊的壓力似乎都壓在測試工程師身上，沒有人會理會開發過程中產生的延誤，因為那已經過去，可以在retro meeting的時候diss，但是目前最重要的問題是完成產品的釋出上線。所以在尋找測試工程師需要什麼技能之前，測試工程師的核心問題是什麼，這是我們要搞清楚的。
測試工程師面臨的核心問題
如何以最小的投入，最大程度保證產品的質量
這個問題相信大家都有所體會，商業社會追求的就是效率，甚至是極致的效率。測試工程師也不能例外，不管是叫測試工程師，QA，或者是聽著高大上的測試開發工程師，其實老闆們的目標是一致的，就是在儘可能少的投入，最大程度保證產品的質量。說得現實一點，你的薪資水平就取決於你能解決這個核心問題的能力。 明確了我們的目標，我們所需要的能力，也是圍繞著這一個目標來設定的。
概述
- 測試設計能力
- 程式碼能力
- 自動化測試技術
- 質量流程管理
- 行業技術知識
- 資料庫
- 業務知識
測試設計
作為一名測試工程師，最基礎的能力應該就是根據產品來設計測試用例的能力。最基礎的能力往往也是最難做到精通的能力。要設計好的測試用例，需要對產品的特性和業務非常的熟悉，對使用者的使用場景有著系統化的思考。除此之外，還有一些科學的測試用例設計方法可以幫助我們設計規範化的用例，而不是僅僅根據經驗或者天馬行空的想法來設計用例。 業界有一些經典的測試用例設計方法需要測試工程師掌握：
- 邊界值分析
- 等價類劃分
- 因果圖
- 判定表
- 正交實驗設計
上述的這些方法並不是教條，而是幫助我們理清測試用例設計的思路和提高效率的工具。
程式碼能力
在傳統的思維中，對測試人員的程式碼能力要求似乎不是很高，在業界確實也是這樣的。很多測試工程師基本上不具備程式碼的能力，更多是測試的執行者。 但是在當今這個時代下，要想突破傳統功能測試人員的天花板，程式碼能力是必須的。 具備程式碼能力的測試工程師有這樣兩個優勢：
閱讀開發程式碼
如果能夠具備閱讀開發程式碼的能力，對於提高測試人員的效率是很有幫助的，它可以幫助我們做到這些一些事情
- 通過開發修改的程式碼預估影響的範圍，即測試的範圍
- 參加技術評審，預估測試的風險，難點，重點
- 通過程式碼的邏輯設計測試用例，強化測試用例的覆蓋程度
- 對缺陷進行初步的定位
其實可以做到的事情還有很多，體現在測試過程的很多細節當中
自動化測試的開發
自動化測試是測試發展的方向，也是提高效率的有效方法。具備了程式碼能力，你可以輕鬆的駕馭各種流行的自動化測試框架和用例開發。
自動化測試
接著上面關於自動化測試的討論。在目前的熱門公司的招聘中，自動化能力已經是必備的能力，也是大家很關注的一個領域。 目前可以粗略的把自動化測試分為這麼幾類：
UI自動化
UI自動化實現的目標是模擬人在產品UI介面上的操作，從而觀察結果來完成測試的執行。UI自動化也可以從客戶端的形態上分為PC端和移動端的自動化測試，有這樣一些著名的自動化工具需要我們掌握：
Selenium
Selenium是一個很經典的WEB端產品的UI自動化工具，針對不同的開發語言都有很好的支援。它的原理簡單來說就是通過WebDriver把指令碼產生的操作指令傳遞到瀏覽器，執行我們需要的操作並且獲取相應的反饋，在指令碼中完成校驗。
Appium
從這個名字就可以看出這個工具和Selenium的相似之處。其實Appium可以理解為就是移動端的Selenium。同樣也是在移動端模擬人的操作來實現執行測試用例的目的。 隨著移動網際網路時代的到來，更多的業務已經從PC的WEB端轉移到了移動端，移動端的自動化測試越來越重要。
其實UI的自動化實現的原理都是很類似的，基本的邏輯都是：
- 定位元素
- 操作元素
- 獲取反饋
最後通過某種測試用例框架來管理測試用例，例如python的unittest，JAVA的TestNG，Ruby的respec等等。 所以說了解了某一種UI自動化的框架和工具，很容易的就能觸類旁通的學習新的框架和工具。
介面自動化
在目前SaaS成為主流的情況下，API，即介面，成為了支撐業務的核心部分。前端頁面和App裡面的業務資料都是通過各種API與伺服器進行通訊，從而實現業務功能。 目前大多數的介面都是基於HTTP協議的，其中Restful的介面又佔大多數。而很多語言，例如Python和Ruby都有很好的庫來支援HTTP協議的請求，這就為我們設計介面自動化提供了很好的基礎。 回到我們的核心問題，投入產出比的衡量。UI的自動化無論是從實現的成本還是維護的成本來說都是巨大的，所以業界越來越把重心放到了介面層的自動化實現上。 介面的自動化具備這樣的優勢：
- 執行效率高
- 開發成本低
- 維護成本低
- 可以與開發程式碼同步開發
介面自動化的實現思路也是簡單明瞭的，那就是模擬瀏覽器，傳送HTTP請求來實現對介面的呼叫，然後比較返回與期望值，達到驗證結果的目的。 當然，要設計一套真正高效的介面自動化框架也是不容易的。這裡面涉及到如何提高用例的開發效率，降低開發維護成本等關鍵問題。同時還可以把介面測試與效能測試結合起來，豐富介面自動化測試的內涵。
質量管理流程
在敏捷開發的流程中，測試工程師有了一個新的定義：Quality Assurance Engineer。而測試的執行僅僅是職責中的一部分，更為重要的是要為整個團隊的產品質量負責。 從整個sprint的週期來看，QA工程師都要始終如一的貫徹質量保證的意識，與開發的關係也從早期的發現bug，轉變為如何幫助開發團隊一起提高產品的質量。同時還要和產品團隊密切的合作，在需求的分析階段就介入，分析質量保證工作如何規劃和設計，而不是在產品釋出前的測試執行階段才介入。 這個裡面還包含很多Soft skill的要求，包括如何與團隊合作，溝通等等，這也是敏捷開發模式的關鍵之一。
行業技術知識
這一部分內容其實涵蓋的內容是非常豐富的，就以網際網路行業舉例吧。 對於一個網際網路產品，測試工程師需要了解的甚至是精通的知識是很多的，從前端頁面的技術棧，API的設計，後端伺服器的設計，後面會專門提到的資料庫，還有整個服務的架構等等，測試工程師都需要有所瞭解。 針對這個問題，其實有一個非常好的問題可以幫助大家去梳理涉及到的知識，這就是：
從在瀏覽器的輸入框輸入一個網址，到看到網頁的內容，這個過程中發生了什麼？
回答這個問題的深度和廣度，基本就能反映一個測試工程師對於網際網路產品技術的掌握情況。 在這裡呢，我簡單的羅列一些涉及到的技術和概念，這些內容對於我們測試產品，都是非常有幫助的。
- DNS
- TCP/IP
- HTTP
- SSL
- Restful
- HTML
- DOM
- CSS
- Render
- Xpath
- 伺服器
- nginx
- SQL
- Cookie&Session
- XSS，CSRF 這裡僅僅是涉及到一部分內容，具體的內容可以根據工作中遇到的場景去深入學習和了解。
資料庫
之所以把資料庫單獨列出來，是因為資料庫的知識對於當今的很多產品都是非常核心的內容。 不管是在手動測試還是自動化測試中，都有需要到資料庫進行資料校驗的時候。 目前主要使用的資料庫可以分為兩類：
- 關係型資料庫
- 非關係型資料庫
關係型資料庫
關係型資料庫是最常見的資料庫型別，這類資料庫通過RDBMS資料庫程式來進行管理和使用，常見的有SQL Server, MySQL等等。 關係型資料庫中強調一個事務（Transaction）的概念。所謂事務是使用者定義的一個資料庫操作系列，這些操作要麼全部執行，要麼全部不執行，是一個不可分割的工作單位。例如在關聯式資料庫中，一個事務可以是一條SQL語句、一組SQL語句或整個程式。 事務應該具有4個屬性：原子性、一致性、隔離性、永續性。這四個屬性通常稱為ACID特性。
- 原子性（Atomicity）：事務作為一個整體被執行，包含在其中的對資料庫的操作要麼全部被執行，要麼都不執行。
- 一致性（Consistency）：事務應確保資料庫的狀態從一個一致狀態轉變為另一個一致狀態。一致狀態的含義是資料庫中的資料應滿足完整性約束。
- 隔離性（Isolation）：多個事務併發執行時，一個事務的執行不應影響其他事務的執行。
- 永續性（Durability）：一個事務一旦提交，他對資料庫的修改應該永久儲存在資料庫中。
對於實際的應用來說，SQL語言是必須要掌握的。能夠通過SQL語句在資料庫中找到需要的資料，是測試工程師必備的技能。SQL語句的語法大體上比較類似，在一些細節上不同的RDBMS會有些許的差別。 對於自動化實現來說，在自動化測試中通過訪問資料庫來獲得期望值也是很常見的場景。不同的語言都有訪問資料庫的庫，整體來說應用也很簡單。
非關係型資料庫
隨著網際網路中大量的非結構化資料的產生，例如社交網路等等應用，使用者的個人資訊，社交網路，地理位置，使用者生成的資料和使用者操作日誌已經正在以幾何級數的速率增加，同時還面臨大量的資料探勘工作，傳統的關係型資料庫已經無法滿足。所以NoSQL漸漸的發展了起來。 NoSQL最突出的特點就是資料的非結構化，通俗的講，就是資料不再是以列和行這樣的形式儲存的。 NoSQL儲存資料的方式很多：值對儲存，列儲存，文件儲存。 例如比較常見的MongoDB就是將資料儲存為一個文件，資料結構由鍵值(key=>value)對組成。MongoDB 文件類似於 JSON 物件。欄位值可以包含其他文件，陣列及文件陣列。
RDBMS vs NoSQL
RDBMS
- 高度組織化結構化資料
- 結構化查詢語言（SQL） (SQL)
- 資料和關係都儲存在單獨的表中。
- 資料操縱語言，資料定義語言
- 嚴格的一致性
- 基礎事務
NoSQL
- 代表著不僅僅是SQL
- 沒有宣告性查詢語言
- 沒有預定義的模式：鍵 - 值對儲存，列儲存，文件儲存，圖形資料庫
- 最終一致性，而非ACID屬性
- 非結構化和不可預知的資料
- CAP定理
- 高效能，高可用性和可伸縮性
業務知識
對於測試工程師來說，所測試產品的業務知識也是非常重要的。 一個測試工程師可能已經具備了上述的所有技能，但是怎麼把這些技能用來解決我們最先提到的軟體測試的核心問題呢？這個裡面的關鍵，或者說中心點，就是你所測試的產品的業務。 測試的方法，規劃，實施方法都是多種多樣的，如果在這些方法中進行選擇，所依賴的正是對產品的業務的深刻理解。 這裡的產品業務不僅僅指產品的特性，同時還包括了產品的使用者特徵，使用者的使用習慣，以及由此帶來的對產品的流量趨勢。也可以說，測試人員必須要站在使用者的角度來分析產品，而不是產品開發人員的角度。 測試人員還需要找到產品的核心功能和核心業務，通過這樣的分析來進行測試優先順序的劃分，以及缺陷的定級。同時對於自動化測試的規劃和架構也有著重要的影響。例如在自動化測試中要首先覆蓋那些核心的業務和功能，同時根據業務的特性，用自動化的方法去模擬使用者的使用場景，把有限的自動化資源投入到最關鍵的部分。 這一塊技能聽起來可能很虛，好像沒有什麼具體的知識點，但是在不斷的工作和總結中，優秀的測試工程師是能夠總結出一套符合某一類產品的測試方法的，甚至還可以提煉出一些更具備通用性的best practice，用到不同的產品中。
說在最後
或者這樣一篇短短的文章無法涵蓋軟體測試的內涵，但是筆者也只是想拋磚引玉，讓讀者能夠通過這樣一種不能算全面的梳理，結合自己的工作經驗，對自己所從事的軟體測試工作有一個更深的理解。
筆者計劃根據這篇文章所列出的技能樹，分別寫文章進行更加細緻的梳理和總結，希望能夠和各位同行一起學習，一起進步，同時非常歡迎大家指正我的錯誤和不足。