軟體測驗工程師是一個歷史很悠久的職位，可以說從有軟體開發這個行業以來，就開始有了軟體測驗工程師的角色，隨著時代的發展，軟體測驗工程師的角色和職責也在悄然發生著變化，從一開始單純的在瀑布式開發流程中擔任測驗階段的執行者，到敏捷開發流程中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，用到不同的產品中，

說在最后

或者這樣一篇短短的文章無法涵蓋軟體測驗的內涵，但是筆者也只是想拋磚引玉，讓讀者能夠通過這樣一種不能算全面的梳理，結合自己的作業經驗，對自己所從事的軟體測驗作業有一個更深的理解，

筆者計劃根據這篇文章所列出的技能樹，分別寫文章進行更加細致的梳理和總結，希望能夠和各位同行一起學習，一起進步，同時非常歡迎大家指正我的錯誤和不足，

最后，綿薄之力

感謝每一個認真閱讀我文章的人，雖然不是什么很值錢的東西，如果你用得到的話可以直接拿走，希望能幫助到您面試前的復習且找到一個好的作業，也節省大家在網上搜索資料的時間來學習！有需要的小伙伴可以加群：11347，25192 

標籤：其他

上一篇：高頻Jmeter軟體測驗面試題

下一篇：返回列表