軟件測試工程師的技能樹

軟件測試工程師是一個歷史很悠久的職位，能夠說從有軟件開發這個行業以來，就開始有了軟件測試工程師的角色。隨着時代的發展，軟件測試工程師的角色和職責也在悄然發生着變化，從一開始單純的在瀑布式開發流程中擔任測試階段的執行者，到敏捷開發流程中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的自動化實現的原理都是很相似的，基本的邏輯都是：

1. 定位元素
2. 操做元素
3. 獲取反饋

最後經過某種測試用例框架來管理測試用例，例如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，用到不一樣的產品中。

說在最後

或者這樣一篇短短的文章沒法涵蓋軟件測試的內涵，可是筆者也只是想拋磚引玉，讓讀者可以經過這樣一種不能算全面的梳理，結合本身的工做經驗，對本身所從事的軟件測試工做有一個更深的理解。

筆者計劃根據這篇文章所列出的技能樹，分別寫文章進行更加細緻的梳理和總結，但願可以和各位同行一塊兒學習，一塊兒進步，同時很是歡迎你們指正個人錯誤和不足。