從外部看，性能測試主要關注如下三個指标：

吞吐量：每秒鐘系統能夠處理的請求數、任務數

響應時間：服務處理一個請求或一個任務的耗時

錯誤率：一批請求中結果出錯的請求所占比例

從服務器的角度看，性能測試主要關注CPU、内存、服務器負載、網絡、磁盤IO等。

1.确定關鍵業務，關鍵路徑；

2.确定測試的關鍵數據。比如并發量，響應時間，循環次數等；

3.準備測試環境，完成腳本錄制或腳本開發；

4.執行測試，觀察或監控輸出參數，比如吞吐量，響應時間，資源占有率等；

5.對執行結果進行分析，分析性能問題。

1.查看聚合報告和服務器的資源使用圖，檢查響應時間，事務成功率，CPU，内存和IO使用率是否達到要求，如果出錯率達到了總請求的3%，我們會檢查是什麼原因導緻的，修改好後，重新測試；

2.如果出現了性能瓶頸，比如響應時間，或者CPU使用率不達标，我們會從服務器上導出日志，分析是哪個地方導緻響應時間過長，如果分析不出來，就叫上開發一起讨論，确定問題後，就提單給代發修複，修複好了就進行回歸測試。

查看在整個性能測試過程中，網絡的吞吐量是多少，如果網絡的吞吐量占到了服務器的70%以上，我們就認為網絡存在瓶頸，通常會增加帶寬或者壓縮傳輸數據。

根據性能測試結果先檢查看下是否是服務器帶寬存在問題，如果帶寬存在瓶頸，則會考慮增加帶寬或者壓縮傳輸數據，如果帶寬沒有問題的話，我們會從服務器上導出日志，開發一起讨論分析是哪個地方導緻響應時間過長，确定問題後，就提單給開發修複，修複好了就進行回歸測試。

CPU使用率不達标，我們會從服務器上導出日志，分析是哪個地方導緻CPU使用率不達标，如果分析不出來，就叫上開發一起讨論，确定問題後，就提單給開發修複，修複好了就進行回歸測試。

APP的性能測試分為服務器端的性能和手機端的性能。

服務器端的性能：jmeter工具進行測試的，和web端性能測試的方法一樣的。

手機端APP的穩定測試：使用monkey做。

1.先使用 adb logcat -c 清空手機的logcat日志；

2.接下來使用 adb logcat -v time 獲取logcat 日志，并導入本地文件使用 monkey 運行被測應用 adb shell monkey -p 包名 -v 3.100000 并将執行結果導入到本地測試；

4.如果中途失敗了就要去看monkey日志中有沒有crash或者anr的關鍵字；

5.如果還需要定位到是什麼原因導緻的anr或者crash的問題，将相關日志和logcat日志與進程号提交給開發定位；

6.如果是anr的問題，還需要從安卓中獲取/data/anr/traces.txt文件提交給開發定位。

線程阻塞，内存不足，CPU滿負荷（現在手機基本都是8核CPU，基本不會出現CPU滿負荷的情況）

空指針值，數組越界，内存不足，CPU滿負荷（現在手機基本都是8核CPU，基本不會出現CPU滿負荷的情況）

1.設備碎片化：由于設備極具多樣性，App在不同的設備上可能有不同表現形式；

2.寬帶限制：寬帶不佳的網絡對App所需的快速響應時間不夠；

3.網絡的變化：不同網絡的切換可能會影響App的穩定性；

4.内存管理：可能内存過低，或者是授權的内存位置的使用可能會導緻App失敗；

5.用戶過多：連續數量過多可能會導緻App崩潰；

6.代碼錯誤：沒有經過測試的新功能，可能會導緻App在生産環境中失敗；

7.第三方服務：廣告或彈出屏幕可能會導緻App崩潰。

adb install（apk的文件路徑） 安裝軟件到手機或者模拟器

adb uninstall（包名） 卸載手機或模拟器上的某款軟件

