? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?探索無界，BUG無限

?

一、修改系統時間

當功能模塊中存在倒計時、計時器、時間，與時間有關系時，嘗試修改系統時間，測試系統時間是否參與計算，修改系統時間是否會影響到倒計時、計時、時間等與時間有關系的模塊

例：1小時后秒殺商品，修改系統時間到1小時后，測試是否可以下單

?

二、斷網、斷網重連、服務器斷開

1、斷網，操作功能流程，是否報錯、閃退、卡死、異常顯示問題

2、斷網重連，app內，測試功能是否可正常使

3、斷網，進入app，重連網，測試部分接口是否未重新調用，導致功能數據缺失

4、服務器斷開功能使用檢測

?

三、弱網

模擬網絡弱網場景（4g網絡、地鐵、機場、地下室、室外等）

弱網狀態，重復提交操作，會導致接口調用錯亂、業務重復調用、業務出錯等BUG

弱網狀態，測試響應超時導致的接口報錯等

弱網狀態，測試延遲導致的頁面交互錯亂等

弱網狀態，測試接口超時，導致的前后端異常問題（狀態變更錯誤、數據加減錯誤）

1、弱網下客戶端要傳參數給服務器。
例如：請求參數是index = 0 ，拿到服務器響應，我們就index++。 若服務器500，我們下次請求，必須還
是index = 0，所以我們要做 --index，用減去1返回值發請求。如果不幸寫成index--，很不幸，bug就來了，
因為此時index = 1。
2、網絡異常，測試客戶端重試策略，只有在弱網下才能看到效果。
例如：客戶端經常做一種處理，請求對象發送返回失敗，客戶端會重試，請求必須是異步進行的，此時可
能會出現重試失敗，仍然一直在發請求，重試策略有問題，如果是服務器爆了，你一直重試發請求，app
絕對被爆…………
3、開源網絡框架，也許經不住弱網
例如：現在Android的http開源框架天多了，公司多數都會用這些二次封裝的框架，類似于okHttp、volley，
用的比較多一些，免不得在弱網環境下，拋異常。就因為請求是在工作線程進行的，所以……，并發不是所
有人都能玩的轉的，很容易出現bug。
4、弱網環境下，網絡連接失敗，拋異常
例如：弱網遲遲沒有返回響應，此時網絡連接拋異常，可能會沒處理，響應實例對象沒有拿到，是個null，
又沒處理，又要拋異常…………
5、弱網環境下，ui可能出現問題
例如：網絡請求還在異步進行中，一般UI我們都會有進度條告知用戶，沒有拿到響應后，我們要更新ui，提
示用戶網絡連接失敗等等文案，此時可能會出現問題，View沒有同步成功，或者忘記gone掉進度條……
6、網絡請求失敗策略之用戶主動再次發出請求
例如：弱網下，請求失敗（拋出異常），提示用戶重試再次發出請求，用戶點擊重試再次發出請求，此時
處理可能會出現問題

?

四、推送

1、已登錄賬號，刪除app重裝，進入登錄頁面，register_id未清空會收到推送

2、已登錄賬號，登錄信息失效，踢出到登錄頁面，register_id未清空，會收到推送

3、已登錄賬號，賬號再其它地方登錄，踢出到登錄頁面，register_id未清空，會受到推送

?

五、修改請求參數、修改響應內容

1、用戶購買會員的金額可以通過修改請求里的金額，進行購買---原因：后端的代碼沒有將拿到的用戶的金額和實際的金額進行對比，再去發出下一步的支付流程。

余額1元，購買2元商品，修改請求金額為2元，測試是否可購買成功

余額1元，購買2元商品，修改請求金額為0.1元，測試是否可購買成功

2、實名認證請求：https://m.kaola.com/member/activity/valid/nameAuth.html，只需將請求里Response里code修改為：unknown200，以及將success的值修改為true，然后將這個請求發出去之后，我們的刷子用戶就可以成功繞過這個圍墻了，去購買參加我們試用會員了，從而可以享受我們的7天會員96折價格

?

六、并發

1、余額1元，并發提現1元100次，測試成功提現多次

