1 什么是 sql 注入，什么是跨站腳本，什么是跨站請(qǐng)求偽造？

SQL 注入攻擊是注入攻擊最常見的形式（此外還有 OS 注入攻擊（Struts 2 的高危漏洞就是通過 OGNL 實(shí)施

OS 注入攻擊導(dǎo)致的）），當(dāng)服務(wù)器使用請(qǐng)求參數(shù)構(gòu)造 SQL 語句時(shí)，惡意的 SQL 被嵌入到 SQL 中交給數(shù)據(jù)庫(kù)執(zhí)行。

SQL 注入攻擊需要攻擊者對(duì)數(shù)據(jù)庫(kù)結(jié)構(gòu)有所了解才能進(jìn)行，攻擊者想要獲得表結(jié)構(gòu)有多種方式：

（1）如果使用開源系統(tǒng)搭建網(wǎng)站，數(shù)據(jù)庫(kù)結(jié)構(gòu)也是公開的（目前有很多現(xiàn)成的系統(tǒng)可以直接搭建論壇，電商網(wǎng)

站，雖然方便快捷但是風(fēng)險(xiǎn)是必須要認(rèn)真評(píng)估的）；

（2）錯(cuò)誤回顯（如果將服務(wù)器的錯(cuò)誤信息直接顯示在頁面上，攻擊者可以通過非法參數(shù)引發(fā)頁面錯(cuò)誤從而通過

錯(cuò)誤信息了解數(shù)據(jù)庫(kù)結(jié)構(gòu)，Web 應(yīng)用應(yīng)當(dāng)設(shè)置友好的錯(cuò)誤頁，一方面符合最小驚訝原則，一方面屏蔽掉可能給系統(tǒng)

帶來危險(xiǎn)的錯(cuò)誤回顯信息）；

（3）盲注。防范 SQL 注入攻擊也可以采用消毒的方式，通過正則表達(dá)式對(duì)請(qǐng)求參數(shù)進(jìn)行驗(yàn)證，此外，參數(shù)綁

定也是很好的手段，這樣惡意的 SQL 會(huì)被當(dāng)做 SQL 的參數(shù)而不是命令被執(zhí)行，JDBC 中的 PreparedStatement 就

是支持參數(shù)綁定的語句對(duì)象，從性能和安全性上都明顯優(yōu)于 Statement。

XSS（CrossSiteScript，跨站腳本攻擊）是向網(wǎng)頁中注入惡意腳本在用戶瀏覽網(wǎng)頁時(shí)在用戶瀏覽器中執(zhí)行惡意

腳本的攻擊方式。跨站腳本攻擊分有兩種形式：

反射型攻擊（誘使用戶點(diǎn)擊一個(gè)嵌入惡意腳本的鏈接以達(dá)到攻擊的目標(biāo)，目前有很多攻擊者利用論壇、微博發(fā)

布含有惡意腳本的 URL 就屬于這種方式）

持久型攻擊（將惡意腳本提交到被攻擊網(wǎng)站的數(shù)據(jù)庫(kù)中，用戶瀏覽網(wǎng)頁時(shí)，惡意腳本從數(shù)據(jù)庫(kù)中被加載到頁面

執(zhí)行，QQ 郵箱的早期版本就曾經(jīng)被利用作為持久型跨站腳本攻擊的平臺(tái)）。

CSRF 攻擊（CrossSiteRequestForgery，跨站請(qǐng)求偽造）是攻擊者通過跨站請(qǐng)求，以合法的用戶身份進(jìn)行非

法操作（如轉(zhuǎn)賬或發(fā)帖等）。CSRF 的原理是利用瀏覽器的 Cookie 或服務(wù)器的 Session，盜取用戶身份，防范 CSRF 的主要手段是識(shí)別請(qǐng)求者的身份，主要有以下幾種方式：

1）在表單中添加令牌（token） ；

2）驗(yàn)證碼；

3）檢查請(qǐng)求頭中的 Referer（前面提到防圖片盜鏈接也是用的這種方式）。

