第一篇：性能測試QQ面試總結

21克

9:46:17 你全權參與的性能測試項目有幾個？ 低調的魚

9:48:08 BECIF平安銀行客戶信息管理系統

平安銀行個人網銀改造（接入一帳通卡后）平安投行證券管理系統 交通銀行積分管理系統 中銀聯OA系統

21克

9:48:50 那在性能測試中有沒有發現什么缺陷？ 低調的魚

9:53:09 我去整理一下 21克

9:55:29 好的

低調的魚

10:03:24 BECIF平安銀行客戶信息管理系統 1822 BECIF1.0.0 性能測試-客戶基本信息查詢（20并發 場景腳本 查詢客戶基本信息_byBecif_c.lrs）P2 L2 關閉 2 1842 BECIF 新增客戶性能優化 P4 L3 已關閉 3 1848 綜合場景測試（300 4hour）未達到1S響應時間要求 P2 L2 已分配

1.疑似客戶判斷代碼取線程數有誤。

2.查詢疑似客戶返回值最大個數未做限定。

3.中間件ESB對于XML腳本的最大長度限制過小。4.數據庫連接數不夠。

平安銀行個人網銀改造（接入一帳通卡后）1.weblogic線程數不夠 2.數據庫連接池數不夠

平安投行證券管理系統 1.服務器系統資源不夠

2.用戶登陸驗證機制時間過長。

交通銀行積分管理系統

1.100并發用戶時積分查詢交易超時

中銀聯OA系統 1.tomcat JVM過少

2.tomcat 線程數過少。

3.多用戶登陸時流量統計插件報錯。

低調的魚

10:04:09 BECIF的缺陷當時我有記錄，其他的項目只是記得自己當時做性能測試過程中發現的問題。21克

10:06:45 對BECIF平安銀行客戶信息管理系統來說，你提及的4條調優的建議是基于什么測試結果提出的？

21克

10:07:00 也就是說你是如何得出這4調結論的 低調的魚

10:25:36 1.疑似客戶判斷代碼取線程數有誤。

查詢疑似交易單獨運行時，weblogic的線程數增長速度過快，系統線程數迅速到到最大負荷

2.查詢疑似客戶返回值最大個數未做限定。

我當時編寫的腳本是新增用戶后再進行疑似查詢操作，用戶的五項關鍵信息為：姓名，性別，生日，證件類型，證件號碼 2.1 證件類型，證件號碼同 2.2 姓名、性別、生日三者相同 如上兩種情況都是屬于疑似客戶，我的查詢疑似的腳本中只用戶姓名進行了參數化，（每增加一個用戶，疑似判斷的用戶就+1）

因為當時跑了100并發用戶的綜合場景，分了15分鐘，1小時，4小時幾次運行。查詢疑似交易的平均響應時間越來越長，后面去CC上取代碼看的時候，發現開發未對疑似的最大值進行限制。

3.中間件ESB對于XML腳本的最大長度限制過小。

新增用戶不添加產品信息時，查詢客戶所有信息交易平均響應時間正常。

但是從生產上取下來的數據屏蔽名字后，進行綜合場景運行過程中，查詢客戶所有信息的交易失敗率大大增加.原因為客戶產品信息和基本信息所涉及的字段有300余個，有80多個字段為文本類型，如果客戶有多個產品信息的話 查詢時系統后臺生成的XML腳本文件有可能大于

而ESB對于BECIF傳出的XML腳本文件限制的最大值為1M

4.數據庫連接數不夠。

200用戶綜合場景運行時,查詢類的交易平均響應時間過長，后臺log中，返回交易有超時情況 weblogic中事務排隊嚴重。21克

10:32:10 上面的這些的調優工作是有測試人遠來做還是由開發人員來做的？ 低調的魚

10:35:33 中間件的參數變更平安銀行那邊是有專門的人做的，我們只能是提缺陷和建議，然后由他們評審之后確定是他們的問題再作修改的，至于代碼類的問題是開發來改的。

我所做的事情就是盡自己可能去收集資源，發現問題，提出自己的見解 21克

10:36:41 你提出的這些建議都有別接受嗎？ 21克