2、創建訂單A，對訂單A進行并發100次付款，測試付款成功多次

3、抽獎系統，每人可抽一次，并發抽取100次，測試可抽取多次

4、1個紅包、2個紅包時，同用戶并發提現100次，不同用戶并發提現100次

?

七、越權

1、登錄權限越權

token失效、賬號被踢出，使用創建訂單、充值、付款功能，對token檢驗進行測試

2、業務邏輯越權

? <1>業務狀態越權

?新建的訂單、已付款的訂單、已發貨的訂單、已收貨的訂單、已完成的訂單、已評價的訂單，進行付款操作測試

? <2>業務終結越權

已實名認證成功，再次實名認證、再次實名認證其它身份證

? <3>業務上下層越權

?已實名認證，進入提現業務，庫里改狀態為未未實名認證，提現檢測

?<4>業務資源占用越權

A身份證被A用戶占用，B用戶綁A身份證檢測

3、垂直越權未授權功能

主管有修改權限，客服有查看權限，主管賬號更換為客服賬號，進行修改操作測試

4、水平越權其它用戶、團隊資源

通過修改URL鏈接上的參數來進行一些非對應賬號信息的查看和操作。

例1：修改URL上的訂單號為別人的，查看、修改、刪除、評價、操作別人的訂單進行測試

例2：修改URL上的訂單參數為不存在的，查看、修改、刪除、評價、操作別人的訂單進行測試

例3：主管有修改權限，A團隊主管修改B團隊成員信息

5、非歸屬關系越權

例：轉移會員給已鎖定的BD，轉移成功，應不可轉移

?

八、重復提交

重復提交業務會處理多次，業務邏輯會錯亂

例1：新建訂單、每次簽到、領取獎勵，重復提交多次，導致業務創建多次檢測

例2：實名認證成功，業務結束，再次實名認證，業務處理檢測

?

九、假設法

1、假設列表字段為0、空、null值、超長、超大，測試異常、報錯、溢出問題

2、假設因為BUG導致綁定了別人的卡，提現測試

3、假設列表數據10w條，大量數據測試

4、假設接口返回跳轉鏈接字段空，點擊跳轉，APP閃退，需異常處理

接口應該返回：

{"code":0,"msg":"成功","data":{"status":true,"url":"http:\/\/activity-h5.st1.test.lanxinka.com\/interview-report?target=watch_c&id=JyNHWjwVbm"}}

但是返回：{"code":0,"msg":"成功","data":{"status":true,"url":""}}

5、假設頁面1接口還未返回數據時，進入頁面2，頁面2需用到接口字段，會報錯

例：頁面1是商品列表，點商品進入商品詳情頁面，進入商品傷情頁面需傳商品id

解決：頁面1還未加載完成時，無法拿到商品id，前端判斷，無法進入商品詳情

6、假設頁面接口字段還未返回時，觸發頁面功能，導致出錯

例：接口返回手機號字段，顯示到頁面上，點撥打電話，可撥打電話

解決：前端還未拿到手機號字段時，不顯示撥打電話按鈕或點撥打電話，彈出提示

?

十、內存溢出、內存泄露

1、內存泄露，長時間操作功能或模塊，感覺越來越卡、越來越慢，測試內存泄露問題

2、內存溢出，長時間操作功能或模塊，感覺越來越卡、越來越慢，直至報錯、閃退等問題，測試內存溢出問題

3、操作功能，觀察內存使用情況，測試后端代碼是否存在內存泄露問題

?

十一、超時、失敗、接口異常報錯

超時

1、接口響應超時，測試超時后的處理

因網絡慢、服務器壓力大、數據量大，導致處理時間過長超時，調用支付中心，業務方失敗，支付中心處理成功，錢已發出去

例1：發傭金2000條，點審核通過，處理結果為發送失敗（應該是超時了），但支付中心處理成功，實際金額已發到用戶賬戶

2、前端請求超時，測試超時后的處理

3、第三方系統維護中，測試維護中處理

4、服務器斷開，測試功能使用的異常處理

失敗

1、失敗結果處理

充值失敗，沖入和沖出賬戶回退檢測