令牌和驗(yàn)證都具有一次消費(fèi)性的特征，因此在原理上一致的，但是驗(yàn)證碼是一種糟糕的用戶體驗(yàn)，不是必要的

情況下不要輕易使用驗(yàn)證碼，目前很多網(wǎng)站的做法是如果在短時(shí)間內(nèi)多次提交一個(gè)表單未獲得成功后才要求提供驗(yàn)

證碼，這樣會(huì)獲得較好的用戶體驗(yàn)。

2. 給你一個(gè)網(wǎng)站怎么開展測(cè)試？

a)首先，查找需求說明、網(wǎng)站設(shè)計(jì)等相關(guān)文檔，分析測(cè)試需求。

b)制定測(cè)試計(jì)劃，確定測(cè)試范圍和測(cè)試策略，一般包括以下幾個(gè)部分：功能性測(cè)，試界面測(cè)試，性能測(cè)試，數(shù)

據(jù)庫(kù)測(cè)試，安全性測(cè)試，.兼容性測(cè)試

c)設(shè)計(jì)測(cè)試用例：

功能性測(cè)試可以包括，但不限于以下幾個(gè)方面：鏈接測(cè)試；鏈接是否正確跳轉(zhuǎn)，是否存在空頁面和無效頁

面，是否有不正確的出錯(cuò)信息返回等；提交功能的測(cè)試；多媒體元素是否可以正確加載和顯示；多語言支

持是否能夠正確顯示選擇的語言等

界面測(cè)試可以包括但不限于一下幾個(gè)方面：頁面是否風(fēng)格統(tǒng)一，美觀。頁面布局是否合理，重點(diǎn)內(nèi)容和熱

點(diǎn)內(nèi)容是否突出。控件是否正常使用。對(duì)于必須但為安裝的空間，是否提供自動(dòng)下載并安裝的功能。文字

檢查。

性能測(cè)試一般從以下兩個(gè)方面考慮：壓力測(cè)試，負(fù)載測(cè)試，強(qiáng)度測(cè)試

數(shù)據(jù)庫(kù)測(cè)試要具體決定是否需要開展。數(shù)據(jù)庫(kù)一般需要考慮連結(jié)性，對(duì)數(shù)據(jù)的存取操作，數(shù)據(jù)內(nèi)容的驗(yàn)證

等方面。

安全性測(cè)試：基本的登錄功能的檢查；是否存在溢出錯(cuò)誤，導(dǎo)致系統(tǒng)崩潰或者權(quán)限泄露；相關(guān)開發(fā)語言的

常見安全性問題檢查，例如 SQL 注入等；如果需要高級(jí)的安全性測(cè)試，確定獲得專業(yè)安全公司的幫助，外

包測(cè)試，或者獲取支持。

兼容性測(cè)試，根據(jù)需求說明的內(nèi)容，確定支持的平臺(tái)組合：瀏覽器的兼容性；操作系統(tǒng)的兼容性；軟件平

臺(tái)的兼容性；數(shù)據(jù)庫(kù)的兼容性。

d)開展測(cè)試，并記錄缺陷。合理的安排調(diào)整測(cè)試進(jìn)度，提前獲取測(cè)試所需的資源，建立管理體系（例如，需求

變更、風(fēng)險(xiǎn)、配置、測(cè)試文檔、缺陷報(bào)告、人力資源等內(nèi)容）。

e)定期評(píng)審，對(duì)測(cè)試進(jìn)行評(píng)估和總結(jié)，調(diào)整測(cè)試的內(nèi)容。

3. 電商支付模塊的測(cè)試如何展開？

支付流程里面就涉及到了第三方支付接口：

下單接口：商戶提交下單請(qǐng)求到第三方支付接口，第三方支付收單成功后返回下單成功結(jié)果給到商戶系統(tǒng)。

下單接口的最終處理結(jié)果分為下單成功和下單失敗，若未收到明確結(jié)果可調(diào)用單筆訂單查詢接口查詢結(jié)

生成一筆訂單，跳轉(zhuǎn)到第三方時(shí)修改金額，無法到賬，或者如果是游戲充值游戲幣的話，到賬為篡改后的

金額對(duì)應(yīng)的游戲幣；