10:37:02 他們修改后的性能提高了多少？ 低調的魚

10:37:36 這幾個都是接受了的 21克

10:37:44 他們修改后的性能提高了多少？ 低調的魚

10:37:55 BECIF項目，按照平安規范，依據性能測試需求分析和方案。進行壓力測試

測試目的（1）模擬真實應用，系統各個主要業務流程能否在78個并發用戶同時訪問情況下響應時間為1s以內。

（2）在系統各業務流程能正常運行的情況下，系統能承受多少個并發用戶同時訪問（系統承壓能力）。

（3）測試主要業務流程（或者某事物）的響應時間。

低調的魚

10:38:25 這個是一期的要求，經過一系列調整后所有交易都達到上面的指標 21克

10:39:25 你們的性能測試時有自己的環境還是在生產環境上進行的？ 低調的魚

10:43:10 生產上肯定是禁止運行的，專門的性能測試應當說有的 一般都是在STG環境上運行的，BECIF這個項目，當時用于性能測試的有三個環境，PER環境 新功能及系統的測試環境

PIR環境主要用于常規版本測試的生產缺陷問題驗證和修復

還有一個是容災環境，這個環境都是最新版本的系統，一般都是在這個上面做性能測試。21克

10:44:15 你們的性能測試用的是什么工具？ 低調的魚

10:46:30 loadrunner 8.1 和loadrunner9.0 當時做性能測試的時候都是在專門的遠程服務器上做的，我用過的一共有5臺，3臺上面裝的是loadrunner8.1另外2臺上面裝的是loadrunner9.0

21克

10:46:56 好的

21克

10:47:36 你的簡歷已經通過了篩選，我會吧你的簡歷提交給測試經理。結果會盡快通知你的 21克

10:47:42

謝謝

低調的魚

10:47:51 好的，多謝了

第二篇：性能測試學習總結

性能測試學習總結

一、明確性能測試的范圍

例如：以iptv系統為例，是需要測試bss頁面、中間件具體接口、boss/crm具體接口

二、明確性能測試的指標 例如：

1、支持最大并發用戶數是多少？（壓力測試）

2、每秒n個用戶并發，能正常持續運行多久？（負載測試）

3、在系統用戶為n個的情況下，每秒x個用戶并發，持續運行y分鐘，查看系統硬件io、cpu、內存；查看軟件平均吞度量、tps、平均響應時間、事務成功率、事務失敗率、錯誤率等（性能測試）、響應時間：事務從開始到完成所花費時間

平均吞吐量：指單位時間內系統處理用戶的請求數

TPS：transaction per second 服務器單位時間處理的事務數（事務數/運行時間s）

事務：指訪問并可能更新數據庫中各種數據項的一個程序執行單元。例如訂購操作，它含有多個請求

事務成功率：成功事務數占完成總事務數的比率 事務失敗率：失敗事務數占完成總事務數的比率

三、定義數據模型

1、目標系統用戶數、目標每秒并發數、硬件系統配置情況，如下：模板

IPTV-BSS 性能指標.docx

四、設計性能測試方案

IPTV BSS四川電信版本性能

五、搭建性能測試環境

1、盡可能模擬現網的環境與組網結構

2、前臺應用和后臺數據庫安裝在獨立干凈的服務器上。

3、當前性能測試環境分別為：192.168.12.11（前臺）192.168.12.31（數據庫）192.167.12.177（Loadrunner）

六、構造性能測試數據

1、使用LR、QTP自動化工具構造（比較慢，不需要了解表結構，但是需要了解業務流）

2、編寫存儲過程構造用戶、包月、訂購數據（比較快，需要對相關表結構和數據庫了解）

七、錄制、調試測試腳本

1、中間件接口目前是web services協議，因當前測試指標均超過100個并發，故使用web（http/html）協議錄制。中間件接口錄制頁面：

2、boss接口當前有兩種協議，一種是web services協議，一種是sockets協議，因當前測試指標最大為100個并發，故可以使用web services協議或http/html協議錄制。

3、bss頁面基于ie運行，故使用web（http/html）協議錄制。