接口異常報錯

1、接口報錯500，前端處理檢測

2、接口返回格式錯誤，前端處理檢測

3、接口未獲取到數據，前端處理檢測

?

十二、SQL、代碼注入

1、表單類注入

登錄時SQL是這樣： select * from user where username='chengzi'? and password=md5('123456');

我們現在需要構建一個比如：在用戶名輸入框中輸入: ’ or 1=1#,密碼隨便輸入，這時候的合成后的SQL查詢語句為：

select * from user where username='' or 1=1 #'? and password=md5('123456');

等價于

select * from user where username='' or 1=1;

就可以登錄成功了

2、url傳參注入

首先應測試是否存在注入漏洞，簡單的：’ 或 and 1=1 and 1=2之類的SQL語句。

如果沒有檢測，直接運行SQL語句，說明有機會注入。

舉例：

從參數注入，簡單的測試方法是：

① http://www.xxx.com/index.php?id=2

② http://www.xxx.com/index.php?id=2' and 1=1

③ http://www.xxx.com/index.php?id=2' and 1=2

可以注入的表現：

① 正常顯示（這是必然的，不然程序就有錯）

② 正常顯示，內容基本與①相同

③ 提示BOF或EOF（程序沒做任何判斷時）、或提示找不到記錄（判斷了rs.eof時）、或顯示內容為空（程序加了on error resume next）說明未進行特殊字符過濾處理，存在SQL注入漏洞

3、代碼注入

提交死循環代碼，測試是否進行過濾處理

<script>
?for(i=0;i<1;i--)
?{
?alert("msg")
?}
?</script>

?

十三、安全測試—短信轟炸

危害：

1、批量給用戶發100w條短信，造成用戶騷擾和公司短信費用損失

2、批量給非正常手機號碼發短信

語預防方案：

1、對手機號做驗證，正確的手機號才可發短信成功

2、同一個手機號不能連續獲取短信驗證碼，如設置1分鐘僅允許使用1次

3、同一手機號，一天設置最大發送驗證碼次數，如同一手機號一天最多發十條

4、設置每日總成功短信上限

5、當同一個手機號碼或者ip重復連續不斷發起請求時，將手機號碼或者ip拉黑處理

?

十四、多觸點控

1、測試頁面交互錯亂問題

?

十五、接口status字段

1、接口各種status，功能頁面顯示檢測

2、接口各種status，操作功能提示信息檢測

?

十六、數據初始化修復

1、因表結構發生變化原因，老數據需做初始化修復

2、因表版本功能變更原因，老數據需做初始化修復

3、因操作失誤原因，老數據需做初始化修復

4、因BUG原因，老數據需做初始化修復

?

十七、接口字段（一般不能刪減）或字段值，修改、刪減

1、新版本原字段檢測

2、新版本原字段值檢測

?

十八、未來狀態/不存在的關聯傳參

1、如果status有1：招聘 ?2：非招聘?

考慮0和3測試，程序如何處理的？是否會=<1統一處理成招聘,>=2統一處理成非招聘，如果這樣處理了，下個版本如果加了status 3：急招，新版本后端先上線，app審核階段，0會顯示招聘，3會顯示非招聘，這樣是錯誤的，所以當時就應該非1和2，統一處理為不存在的狀態

2、支付不存在的訂單號檢測

?

十九、優選資源少校驗

因為優先校驗資源少的，校驗不通過，避免校驗資源大的，造成服務器資源浪費消耗

例如：手機號和驗證碼登錄，優先校驗驗證碼是否正確，再校驗用戶登錄信息是否正確，如果驗證碼不正確，避免用戶信息查詢校驗

?

二十、外部事件

斷網、斷網重連、關閉定位權限、關閉通知、關閉相機相冊權限、關閉電話權限

電話、短信、視頻、重啟手機

安卓（返回鍵、清緩存、清數據、轉移應用）

IOS（鎖屏、HOME）

?

持續更新——————————————————————————————

總結

以上是生活随笔為你收集整理的【探索测试篇】探索无界，BUG无限，让程序猿头疼的测试技术的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。