異步通知屏蔽，同步有效，進(jìn)行支付，同步能夠正常到賬；

同步設(shè)置無效，異步有效，進(jìn)行支付，異步能夠正常到賬；

同步異步都設(shè)置無效，在第三方支付完成后，在重發(fā)機(jī)制時(shí)間范圍內(nèi)，設(shè)置異步有效，到下次通知時(shí)間點(diǎn)

時(shí)，能夠正常通知到賬（補(bǔ)單機(jī)制的驗(yàn)證，如果商戶收到第三方支付成功的通知后，要告知第三方支付收

到了成功的通知，如果第三方支付收到商戶應(yīng)答不是 ok 或超時(shí)，第三方支付就會(huì)認(rèn)為通知失敗，會(huì)在規(guī)定

的時(shí)間內(nèi)持續(xù)調(diào)用 notify_url，一般有時(shí)間或次數(shù)的限制）；

? 針對(duì)支付訂單在數(shù)據(jù)庫(kù)中存儲(chǔ)是否完整和正確進(jìn)行校驗(yàn)（比如：第三方訂單號(hào)--方便與第三方對(duì)賬和問題

排查、訂單金額、訂單狀態(tài)等）；

果。）

支付接口：調(diào)用該接口時(shí)指定支付參數(shù)，完成買家賬戶向商戶賬戶的支付，采用頁面跳轉(zhuǎn)交互模式和后臺(tái)

通知交互模式。（結(jié)果分為兩路返回：一路為前臺(tái)在 return_url 頁面跳轉(zhuǎn)顯示支付結(jié)果；一路為后臺(tái)在

notify_url 收到支付結(jié)果通知后進(jìn)行響應(yīng)。）

退款接口：調(diào)用第三方支付的支付請(qǐng)求接口返回付款成功后，在需要做退款處理時(shí)調(diào)用退款請(qǐng)求接口發(fā)起

退款處理。（退款接口的最終處理結(jié)果分為退款成功和退款失敗，若未收到明確結(jié)果可調(diào)用退款查詢接口查

詢結(jié)果。）

單筆訂單查詢接口：根據(jù)訂單號(hào)查詢單筆訂單信息和狀態(tài)。退款訂單查詢接口：調(diào)用第三方支付的退款接

口返回后，在需要查詢退款請(qǐng)求狀態(tài)可調(diào)用退款訂單查詢接口查詢退款訂單的狀態(tài)和訂單信息。

測(cè)試過程中需要注意的主要測(cè)試點(diǎn)及異常場(chǎng)景：

首先要保證接口都能正常調(diào)用；

生成一筆訂單，支付完成后，同步或異步重復(fù)回調(diào)，只有一次有效；

生成一筆訂單，復(fù)制訂單號(hào)和金額，再次生成一筆訂單，用 fiddler 設(shè)置斷點(diǎn)，用第一筆已完成的訂單號(hào)和

訂單金額去替換現(xiàn)有的訂單號(hào)和金額，無法完成支付；

如果是用戶購(gòu)買實(shí)物商品，用戶發(fā)起退貨，要保證退貨流程正常，資金能正常返還，要考慮下并發(fā)情況的

驗(yàn)證以確保安全性；

?如果是用戶購(gòu)買虛擬商品，比如話費(fèi)、油卡之類的商品，只有在發(fā)貨失敗的時(shí)候才能發(fā)起退貨，注意驗(yàn)證；

4.如何開展兼容性測(cè)試？

（1）Web 兼容性測(cè)試

(a).首先開展人工測(cè)試，測(cè)試工程師測(cè)試主流瀏覽器和常用操作系統(tǒng)測(cè)試主流程和主界面，看看主流程和主界

面是否有問題，如果存在問題，那么記錄下 bug 情況，以及瀏覽器型號(hào)和版本，以及操作系統(tǒng)，準(zhǔn)確定位

bug 產(chǎn)生的原因，提交 bug，告知開發(fā)人員修改。所有的主流設(shè)備都需要進(jìn)行測(cè)試，只關(guān)注主流程和主界

面，畢竟每個(gè)系統(tǒng)主流程和主界面不是很多，所以這個(gè)工作量還是可以承受的。