adb devices 查看與當前電腦連接的移動設備

adb ,adb start-server 啟動

adb,adb kill-server 殺死

adb logcat 查看日志

adb logcat -v time process >

adb install -r xx.apk 覆蓋低版本的

adb install -r -d 覆蓋高版本的

adb shell dumpsys cpuinfo 查看手機cpu的使用情況

adb shell getprop|findstr dalvik 手機系統自己運行的内存使用

Adb shell monkey -p 包名

Adb-shell–ignore-crashes 忽略崩潰

Adb-shell–ignore-timeouts 忽略延時

Adb-shell–ignore-throttle 延時毫秒值

Adb-shell–pct-touch–pct-motion 觸摸與滑動事件的比例

1.2G的網速150kbps，折合下載速度15-20k/s

2.3G的網速1-6mbps，折合下載速度120k/s-600k/s

3.4G的網速10-100mbps，折合下載速度1.5m/s-10m/s

4.使用真實的SIM卡，運營商網絡來進行測試

5.通過代理的方式模拟弱網環境下進行測試（Charles延遲）

6.鍊接模拟弱網的熱點進行測試（如360WiFi助手可以設置）

1.後端完成開發，輸出接口文檔；

2.前端開發和後端開發進行前後端聯調，結束後後端開發人員提測接口；

3.測試人員進行接口測試；

4.進行驗收測試；

5.利用持續集成技術進行持續的校驗。

1.通過性驗證：保證接口好使，能正常傳入且返回正确的結果；

參數組合：有必傳項時檢查必傳項；

接口安全：①繞過驗證（比如商品價格不能被外部修改）②繞過身份授權（商品必須商家本人才能修改）③參數是否加密（用戶名密碼加密）④密碼複雜程度校驗

2.根據業務邏輯來設計用例

3.工具：postman和jmeter。一般用postman測接口，jmeter也能側，但一般不用。

先看接口文檔，根據接口文檔進行測試，包含接口的URL，請求參數，響應結果。如果沒有接口文檔，就自己抓包。我們是用jmeter來做接口測試的，首先，要新建一個線程組，在線程組下面添加一個http請求，然後填寫好服務器地址，接口路徑，請求方式，請求參數。如果需要參數化，先在本地創建一個TXT文檔，把參數填寫到文檔裡面，在jmeter中添加一個csv文件設置，填寫好TXT文檔的路徑，然後在請求參數中使用json提取器把token值關聯出來，然後在下單接口中使用${參數名}的方式引用；接下來添加斷言，檢查服務器返回的結果和預期結果是不是一緻的。最後，添加查看結果數查看測試結果。

1.有一部分是重疊的，UI測試是通過前端寫的界面，是來調用接口的，而接口測試是直接調用接口；

2.排除前端的處理邏輯與調用的正确性，在理論上接口測試是可以覆蓋所有的UI測試，但實際中，如幾口層覆蓋所有的業務流，在UI上隻測試前端的邏輯，而最終的結果會忽視很多原有的功能點，導緻了UI測試的不充分，那麼會存在人多分工且實踐充分的時候可以嘗試接口去做業務流的全覆蓋，否則不要輕易地去嘗試。

1.有些公司沒有标準的接口文檔，隻能通過抓包獲取接口信息；

2.通過抓包可以查看整個請求過程以及相應過程，從而分辨是前台bug還是後台bug；

3.可以查看是否有敏感信息洩漏；

4.抓包進行測試，攔截請求，修改請求數據，查看響應結果本來就是接口測試的一部分。

Charles。

在工具設置http代理，設置端口号，在手機上設置同一網段，設置代理IP，設置代理端口，手機上的請求就可以抓取到了。

可以設置過濾，找到自己域名下的請求，通過分析請求地址，請求參數，響應結果來查找問題。

https，下載證書就可以抓取到請求了。

1.打開jmeter；

