專訪|HPE測試中心總監徐盛:測試新思維-DevOps,持續測試,更敏捷,更快速
2016年7月22日,「HPE&msup軟體技術開放日」將在上海浦東新區,張江高科技園區納賢路799號科榮大廈小樓2樓舉辦,msup攜手HPE揭祕全球測試中心背後的12條技術實踐。
徐盛:HPE測試中心總監。徐盛將在本次開放日帶來《軟體測試新趨勢》的分享,在開放日舉辦之前,主辦方特別對徐盛進行了採訪,提前劇透在軟體測試新趨勢下HPE如何進行測試和質量管理。
msup:移動互聯的到來給測試帶來了哪些挑戰?
徐盛:開發移動應用確實給我們的開發和測試人員都帶來了新的挑戰。我們大致總結了3個方向的挑戰:
1、理念 我們傳統軟體的測試更多的是使用固定的測試人員,一般很少引入專案之外的人員來做測試;對於移動應用,由於裝置的繁雜性和應用場景的複雜性,移動專案開始越來越多的引入外部測試人員,外包測試工作,甚至是使用眾測的方式來提高測試的覆蓋率。
同時,在傳統軟體的測試中,我們主要關注在軟體的功能上,功能性測試上面花費的時間是最多的。而對於移動應用,由於應用場景的不同,測試人員開始把目光投向了以往不是太受重視的非功能測試方面。特別是效能,易用性和安全性的測試。
2、速度 移動互聯的一個特徵就是快速,不僅包括我們裝置硬體的升級速度,還包括我們應用軟體的更新速度。我們現在看一些熱門的移動應用,他們的更新速度是以天計算的。
這樣高的更新頻率,對我們的開發和測試都提出了新的要求。我們測試人員在節奏如此快的專案裡,需要轉變傳統的測試方法,採用週期更短的測試策略。
我們倡導在移動應用專案裡實施DevOps,通過DevOps所推崇的持續部署的流程,應用 Shift Left(儘早地測試)、automate everything(自動化測試,自動化構建,自動化部署),continuous testing(持續釋出新版本到QA環境,無等待的持續測試)等方法,使測試更敏捷,更快速,來保障應用的快速上線,為公司佔得先機。
3、工具 移動裝置種類繁多(各種螢幕解析度,各種ROM定製),最主流的作業系統至少就有2個 - 安卓,iOS,每個作業系統都有眾多的版本並頻繁更新,移動應用開發技術的多樣性(原生,混合,HTML5,網頁),等等這些使得手工測試再也無法保證裝置和功能的高覆蓋。不同於以往,自動化成了移動應用測試的必需品。桌面系統發展已經很多年了,它的測試工具非常的成熟好用,像HP UFT, Selenium等等。相比之下,移動應用的測試工具才剛剛起步,對軟體硬體的支援都有待提高。
選擇一個適合的測試工具對於我們測試的速度和質量都是至關重要。我們認為一個合格的移動應用測試工具需要支援以下幾點:
相容主流的裝置,作業系統和開發技術 同時支援手工和自動化測試 基於屬性的物件識別方法 支援指令碼的錄製回放 帶有裝置管理功能,支援裝置的遠端訪問 能和持續整合系統對接 能模擬行動網路環境 選好工具,用好工具才能使我們的測試如魚得水,快速高效。
msup:大資料技術在質量領域會帶來哪些新的變化?
徐盛:傳統的質量管理一般是以定性分析和質量管理人員的主觀判斷為主,雖然也會在很大程度上依賴於量化管理指標對組織和個人進行量化管理和考核,但是這些指標大多是離散的、不相關的,這就導致了傳統質量管理的決策在很多情況下是片面的,而滯後的分析報表為決策層帶來的資訊通常都是“馬後炮”,無法為組織建立起有一定預防能力的質量管理體系。
而大資料技術的發展為質量領域帶來資料化管理的革新,使企業可以充分利用在長期的企業質量管理中積累下的歷史資料,以及在當前的質量管理活動中實時產生的各項資料,如人員、計劃、需求、用例、缺陷等,以全量資料分析替代片面資料計算,以實時資料展現補充滯後報表分析,以多維度資料融合提高度量指標價值,幫助企業進行基於資料的客觀化質量管理。
而作為大資料技術的核心,數學建模和分析預測可以使質量管理在實時分析的基礎上更進一步,為企業建立缺陷預測和風險預防的能力,真正使企業在質量管理中做到防患於未然,節省質量問題所帶來的成本和損失,在此之上更是可以建立起計算機的輔助決策能力,為決策者提供基於資料的客觀依據,減少主觀情感和判斷在決策中的不利影響。
資料視覺化在大資料技術的推動下從傳統的直方圖、趨勢圖、餅圖等維度單一的展現方式進化為動態的、互動的、多維的視覺化展現方式,以幫助使用者快速直接地從海量資料中定位到所需的資訊,在質量領域,力導向圖、弦圖、桑基圖等都有很好的應用場景。
msup:如何提升全員的質量意識?
徐盛:提高全員的質量意識非一日之功,我們覺得需要自上而下的在組織內建立全員質量管理的文化,並落地實施,持續改進。
具體實踐如下: 1、定義組織的質量方針和質量策略來指導整個質量管理; 2、加強和各層級員工的溝通; 3、定義質量屬性度量的效能指標(包括績效;指標),並據此建立在專案管理中反應該系列指標的專案對應指標 4、建立質量管理系統,在專案團隊中建立產品意識,質量意識,實施質量管理並持續改進; 5、把質量相關的績效指標整合進入個人績效指標; 6、重複以上步驟並持續改進。
msup:測試管理的難點在哪幾個方面?
徐盛:測試管理在專案級別和組織級別各有不同的難點。 專案級: 測試估算 測試風險的管理 測試和開發的高效整合 測試流程改進(TPI)
組織級: 測試人員績效的考核及其真實性和有效性 測試價值的量化和顯性化 有限的測試投資組合,質量價值最大化 測試中心的透明性,高層人員對全部測試專案狀況的及時瞭解 測試中心的知識管理 測試中心技術路線制定和技術儲備 測試管理體系和度量系統 測試組織成熟度評估(TMMi)
msup:企業級軟體測試和網際網路測試的不同有哪些?
徐盛:首先,企業級軟體,特別是大型企業的業務邏輯本身十分複雜,造成了軟體系統特別複雜,比如惠普就有2000多個相互連線的內部IT系統,每一個流程域都有幾十個上下游程式,程式之間互相連線加護,合作完成某一個業務流程。因此測試人員需要對業務系統本身和上下游系統的資料及協調要求有深刻的理解。網際網路企業的業務邏輯往往是To C的,因此相對已經做過了簡化,對邏輯本身的功能測試其實相對簡化,但是對易用性,效能包括安全性測試的要求會更加看重。
其次,企業級軟體往往有系統的歷史比較悠久,採購或開發採用的架構和技術五花八門,從集中式,到B/S到C/S到SaaS到APP都有;而且因為企業軟體往往是完成一個功能,軟體是用什麼技術開發的是第二位的,因此企業的軟體生態系統的技術比較複雜。因此對於測試軟體,特別是功能自動化測試軟體需要考慮滿足各種型別和技術的產品的自動化要求。而對於網際網路企業,網站本身就是企業的核心競爭力,需要精益求精,而且因為沒有歷史包袱,技術一致性比較好,加上功能測試相對簡單,測試人員和開發人員又相互交叉,因此選擇的自動化測試框架多是開源的框架。
再次,企業級軟體系統由於比較複雜,往往是網狀的拓撲結構,系統之間相互勾連,牽一髮而動全身。因此測試時測試環境和資料的準備就需要花大量的時間,保證測試環境的互聯互通和資料一致性就需要花大量的時間。網際網路企業往往是以一個核心繫統為主的星狀甚至是點狀結構,因此測試環境的準備相對依賴性比較小,甚至可以利用雲和虛擬化的技術實時生成測試環境載入測試資料進行測試。
最後,企業級軟體的大部分需求比較清楚,加上本身系統和邏輯的複雜性,專案開發選用V模型比較多,工作方式是先計劃再幹。測試計劃上特別需要考慮上下游系統在計劃上的配合。而網際網路企業由於需求主要由產品經理估計,因此不確定性更大,加上環境變化快,需要更新更加頻繁,因此開發方式更多采用敏捷的方式,邊幹邊看邊改。測試的工作方式要符合整個專案的工作方式的選擇。
沒有誰對誰錯,誰先進誰落後,其實根據企業的自身情況選用合適的測試方法才是正確的答案。兩邊也會相互融合借鑑。比如傳統企業也有手機APP應用,那其開發和測試方式就和網際網路企業接近。反之,網際網路企業,特別是大的網際網路企業,隨著系統的不斷髮展和複雜,也會面臨傳統企業現在面對的複雜邏輯和網狀系統的功能測試的複雜性問題。
msup:現在測試的崗位在矽谷已經逐漸消失了,但是測試的工作還在一直繼續,這種趨勢會帶來哪些影響,現在的測試人員應該如何應對這種變化?
徐盛:所謂的矽谷沒有測試職位的話是不準確的。首先矽谷本身的大型網際網路企業和傳統IT企業依然還有保留有軟體測試的職位。只不過因為矽谷的高成本,各大跨國企業會把新增的純黑盒功能型測試等相對低價值的職位外包到印度等低成本的地點,這個是可以理解的。而且,由於DevOps,測試和開發的融合,有些測試職位是以開發的形式在招聘。另外在很多其他專門測試職位,比如測試經理安全性測試,依然存在。舉個例子,在SimplyHired網站上在San Jose就有1400多個QA測試相關的職位(2016年7月18號搜尋)。 <img src="/download/01uizxzTY0rJ" alt="enter image description here" /> 另外任何IT人士,包括測試人員都需要不斷提高自身的能力和價值。我們也總結出了測試人員發展的所謂“火山口模型”。在會上可以跟大家詳細的分享。
msup:測試用例的設計需要一定的測試方法和思維,這方面的能力應該如何培養?
徐盛:如何培養設計測試用例的測試方法和思維有如下建議: 1、系統學習軟體測試用例設計方法,可以參考業界的標準,如ISTQB; 2、結合測試團隊和被測系統實際情況,建立組織內的測試設計最佳實踐; 3、更多的站在使用者角度來考慮被測系統,持續提高使用者體驗; 4、積極參加各種測試沙龍,測試峰會等測試交流活動,持續學習和改進。
相關文章
- 聊聊持續測試
- 在持續測試中使用哪種測試?談談DevOps在測試策略中的實踐!dev
- 開放出版:徐毅《大測大悟:測試的敏捷之道》敏捷
- 讓測試更方便系列:快速建立資料
- 測試筆試邏輯思維題筆試
- 敏捷測試VS傳統測試對比,6招玩轉敏捷測試!敏捷測試
- 測試測試測試測試測試測試
- 聊聊持續測試與安全
- .net持續整合測試篇之Nunit引數化測試
- .netcore持續整合測試篇之測試方法改造NetCore
- 【自動化測試入門】自動化測試思維
- 從傳統測試轉向敏捷測試敏捷測試
- SoapUI實踐:自動化測試、壓力測試、持續整合UI
- 簡單談一下我對持續測試下的測試左移、迭代測試和測試右移的理解吧
- Laravel 持續測試主控平臺Laravel
- 持續測試企業架構架構
- 聊聊持續測試的進階
- 探索式測試的思維模型模型
- 學習日誌-----測試思維
- 敏捷宣言 + 測試管理敏捷
- Linux 核心的持續整合測試Linux
- 持續整合之路——資料訪問層的單元測試(續)
- 初識效能測試(測試小白麵試總結)
- 介面效能測試 —— Jmeter併發與持續性壓測JMeter
- 持續測試跟自動化測試的這些區別你知道嗎?
- 當程式碼變更遇上精準測試的總結
- 效能測試總結(二)---測試流程篇
- 敏捷開發與測試敏捷
- 敏捷測試是什麼?敏捷測試
- 向敏捷測試轉變敏捷測試
- 破解敏捷測試的迷思敏捷測試
- 使用如今更智慧的光纖測試工具執行專家級光纖測試和認證
- 軟體測評中心▏效能測試、壓力測試、負載測試有什麼區別?負載
- 使用 Xcode Server 持續整合 & 打包測試XCodeServer
- WLK 1.6中的Windows Touch測試變更Windows
- 測試總結①
- 專案管理大法歸檔-思維導圖、原型工具、介面測試、設計模式、版本管理、單元測試、持續整合、程式碼審查、Bug跟蹤專案管理原型設計模式
- App測試、Web測試和介面測試一般測試流程APPWeb