(b).其次借助第三方測(cè)試工具，目前我覺得比較好用的第三方 Web 測(cè)試工具有 IEtester（離線）、SuperPreview?

（離線）和 Browsershots：browsershots.org（在線），一款可以測(cè)試 IE 的兼容，一款可以測(cè)試主流瀏覽

器的兼容，包括谷歌、火狐、Opera 等等。借助第三方測(cè)試工具，找到 bug 產(chǎn)生的位置，分析測(cè)試結(jié)果，

告知程序員調(diào)整。

（2）APP 兼容性測(cè)試

(a).APP 的兼容性測(cè)試和 Web 測(cè)試類似，首先開展人工測(cè)試，測(cè)試工程師借助測(cè)試設(shè)備對(duì)主流程和主功能，

主界面進(jìn)行測(cè)試；收集所有的能收集到的不同型號(hào)的測(cè)試設(shè)備測(cè)試主流程和主界面，看看主流程和主界面

是否有問題，如果存在問題，綜合考慮設(shè)備的使用率等因素，看看是否需要調(diào)整，如果需要，那么記錄下

bug 情況以及測(cè)試設(shè)備的型號(hào)和操作系統(tǒng)，準(zhǔn)確定位 bug 產(chǎn)生的原因，提交 bug，告知開發(fā)人員修改。

(b).其次借助第三方測(cè)試工具，對(duì)于 APP 的兼容性測(cè)試，推薦的是百度眾測(cè)平臺(tái)和云測(cè)平臺(tái)，我經(jīng)常使用的是

云測(cè)平臺(tái)，這兩款測(cè)試工具里面包含了安卓和 iOS 的測(cè)試；測(cè)試很齊全，包括功能測(cè)試、深度兼容測(cè)試、

性能測(cè)試、網(wǎng)絡(luò)環(huán)境測(cè)試，還可以模擬海量用戶測(cè)試，，還可以導(dǎo)入自己編寫的測(cè)試用例進(jìn)行功能測(cè)試，里

面還包括測(cè)試專家的測(cè)試，當(dāng)然了找專家是要花錢滴。基本進(jìn)行兼容性測(cè)試是不需要花錢的；測(cè)試工程師

把打包好的 apk 或者 IPA 文件，上傳到測(cè)試平臺(tái)，選擇需要測(cè)試的設(shè)備型號(hào)，開始任務(wù)即可；等待一段時(shí)

間，在等待的時(shí)間你是不需要盯著的，你可以做其他的工作。測(cè)試完成后會(huì)生成一份測(cè)試報(bào)告，可以查看

錯(cuò)誤頁面和錯(cuò)誤日志，如果需要調(diào)整，那么提交 bug，告知程序員修改即可。

5.常用 HTTP 協(xié)議調(diào)試代理工具有什么？詳細(xì)說明抓取 HTTPS 協(xié)議的設(shè)置過 程？

Fiddler 是一個(gè)http 協(xié)議調(diào)試代理工具

打開 Fiddler，進(jìn)入 Tools-Options-HTTPS，配置允許抓取 HTTPS 連接和解析 HTTPS 流量然后選擇要解釋的

來源，設(shè)置是否忽略服務(wù)證書錯(cuò)誤（這些操作做完之后，在瀏覽器方位IP:8888，安裝證書就可以在瀏覽器抓取HTTPS

協(xié)議了）

進(jìn)入 Tools-Options-Connections，保證打開啟抓取 HTTPS 連接，然后默認(rèn)端口按需求是或否需要修改，然后

點(diǎn)選允許遠(yuǎn)程計(jì)算機(jī)連接選項(xiàng)

6. APP 測(cè)試的內(nèi)容主要包括哪些，如何開展？

功能測(cè)試：

1.業(yè)務(wù)邏輯正確性測(cè)試：依據(jù)：產(chǎn)品文檔->測(cè)試用例編寫

兼容性測(cè)試：

1.系統(tǒng)版本：Android:官方版本,定制版本;IOS：官方提供版本

2.分辨率：720 *1280 1080*1920