2.創建線程組；

3.設置線程數和循環次數；

4.配置元件；

5.配置我們需要進行測試的程序協議、地址和端口；

6.構造http請求；

7.添加http請求頭；

8.添加斷言；

9.添加查看結果樹；

10.添加Summary Report；

11.執行測試計劃，執行測試計劃不能用GUI，需要用命令來執行；

12.web報告。

1.在jmeter的線程組中分别添加JDBC Connection ConfigConfiguration 、JDBC Request 、 Debug Sampler 、 查看結果數。

2.在測試計劃中将連接mysql需要的包加到classpath中。

3.在JDBC Connection Configuration 中添加JDBC的配置。

做壓力測試時，我們經常需要替換參數，在jmeter中，有多種參數化的形式。可以在測試計劃中設置全局參數，可以設置用戶參數，還可以在前置處理器中設置用戶參數。在進行多線程并發的時候，如果需要多個參數，可以使用csv配置元件。比如做登錄操作，後台有可能會限制一個用戶不能重複登錄多次，如果演示登錄的并發操作，可以使用jmeter中的csv元件，将用戶信息導出來，放到文件中，就可以讓線程共享這些數據。另外，對于一些随機變化的參數，可以使用jmeter中的函數助手，生成随機函數，進行參數化測試。比如注冊這樣的操作，用戶名要求唯一的，那就可以使用随機函數模拟出來。

當測試接口的時候，發現某個接口性能比較差，需要進一步判定問題的時候，會壓測數據庫。壓測數據庫需要配置驅動，設置連接池大小，需要使用sql去操作數據庫。具體的哪條sql問題需要問開發要具體的sql進行壓測。

1.用例組織不同：jmeter的組織是比較偏扁平，首先它沒有工作空間的概念，直接就是測試計劃，而postman功能上更簡單，組織方式是輕量級，他主要針對的是單個的http請求。

2.支持接口的類型與測試的類型不同：jmeter的功能更強大，可以通過各種類型的接口，不支持的頁可以通過網上或者自己編寫的插件進行擴展，而postman更輕量級，定位不同，可用來測試rest接口。

3.配置不同：jmeter可以在線程組裡添加http，tcp，而postman隻支持rest接口。

用它來做接口測試。

查看接口的返回結果；

查看接口是get請求還是post請求；

數據庫語言最常用的是SQL

多表聯查：select * from table1 t1,table2 t2 where tl.id=t2.id

這樣就是多表聯查。

left join

right join

inner join

增：

alter table 數據表名 add birthday datetime;

删：

alter table 表名 drop 列名;

改：

1.修改字段，不重命名，用modify

alter table 數據表名 modify birthday date;

2.修改字段，重命名，用change

alter table 表名 change 原名 新名 類型及約束

alter table 數據表名 change birthday birth date；

查：

查詢表使用數據 select * from 表名;

部分查詢 select * from 表名 where 條件;

可以使用as 為列表指定别名

select 字段 as 别名,字段 as 别名 from 數據表名 where…;

内關聯是求交集

外關聯是以主表為标準，去附表找需要的信息

不能，腳本需要通過Windows調試好之後，才能在Linux上運行，運行的時候，隻能通過non GUL的形式進行啟動jmeter，但需要注意的是，csv文件在Windows上與Linux上要統一路徑，最好使用相對路徑，放到統一目錄下邊。

cd:進入目錄

cd app：切換到app目錄

cd… ：切換到上一層目錄

cd/: 切換到系統根目錄

tail -10 a.txt :查看後10行數據

ifconfig :查看ip

ll:查看文件及其屬性

vi: 編輯

rm-rf: 删除

car:解壓及壓縮命令

cp:複制

pwd:顯示當前路徑

mv:移動

cat:查看文件内容

touch:創建文件

tail logcat:查看日志

cat logcat:查看日志

tomcat：日志

tail ：查看日志記錄信息，tail -f catinalia out