注明：當前中間件接口，四川boss接口，浙江電信bss部分頁面均有現成的腳本，如果其它局點需要測試可使用原有的腳本調試即可。

詳細參考：LoadRunner性能測試_劉雙林_20110115.doc

2.3/2.4章節 進行學習

八、執行性能測試場景

1、按照測試方案文檔中的測試用例執行即可。

2、在執行性能測試過程中會具體使用到性能測試工具LR。關于性能測試工具的使用方法網上有大把資料。請自行學習：場景設置、參數化等

詳細參考：LoadRunner性能測試.doc

3章節 進行學習

九、監控并記錄性能測試結果

1、硬件性能：bss應用服務器cpu、內存；數據庫服務器cpu、內存、io 內存、cpu 不高于70% ；IO不高于80% 否則可能存在性能瓶頸 統計方式：

（1）通過命令在服務器上查詢

內存 sar-r 5 120

（每5s刷新1次共刷新120次）cpu sar-u 5 120 io

iostat 5 120（2）在服務器上安裝rpc.rstatd工具，通過LR客戶端窗口監控記錄

2、軟件性能：平均吞度量、tps、平均響應時間、事務成功率、事務失敗率、錯誤率等（場景運行完畢可通過loadrunner工具導出性能測試結果），是否達標是要與性能測試指標進行比對。

詳細參考：LoadRunner性能測試.doc

4章節 進行學習

十、分析性能測試結果輸出總結報告

1、將實際測試結果和性能測試指標進行對比，總結出不達標測試對象及具體測試數據

2、測試與開發人員根據性能測試數據，從硬件環境和軟件本身進行分析。例如：優化硬件配置、軟件處理邏輯、數據庫架構腳本等。

3、具體分析的方法：一般是具體問題具體分析，查找瓶頸時按以下順序，由易到難。（1）服務器硬件瓶頸

（2）網絡瓶頸(對局域網，可以不考慮)（3）服務器操作系統瓶頸(參數配置)（4）中間件瓶頸(參數配置，數據庫，web 服務器等)（5）應用瓶頸(SQL 語句、數據庫設計、業務邏輯、算法等)注：以上過程并不是每個分析中都需要的，要根據測試目的和要求來確定分析的深度。對一些要求低的，我們分析到應用系統在將來大的負載壓力(并發用戶數、數據量)下，系統的硬件瓶頸在哪兒就夠了。

十一、LoadRunner性能測試工具操作文檔

LoadRunner性能測試.doc

loadrunner8.1教材.pdf

第三篇：Linux_網絡性能測試(總結)

Linux網絡性能測試 使用 Ipref測試吞吐

1.1 安裝

tar-zxvf iperf-2.0.5.tar.gz cd iperf-2.0.5./configure make && make install

1.2 測試UDP

服務器命令：iperf-s-i 1-u 客戶端命令：iperf-c 170.0.0.100-i 1-t 999-b 1000000000-u-l 22-c：服務器地址-i：每次報告的間隔-t：持續測試的時間-b：帶寬-u：UDP-l：UDP 有效負荷大小

各字節測試時，輸入-l參數如下：

在服務端查看結果，64字節UDP小包的吞吐約是7.32 Mbits/s。

