軟件測試人員的挑戰與機遇_軟件測試工程師入門

軟件測試人員的挑戰與機遇

發表于：2019-06-11來源：林冰玉作者：林冰玉點擊數：標簽：

軟件測試總是被看做沒有技術含量、沒有前途的工作，很多做軟件測試的朋友也比較迷茫，表示發展受限。在這個技術飛速發展的時代，各行各業都在實行數字化轉型，各種高新技術似

軟件測試總是被看做沒有技術含量、沒有前途的工作，很多做軟件測試的朋友也比較迷茫，表示發展受限。在這個技術飛速發展的時代，各行各業都在實行數字化轉型，各種高新技術似乎離測試人員越來越遙遠…

那么，測試人員真的是前途渺茫嗎？本文將根據ThoughtWorks最新發布的第20期技術雷達來分析當前流行的技術給軟件測試人員帶來的影響是什么，有哪些機遇與挑戰。

技術雷達上的內容涵蓋有技術、平臺、工具和語言四個維度，我觀察到其中跟測試人員關系比較緊密的主要有以下幾個方面：

1. 支持快速、持續交付的基礎設施與DevOps實踐

質量和速度是最關鍵需求，為了適應各行各業對速度的要求，配套的支持快速、持續交付的基礎設施與DevOps實踐是成功之必備。技術雷達上與之相關的條目有很多，比如：Terraform生態系統和四個關鍵指標等。

Terraform生態系統

Terraform是一種安全有效地構建、更改和版本化基礎架構的工具，可以管理現有和流行的服務提供商以及定制的內部解決方案，正在迅速成為通過聲明式定義來創建和管理云基礎設施的首選工具。本期雷達Terraform相關的內容重點包括Terratest（用于測試基礎設施代碼)，以及GoCD的新提供商（可以使用Terraform配置GoCD)。

基礎設施不僅是Ops或者開發人員需要關注的領域，作為測試人員，同樣需要加強這項知識的掌握：

了解了基礎設施知識，結合已有的測試sense，測試人員可以和開發或Ops一起測試基礎設施；
了解基礎設施特點，可以指導測試的設計，在測試的時候更有針對性的關注比較脆弱的節點、環節，規避風險，增強系統的反脆弱性；
利用基礎設施知識，可以指導測試環境的搭建和維護、自動化測試數據的準備和管理等。

四個關鍵指標

埃森哲發布的DevOps報告指出組織績效跟軟件交付性能關系緊密，而衡量組織績效的四個關鍵指標分別是前置時間、部署頻率、平均修復時間(MTTR)和變化失敗率。本期技術雷達采納了這項技術。

作為測試人員，我們需要了解每個指標的真正含義，并且思考我們測試策略是否需要做某些調整來提供對應的指標值。比如說為了提高部署頻率，可能不需要那么高的E2E自動化測試覆蓋率，而是達到覆蓋效果和執行效率最佳平衡的一個狀態即可。

2. 支持業務靈活擴展的微服務架構

引入微服務令我們受益匪淺，使用微服務，團隊可以擴展那些獨立部署和維護的服務的交付，從而方便業務的靈活擴展。微服務架構正在逐漸被越來越多的企業采用。我們看到技術雷達上應對微服務的相關條目有服務網格、混沌工程、API測試框架Karate等。

服務網格（Service Mesh）

服務網格是一種安全、快速、可靠的運行微服務生態系統的方式。這種方式為輕松地大規模采納微服務奠定了基礎。它提供了檢測、保障、跟蹤、監控和故障處理功能。它提供的這些跨功能能力無需共享API網關等資產或將很多依賴庫納入到每個服務中。

混沌工程（Chaos Engineering）

混沌工程是對系統進行試驗的一門學科，旨在建立對系統抵抗生產環境中不確定條件的能力的信心。在去年，我們看到混沌工程從一個備受關注的、想法，轉變成公認的主流方法，來改善并保證分布式系統的彈性。主要用于以下幾類故障時增強系統的彈性：基礎設施故障、網絡故障和應用程序失敗，對應的工具有Gremlin和Chaos Toolkit等。