3.網(wǎng)絡(luò)情況:2g 3g 4g 5g Wi-Fi

異常測(cè)試

1.熱啟動(dòng)應(yīng)用:應(yīng)用在后臺(tái)長(zhǎng)時(shí)間待機(jī);應(yīng)用在后臺(tái)待機(jī)過程中，手機(jī)重啟

2.網(wǎng)絡(luò)切換和中斷恢復(fù):網(wǎng)絡(luò)切換;中斷恢復(fù)：

3.電話信息中斷恢復(fù)

升級(jí)，安裝，卸載測(cè)試

1.升級(jí)測(cè)試：臨近版本升級(jí)(1.0->1.1);跨版本(1.0->....->2.2)

2.安裝測(cè)試：首次安裝;覆蓋安裝(同版本，不同版本覆蓋);卸載后安裝

3.卸載測(cè)試：首次卸載;卸載安裝后在卸載

健壯性測(cè)試

1.手機(jī)資源消耗：cpu，內(nèi)存

2.流量消耗：圖片，數(shù)據(jù)，視頻

3.電量測(cè)試

4.崩潰恢復(fù)

7. 針對(duì) App 的安裝功能，寫出測(cè)試點(diǎn)？

安裝

1.正常安裝測(cè)試，檢查是否安裝成功。

2.APP 版本覆蓋測(cè)試。例如：先安裝一個(gè) 1.0 版本的 APP,再安裝一個(gè)高版本(1.1 版本)的APP，檢查是否被覆

蓋。

3.回退版本測(cè)試。例如：先裝一個(gè) 2.0 版本的 APP,再安裝一個(gè) 1.0 版本的 APP,正常情況下版本是可以回退的。

4.安裝時(shí)內(nèi)存不足，彈出提示。

5.根據(jù)安裝手冊(cè)操作，是否正確安裝。

6.安裝過程中的意外情況（強(qiáng)行斷電、斷網(wǎng)、來電話了、查看信息）等等，檢查會(huì)發(fā)生的情況。

7.通過‘同步軟件’，檢查安裝時(shí)是否同步些文件。安裝了一

8.在不同型號(hào)、系統(tǒng)、屏幕大小、分辨率上的手機(jī)進(jìn)行安裝。

9.安裝時(shí)是否識(shí)別有 SD 卡，并默認(rèn)安裝到 sd 卡中。

10.安裝完成后，能否正常啟動(dòng)應(yīng)用程序。

11.安裝完成后，重啟手機(jī)能否正常啟動(dòng)應(yīng)用程序。

12.安裝完成后，是否對(duì)其他應(yīng)用程序造成影響。

13.安裝完成后，能否添加快捷方式。

14.安裝完成后，殺毒軟件是否會(huì)對(duì)其當(dāng)做病毒處理。

15.多進(jìn)程進(jìn)行安裝，是否安裝成功。

16.在安裝過程中，所有的提示信息必須是英文或者中文，提示信息中不能出現(xiàn)代碼、符號(hào)、亂碼等。

17.安裝之后，是否自動(dòng)啟動(dòng)程序。

18.是否支持第三方安裝。

19.在安裝中點(diǎn)擊取消。

?卸載

1.用自己的卸載程序進(jìn)行卸載，檢查是否卸載干凈。

2.用第三方工具，檢查是否卸載干凈。

3.在卸載過程中，點(diǎn)擊取消按鈕，看是否正常退出卸載程序，檢查軟件是否還能繼續(xù)正常使用。

4.卸載過程中，出現(xiàn)意外（比如手機(jī)關(guān)機(jī)，沒電，查看信息，接打電話），程序是否還能運(yùn)行。

5.在卸載過程中，突然重啟設(shè)備，再次訪問程序，是否還能運(yùn)行。

6.在沒用使用程序時(shí)，刪除目錄文件，看程序是否能運(yùn)行。

7.在使用過程中，直接刪除目錄文件，程序是否還能運(yùn)行。

8.不同系統(tǒng)、硬件環(huán)境、網(wǎng)絡(luò)環(huán)境下進(jìn)行卸載。