[root@localhost ~]# iperf-s-u-i 2-----------------------------Server listening on UDP port 5001 Receiving 1470 byte datagrams UDP buffer size: 208 KByte(default)-----------------------------[ 3] 10.0-12.0 sec 1.72 MBytes 7.22 Mbits/sec 0.022 ms 55728/137802(40%)[ 3] 12.0-14.0 sec 1.79 MBytes 7.49 Mbits/sec 0.016 ms 52637/137735(38%)[ 3] 14.0-16.0 sec 1.74 MBytes 7.30 Mbits/sec 0.040 ms 53247/136227(39%)[ 3] 16.0-18.0 sec 1.74 MBytes 7.32 Mbits/sec 0.071 ms 54608/137771(40%)[ 3] 18.0-20.0 sec 1.79 MBytes 7.52 Mbits/sec 0.021 ms 52133/137632(38%)[ 3] 20.0-22.0 sec 1.75 MBytes [ 3] 22.0-24.0 sec 1.74 MBytes 7.32 Mbits/sec 0.020 ms 54508/137672(40%)[ 3] 24.0-26.0 sec 1.79 MBytes 7.51 Mbits/sec 0.022 ms 52519/137838(38%)[ 3] 26.0-28.0 sec 1.72 MBytes 7.20 Mbits/sec 0.019 ms 55779/137599(41%)[ 3] 28.0-30.0 sec 1.72 MBytes 7.23 Mbits/sec 0.016 ms 55504/137640(40%)[ 3] 30.0-32.0 sec 1.77 MBytes 7.41 Mbits/sec 0.017 ms 52849/137002(39%)[ 3] 32.0-34.0 sec 1.74 MBytes 7.31 Mbits/sec 0.022 ms 54785/137842(40%)[ 3] 34.0-36.0 sec 1.74 MBytes 7.30 Mbits/sec 0.019 ms 54717/137710(40%)

7.32 Mbits/sec 0.021 ms 54418/137616(40%)2 使用http_load測試HTTP Server吞吐和并發

2.1 安裝Apache服務器

1、安裝并啟動

yum-y install httpd service httpd start

2、在Apache服務端準備好各字節大小的頁面

（頁面大?。?4、128、256、512、768、1024、1280、1518）cd /var/ Document Length: 64 bytes

Concurrency Level: 10 // 每秒測試并發數 Time taken for tests: 9.920 seconds Complete requests: 100 // 成功的請求數 Failed requests: 0 // 失敗的請求數 Write errors: 0 Total transferred: 45100 bytes HTML transferred: 6400 bytes Requests per second: 10.08 [#/sec](mean)// 每秒事物處理，mean表示平均值 Time per request: 992.027 [ms](mean)//平均事物響應時間

Time per request: 99.203 [ms](mean, across all concurrent requests)Transfer rate: 4.44 [Kbytes/sec] received //傳輸為4.44字節每秒 吞吐為4.44 * 8 = 35.52 Mbit/s 3.3 其他參數

-n requests 全部請求數-c concurrency 并發數

-t timelimit 最傳等待回應時間-p postfile POST數 據文件-T content-type POST Content-type-v verbosity How much troubleshooting info to print-w Print out results in HTML tables-i Use HEAD instead of GET-x attributes String to insert as table attributes-y attributes String to insert as tr attributes-z attributes String to insert as td or th attributes-C attribute-H attribute Inserted after all normal header lines.(repeatable)-A attribute http-P attribute Add Basic Proxy Authentication, the attributes are a colon separated username and password.-X proxy:port-V-k Use HTTP KeepAlive feature-d Do not show percentiles served table.-S Do not show confidence estimators and warnings.-g filename Output collected data to gnuplot format file.-e filename Output CSV file with percentages served-h Display usage information(this message)加入cookie, eg.'Apache=1234.(repeatable)加入http頭, eg.'Accept-Encoding: gzip' 驗證,分隔傳遞用戶名及密碼

代理服務器 查看ab版本

使用sendip發原地址跳變的數據包（并發）

3.1 安裝

1、到http://www.tmdps.cn and CWR bits Default: 0-tfe x TCP ECN bit(rfc2481)Default: 0(options are 0,1,r)-tfc x TCP CWR bit(rfc2481)Default: 0(options are 0,1,r)-tfu x TCP URG bit Default: 0, or 1 if-tu specified(options are 0,1,r)-tfa x TCP ACK bit Default: 0, or 1 if-ta specified(options are 0,1,r)-tfp x TCP PSH bit Default: 0(options are 0,1,r)-tfr x TCP RST bit Default: 0(options are 0,1,r)-tfs x TCP SYN bit Default: 1(options are 0,1,r)-tff x TCP FIN bit Default: 0(options are 0,1,r)-tw x TCP window size Default: 65535-tc x TCP checksum Default: Correct-tu x TCP urgent pointer Default: 0-tonum x TCP option as string of hex bytes(length is always correct)Default:(no options)-toeol TCP option: end of list-tonop TCP option: no op-tomss x TCP option: maximum segment size-towscale x TCP option: window scale(rfc1323)-tosackok TCP option: allow selective ack(rfc2018)-tosack x TCP option: selective ack(rfc2018), format is-tots x TCP option: timestamp(rfc1323), format is tsval:tsecr l_edge1:r_edge1,l_edge2:r_edge2...

