測試已死,我看未必
“測試已死”的觀點在業內仍然存在著爭議,很多公司縮減了測試人員,開發測試比屢創新高。本文旨在通過介紹軟體測試的新趨勢和新技術來展示軟體測試行業面臨的機遇與挑戰,為軟體測試工程師的職業規劃提供參考。
安全測試
從孟加拉國銀行 8100 萬美元被黑客成功盜取到美國民主黨郵件洩露事件可以看出,網路安全事件已經被推到了風口浪尖。隨著物聯網逐步普及,智慧家居、汽車電子等裝置的網路化水平大幅提升。但物聯網的安全卻不容樂觀,很多中小企業往往忽視安全防護。開源軟體的原始碼公開,黑客可以通過閱讀原始碼更容易的分析出軟體的安全漏洞,使得網路安全迎來了新的挑戰。當開源社群中釋出出 cve 漏洞時,需要廠商及時的合入補丁,否則將給黑客入侵敞開大門。
新的程式語言的出現在提高了編碼效率的同時,也為軟體產品增添了安全挑戰,需要安全廠商儘快推出相應的安全工具和安全加固方案。隨著 SaaS 的普及,相信會有更多的安全工具問世。滲透測試需要測試工程師閱讀原始碼來找出漏洞,與安全合規測試相比,需要更高的技術水平。在未來相當長的一段時間內滲透測試工程師將有很大的缺口。
人工智慧測試
近年來,人工智慧(AI)被越來越多的應用在 IT 行業,如智慧汽車、智慧家居和機器人等。尤其是 2016 年 AlphaGo 在圍棋領域掀起一股熱潮之後,AI 更多地成為人們熱議的焦點。人工智慧是一個新的領域,對於人工智慧本身的測試方案和測試工具還有待完善。
對於人工智慧在軟體測試領域的應用,即利用人工智慧來優化其他軟體的測試,目前已經取得了一定的進展。人工神經網路是軟體測試領域使用相對廣泛的 AI 技術之一。神經網路是基於生物學中神經網路的基本原理,在理解和抽象了人腦結構和外界刺激響應機制後,以網路拓撲知識為理論基礎,模擬人腦的神經系統對複雜資訊的處理機制的一種數學模型。目前在 OCR,語音識別,醫學診斷等方面已經取得了很大的成功。在軟體測試中,它非常適合 GUI 測試、記憶體使用測試及分散式系統功能驗證等場景。
遺傳演算法是另一個軟體測試中用到的 AI 技術。它是模仿生物遺傳和進化機制的一種最優化方法,它把類似於遺傳基因的一些行為,如交叉重組、變異、選擇和淘汰等引入到演算法求解的改進過程中。遺傳演算法的特點之一是,它同時保留著若干區域性最優解,通過交叉重組或者解的變異來尋求更好的解。在軟體單元測試中,已知輸入的引數的範圍,求解哪些引數的組合能夠達到最大的程式碼覆蓋率(也有些研究是能達到最大的路徑覆蓋 / 分支覆蓋)。因此,遺傳演算法可以用於選擇最優的單元測試用例,也就是單元測試的最優輸入集。同時利用人工智慧還可以優化測試工具,將軟體測試的上下文與測試用例結合起來,選擇最優的測試用例集進行測試。
靜態分析與符號執行
軟體可靠性是對軟體在設計、開發以及所預定的環境下既有能力的置信度的一個度量,是衡量軟體質量的主要引數之一。而軟體測試則是保證軟體質量、提高軟體可靠性的最重要手段。靜態分析工具可以直接對原始碼進行掃描,但其誤報率的問題有待改善。
大量可靠性問題隱藏在未知場景和不熟悉的開原始碼中,有必要通過程式行為分析工具來遍歷各種異常分支、程式碼的所有路徑。符號執行技術是精確的路徑遍歷,是隨機測試、FUZZ 測試的有益補充。
符號執行代表工具 KLEE,在第一次學術使用(2008)便發現了 unix 系統中最常用的程式的多個問題,有的問題已經存在超過 15 年。符號執行技術在之前沒有得到大規模應用,主要原因是技術本身需要大量的計算資源(路徑爆炸)。隨著軟硬體技術的發展,平均計算成本比之前降低了很多,為符號執行的發展和推廣提供了有利的客觀條件。目前符號執行技術已應用在許多公司的產品測試當中,如 HP、微軟等公司都已經有 10 年以上的符號執行探索經驗。當前基於 KLEE 的二次開發工具已經大量應用在軟體可靠性測試中,如 Mayhem 已發現了 DebianOS 的上千個 crash 問題,以及 Linux 和 Windows 系統的幾十個可利用漏洞。
精準測試
在當前敏捷測試的時代,版本釋出日趨頻繁,快速釋出高質量的軟體是很多企業的目標。對於急於釋出的軟體版本,全量執行所有的用例往往需要花費較長的時間,已經不能滿足產品釋出的節奏。如何避免過度測試並在時間、質量、成本中找到最佳的平衡?
精準測試可讓軟體測試過程可量化衡量、可追溯,清楚的展示出測試用例執行的路徑,並可以實現測試用例與程式碼的雙向追蹤。對於程式碼量較大的系統的軟體,通過精準測試可以獲取到曾經執行過某段程式碼的測試用例,當這部分程式碼進行修改後,只需執行對應的用例即可,大大縮短了測試的時間,加快了產品上線速度。因此精準測試成為了近期軟體測試技術的新方向之一。精準測試的實施對測試人員的程式碼開發、測試設計、需求理解、架構理解、自動化測試能力均有較高的要求。
雲測試
雲端計算是一種按需提供計算資源的技術,它可以減少使用者基礎設施投入並降低管理成本。然而,雲平臺在近年來不斷出現大面積當機的情況,這為雲端計算測試技術提出了新的挑戰。需要測試人員深入理解雲平臺底層、中間層和上層技術,構建符合雲平臺質量要求的測試工程能力和質量保障方案。
很多測試服務提供商已經將測試服務部署到雲上,這種方式有很多的優勢。首先,它可以按需提供服務,使用者可以根據需求靈活的佔用雲端資源,避免了傳統測試中的資源浪費。例如手機應用提供商可以把應用程式通過雲平臺進行主流手機的相容性測試,而不必直接購買各品牌的手機。其次,雲平臺可以提供較為全面的測試環境和測試工具,免去了部署環境和工具的時間,使測試工程師可以將更多的精力投入到業務中。再次,當雲平臺和容器技術結合起來時,可以快速構建可擴充套件可伸縮的測試環境,並行執行測試用例,從而減少測試執行時間。
物聯網測試
IoT 是一個包含大量網路裝置、感測器和計算基礎設施的龐大系統。IoT 的應用覆蓋了軍事、家庭、醫療、零售等多個領域。其使用場景複雜,解決方案多元化,使得 IoT 裝置以及解決方案的測試面臨很大的挑戰。下面筆者提出了一些觀點和思路供大家參考。
模擬
基於效率和成本的考慮,測試人員無法針對所有的 IoT 裝置、連線協議以及服務節點進行全面覆蓋。依靠 IoT 場景模擬能力,測試人員可以在少量可用的物理裝置上建立各類虛擬裝置並建立不同協議的虛擬連線,從而模擬出真實應用場景,達到全面測試覆蓋的目的。不僅能夠節約時間和成本,還具有更好的靈活性和擴充套件性。
安全
當前 IoT 發展的重點是技術的創新、推廣和應用,安全問題沒有受到足夠的重視。相對傳統移動網際網路,IoT 的規模、應用和服務都更加龐大複雜,安全問題無疑具有極大的挑戰性。
自動化
在 IoT 領域,目前自動化測試工具和系統的發展還處於比較初級的階段。在測試執行、場景構建、效能度量及狀態監控等各個方面都需要有強有力的工具、框架和規範的出現,來支撐複雜的 IoT 自動化測試。
開源測試
開源軟體本著“不要重複造輪子”的原則,與商業軟體相比,擁有使用成本低、可定製性高等特點。目前開源測試工具種類繁多,涵蓋測試管理、缺陷管理、持續整合、功能測試、效能測試、測試框架、測試設計、安全測試等類別。下面列舉了這些分類中一些典型的測試工具。而針對我們自身的業務需求,可以通過修改原始碼來適配自己的業務,從而實現工具定製化。
-
測試管理: TestLink、Testopia
-
缺陷管理:Redmine、Bugzilla、Mantis
-
持續整合:Jenkins、Buildbot
-
功能測試:Selenium、LTP
-
效能測試:lmbench、Sysbench、Iperf、Fio
-
測試框架:JUnit、Autotest
-
測試設計:Xmind、StarUML、UML Designer
-
安全測試:Metasploit、Nessus、AppScan
為了減少研發成本,很多公司都制定了基於開源軟體進行二次開發的策略。在重點測試自研特性的同時,面對大量的開原始碼,測試工程師需要與開源社群互動,及時將發現的問題提交給社群並同步社群的問題單和 cve 補丁。
然而,當前很多開源社群中的測試並不到位,很多特性在釋出之後長時間沒有對應的文件和測試用例。以 kernel 社群的 user namespace 核心特性為例,其是在 2013 年 2 月 18 日隨核心 3.8 版本正式釋出的,然而直到 2015 年 5 月 21 日,社群才擁有第一個該特性的測試用例。二者時間間隔在兩年以上,版本的質量保證令人堪憂。對於這部分特性,需要測試工程師根據業務需要自行補充測試。測試工程師同時還要注意構建社群影響力,以保證與自己平臺相關的測試用例能夠順利的被社群接收,從而減少測試程式碼維護成本。感興趣的讀者可以閱讀 《讓我們成為開源軟體測試者》。
容器化 /Devops/ 微服務
容器為開發、測試、運維三個團隊提供一致的環境,避免因為環境不統一產生的缺陷誤報。同時使開發人員可以很容易的通過容器映象復現測試人員和客戶報來的缺陷。利用容器還可以避免環境汙染和批量快速的啟動多個測試環境並行測試來提高測試效率。微服務將軟體細分為多個子模組,各模組間相對獨立,便於測試進行遷移以便及早的發現缺陷。Devops 通過成熟的自動化解決方案,同時配合容器、微服務技術,打通了開發、測試、運維團隊的壁壘。隨著容器、微服務時代的到來,配置基於 CI/CD 的 Devops 流程成為了測試人員必備的技能。感興趣的讀者可以閱讀 《Docker 引領測試革新》。
敏捷測試
傳統的軟體測試方法將開發和測試視作兩個團隊的兩種不同的工作模式,團隊之間溝通比較有限,團隊壁壘較為明顯。在這種開發模式下,軟體缺陷通常在專案後期才逐步被發現。近年來,在客戶需求頻繁變化、高強度的外部競爭壓力和軟體交付迭代頻繁的大環境下,傳統的軟體測試方式已經不能滿足需求。
敏捷測試強調從客戶的角度進行測試,重點關注持續迭代地測試新開發的功能,而不再強調傳統測試過程中嚴格的測試階段,同時提倡儘早開始測試。它強調開發和測試團隊在合作、透明、靈活的環境下協同工作,以測試前移、持續整合、自動化等方式為優化手段,可以很好的適應快速、需求變更頻繁的軟體交付。
目前敏捷測試已經受到了行業內的認可,相信會有更多的公司將會進行敏捷轉型,敏捷教練的薪水也會水漲船高。
大資料測試
當前全球資訊資料量增長迅猛,據市場調查機構 IDC 預測,到 2020 年,全球資料總量將達到 40ZB,相當於每人擁有一千張 DVD 光碟以上的資訊量。如此大量的資料為測試資料的備份和管理帶來了挑戰,測試人員需要確認資料完整性,保證資料質量。面對大量而動態變化的資料和有限的測試時間,需要制定出行之有效的測試策略,開發出適用的測試工具,並完善自動化測試。
隨著大資料應用的快速增長,我們需要更快速的完成資料處理。大資料探勘的目的是找出資料與資料的關聯關係,與傳統軟體相比,很多大資料場景中的輸出是無法直接確定的,同時資料又具有多樣性,需要測試人員具備更多的發散思維;面對爆炸式的資料服務,測試時需要搭建可擴充套件伸縮的測試平臺模擬大量的測試客戶端。而面對大資料中很多場景下程式輸出的不確定性、大資料結構多樣化、定位資料因果關係困難等問題為測試工程師帶來了新的挑戰。
自動化測試
傳統的自動化測試需要測試工程師直接編寫測試程式,而這樣的程式往往可維護性不強,當開發程式碼變更時往往需要重新適配自動化測試程式。測試驅動開發是軟體工程中的一個里程碑,即開發在提交開發程式碼修改時同時要提交測試程式碼,但這種方式仍然需要較多的人力投入到測試程式碼的編寫中。而一些程式可以通過錄制或符號執行等方法自動生成自動化程式碼,免去了手工編寫的不便。另外通過埋點、mock 等技術還可以輔助自動化測試。隨著測試業務日趨多樣化,需要不斷開發新的自動化測試框架、測試平臺來滿足業務需求。當自動化測試與雲平臺相結合時,可以方便的進行任務遷移、回滾、故障自動修復等功能。
移動網際網路測試
隨著智慧移動裝置的普及,測試範疇也從智慧手機、智慧平板擴充套件延伸至包含了運動手環、車載聯網應用、共享單車、無人機等事物。移動平臺也呈現多樣化趨勢,而每個平臺的版本升級速度非常快。移動應用種類繁多,從社交到遊戲、教育、辦公、旅行、工具等類別。為滿足使用者需求,熱門應用的迭代更新非常頻繁。面對眾多的移動裝置硬體型號、多個終端平臺版本、繁多的移動應用、各應用的不同版本號,測試人員不得不制定新的測試策略和方案來應對業務。即使應用沒有新的特性引入,但自動化測試不得不根據新的平臺進行適配工作。而多種組合的測試為測試人員、測試工程能力、自動化測試提出了更高的要求。
目前已經出現了針對移動測試的自動化裝置和 SAAS 平臺。測試裝置可以模擬出使用者真實的終端操作的方式。在 SAAS 平臺中,使用者可以將應用提交到平臺中進行全量的自動化測試,來確保應用的多個版本可以適配到不同的平臺和硬體中。此外,領域中的專項測試,如效能測試、功耗測試、安全測試、相容性測試、跨地域跨時區測試、老化測試,也將產生很大的測試需求。
寫在最後
當前很多公司已經將基本的功能測試任務交由開發團隊負責,測試人員主要專注於自動化測試開發、安全測試、測試建模、精準測試、效能測試、可靠性測試等專項測試中。這部分測試任務能夠很好的體現測試人員的價值。雖然“測試已死”的爭論還在繼續,但只要把握好軟體測試發展的趨勢並憑藉自身的努力,相信測試人員是能夠在行業中受到認可的。
作者簡介
孫遠,華為中央軟體院資深工程師,個人網站:www.enjoytesting.cn
孟憲偉,華為中央軟體院資深工程師,碩士畢業,軟體行業 10 年以上從業經驗。目前從事華為雲端計算產品虛擬化平臺的測試以及相關測試工具的開發工作。加入華為前供職於 IBM,Thomson Reuters 以及 VMware 等多家公司,期間曾從事軟體開發,專案管理,軟體測試等各類工作。
文章來源:InfoQ
相關文章
- 測試已死?我看未必!分享我在華為做敏捷測試的那些流程……敏捷測試
- 甭做啦,軟體測試已死……
- 面試官:Java中緩衝流真的效能很好嗎?我看未必面試Java
- SQL已死? - thenewstackSQL
- 關於面試,我這樣看面試
- Spark已死?DBT會替代?Spark
- 我的測試啊
- JAVA死鎖排查-效能測試問題排查思路Java
- SQL 已死,但 SQL 將永存!SQL
- “A牌已死,霸業當立”
- 【轉】Lisp 已死,Lisp 萬歲!Lisp
- 我對測試的思考
- Hexo已經看膩了,來試試VuePress搭建個人部落格HexoVue
- ChatGpt的出現,前端真的已死?ChatGPT前端
- .NET已死,.NET萬歲 - Richard Reedy
- 我瞭解的測試工具
- 疫情已過,2023 我的前端面試記錄前端面試
- 036 Rust死靈書之Vec的完整程式碼測試Rust
- 看過無數Java GC文章,這5個問題你也未必知道!JavaGC
- 我看 KotlinKotlin
- 測試工程師看過來!面試,你真的會嗎?工程師面試
- 雲端計算崛起,大型機已死?
- 作業系統已死?容器勝出!作業系統
- 程式設計已死?資料勝出!程式設計
- iOS面試必看,我已經找到12k工作iOS面試
- 我的效能測試工作流程
- 那些虐死我的寬高
- FreeBSD 10.0 Beta 1已經可以下載測試
- 對照測試中 《生於憂患,死於安樂》,都有哪些機會值得我們 學習和借鑑?
- Android逆向之路—讓我們試試另一種方法看漫畫-(1)Android
- Android逆向之路---讓我們試試另一種方法看漫畫-(1)Android
- 簡單談一下我對持續測試下的測試左移、迭代測試和測試右移的理解吧
- 《鏡子》《過去已死》閱讀筆記筆記
- CentOS已死:RedHat稱Stream不是替代品CentOSRedhat
- UML已死?其實是敏捷惹的禍?敏捷
- 測試測試測試測試測試測試
- 我真的從測試轉成了開發......
- 我們應該測試 DAO 層嗎?