電信行業效能測試 需求分析

2021-10-18 04:01:37 字數 3940 閱讀 2211

為滿足瞬息萬變的資訊化時代需求,電信業務變化層出不窮,業務支撐系統每月一到兩次大版本更新,緊急版本更不在話下了。為保障系統的正常穩定,效能測試是版本上線前最後一道重要保障。作為開展效能測試的首要任務,需求分析階段決定了效能測試的目標是否正確、方法是否合理、度量是否得當。更確切地說,需求分析決定了測試是否能得出客戶所希望要的結果。

需求分析第一步:了解客戶的痛點、難點,以便對症下藥為客戶解決問題。但往往不是每個「病人」都能確切地說出病在**,需要細心聆聽、耐心溝通,逐步深入問題根源。對於電信這類業務繁多、關係複雜的系統,初入門的需求分析人員會經常遇到由於業務不精的問題,導致過於順從客戶,客戶怎麼說就怎麼執行,最後做得很苦很累,結果卻不能讓客戶滿意。

經歷了多個專案的實踐,與電信客戶交往密切後,總結經驗得出:在與客戶溝通前必須先在電信業務上下苦功,搞清楚業務需求、使用場景、操作步驟、業務系統關聯、業務執行路徑。多向客戶問為什麼,可以更深入地理解這些領域知識,站在客戶的視角去思考問題,更確切地理解客戶提出業務需求的原因。此外,與客戶打交道過程中發現:從客戶嘴中得到的需求,只是整個測試需求中的冰山一角,還有一些隱藏的需求需要我們自己去挖掘,例如:客戶嘴裡沒說出來的需求,客戶未曾想到過的需求。

對於客戶沒有說出來的需求,並不是客戶故意賣弄玄虛不願說出來,而是在客戶所在業務領域已經約定俗稱,就像人每天都必須吃飯、睡覺一樣,根本就不用說出來,行內都自覺遵循的業務規則。然而,作為剛剛步入該領域的需求人員,並不了解這些規則。如果採用被動的方式硬生生地記錄客戶提到的需求,這部分需求肯定會被忽略掉,這就是為什麼累死累活地得出測試結果後,仍然得不到客戶滿意的結果,並提出大量疑問的原因。遇到這類困境的正確做法應該是先向客戶了解清楚業務,摸清楚業務是什麼型別,業務規則都有哪些,日常使用者的操作習慣,高峰時段等。其中使用者群的操作習慣和體驗是最重要的,它體現了系統需要承載多少壓力,達到怎樣的響應速度。多問為什麼,因為客戶深受該問題困擾,收集整理客戶口中的「痛點」可以深入地理解問題產生的根源,從中學習相關領域知識,站在客戶的視角去思考問題,從而更準確地理解客戶為什麼要提出他們的那些業務需求。

另一種就是客戶從沒有想到過需求。這種沒有想到過的,實際是在業務需求階段還沒有呈現出來的問題,並不代表客戶不需要解決或不會出現。很多需求管理員經常抱怨客戶的想法一直在變,不斷增加新內容。而客戶並非專業的測試人員,當新問題被發現,或問題被修復後都需要重新作評估,驗證問題產生的原因或修復後的效果。這些都是客戶考慮需求前不可能**到的,當執行到這一階段,問題出現的時候,很多他們起初沒有想到的需求就會源源不斷地被提出來。但這時候,效能測試人員的工作量變得很大,被動接受所產生的需求分析工作對專案執行及後續工作埋下巨大風險。解決這類問題要求需求分析人員精通系統架構原理,並結合業務領域知識與需求的充分理解基礎上,通過分析提前發現這部分需求,制定測試模型、測試方法,最終形成需求的測試方案。通過從獲取、理解、分析、設計、成形的各個階段,得出高質量的需求分析,才能有效地引導整個測試執行過程,規避各種可能存在的專案風險。可以說,需要分析就是效能測試的藍圖,決定著測試的質量和成敗。

理解了客戶的真正想法、掌握真正需求後,需要結合測試思維、環境特性深入分析測試方法及度量指標,定立測試目標,並與客戶反覆確認。因為測試目標必須要各方都保持清晰一致,才能確保測試得到客戶認可的結果。

業務分析必須要建立在熟悉業務的基礎上,了解為什麼需要這個業務,這個業務是做什麼的,該業務的使用人群,影響物件等。這些業務背景往往很容易在繁重的測試任務中被忽略掉,必須要時時刻刻銘記這個關鍵步驟,否則得不償失。例如:有一次接到某個需求要對群組網新增黑白名單開頭,黑名單是針對訂購了某型別業務的使用者物件,限制他們的業務操作。因為未搞清楚這個黑白名單開頭的作用,直接執行了測試,得出開頭狀態下的結果都是一樣,被客戶痛批一頓。後來弄清楚是針對特定使用者群體這業務規則後,花了幾個通宵才把結果修正過來。這案例說明了測試技術再利害,在沒搞清楚業務的前提下是無法發揮出來。此外,熟悉業務、了解業務規則可以避免犯錯,還有利於提高工作效率。例如:每次效能測試都需要準備大量測試資料,了解業務規則可以很容易地找到捷徑獲取資料,或得出獲取資料的方式。有需要客戶出面協調的時候,清晰的業務邏輯表達也有利於提高客戶對你工作的認可,提高配合程度。

總之,測試是否得到客戶的認可,並不是取決於技術能力的高低,而是取決於測試工作是否從業務原理、客戶想法和需求出發。

在充分了解測試目的,完成需求分析後,需要選擇一種合適的測試方式。從壓力變化模型中可分為4種測試型別:

●效能測試。在a點與b點之間的系統效能,驗證系統在資源可用範圍內,是否能達到效能預期的目標。

●負載測試。b點的系統效能,驗證在一定的壓力下持續一段時間,直到系統的某項或多項指標達到極限。

●壓力測試。b點到d點的系統效能,驗證在超過安全負載的條件下,不斷對系統進行加壓,直到系統不能再接受請求。

●穩定性測試。a點到b點的系統效能,驗證系統在一定壓力下執行一段時間,以此檢測系統是否穩定。

效能測試通常使用先單業務場景測試、再執行綜合業務場景測試。

單業務場景主要用於測試該業務的基礎效能指標,作為同型別業務的橫向比較,或該業務的基線指標,做版本間的對比。單業務場景適用於效能測試、負載測試、壓力測試、穩定性測試;

混合業務場景用於模擬生產線上執行的業務壓力或使用者使用場景,測試系統的整體效能是否滿足實際效能需求。它是將經過一定規則篩選的效能測試點,按照合乎實際邏輯的虛擬使用者請求、併發,組合而成的業務場景。混合業務場景通常包含兩個或者兩個以上的指令碼組,執行時間較長。混合場景通常在穩定性測試、負載測試中使用。

●響應時間,是指操作該業務時的系統響應速度,直接影響使用者體驗。這個指標一般會有設計規範值,或使用者體驗的反饋值。

●業務處理速度,是指系統每秒能處理多少筆該型別的業務。由於每個地市的使用者數量都不一樣,所以數量級別有所區別,可通過以下公式計算:

●獲取地市該業務的高峰月工單問題,假設80%的工單在4小時的時間內處理完:

(當月前台業務工單總數×80%)/30天/(4×60×60)

例如:某地市前台**的開戶業務月工單總數2615537。

2615537×80%/30/(4×60×60)=4.84筆/秒

●併發數,廣義的併發數是指系統同一時間內處理的業務數量,狹義是指系統同一時間內處理的某一業務數量。通常會取後者作為單業務場景的併發數作參考指標。

●系統資源消耗指標:cpu、記憶體、磁碟io。在某些情況下,業務指標都讓客戶滿意,但資源消耗指標卻反映出可能有風險存在。例如:業務的處理速度、響應時間都達標的情況下,cpu的使用量達到90%以上。如果這種情況持續一段時間,或者使用者數量有所增加的情況下,伺服器有宕機、運算速度下降的風險。

客戶的想法通常是覆蓋面越廣越好,但理想與現實總是有差距,往往受限於留給測試的視窗時間有多少。在接收測試任務之前必須先建立准入標準原則,例如:完成測試環境的配置確認,約定其它開發、測試工作使用測試資源的時間段,每次接收的用例數、最後接收時間點等。只有把好准入規範才有可能保證測試的高質量。

在時間和覆蓋面之間衡量,除了要考慮完成質量,更重要是考慮風險和問題跟蹤機制。例如:某個業務模組的測試結果不達標,但該業務必須按時上線。這就存在乙個測試->調優->測試驗證的迴圈,雖然測試指令碼不需要重複修改,但需要考慮準備測試資料的工作量。修改次數、最後上線時間及測試結果都必須與客戶確認,提供風險判斷的資料支援,讓客戶對上線的風險有個清晰的認知,把風險產生的機率降到最低。

此外,如果有多個團隊參與或支援的時間,需要明確劃分好各團隊的職責分工,以便出現緊急情況時各施其職,齊心協力化解問題,而不是亂作一團。

經過溝通、分析和設計階段,得出的測試方案需要文件化知會各方,得到認可後才開展測試。

1、測試目標,說明測試的目的是什麼,或需要產生怎樣的效果;

1、測試背景,說明業務原理,產生背景,讓測試人員了解測試目的;

2、測試環境,描述測試環境架構,伺服器,施壓機配置情況,測試工具等;

3、測試場景,說明測試業務的側重點;

3.1測試用例,描述用例操作步驟,入參、出參,業務規則。

3.2測試指標,描述具體指標及閥值,以判斷測試是否通過;

4、團隊分工,描述各個參與團隊的工作範圍、內容;

5、執行時間,規定環境的執行測試時間段、釋放時間點等;

6、交付物,測試後的產出物(如:測試報告)。

效能測試需求分析

需求分析問題 1 剛開始最好不要上來就跟客戶談,某個效能點需要什麼樣的指標,比如支援多少人同時登陸,等等。一上來最主要的事情是了解整個系統的作用,使用者,部署的方式,約束,上線時間,等等,目的是讓自己能慢慢的站在客戶角度來看待這個系統,通過自己的知識,想客戶所想,憂客戶所憂,因為我們的目的就是要讓客...

效能測試需求分析

需求分析問題 1 剛開始最好不要上來就跟客戶談,某個效能點需要什麼樣的指標,比如支援多少人同時登陸,等等。一上來最主要的事情是了解整個系統的作用,使用者,部署的方式,約束,上線時間,等等,目的是讓自己能慢慢的站在客戶角度來看待這個系統,通過自己的知識,想客戶所想,憂客戶所憂,因為我們的目的就是要讓客...

效能測試需求分析

原文 效能測試需求分析與傳統的功能測試需求有所不同,功能測試需求分析重點在於從使用者層面分析被測物件的功能性 易用性等質量特性,效能測試則需要從終端使用者應用 系統架構設計 硬體配置等多個緯度分析系統可能存在效能瓶頸的業務。效能測試必要性評估 任何專案在開展效能測試活動前都需要進行必要性評估。通過必...