第四篇：Android客戶端性能測試總結

Android客戶端性能軟件測試小結

發布時間: 2012-3-09 13:52 作者: xiaowan 來源: TaoBao QA Team 字體: 小 中 大 |上一篇下一篇 |打印 |我要投稿 |推薦標簽：性能測試軟件測試

Android手機客戶端的性能測試開展近3個月了，期間包括性能監測工具的開發周期和工具的投入使用和優化；客戶端性能測試從這里起步，從這里開始。

一般情況，對于新生的產品，都會用定勢的思維考慮：優先功能測試，之后才會是安全、性能等方面。android客戶端從誕生到現在，在測試上走的也是這樣的路線。隨著客戶端功能越來越完善、越來越繁大，用戶群越來越多，性能、響應、穩定等被正式提上議程，重點考慮關注。

為什么我們要從以上幾個點來考慮客戶端性能呢？ 針對上面的幾個點我們是如何開展監控測試的？如何來評估一個客戶端的性能好不好，是否給予通過？下面就我自己看法跟大家詳細交流。

有數據統計：有很大一部分人群喜歡睡覺前、公交車、廁所、或者會議中開小差中使用手機；在看下移動互聯網的發展趨勢【下圖摘自某次互聯網統計報告】：

在上圖為各大運營商所占移動市場份額的變化情況：整體上移動用戶數仍絕對領先，但其市場份額也明顯的下降趨勢，百度推斷導致此變化的原因是基礎網絡的性能已經開始影響移動互聯網應用的使用，即網絡到底好不好，速度到底快不快，已經開始在影響應用市場份額了。同樣，對用戶而言：特定網絡下客戶端流暢不流暢、響應快不快決定著用戶對客戶端的使用時長和粘度；此外，用戶在考慮速度的同時，還會考慮跟自身利益相關的—-金額&網絡流量的消耗。

一個成熟的場景包括：人、時間、地點、行為。換言之：什么特征的人在什么情況下會使用比較容易比較經常使用客戶端，他們又經常使用客戶端的哪些面呢？

在客戶端性能監測前，我們需要采集真實場景中的性能數據：2G的網絡下的時間指標、訪問量較多頁面的流量消耗情況、整個客戶端的穩定情況。

（1）穩定性測試：【不同網絡、不同軟硬件系統下】

客戶端可穩定運行的時間、以及長時間操作后的流量消耗和內存消耗；

（2）性能測試指標：【不同網絡下】

界面流暢性、界面切換時間、占用的內存數、服務器返回數據消耗流量大小及數據的返回時間；

對以上的點，有幾種方法可以采用來監測?，F在我們使用的是自己開發的客戶端性能工具。其中：流量統計使用TrafficStats.getUidRxBytes()來獲取下行流量值；響應時間通過判斷activity的狀態和日志中記錄的時間戳來獲取響應時間段； 內存通過解析dumpsys命令返回內容，截取我們需要的值進行分析；電量統計android系統提供查看。除了自己研發的小工具之外，外界也提供很多工具，都可以幫助我們完成相關的性能監測。

對用戶而言，性能不等于響應。堅持客戶第一，通過我們一個測試環節來保證用戶手中的每個客戶端都用的暢快。

第五篇：噴漆性能測試

6.4 噴漆性能測試（樣品數量：每種顏色6套外殼）

試驗條件：物理測試需要在注塑完成，產品放置72小時以后進行，化學測試則需6天以后。噴涂干燥 硬化后應在常溫下放置48小時以后再進行試驗。

試驗方法：

1）把濾紙放于酸性（PH=2.6）溶液中充分浸透；

2）用膠帶將浸有酸性溶液的濾紙分別粘在兩套噴涂樣品表面，確保濾紙與樣品噴漆 表面充分接觸，將樣品放入試驗箱。