Karate

Karate是一款API測試框架，其特色在于，直接使用Gherkin來編寫測試，無需依賴常用編程語言來實現測試行為。Karate是一個領域特定語言，用來描述基于HTTP的API測試。雖然該方法很有趣，可以為簡單的測試創建非常易讀的規范，但用于匹配和驗證負載的專用語言可能會變得語法晦澀、難以理解。從長遠來看，使用此風格編寫的復雜測試是否將可讀且可維護，仍有待觀察。

微服務帶來靈活性的同時，也帶來很多的復雜性和不確定因素，尤其是對質量保障帶來了挑戰，因此微服務系統的測試也備受關注。作為測試人員，只有了解了微服務架構與服務網格的特點及其對測試的影響、混沌工程對質量保障的幫助、API測試的框架選擇與測試優化等，才能更好的做好微服務系統的測試。

3. 多樣化數據形態的支持

隨著數據源的增加、數據規模的擴大、數據種類越來越多，相應的數據形態也呈現出多樣性，包括NoSQL、時間序列、像CockRoachDB和Spanner這樣提供全局一致性的SQL存儲，以及提供聚合日志文件查詢功能的事件流。不再是關系型數據庫解決一切存儲的時代了，要考慮真實需求，采用合適的策略和工具。

數據形態的變化，必然對測試也提出不同的要求。作為測試人員，需要了解不同的數據規模、不同的存儲形態、不同的數據類型分別該如何驗證、測試該如何設計、測試數據該如何準備，還有數據安全、數據匿名化、數據分析等數據相關技術對測試的支持等。比如，對于大量數據處理的項目，測試人員需要了解數據處理的技術與處理邏輯，分別從功能層面驗證處理邏輯的正確性，以及從非功能方面考慮大量數據處理的性能、數據處理的安全規約等。

(圖片來自網絡)

4. 網絡安全始終是重中之重

網絡給我們生活帶來便利性的同時，其安全性也是備受關注。2018年歐盟頒布了GDPR法令，使得眾多企業不得不緊急調整系統功能做好個人身份信息的保護工作。網絡安全始終是質量保障的重中之重，絕對不容忽視。本期技術雷達推薦的安全相關條目有密碼即服務、容器安全掃描、密鑰銷毀技術等。

密碼即服務（Secrets as a service）

在構建和運維軟件的價值流中，密碼憑據在多個場合都需要使用：構建流水線需要使用密碼來與容器注冊中心等安全基礎設施進行交互，應用程序需要使用API密鑰作為密碼憑據來獲得業務功能訪問權限，而服務間通信則需要以證書和密鑰作為密碼憑據來保護其安全，這些密碼憑據不建議通過源代碼的方式管理，而是采用密碼即服務的技術來存儲和訪問。利用這種技術，可以使用Vault或AWS Key Management Service(KMS)等工具來讀寫HTTPS端點上的密碼憑據，同時實現精細的訪問控制。

密鑰銷毀技術（Crypto shredding）

密鑰銷毀是指主動覆蓋或刪除用于保護敏感數據的加密密鑰，以保護敏感數據不被讀取。對于審計應用程序或區塊鏈這樣不應該或不能刪除歷史記錄的系統來說，密鑰銷毀技術對于隱私保護和GDPR合規非常有用。

容器安全掃描（Container security scanning）

圍繞Docker的容器革命顯著減少了應用在跨環境遷移時的阻力，并推動持續交付和持續部署的采納。但尤其是后者，對于傳統的投產控制帶來了相當大的漏洞。容器安全掃描技術是對該威脅載體的必要響應。構建流水線中的工具，會自動檢查流水線中的容器是否存在已知漏洞。

作為測試人員，對于上面的安全相關技術可能不需要掌握的很深，但是需要了解有這樣的一些技術，以及對應的使用場景。這樣，才能對于系統整體的安全質量有更好的把握。此外，測試人員需要了解相應的安全測試技術，需要關注業務方面的安全需求，了解不同領域的安全規范和要求，從需求階段做好威脅建模開始，跟團隊一起在軟件開發生命周期做到安全內建（Build Security in）。

