第一篇:銀行性能測試項目小結(jié)
1、背景
本次性能測試的系統(tǒng)是X銀行營銷服務(wù)系統(tǒng)總行版,該系統(tǒng)使用的數(shù)據(jù)庫服務(wù)器、應(yīng)用服務(wù)器均布署在總行機房,各地分行通過 WEB 方式登錄訪問本系統(tǒng)。系統(tǒng)上線后的總用戶數(shù)(包括各分行、支行主管,客戶經(jīng)理等)在 5000 左右。
該系統(tǒng)采用 DB2 數(shù)據(jù)庫、WebLogic 應(yīng)用服務(wù)器。
本次性能測試進入的條件是系統(tǒng)的代碼已經(jīng)基本完成并經(jīng)過功能測試。
2、測試計劃
在確定了本次性能測試的要點后,我們初步擬定一份性能測試計劃,提交給客戶,并獲得了客戶的認可。在本文中不列出項目測試計劃中的所有內(nèi)容,僅就主要問題進行說明。
測試范圍:在真實業(yè)務(wù)局域網(wǎng)測試環(huán)境下,對系統(tǒng)實施并發(fā)性能測試的同時,監(jiān)控 Web 服務(wù)器和數(shù)據(jù)庫服務(wù)器的系統(tǒng)資源,以及數(shù)據(jù)庫資源的使用情況。
測試內(nèi)容:并發(fā)性能測試、系統(tǒng)資源監(jiān)控。
測試方法與工具:采用自動測試與人工測試相結(jié)合的測試方法,測試工具使用 LoadRunner。
測試資源:測試環(huán)境及測試數(shù)據(jù)準備。
3、測試用例
確定了測試計劃,我們針對該系統(tǒng)的特點,從中挑選出三個有代表性的功能點,作為本次性能測試的用例。我們認為作為銀行的營銷服務(wù)系統(tǒng),最常使用且對于系統(tǒng)的整體性能有著較大影響的是“客戶信息查詢”和“客戶對賬單查詢”兩個模塊。因此,我們設(shè)計了三個單交易性能測試用例,分別是:“用戶簽到 / 簽退”、“客戶信息查詢”、“客戶對賬單查詢”。然而客戶卻對此提出異議,他們認為我們設(shè)計的測試用例數(shù)量太少,要求我們的測試用例應(yīng)包含更多的功能模塊。經(jīng)過會議討論,最終我們根據(jù)客戶給出的一份性能測試大綱,針對其中提出的測試內(nèi)容、測試策略,以及測試目標(biāo),將單交易測試用例增加到十四個。
測試用例采用以下格式:
要求清晰地描述出詳細的操作步驟。
4、測試數(shù)據(jù)
針對以上設(shè)計的測試用例,需要準備大量的業(yè)務(wù)數(shù)據(jù)。本次性能測試的環(huán)境即系統(tǒng)上線后真實運行的環(huán)境,所有的業(yè)務(wù)數(shù)據(jù)均來自興業(yè)銀行的真實核心系統(tǒng)(通過 ETL 轉(zhuǎn)換),數(shù)據(jù)量已經(jīng)能滿足測試的需要。
由于測試用例中要求執(zhí)行并發(fā)操作的時候使用不同身份的用戶登錄系統(tǒng),因此在測試開始前需要準備一批具有不同身份的用戶名(包括各分支行的主管以及客戶經(jīng)理),并且要有相應(yīng)的操作權(quán)限。
對于“積分轉(zhuǎn)移”、“積分兌換”、“禮品兌換”等等交易,則需要提供一批卡上有足夠積分的客戶理財卡號。
以上測試數(shù)據(jù)由興業(yè)銀行負責(zé)提供,在性能測試執(zhí)行之前提供給我們。
5、測試腳本
使用性能測試工具 LoadRunner 錄制并調(diào)試測試腳本,對相關(guān)的輸入項進行參數(shù)化。
6、測試實施
在 LoadRunner 中執(zhí)行測試腳本,實施性能測試。對于每個單交易測試腳本各執(zhí)行一輪測試,并按一定的用戶比例設(shè)計出一個混合交易場景,令其自動持續(xù)運行五小時左右,觀察系統(tǒng)的性能表現(xiàn)。每次執(zhí)行的結(jié)果文件均保存下來,待測試完成后連同性能測試報告一并交付客戶確認。在此過程中,需要監(jiān)視相關(guān)的系統(tǒng)資源使用情況,包括:應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器的所有系統(tǒng)資源指標(biāo),所有數(shù)據(jù)庫資源指標(biāo)。
7、測試結(jié)果
經(jīng)過本次性能測試,發(fā)現(xiàn)了系統(tǒng)五個主要的性能問題。我們與程序開發(fā)人員一同分析問題產(chǎn)生的原因,并給出改進建議,一起記錄到測試報告中。其中的一個問題在性能測試報告提交客戶之前已經(jīng)過優(yōu)化,得到顯著改進。
8、測試結(jié)論
測試結(jié)果顯示,系統(tǒng)性能能滿足測試目標(biāo),交易并發(fā)數(shù)達到或超過30個,批量交易(查詢記錄50條以上的交易)并發(fā)數(shù)也能達到或超過10個,交易平均響應(yīng)時間在2-12秒內(nèi),90%平均響應(yīng)時間在2-15秒間完成。
混合交易案例持續(xù)運行 5 小時,運行結(jié)果正常,系統(tǒng)沒有報任何錯誤,系統(tǒng)穩(wěn)定,可用率應(yīng)達到100%。
另外如在ETL批處理期間運行 營銷服務(wù)系統(tǒng),系統(tǒng)性能明顯下降,建議ETL批處理在夜間處理,避免影響 系統(tǒng)的正常運行。
9、經(jīng)驗
在本次性能測試的過程中,我們遇到一些問題,通過解決這些問題,從中獲得了一些經(jīng)驗。現(xiàn)總結(jié)如下:
問題一
在我們對系統(tǒng)進行測試的過程中,某些操作是相關(guān)聯(lián)的。例如我們測試“查看客戶資產(chǎn)歷史” 這個交易的系統(tǒng)響應(yīng)時間,這時需要先列出客戶的基本信息,選中一個客戶,點擊打開另一個頁面,才能查看到該客戶的資產(chǎn)歷史信息,同時,在測試腳本中需要對所選擇的客戶編號做一個參數(shù)化,但由于 LoadRunner 不提供像 WinRunner 或 QTP 一樣識別頁面對象的功能,如果在 Vugen 中直接抓取頁面上顯示的客戶編號去參數(shù)化,實現(xiàn)起來將十分煩瑣。考慮到在以上那兩步操作中,第一步“列出客戶基本信息”只是輔助的操作,而第二步操作“查看客戶資產(chǎn)歷史”才是我們要測試的功能點,因此我們忽略了這二者之間的關(guān)聯(lián)性,僅對第二步操作中的客戶編號進行參數(shù)化。(只要服務(wù)器端對此不加驗證,甚至我們將第一步操作都忽略掉,也是可行的)。
結(jié)論: LoadRunner 的工作原理是根據(jù)所選擇的協(xié)議組裝成相應(yīng)的報文在前后臺之間通訊,以此達到模擬實際操作的目的,因此我們只需將要測試的交易或功能點所需要組裝的報文傳送給后臺服務(wù)器即可(因為我們關(guān)注的只是系統(tǒng)的性能,不是功能),而不必像功能測試那樣,按部就班地重現(xiàn)每一步操作。
問題二
在測試過程中,我們發(fā)現(xiàn)有一個查詢交易的系統(tǒng)響應(yīng)速度特別慢,無論是在 Controller 中使用單個虛擬用戶執(zhí)行腳本,還是在 Vuser 中直接運行,情況均是如此,然而當(dāng)我們用手工進行同樣操作的時候,響應(yīng)時間卻明顯地小于工具統(tǒng)計出來的時間,也就是說,在 LoadRunner 中模擬操作的結(jié)果與真實操作的結(jié)果明顯不一致。經(jīng)過反復(fù)嘗試與觀察,我們才終于找到問題的原因所在:該查詢交易是通過客戶的證件號碼查詢客戶信息,當(dāng)用戶輸入客戶的證件號碼時,如果沒
有選擇證件類型,系統(tǒng)會自動將證件類型設(shè)置為默認值“身份證”。按“證件類型 + 證件號碼”為組合索引查詢客戶信息表,查詢速度極快,而在我們錄制腳本時,忽視了“證件類型”這項輸入,只有“證件號碼”,因此查詢的效率大為降低。解決辦法:只需在測試腳本中,對 CertType(“證件類型”)一項賦值為“ A ”(“身份證”),此時在 LoadRunner 中重新運行該腳本,響應(yīng)速度提高,統(tǒng)計結(jié)果與實際完全一致!
結(jié)論: LoadRunner 的工作原理是根據(jù)所選擇的協(xié)議組裝成相應(yīng)的報文在前后臺之間通訊,以此達到模擬實際操作的目的,因此我們在測試腳本中組裝發(fā)送到服務(wù)器端的報文時,注意一定要和實際操作時的發(fā)送報文完全一致,這樣才能保證測試的結(jié)果與真實情況相吻合。這就要求在測試正式開始執(zhí)行時,要對測試腳本進行反復(fù)的調(diào)試,通常的做法是:在 Vugen 中執(zhí)行一遍腳本,統(tǒng)計執(zhí)行某個事務(wù)的時間,再用手工實際做一遍同樣的操作,大體上比較一下,確保與實際估算的時間沒有太大出入后,再逐漸增加并發(fā)用戶數(shù),正式開始性能測試。
問題三
在我們的每個測試腳本中的 init 部分,都錄制了登錄系統(tǒng)的操作,并且對登錄的用戶名進行了參數(shù)化,使用各種不同身份的用戶(分行主管、支行主管、客戶經(jīng)理等)進行相同的操作。在并發(fā)測試過程中發(fā)現(xiàn)對某些查詢交易測試的結(jié)果波動較大,系統(tǒng)響應(yīng)時間從零點幾秒到幾十秒不等。經(jīng)檢查后發(fā)現(xiàn)原因在于:使用不同身份的用戶登錄系統(tǒng)后,在輸入查詢條件后,點擊查詢按鈕后會將根據(jù)該用戶的身份,將其所屬的分行機構(gòu)號、支行機構(gòu)號、客戶經(jīng)理編號等一并提交,因此在腳本中,就必須根據(jù)不同的用戶身份,分別將其對應(yīng)的分支行機構(gòu)號等也運用參數(shù)提交,否則在執(zhí)行腳本時就會出現(xiàn)查詢不到記錄或查詢速度變慢等各種問題。解決方法有三個: 1、修改腳本,使其能夠依據(jù)用戶的身份分別傳送相應(yīng)參數(shù),2、針對不同類型的用戶使用不同的腳本分別測試。3、輸入?yún)?shù)使用統(tǒng)一的用戶類型。在實際中,我們?yōu)榱撕喕_本的復(fù)雜度,節(jié)省對腳本編程的時間,采取的是第三種方法。
結(jié)論:由于 LoadRunner 的工作原理是根據(jù)所選擇的協(xié)議組裝成相應(yīng)的報文在前后臺之間通訊,因此它會跳過在應(yīng)用程序前臺進行的校驗,所以在腳本回放的時候一定要注意在腳本中提前進行這些校驗或改由人工控制,以保證發(fā)送報文的正確性(如操作權(quán)限的控制等)。
問題四
測試多用戶并發(fā)登錄系統(tǒng)的時候,從虛擬用戶圖和事務(wù)圖上發(fā)現(xiàn),總有一部分用戶在登錄的時候要等待很長時間,用戶登錄的最小時間與最大時間相差非常大。于是我們在讓腳本自動運行的同時,手工再登錄一個用戶,發(fā)現(xiàn)無論如何都不會發(fā)生等待的情況,多次試驗的結(jié)果均是如此,也就是說 LoadRunner 測試的結(jié)果與實際結(jié)果再次發(fā)生了偏差!經(jīng)過反復(fù)的調(diào)試,以及與程序開發(fā)人員溝通,我們終于發(fā)現(xiàn)問題的原因所在:在用戶登錄系統(tǒng)的時候,系統(tǒng)會自動記錄登錄用戶的信息,并產(chǎn)生一個登錄 ID,以此 ID 做為主鍵,向數(shù)據(jù)庫插入記錄。因此當(dāng)大量用戶在極短的時間內(nèi)同時登錄時,就有可能出現(xiàn)生成相同的登錄 ID 的情況,此時便會造成數(shù)據(jù)庫中的主鍵沖突,導(dǎo)致用戶等待很長時間或登錄失敗。而我們手工測試時卻無法做到在很短的時間內(nèi)同時登錄,因此很難用手工重現(xiàn)此種
情況。通過 LoadRunner 的模擬表現(xiàn)出來的狀況,正是我們測試出程序存在的性能問題,并非與實際結(jié)果的偏差。
還有一個例子,在第二輪性能測試中,同樣發(fā)生了類似的情況。在本系統(tǒng)中,如果同一個用戶登錄后,未正常退出超過 5 次,系統(tǒng)將會把該用戶鎖住,使其無法再次登錄,而我們用于參數(shù)化的用戶名個數(shù)有限,因此當(dāng)腳本使用大量用戶同時登錄時,很容易造成同樣的用戶登錄系統(tǒng)而未簽退的情況發(fā)生(腳本正在執(zhí)行,還未能退出),此時將會造成許多用戶操作的失敗。
結(jié)論:使用 LoadRunner 可以模擬出大量用戶同時對系統(tǒng)操作的情況,而這些情況通過手工往往是很難重現(xiàn)出來的。例如大量用戶在同時對系統(tǒng)做某些操作時,很容易造成數(shù)據(jù)庫的死鎖、鎖等待、主鍵沖突、數(shù)據(jù)混亂等等問題,因此在做性能測試的同時,也常常可以連帶測試出系統(tǒng)的一些隱蔽的“缺陷”。在本次性能測試中,這種例子是很多的。對待此類“缺陷”,應(yīng)具體情況具體分析。有些確實是程序的 BUG,需要修正,而有些可能只是很極端的情況,只有在做壓力測試時才有可能發(fā)生,可不必深究。
問題五
此問題發(fā)生在第二輪測試(即回歸測試)中。在第一輪測試中發(fā)現(xiàn)的性能問題,經(jīng)程序員修正后,我們對系統(tǒng)進行了第二輪性能測試,以驗證其性能改進的效果。在前一輪測試中,我們發(fā)現(xiàn)通過選擇客戶級別為“未評級”時,查詢的速度極慢,經(jīng)過改進后,速度應(yīng)有較大提高。然而在回歸測試中,卻依然很慢。經(jīng)過對測試腳本和程序的仔細檢查,才發(fā)現(xiàn)原來在程序中已將“未評級”這個選項去除,而我們的測試腳本的參數(shù)文件中仍然保留有該選項,因此測試的結(jié)果與前次沒有區(qū)別。在參數(shù)文件中將該選項去掉后,測試結(jié)果正常,查詢效率有所提高。
結(jié)論:使用錄制好的測試腳本進行回歸測試之前,一定要先仔細檢查、了解程序的改動,對原先的測試腳本做必要的修改后,才可以重新測試,否則只是在做無用功。
10、教訓(xùn)
在本次測試過程中,由于經(jīng)驗不足,我們也得到了一些教訓(xùn)。前事不忘,后事之師,現(xiàn)總結(jié)出來與大家分享。
l 與客戶的溝通做得不夠,客戶要求我們做的性能測試用例數(shù)量太多,我們未能據(jù)理力爭,最后導(dǎo)致工作量過大。
l 按照原定的項目計劃,我們要在系統(tǒng)的功能測試即將結(jié)束前進駐項目組,準備并進行性能測試。然而由于客戶在功能測試的后期仍然不斷的提出新需求,導(dǎo)致開發(fā)人員疲于奔命,系統(tǒng)的性能難以穩(wěn)定下來,性能測試的前期準備工作也受到很大影響,不能正常開展,浪費了很多人力物力。
l 由于客戶無法提供一個單獨的性能測試環(huán)境,我們的性能測試工作與業(yè)務(wù)組的功能測試在同一個環(huán)境下進行,而系統(tǒng)的功能測試遲遲未能完成,加上 ETL(數(shù)據(jù)轉(zhuǎn)換)小組對數(shù)據(jù)庫資源的占用,因此我們的性能測試只能在夜間才能進行。導(dǎo)致時間上的浪費,使項目的成本增加。
l 沒有將性能測試中發(fā)現(xiàn)的缺陷記錄到缺陷管理工具中加以跟蹤,而僅僅體現(xiàn)在最后的測試報告上,個人認為這是比較不規(guī)范的做法。
l 性能測試前的數(shù)據(jù)準備不夠充分。客戶提供測試的系統(tǒng)用戶、身份數(shù)量有限,導(dǎo)致許多案例的測試只能使用少量數(shù)據(jù)進行參數(shù)化,由此帶來許多本可以避免的問題。
l 測試計劃及測試報告的書寫格式缺乏規(guī)范,尤其測試計劃書未能包含本應(yīng)包含的所有內(nèi)容。
l 在我們將 LoadRunner 的測試結(jié)果文件全部提交給客戶的前提下,客戶仍然要求我們在測試報告中將每一次測試的數(shù)據(jù)均以表格的形式填至測試報告中,此項工作的工作量十分巨大,個人認為這樣做并無必要。
以上是在本次性能測試及回歸測試過程中總結(jié)出來的一些經(jīng)驗教訓(xùn),在此做一個小小的總結(jié),以便下次工作中改進。
第二篇:噴漆性能測試
6.4 噴漆性能測試(樣品數(shù)量:每種顏色6套外殼)
試驗條件:物理測試需要在注塑完成,產(chǎn)品放置72小時以后進行,化學(xué)測試則需6天以后。噴涂干燥 硬化后應(yīng)在常溫下放置48小時以后再進行試驗。
試驗方法:
1)把濾紙放于酸性(PH=2.6)溶液中充分浸透;
2)用膠帶將浸有酸性溶液的濾紙分別粘在兩套噴涂樣品表面,確保濾紙與樣品噴漆 表面充分接觸,將樣品放入試驗箱。
3)測試時間以試驗箱達到所需溫濕度條件時開始計算。在24小時與48小時分別取 出一套樣品,揭下濾紙,并放置2小時后,檢查樣品表面噴涂。
檢驗標(biāo)準:樣品表面無變色、起氣泡、起皮、脫落、褪色以及其他與測試前狀態(tài)不一致的現(xiàn)象。
6.4.5 鏡面劃傷測試
測試環(huán)境:室溫(20~25° C);
測試目的:驗證鏡面耐硬物劃傷性能的可靠性
樣品數(shù)量:不少于2個
試驗方法:將實驗樣品固定在劃傷試驗機上,接觸部分為直徑為1mm的碳化鎢球,硬度為90.5~ 91.5,用載重(load)為500g的力在樣品表面往復(fù)劃傷50次,劃線速度為3~4cm/秒,接觸部分與被測面成90度角,對樣品的X和Y軸兩個軸向進行測試。每10次對鏡面進行外觀檢查,并對鏡面表面進行清潔。檢驗標(biāo)準:鏡面表面劃傷寬度應(yīng)不大于100μm(依靠目視分辨、參照缺陷限度樣板)
6.4.6 紫外線照射測試
測試環(huán)境:50° C
測試目的:驗證噴涂抗紫外線照射的可靠性
樣品數(shù)量:不少于1套殼體
試驗方法:在溫度為50° C,紫外線為340W/mm2的光線下直射油漆表面48小時。
試驗結(jié)束后 將手機外殼取出,在常溫下冷卻2小時后檢查噴漆表面。
檢驗標(biāo)準:印刷、電鍍無褪色、變色、紋路、開裂、剝落以及與測試前不一致的現(xiàn)象。
6.4.7鹽霧測試
測試環(huán)境:35° C
測試目的:測試樣機抗鹽霧腐蝕能力
試驗方法:a.溶液含量:5%的氯化鈉溶液b.將手機關(guān)機放在鹽霧試驗箱內(nèi),合上翻蓋,樣機用繩子懸掛起來,以免溶液噴灑 不均或有的表面噴不到。c.樣機需要立即被放入測試箱。實驗周期是48個小時。實驗過程中樣機不得被中途 取出,如果急需取出測試,要嚴格記錄測試時間,該實驗需向后延遲相同時間。d.取出樣機,放置48小時進行常溫干燥,對其進行外觀檢查。
檢驗標(biāo)準:外觀檢查無異常:表面噴涂、絲印、電鍍、裝飾件、標(biāo)牌等無脫落、起泡、腐蝕以及與測試前不一致的現(xiàn)象。
試驗環(huán)境:溫度20~25度,濕度65+/-20% 6.4.1 耐磨測試測試環(huán)境:室溫(20~25° C);測試目的:噴涂/印刷等抗摩擦性能的可靠性 樣品數(shù)量:不少于1套殼體
試驗方法:將最終噴涂的手機外殼固定在RCA試驗機上,用175g力隊同一點進行摩擦試驗。對于表面摩擦300cycles,側(cè)面和側(cè)棱摩擦150 Cycles。特殊形狀的手機摩擦點的確定由測試工程師和設(shè)計工程師共同確定
檢驗標(biāo)準:對于噴涂、電鍍、IMD等,涂層不能脫落,不可露出底材質(zhì)地;對于表面印刷類,印刷圖案、字體不能出現(xiàn)缺損、不清晰現(xiàn)象。
6.4.2 附著力測試
測試環(huán)境:室溫室溫(20~25° C);高低溫箱
測試目的:噴涂附著力測試
樣品數(shù)量:不少于1套殼體
試驗方法:選最終噴涂的手機外殼表面,使用百格刀刻出25個1mm2方格,劃線應(yīng)深及底材;使用毛刷將劃線處的噴漆粉屑清除干凈;再用3M610號膠帶紙完全粘貼在方格面,1分鐘后迅 速以90度的角度撕下膠帶,檢查被測區(qū)域表面。
檢驗標(biāo)準:有涂層脫落的方格數(shù)應(yīng)不大于總方格數(shù)的3%;單個方格涂層脫落面積不大于單個方格總面積的50%。
6.4.3 硬度測試
測試環(huán)境:室溫(20~25° C);
測試目的:表面噴涂硬度的可靠性
樣品數(shù)量:不少于1套殼體
試驗方法:將鉛筆芯削成圓柱形并在400目砂紙上磨平后,裝在鉛筆硬度測試儀上,以500g 的力度,鉛筆與水平面的夾角為45度,在樣品表面從不同方向劃出30~50mm長的線條3~5條。對于噴漆表面的硬度標(biāo)準為2H(三菱牌),500g的載荷;對于Lens表面的硬度標(biāo)準為3H(三菱牌),500g的載荷;每劃完一次都應(yīng)將鉛筆磨平。
檢驗標(biāo)準:用橡皮擦去鉛筆痕跡,目視噴漆、印刷、電鍍、Lens表面無劃痕。
6.4.4 汗液測試
測試環(huán)境:60° C,95%RH
測試目的:表面抗汗液腐蝕的能力
樣機數(shù)量:不少于2套
注:部品由于使用場所、材質(zhì)、色澤等有特殊要求時可以考慮采用其他標(biāo)準。
7.2 整機狀態(tài)下的可靠性試驗
溫度沖擊測試(Thermal shock)
測試環(huán)境:低溫箱:-40° C ;高溫箱:+80° C
試驗方法:將手機設(shè)置成關(guān)機狀態(tài)放置于高溫箱內(nèi)持續(xù)30分鐘后,在15秒內(nèi)迅速移入低溫箱并持續(xù)30分鐘,為一個循環(huán),共循環(huán)27次。實驗結(jié)束將樣機從溫度沖擊箱中取出,并在 室溫下恢復(fù)2小時,進行外觀、機械和電性能檢查。
試驗標(biāo)準:手機各項功能正常;外觀檢驗:殼體表面噴涂、絲印、電鍍無氣泡、褶皺、裂紋、起皮、脫落;裝飾件無翹起、脫落以及其他與測試前狀態(tài)不一致的現(xiàn)象。跌落試驗(Drop Test)測試條件:1.5m高度,20mm大理石板。
試驗方法:將手機處于開機狀態(tài),進行6個面的自由跌落實驗,每個面的跌落次數(shù)為1次,跌 落之后進行外觀、機械和電性能檢查。對于翻蓋手機,在跌翻蓋一面時,應(yīng)將一半樣品合上翻蓋跌,一半樣品打開翻蓋跌。
試驗標(biāo)準:手機各項功能正常;
外觀檢查:殼體表面無明顯掉漆,無裂紋、破損、沖擊痕以 及其他與測試前不一致的現(xiàn)象。振動試驗(Vibration test)
測試條件:振幅:0.38mm;振頻:10~30Hz;振幅:0.19mm;振頻:30~55Hz;
試驗方法:將手機開機放入振動箱。X、Y、Z三個軸向分別振動1個小時之后取出,然 后進行外觀、機械和電性能檢查。
試驗標(biāo)準:振動前5分鐘內(nèi)手機內(nèi)存和設(shè)置沒有丟失現(xiàn)象,后55分鐘可以出現(xiàn)關(guān)機現(xiàn)象,手機各項功能正常,尤其是顯示和SPL,外殼無嚴重損傷(如掉漆),內(nèi)部元件無脫落。
濕熱試驗(Humidity test)
測試環(huán)境:60oC,95%RH
試驗方法:將手機處于關(guān)機狀態(tài),放入溫度實驗箱內(nèi)的架子上,持續(xù)60個小時之后 取出,恢復(fù)2小時,然后進行外觀、機械和電性能檢查。
試驗標(biāo)準:手機各項功能正常;外觀檢查:外觀測試無異常(殼體、Lens表面無裂紋、氣泡;Lens 無被腐蝕現(xiàn)象;金屬、電鍍殼體或裝飾件無變色、腐蝕,以及無其他與測試前不一致的現(xiàn)象)。
高溫/低溫參數(shù)測試(Parametric Test)
測試環(huán)境:-10oC/55oC
試驗方法:將手機處于開機狀態(tài),放入溫度實驗箱內(nèi)的架子上。持續(xù)2個小時之后(與 環(huán)境溫度平衡),然后在此環(huán)境下進行電性能檢查,檢查項目見附表1。
試驗標(biāo)準:手機電性能指標(biāo)滿足要求,功能正常,表面噴涂、電鍍無裂紋等。高溫高濕參數(shù)測試(Parametric Test)
測試環(huán)境:+45oC,95%RH
試驗方法:將手機處于開機狀態(tài),放入溫度實驗箱內(nèi)的架子上。持續(xù)48個小時之 后,然后在此環(huán)境下進行電性能檢查。
試驗標(biāo)準:手機電性能指標(biāo)滿足要求,功能正常;結(jié)構(gòu)檢查:裝飾件、Logo及機殼 等無脫落,殼體卡鉤無脫出、斷裂,外殼無變形;
外觀檢查:殼體表面無明顯掉漆,無裂紋、破損、沖擊痕以及其他與測試前狀態(tài)不一致現(xiàn)象。高溫/低溫功能測試(Functional test)
測試環(huán)境:-40oC/+70oC
第三篇:性能測試工程師心得
高級性能測試工程師培訓(xùn)心得
--稅務(wù)事業(yè)部 魏琳
從中國的軟件現(xiàn)狀來看,各式各樣的軟件層出不窮,但是好的卻并不多,能夠走向國際的更是少之又少。中國的軟件要想與國際接軌,就必須要完善自己的軟件產(chǎn)業(yè),使軟件產(chǎn)業(yè)走向正規(guī)化、國際化,從而更加完善自己的軟件產(chǎn)品,這就使軟件測試工程師的人員缺口很大。很多人認為軟件測試無非就是找錯誤,挑程序員的毛病,僅此而已,其實不然,測試并不只是單純的挑刺,更多的意義是在輔助程序員,讓程序員的程序更加完美,讓公司的產(chǎn)品能夠更穩(wěn)固的占據(jù)市場,尤其是現(xiàn)在這個軟件行業(yè)競爭異常激烈的時代,只有公司的產(chǎn)品站住了腳,公司才會有更多的效益產(chǎn)生,只有公司有了效益,員工才會領(lǐng)到更多的工資,這樣公司才能長久的生存下去,而幫助產(chǎn)品能夠更堅牢的站住市場的,就是軟件測試人員。
這次有幸參加公司組織的為期五天的高級性能測試工程師的培訓(xùn),雖然課程緊密,內(nèi)容繁多,但是我卻樂在其中,受益匪淺。借此機會與大家分享一下我這幾天以來的學(xué)習(xí)心得:
首先,知識日新月異,不學(xué)則惘。在當(dāng)今這個信息高速傳遞的社會,不難感受到知識爆炸的巨大威力,特別對于我們IT行業(yè),更加深刻體會到什么叫做“日新月異”,更加深刻認識到,先進的知識與技術(shù)是一個企業(yè)立于不敗之地關(guān)鍵因素。但是對于已經(jīng)步入社會的我們,已經(jīng)遠離校園的我們,現(xiàn)在的學(xué)習(xí)缺乏系統(tǒng)性,往往不能自覺主動地抽出時間,靜下心來學(xué)習(xí),常常是需要什么,急用什么,才想起來學(xué)什么,遇到問題才翻理論、尋政策,臨時抱佛腳,學(xué)習(xí)缺乏“擠”勁和“鉆”勁,淺嘗輒止,通過這次培訓(xùn),使我在老師那里學(xué)到了當(dāng)今最流行的測試技術(shù)以及測試管理,當(dāng)然這只是其次,最重要的是在同行中營造了濃厚的學(xué)習(xí)氛圍,大家互相取長補短,分享工作中遇到的各種問題,與老師討論如何提升自己的價值。知識就是力量,知識就是本錢,我們應(yīng)該以這次培訓(xùn)為契機認真學(xué),努力學(xué)。
其次,責(zé)任重于泰山,無為則殆。做而不學(xué)等于蠻干,學(xué)而不做等于白學(xué)。我們學(xué)習(xí)的根本目的就是要用所學(xué)的知識來指導(dǎo)我們做事。通過這次學(xué)習(xí),我更清楚地感到自己肩上責(zé)任的重大,無論我們從事哪種行業(yè),無論我們身兼何職,責(zé)任心、使命感和進取心是我們一輩子不能舍棄的東西。通過這次學(xué)習(xí),使我感覺到學(xué)習(xí)的重要性和緊迫性,我們學(xué)習(xí)的自覺性、主動性、積極性得到了激發(fā),把所學(xué)的知識應(yīng)用到自己的崗位當(dāng)中,提升自己的價值,當(dāng)我們付出艱苦勞動得到的產(chǎn)品傳遞的客戶那里,獲得的是一份肯定,一份贊賞時,我們才可以如釋重負,我們的努力才沒有白費。
最后,學(xué)以致用,做好本職工作。通過五天的學(xué)習(xí),使我的理論水平、知識素養(yǎng)都有了很大的提高,但歸根到底還是要把工作做好。NO excuse!不為失敗找借口,要為成功找方法。我們在工作中要完成一項工作,往往會碰到這樣那樣的問題和困難,如何正確的對待這些問題和困難?沒有任何借口,只有千方百計地尋找解決問題、克服困難的辦法。
北京學(xué)習(xí)雖然短暫,但是我們從中獲得的東西卻是受益終生的!
第四篇:性能測試學(xué)習(xí)總結(jié)
性能測試學(xué)習(xí)總結(jié)
一、明確性能測試的范圍
例如:以iptv系統(tǒng)為例,是需要測試bss頁面、中間件具體接口、boss/crm具體接口
二、明確性能測試的指標(biāo) 例如:
1、支持最大并發(fā)用戶數(shù)是多少?(壓力測試)
2、每秒n個用戶并發(fā),能正常持續(xù)運行多久?(負載測試)
3、在系統(tǒng)用戶為n個的情況下,每秒x個用戶并發(fā),持續(xù)運行y分鐘,查看系統(tǒng)硬件io、cpu、內(nèi)存;查看軟件平均吞度量、tps、平均響應(yīng)時間、事務(wù)成功率、事務(wù)失敗率、錯誤率等(性能測試)、響應(yīng)時間:事務(wù)從開始到完成所花費時間
平均吞吐量:指單位時間內(nèi)系統(tǒng)處理用戶的請求數(shù)
TPS:transaction per second 服務(wù)器單位時間處理的事務(wù)數(shù)(事務(wù)數(shù)/運行時間s)
事務(wù):指訪問并可能更新數(shù)據(jù)庫中各種數(shù)據(jù)項的一個程序執(zhí)行單元。例如訂購操作,它含有多個請求
事務(wù)成功率:成功事務(wù)數(shù)占完成總事務(wù)數(shù)的比率 事務(wù)失敗率:失敗事務(wù)數(shù)占完成總事務(wù)數(shù)的比率
三、定義數(shù)據(jù)模型
1、目標(biāo)系統(tǒng)用戶數(shù)、目標(biāo)每秒并發(fā)數(shù)、硬件系統(tǒng)配置情況,如下:模板
IPTV-BSS 性能指標(biāo).docx
四、設(shè)計性能測試方案
IPTV BSS四川電信版本性能
五、搭建性能測試環(huán)境
1、盡可能模擬現(xiàn)網(wǎng)的環(huán)境與組網(wǎng)結(jié)構(gòu)
2、前臺應(yīng)用和后臺數(shù)據(jù)庫安裝在獨立干凈的服務(wù)器上。
3、當(dāng)前性能測試環(huán)境分別為:192.168.12.11(前臺)192.168.12.31(數(shù)據(jù)庫)192.167.12.177(Loadrunner)
六、構(gòu)造性能測試數(shù)據(jù)
1、使用LR、QTP自動化工具構(gòu)造(比較慢,不需要了解表結(jié)構(gòu),但是需要了解業(yè)務(wù)流)
2、編寫存儲過程構(gòu)造用戶、包月、訂購數(shù)據(jù)(比較快,需要對相關(guān)表結(jié)構(gòu)和數(shù)據(jù)庫了解)
七、錄制、調(diào)試測試腳本
1、中間件接口目前是web services協(xié)議,因當(dāng)前測試指標(biāo)均超過100個并發(fā),故使用web(http/html)協(xié)議錄制。中間件接口錄制頁面:
2、boss接口當(dāng)前有兩種協(xié)議,一種是web services協(xié)議,一種是sockets協(xié)議,因當(dāng)前測試指標(biāo)最大為100個并發(fā),故可以使用web services協(xié)議或http/html協(xié)議錄制。
3、bss頁面基于ie運行,故使用web(http/html)協(xié)議錄制。
注明:當(dāng)前中間件接口,四川boss接口,浙江電信bss部分頁面均有現(xiàn)成的腳本,如果其它局點需要測試可使用原有的腳本調(diào)試即可。
詳細參考:LoadRunner性能測試_劉雙林_20110115.doc
2.3/2.4章節(jié) 進行學(xué)習(xí)
八、執(zhí)行性能測試場景
1、按照測試方案文檔中的測試用例執(zhí)行即可。
2、在執(zhí)行性能測試過程中會具體使用到性能測試工具LR。關(guān)于性能測試工具的使用方法網(wǎng)上有大把資料。請自行學(xué)習(xí):場景設(shè)置、參數(shù)化等
詳細參考:LoadRunner性能測試.doc
3章節(jié) 進行學(xué)習(xí)
九、監(jiān)控并記錄性能測試結(jié)果
1、硬件性能:bss應(yīng)用服務(wù)器cpu、內(nèi)存;數(shù)據(jù)庫服務(wù)器cpu、內(nèi)存、io 內(nèi)存、cpu 不高于70% ;IO不高于80% 否則可能存在性能瓶頸 統(tǒng)計方式:
(1)通過命令在服務(wù)器上查詢
內(nèi)存 sar-r 5 120
(每5s刷新1次共刷新120次)cpu sar-u 5 120 io
iostat 5 120(2)在服務(wù)器上安裝rpc.rstatd工具,通過LR客戶端窗口監(jiān)控記錄
2、軟件性能:平均吞度量、tps、平均響應(yīng)時間、事務(wù)成功率、事務(wù)失敗率、錯誤率等(場景運行完畢可通過loadrunner工具導(dǎo)出性能測試結(jié)果),是否達標(biāo)是要與性能測試指標(biāo)進行比對。
詳細參考:LoadRunner性能測試.doc
4章節(jié) 進行學(xué)習(xí)
十、分析性能測試結(jié)果輸出總結(jié)報告
1、將實際測試結(jié)果和性能測試指標(biāo)進行對比,總結(jié)出不達標(biāo)測試對象及具體測試數(shù)據(jù)
2、測試與開發(fā)人員根據(jù)性能測試數(shù)據(jù),從硬件環(huán)境和軟件本身進行分析。例如:優(yōu)化硬件配置、軟件處理邏輯、數(shù)據(jù)庫架構(gòu)腳本等。
3、具體分析的方法:一般是具體問題具體分析,查找瓶頸時按以下順序,由易到難。(1)服務(wù)器硬件瓶頸
(2)網(wǎng)絡(luò)瓶頸(對局域網(wǎng),可以不考慮)(3)服務(wù)器操作系統(tǒng)瓶頸(參數(shù)配置)(4)中間件瓶頸(參數(shù)配置,數(shù)據(jù)庫,web 服務(wù)器等)(5)應(yīng)用瓶頸(SQL 語句、數(shù)據(jù)庫設(shè)計、業(yè)務(wù)邏輯、算法等)注:以上過程并不是每個分析中都需要的,要根據(jù)測試目的和要求來確定分析的深度。對一些要求低的,我們分析到應(yīng)用系統(tǒng)在將來大的負載壓力(并發(fā)用戶數(shù)、數(shù)據(jù)量)下,系統(tǒng)的硬件瓶頸在哪兒就夠了。
十一、LoadRunner性能測試工具操作文檔
LoadRunner性能測試.doc
loadrunner8.1教材.pdf
第五篇:鍋爐性能試驗小結(jié)
培訓(xùn)小結(jié)
本次培訓(xùn)內(nèi)容是電站鍋爐燃燒調(diào)整、性能試驗及運行相關(guān)問題的探討,培訓(xùn)時間2016年11月1日至2日,授課內(nèi)容主要包括鍋爐燃燒調(diào)整試驗、冷態(tài)動力場試驗、電站鍋爐性能試驗、煤質(zhì)對鍋爐運行的影響。最后并講解了一個超超臨界機組實例。
本次培訓(xùn)以PPT課件形式由淺入深進行理論授課,內(nèi)容詳細,重點突出,崗位人員學(xué)習(xí)的積極性提高明顯,印象深刻。
以課件形式講解各知識點時,有疑問,培訓(xùn)課上大家可以進行探討,發(fā)散思維,豐富專業(yè)知識。對于新來的同事,尤其是非本專業(yè)的同事來說,可以加深印象。
培訓(xùn)課上現(xiàn)場講解流程,非本專業(yè)的同事可以很快熟悉現(xiàn)場工藝系統(tǒng)和設(shè)備工作特性,同時在講解流程的同時順便加入了一些設(shè)備的工作原理,結(jié)構(gòu)及運行特性,效果很好,尤其是新同事,容易理解,記憶深刻。培訓(xùn)課上也播放了一下視頻,讓大家更直觀的了解相關(guān)內(nèi)容,并結(jié)合現(xiàn)場作業(yè)情況學(xué)習(xí)了一下監(jiān)護知識,提高專業(yè)和安全知識。這對于非本專業(yè)員工來說,非常重要,學(xué)習(xí)作業(yè)監(jiān)護是提高他們專業(yè)知識和安全知識最快最好的方法。通過此次培訓(xùn),讓科晨公司所有員工系統(tǒng)的學(xué)習(xí)了鍋爐燃燒調(diào)整試驗、冷態(tài)動力場試驗和電站鍋爐性能試驗。使得非鍋爐專業(yè)人員也更快更好的熟悉鍋爐試驗,下一步更好的參與并完成鍋爐相關(guān)試驗。