3）測試時間以試驗箱達到所需溫濕度條件時開始計算。在24小時與48小時分別取 出一套樣品，揭下濾紙，并放置2小時后，檢查樣品表面噴涂。

檢驗標準：樣品表面無變色、起氣泡、起皮、脫落、褪色以及其他與測試前狀態不一致的現象。

6.4.5 鏡面劃傷測試

測試環境：室溫（20~25° C）；

測試目的：驗證鏡面耐硬物劃傷性能的可靠性

樣品數量：不少于2個

試驗方法：將實驗樣品固定在劃傷試驗機上，接觸部分為直徑為1mm的碳化鎢球，硬度為90.5～ 91.5，用載重（load）為500g的力在樣品表面往復劃傷50次，劃線速度為3～4cm/秒，接觸部分與被測面成90度角，對樣品的X和Y軸兩個軸向進行測試。每10次對鏡面進行外觀檢查，并對鏡面表面進行清潔。檢驗標準：鏡面表面劃傷寬度應不大于100μm（依靠目視分辨、參照缺陷限度樣板）

6.4.6 紫外線照射測試

測試環境：50° C

測試目的：驗證噴涂抗紫外線照射的可靠性

樣品數量：不少于1套殼體

試驗方法：在溫度為50° C，紫外線為340W/mm2的光線下直射油漆表面48小時。

試驗結束后 將手機外殼取出，在常溫下冷卻2小時后檢查噴漆表面。

檢驗標準：印刷、電鍍無褪色、變色、紋路、開裂、剝落以及與測試前不一致的現象。

6.4.7鹽霧測試

測試環境：35° C

測試目的：測試樣機抗鹽霧腐蝕能力

試驗方法：a.溶液含量：5%的氯化鈉溶液b.將手機關機放在鹽霧試驗箱內，合上翻蓋，樣機用繩子懸掛起來，以免溶液噴灑 不均或有的表面噴不到。c.樣機需要立即被放入測試箱。實驗周期是48個小時。實驗過程中樣機不得被中途 取出，如果急需取出測試，要嚴格記錄測試時間，該實驗需向后延遲相同時間。d.取出樣機，放置48小時進行常溫干燥，對其進行外觀檢查。

檢驗標準：外觀檢查無異常：表面噴涂、絲印、電鍍、裝飾件、標牌等無脫落、起泡、腐蝕以及與測試前不一致的現象。

試驗環境：溫度20~25度，濕度65＋/-20% 6.4.1 耐磨測試測試環境：室溫（20~25° C）；測試目的：噴涂/印刷等抗摩擦性能的可靠性 樣品數量：不少于1套殼體

試驗方法：將最終噴涂的手機外殼固定在RCA試驗機上，用175g力隊同一點進行摩擦試驗。對于表面摩擦300cycles，側面和側棱摩擦150 Cycles。特殊形狀的手機摩擦點的確定由測試工程師和設計工程師共同確定

檢驗標準：對于噴涂、電鍍、IMD等，涂層不能脫落，不可露出底材質地；對于表面印刷類，印刷圖案、字體不能出現缺損、不清晰現象。

6.4.2 附著力測試

測試環境：室溫室溫（20~25° C）；高低溫箱

測試目的：噴涂附著力測試

樣品數量：不少于1套殼體

試驗方法：選最終噴涂的手機外殼表面，使用百格刀刻出25個1mm2方格，劃線應深及底材；使用毛刷將劃線處的噴漆粉屑清除干凈；再用3M610號膠帶紙完全粘貼在方格面，1分鐘后迅 速以90度的角度撕下膠帶，檢查被測區域表面。

檢驗標準：有涂層脫落的方格數應不大于總方格數的3%；單個方格涂層脫落面積不大于單個方格總面積的50%。

6.4.3 硬度測試

測試環境：室溫（20~25° C）；

測試目的：表面噴涂硬度的可靠性

樣品數量：不少于1套殼體

