測試人的自我修養（二）

來自專欄 有道測試

接上一篇這裡講述一下在技術層面測試工程師需要具備的素質和能力，分四個方面，分別是：

> 測試技術&建模能力 > 問題敏感性&邏輯分析能力 > 行業知識&快速學習能力 > 技術框架&讀、寫代碼的能力

1. 測試技術、建模能力

開發、產品甚至是技術領導覺得測試只要了解了被測試對象是做什麼的，怎麼做的，就能做好測試了。甚至很多測試人自己也普遍存在此種想法。這兩個能力是測試人的能力核心，也是價值的體現。

建模能力是分析產品的能力，既包括功能、性能、壓力等，也包括使用場景、所屬行業，測試完整性反饋出來的就是這方面的能力。測試leader如果欠缺這方面的功力，那麼產品發布後得到的可能就是不定期和無休止的「驚喜」。不同公司在測試建模方面有不同的實踐，目前國內大部分公司基本是延續公司的既有先例，比如將測試用例分為功能、性能、組合、壓力、異常等，公司的測試人員也甚少去考慮為什麼測試這些，是否還有其他方面需要考慮的，只是簡單重複執行而已。不同的產品有不同的用戶和市場，測試模型需要單獨考慮。 目前比較有代表性測試建模工具，一個是james bach的HTSM(啟發式測試策略模型)，另一個是Google在《

How Google Tests Software 》提到的ACC模型。

這兩個模型都有幾年的時間了，不知道是否有所更新和發展，後續有單獨的文章對測試建模進行分析。

Cem Kaner教授從測試的範圍、覆蓋程度、測試者、風險、活動、質量評估幾個角度來對測試技術進行分類，此分類已經建立了有十幾年的時間，業界具有權威性。比如基於測試的範圍和覆蓋度有功能、性能、本地化、配置、邊界值等；基於由誰來進行可以分為用戶測試、α測試、β測試、本地化測試、專家測試等；基於風險有快速測試、負載測試、性能測試等。不同的測試分類會有相互交叉，我們可以根據公司產品的質量狀態、研發流程、產品特點、研發水平選用不同的測試技術，來滿足市場對產品質量的需求。

junit、nose、robotframework、jenkins、monkeys、selenium等等只是實踐測試技術的工具，技術是核心，建議未了解過的測試同學增強這方面的能力。

2. 問題敏感性、邏輯分析能力

看到同一個現象，不同的人有不同的反應：無反應（我看到什麼了？）、正常、有問題。對於反饋正常或有問題的，說明他意識到了這個現象，並且有意識的去分析這個現象是對還是錯；而完全無反應的，就屬於那種對問題特別不敏感的，需要加強鍛煉。比如可以對看到的任何現象都有意識的去分析一下，是對的還是錯的、是否符合習慣、是否合理、讓你來做你會怎麼做等等。

對問題比較敏感的人會將這類思維帶入到生活中，比如快遞到了得先看看是哪裡寄出來的、字有沒有寫錯的、採用這種包裝內容物有沒有被換掉的風險等等。

每個測試人都希望得到所在團隊的尊重和認可。在技術型的公司中，得到尊重唯一的方法是彰顯自己的技術實力（當然交流方式也是很重要的）。被尊重是通過自己不斷的努力爭取來的，這就是平時溝通、交流過程中所體現出來的問題綜合分析能力，以及對系統實現、市場應用的深刻理解。

作為一個測試工程師，碰到問題的時候，你能指出這個問題出現在代碼的哪個服務、哪個模塊、哪個函數嗎？是如何調用的？ 甚至是開發同學是如何寫錯的，怎麼改正是對的？如果你覺得這不是測試該乾的，那也就只能呵呵了。

3. 行業知識、快速學習能力

所謂行業知識，是指從事這個行業的人，所需要掌握的知識體系、行業規範、實時動向、發展狀況等。不同行業比如金融、電信、製造、電商、教育、物流等所需具備的知識是完全不同的。只有具備良好的行業背景才能理解客戶需求，並設計滿足用戶需求的產品，做出合理的測試決策。

你所在的行業有哪些技術規範、行業標準，了解嗎？ 國內的，國際的，差異在哪裡？

在當前智力大爆發、黑科技頻出，不想關的兩個行業都可以相互顛覆的時代，測試人作為投身其中的一份子要麼隨波逐流被動調整，要麼主動尋求改變。不管哪種方式，我們都需要具有快速學習的能力才能跟得上這個時代的發展，並站在用戶的角度去研究領域知識，成為領域專家，給產品、市場等團隊提出合理的產品設計建議，並給出客觀的質量評價標準。

你有危機感嗎？測試工作會被機器學習、人工智慧取代嗎？還是開發同事先擔心吧，Google已經在研究機器學習寫代碼了。

4. 技術框架、讀寫代碼的能力

隨著競爭的加劇，不管是熊廠、鵝廠還是狼廠比拼的都是產品上市速度。在這種壓力下，不可能預留太長的測試時間，持續集成、自動化測試是必然的。這就要求測試人不光要了解測試的技術，還要熟悉網站業務的分割分層、資料庫的分庫分表、數據的冷備熱備；開發所採用hibernate、spring、structs等技術框架，以及java、python、go等層出不窮的語言，以便及時進行單元、集成、API介面、UI層面自動化用例的開發，提高測試的效率。

這是在網上看到的一個例子： 在一個有著廣泛市場影響的項目中，新版本發布增加了新的功能，在HTML頁面中使用JavaScript來控制控制項的顯現。而發布時間緊迫，不允許有更多的時間使用正向用例來驗證功能的正確性。儘管如此，我們也針對這小小的控制項設計了將近百條用例。涉及的方面包括從頁面的正反向跳轉來驗證控制項的版本升級，到控制項的跨域調用、瀏覽器的兼容、服務設置及干擾，如此種種，無一不需要了解相關技術，才能設計出有價值的用例。

不管測試分析能力多強，黑盒始終發現的是一部分問題，白盒測試是發現更多問題、提高測試效率的必然手段。但是目前來看，測試工程師對系統的認知能力，是自動化測試比拼不了的，比如易用性、性能測試等。

微信公眾號：有道測試

推薦閱讀：