9.卸載成功后，是否對(duì)其他程序有影響。

10.卸載后再次安裝，是否正常使用。

11.在卸載過程中，所有的提示信息必須是英文或者中文，提示信息中不能出現(xiàn)代碼、符號(hào)、亂碼等。

?更新

1.當(dāng)客戶端有新版本時(shí)，提示更新。

2.非強(qiáng)制更新，可以取消更新，舊版本正常使用，下次使用軟件時(shí)，仍然會(huì)出現(xiàn)更新提示。

3.強(qiáng)制更新，強(qiáng)制更新而用戶沒有更新時(shí)，退出客戶端，下次啟動(dòng)，依然提示更新。

4.不卸載更新，檢查是否可以更新。

5.不卸載更新，檢查資源同名文件如圖片等是否更新成最新版本。

6.非 wifi 網(wǎng)絡(luò)下，提示是否更新，取消就加入待下載，wifi 下自動(dòng)更新。

8.常用的 ADB 命令？

adb --help /adb :看見幫助信息

adb start-server:啟動(dòng) adb 服務(wù)

adb kill-server:關(guān)閉 adb 服務(wù)

adb devices:查看手機(jī)設(shè)備號(hào)

adb shell getprop ro.build.version.release:獲取系統(tǒng)版本

adb push 電腦 手機(jī)

adb pull 手機(jī) 電腦

adb logcat |grep(unix) 包名

adb logcat |findstr(win) 包名

adb shell :進(jìn)入 shell 命令行，可以操作 Linux 命令

adb shell dumpsyswindow windows |grep mFocusedApp:獲取包名 啟動(dòng)名(win：adb shell dumpsyswindow

windows |findstr mFocusedApp)

adb install 路徑/apk 文件:安裝 apk 到手機(jī)上

adb uninstall 包名:卸載 app 從手機(jī)上

adb shell am start-W 包名/啟動(dòng)名:app 啟動(dòng)時(shí)間

9.在查看 logcat 命令日志時(shí)候怎么內(nèi)容保存到本地文件？

輸出重定向：logcat>> log_file_name

10. App 崩潰（閃退），可能是什么原因?qū)е碌模?/h2>

緩存垃圾過多：由于安卓系統(tǒng)的特性,如果長(zhǎng)時(shí)間不清理垃圾文件.會(huì)導(dǎo)致越來越卡.也會(huì)出現(xiàn)閃退情況.

運(yùn)行的程序過多,導(dǎo)致內(nèi)存不足

應(yīng)用版本兼容問題：如果應(yīng)用版本太低，會(huì)導(dǎo)致不兼容，造成閃退。此外，有些新版本在調(diào)試中，也會(huì)造成應(yīng)

用閃退。解決方法：如果是版本太舊，更新為新版本即可；如果是新版本閃退，可能是應(yīng)用在改版調(diào)試，可卸載后

安裝舊版。

檢查 APP 中訪問網(wǎng)絡(luò)的地方，組件中的 ImageView 是否可以正常的下載并顯示到 app 頁面上。

檢查 APP 的 sdk 和手機(jī)的系統(tǒng)是否兼容。

在一些特定情況下的閃退,比如播放視頻,在Android5.0 升級(jí)到Android6.0 的時(shí)候,有些系統(tǒng) API老版本有,新版

本沒有,到時(shí)回去對(duì)象的時(shí)候失敗,報(bào)空,系統(tǒng)就會(huì)出現(xiàn)閃退問題.

11.如何測(cè)試監(jiān)測(cè) app 的內(nèi)存使用、CPU 消耗、流量使用情況？

adb shell top

Android 應(yīng)用性能測(cè)試通常包括：?jiǎn)?dòng)時(shí)間、內(nèi)存、CPU、耗電量、流量、流暢度等

根據(jù)手機(jī)的使用應(yīng)用頻度和強(qiáng)度不同，可將應(yīng)用使用強(qiáng)度分為如下幾種狀態(tài)：

空閑狀態(tài)：指啟動(dòng)應(yīng)用后，不做任何操作或切換到后臺(tái)運(yùn)行的情況稱為空閑狀態(tài)，該情況為應(yīng)用對(duì)內(nèi)存的