試驗方法：將鉛筆芯削成圓柱形并在400目砂紙上磨平后，裝在鉛筆硬度測試儀上，以500g 的力度，鉛筆與水平面的夾角為45度，在樣品表面從不同方向劃出30~50mm長的線條3~5條。對于噴漆表面的硬度標準為2H（三菱牌），500g的載荷；對于Lens表面的硬度標準為3H（三菱牌），500g的載荷；每劃完一次都應將鉛筆磨平。

檢驗標準：用橡皮擦去鉛筆痕跡，目視噴漆、印刷、電鍍、Lens表面無劃痕。

6.4.4 汗液測試

測試環境：60° C，95%RH

測試目的：表面抗汗液腐蝕的能力

樣機數量：不少于2套

注：部品由于使用場所、材質、色澤等有特殊要求時可以考慮采用其他標準。

7.2 整機狀態下的可靠性試驗

溫度沖擊測試（Thermal shock）

測試環境：低溫箱：-40° C ；高溫箱：+80° C

試驗方法：將手機設置成關機狀態放置于高溫箱內持續30分鐘后，在15秒內迅速移入低溫箱并持續30分鐘，為一個循環，共循環27次。實驗結束將樣機從溫度沖擊箱中取出，并在 室溫下恢復2小時，進行外觀、機械和電性能檢查。

試驗標準：手機各項功能正常；外觀檢驗：殼體表面噴涂、絲印、電鍍無氣泡、褶皺、裂紋、起皮、脫落；裝飾件無翹起、脫落以及其他與測試前狀態不一致的現象。跌落試驗（Drop Test）測試條件：1.5m高度，20mm大理石板。

試驗方法：將手機處于開機狀態，進行6個面的自由跌落實驗，每個面的跌落次數為1次，跌 落之后進行外觀、機械和電性能檢查。對于翻蓋手機，在跌翻蓋一面時，應將一半樣品合上翻蓋跌，一半樣品打開翻蓋跌。

試驗標準：手機各項功能正常；

外觀檢查：殼體表面無明顯掉漆，無裂紋、破損、沖擊痕以 及其他與測試前不一致的現象。振動試驗（Vibration test）

測試條件：振幅：0.38mm；振頻：10~30Hz；振幅：0.19mm；振頻：30~55Hz；

試驗方法：將手機開機放入振動箱。X、Y、Z三個軸向分別振動1個小時之后取出，然 后進行外觀、機械和電性能檢查。

試驗標準：振動前5分鐘內手機內存和設置沒有丟失現象，后55分鐘可以出現關機現象，手機各項功能正常，尤其是顯示和SPL，外殼無嚴重損傷（如掉漆），內部元件無脫落。

濕熱試驗（Humidity test）

測試環境：60oC，95%RH

試驗方法：將手機處于關機狀態，放入溫度實驗箱內的架子上，持續60個小時之后 取出，恢復2小時，然后進行外觀、機械和電性能檢查。

試驗標準：手機各項功能正常；外觀檢查：外觀測試無異常（殼體、Lens表面無裂紋、氣泡；Lens 無被腐蝕現象；金屬、電鍍殼體或裝飾件無變色、腐蝕，以及無其他與測試前不一致的現象）。

高溫/低溫參數測試（Parametric Test）

測試環境：-10oC/55oC

試驗方法：將手機處于開機狀態，放入溫度實驗箱內的架子上。持續2個小時之后(與 環境溫度平衡)，然后在此環境下進行電性能檢查，檢查項目見附表1。

試驗標準：手機電性能指標滿足要求，功能正常，表面噴涂、電鍍無裂紋等。高溫高濕參數測試（Parametric Test）

測試環境：+45oC，95%RH

試驗方法：將手機處于開機狀態，放入溫度實驗箱內的架子上。持續48個小時之 后，然后在此環境下進行電性能檢查。

試驗標準：手機電性能指標滿足要求，功能正常；結構檢查：裝飾件、Logo及機殼 等無脫落，殼體卡鉤無脫出、斷裂，外殼無變形；

外觀檢查：殼體表面無明顯掉漆，無裂紋、破損、沖擊痕以及其他與測試前狀態不一致現象。高溫/低溫功能測試（Functional test）

測試環境：-40oC/+70oC