5. 自動化測試與線上質量的關注

要快速交付，必然離不開自動化測試，而要做好自動化測試，更是離不開相應工具的支持。本期技術雷達上列出的Cypress、TestCafe和Puppeteer被譽為后Selenium時代的Web UI測試的三駕馬車，值得關注。這三個工具不同于WebDriver時代的自動化測試工具，具有更加輕量級、更加穩定、速度更快的優點。

隨著技術架構的演進和業務領域的發展，軟件系統生態越來越復雜。過于重視預生產環境的測試，不僅不能很好的保證生產環境的質量，而且影響交付速度。因此，我們要把質量關注點拓寬到生產環境，做到測試右移。本期技術雷達列出的相關工具有：日志管理工具Humio，Honeycomb，以及前面提到的混沌工程相關條目等。

Humio

在日志管理領域，Humio是一款相對較新的工具。該工具完全從零開始構建，通過基于定制設計的時序數據庫的內置查詢語言，在日志提取和查詢方面性能非?？?。從提取、可視化和報警提醒的角度來看，該工具能夠與幾乎所有工具相集成。

Honeycomb

Honeycomb是一個可觀測性工具，它從生產環境中提取出豐富的數據，并通過動態采樣使其可管理。開發人員可以記錄大量豐富的事件，并在之后決定如何劃分和關聯它們，這對于大型分布式系統的問題診斷很有幫助。

作為測試人員，自動化測試成為了必備技能，需要關注自動化測試工具的發展，了解新工具的特點與適應場景，更好的讓自動化測試工作發揮最大的價值。另外，測試右移的思想也越來越被大家接受，需要測試人員更多的了解基礎設施相關技術、線上監控技術等，跟Ops緊密的合作，做好QA in production。同時，利用生產環境的數據，為預生產環境的測試設計和數據準備等提供幫助，構建反脆弱的軟件系統。

6. 新興領域不容忽視

（圖片來自網絡）

最火熱的新興領域當屬AI，這也是未來的發展方向。本期技術雷達上列出的有機器學習和神經網絡訓練等內容，比如：機器學習持續交付模型、NLP的遷移學習和fastai等。

另一個熱門新技術是區塊鏈，技術雷達上區塊鏈相關技術條目有智能合約、超越以太坊的EVM和企業版以太坊Quorum等。

技術雷達上還提到一個新的內容，那就是隨著社會對科技的依賴程度日益增長，建議軟件開發團隊在制定決策時必須考慮道德問題，思考自己所構建的軟件會在未來產生什么影響。相應的工具有技術塔羅牌和道德風險手冊。

作為測試人員，這些都是大家可以關注并深入了解的方向。新興領域必然會對測試有不同的要求，比如：關于AI的測試需要考慮兩個方面，一個是對于AI產品的測試，另一個是把AI技術運用于測試中，比如自動化測試的智能化、生產環境數據的智能分析等。另外，對于區塊鏈，需要考慮它對測試帶來什么挑戰、有什么樣不同的測試方法來支持；對于道德風險的把控，我們軟件測試人員又該注意些什么？能夠提供哪些支持呢？

寫在最后

前面列的這幾項，除了自動化測試工具以外，其他的內容通常被認為跟測試人員沒多大關系。其實，軟件測試已經不再是那個簡單的通過模擬用戶行為點擊去驗證功能是否滿足的時代了，測試人員的眼光要放更開闊一些，考慮更多的質量相關因素。對于前面總結的這些項目，我認為不是跟測試人員沒有關系，而是給測試人員帶來了新的挑戰，提出了新的要求。同時，機遇跟挑戰并存，這些挑戰同樣也給測試人員帶來了很多新的發展機會。

那么，在眾多機會面前，測試人員該如何把握呢？推薦大家可以根據T型能力模型去提升自己的能力。