消耗是最小的。

中強(qiáng)度狀態(tài)：該情況用戶使用應(yīng)用的強(qiáng)度和時(shí)間長(zhǎng)短不確定，相對(duì)來說使用時(shí)長(zhǎng)偏長(zhǎng)。

高強(qiáng)度狀態(tài)：該種情況為應(yīng)用內(nèi)高頻率的使用，用戶很少達(dá)到，跑 monkey 時(shí)可認(rèn)為高強(qiáng)度狀態(tài)，該種情

況常用來測(cè)試應(yīng)用內(nèi)存泄漏的情況測(cè)試時(shí)，可根據(jù)用戶的操作習(xí)慣模擬應(yīng)用使用頻率和強(qiáng)度等級(jí)。

使用 adb 命令，手機(jī)連接電腦開啟 USB 調(diào)試模式，進(jìn)入 adbshell。

1）查看 CPU 占用率（

使用命令 top-m10-scpu（-t 顯示進(jìn)程名稱，-s 按指定行排序，-n 在退出前刷新幾次，-d 刷新間隔，-m 顯

示最大數(shù)量），如下圖：

參數(shù)含義：

PID：progressidentification，應(yīng)用程序 ID

S: 進(jìn)程的狀態(tài)，其中 S 表示休眠，R 表示正在運(yùn)行，Z 表示僵死狀態(tài)，N 表示該進(jìn)程優(yōu)先值是負(fù)數(shù)。

#THR：程序當(dāng)前所用的線程數(shù)

VSS：VirtualSet Size 虛擬耗用內(nèi)存（包含共享庫(kù)占用的內(nèi)存）

RSS： ResidentSet Size 實(shí)際使用物理內(nèi)存（包含共享庫(kù)占用的內(nèi)存）

UID：UserIdentification，用戶身份 ID

Name:應(yīng)用程序名稱

在測(cè)試過程中，QA 需要關(guān)注對(duì)應(yīng)包的 cpu 占用率，反復(fù)進(jìn)行某個(gè)操作，cpu 占用過高且一直無法釋放，此時(shí)

可能存在風(fēng)險(xiǎn)。如果你想篩選出你自己的應(yīng)用的話可以用下面命令 top -d 3|grep packageName

（2）查看內(nèi)存使用情況

dumpsys meminfo <package_name>或 dumpsys meminfo <package_id>

參數(shù)含義：

Naitve Heap Size: 從 mallinfo usmblks 獲得，代表最大總共分配空間

Native Heap Alloc: 從 mallinfo uorblks 獲得，總共分配空間

Native Heap Free: 從 mallinfo fordblks 獲得，代表總共剩余空間

Native Heap Size 約等于 Native Heap Alloc +Native Heap Free

mallinfo 是一個(gè) C 庫(kù)， mallinfo 函數(shù)提供了各種各樣的通過 C 的 malloc（）函數(shù)分配的內(nèi)存的統(tǒng)計(jì)信息。

Dalvik HeapSize:從 Runtime totalMemory()獲得，DalvikHeap 總共的內(nèi)存大小。

Dalvik HeapAlloc: Runtime totalMemory()-freeMemory() ，DalvikHeap 分配的內(nèi)存大小。

Dalvik Heap Free:從 Runtime freeMemory()獲得，Dalvik Heap 剩余的內(nèi)存大小。

Dalvik HeapSize 約等于 DalvikHeapAlloc +DalvikHeap Free

重點(diǎn)關(guān)注如下幾個(gè)字段：

Native/Dalvik 的 Heap 信息中的 alloc ：具體在上面的第一行和第二行，它分別給出的是 JNI 層和 Java

層的內(nèi)存分配情況，如果發(fā)現(xiàn)這個(gè)值一直增長(zhǎng)，則代表程序可能出現(xiàn)了內(nèi)存泄漏。

Total 的 PSS 信息：這個(gè)值就是你的應(yīng)用真正占據(jù)的內(nèi)存大小，通過這個(gè)信息，你可以輕松判別手機(jī)中哪些

程序占內(nèi)存比較大了。