tar -xvf 文件名 :解壓

tar -n logcat 查看系統日志

tar -zcvf 文件名：壓縮

顯示，管理執行中的程序，就是任務管理器

通過腳本代替一些手動化測試的步驟。unittest， web端：selenium ；app端：appium

find_element_by_id()（常用）

find_element_by_name()（常用）

find_element_by_class_name()

find_element_by_tag_name()

find_element_by_link_text()

find_element_by_partial_link_text()

find_element_by_xpath()（常用）

find_element_by_css_selector()

我們的電腦（c端）上運行自動化測試腳本，調用的是appium的webdriver的接口，appium服務器（s端）接收到我們client上發送過來的命令後，它會将這些命令轉換為UIautomator認識的命令，然後由UIautomator來在設備上執行自動化。

1.用戶程序安全；

2.系統網絡安全；

3.數據庫安全。

1.覆蓋用戶的需求；

2.從用戶使用場景觸發，考慮用戶的各種正常和異常的使用場景；

3.用例的顆粒大小要均勻。通常，一個測試用例對應一個場景；

4.用例各個要素要齊全，步驟應該足夠詳細，容易被其它測試工程師讀懂，并能順利執行；

5.做好用例評審，及時更新測試用例。

1.首先進行需求分析，用XMind梳理測試點，再編寫案例，之後就進行案例評審，尋求他人意見。之後再完善案例，發出來給其他人檢查。

2.測試點，首先是UI方面，美觀度和易操作性，易理解性方面進行測試。

3.然後再考慮其他功能點，注冊登錄，添加購物車，下單，付款，發貨，确認收貨，評價等。

4.性能方面：打開網頁，确認訂單，付款的響應時間等等

5.兼容性：支持各種主流浏覽器，IE，360，火狐，谷歌等

功能：

1.在紅包錢數和紅包個數的輸入框中隻能輸入數字；

2.紅包最多和最少的輸入錢數 200,0.01；

3.拼手氣紅包最多可以發多少個紅包；

4.超過最大拼手氣紅包是否有提醒；

5.當紅包錢數超過最大範圍是否有提醒；

6.餘額不足時，紅包發送失敗，或者會不會匹配切換支付方式；

7.紅包描述裡是否可以輸入表情、漢字、英文、數字等；

8.紅包描述裡最多有多少個字符；

9.發送的紅包别人是否能正常領取；

10.發送的紅包自己可不可以領取；

11.24小時後别人沒有領取的紅包是否可以退回原來的賬戶，或者是否還可以領取；

12.用戶是否可以多次搶一個紅包；

13.用戶在多人群裡發紅包是否可以搶自己的紅包；

14.紅包餘額裡的小位數是否有限制；

15.返回鍵可以正常取消發紅包嗎；

16.斷網時是否可以搶紅包；

17.收發紅包界面是否有自己以前收發紅包的記錄，以及和自己實際收發紅包是否匹配；

18.支付時密碼支付和指紋支付是否正常；

19.支付成功是否正常返回聊天界面；

20.是否可以連續發紅包。

性能：

1.網絡環境差，發紅包的時間；

2.不同網速時，搶紅包的時間；

3.收發紅包後跳轉時間；

4.收發紅包的耗電量；

5.退款到賬的時間。

兼容：

1.蘋果，安卓系統；

2.電腦端是否可以搶紅包；

3.不同品牌的手機是否正常使用。

界面：

1.發紅包界面有沒有錯别字；

2.搶完紅包界面有沒有錯别字；

3.收發紅包界面排版美觀合理；

4.界面顔色搭配好。

安全：

1.發送紅包領取紅包後對應相關的金額是否會變化；

2.發送失敗銀行卡或者餘額會不會變；

3.發送成功後是否會收到微信支付的通知。

易用：

1.支持指紋，人臉識别支付碼；

2.紅包描述可以通過語音輸入嗎。