工作中容易被忽略的缺陷
經過軟件測試課程及系統性學習之後，進入工作中，總是遇到一些遺漏的或沒有考慮到的缺陷，自己記錄一下，以後針對不同的系統可以套用這個模版。
目錄
權限
- 瀏覽器直接訪問url地址
- …
瀏覽器直接訪問url地址
有時候，開發只考慮到正常登錄後的權限，沒有考慮到直接訪問url地址的情況。包括未登錄直接訪問url地址和已登錄但無頁面權限直接訪問url地址。
具體做法：
1. 登錄系統後摘錄所有頁面的url，包括通過超鏈接跳轉的子頁面。（獲取方式: 鼠標中鍵/ F12/ Fiddler）
2. 在未登錄系統的瀏覽器上，直接粘貼摘錄到的url地址。
3. 在已登錄但無頁面權限帳號的瀏覽器上，直接粘貼摘錄到的url地址。
預期：
- 跳轉至登錄頁面。
- 給予無權限提示。
健壯性
- 多個用戶同時對一條記錄進行操作
- 接口在併發請求下的健壯性
- …
多個用戶同時對一條記錄進行操作
工作中，經常發現開發對多個用戶同時對一條記錄進行操作的場景沒有做約束。特別是有狀態變更的業務場景，嚴重程度不低。例如：用戶A對記錄進入編輯頁面，用戶B此時將該記錄刪除，用戶A再進行保存操作，這種情況下，很可能已經被刪除的記錄又”復活”了。
具體做法：
1. 使用用戶A對一條記錄進行編輯操作，保持在編輯頁面。
2. 使用用戶B對該記錄進行刪除操作。
3. 此時，使用用戶A繼續編輯，完成保存動作。
預期：
- 用戶B操作時，給予友好提示，並且不可刪除。
- 用戶A完成保存動作時，提示記錄已被刪除。
接口在併發請求下的健壯性
工作中，曾經遇到一個缺陷。有一個退款接口，併發請求時，餘額會被扣成負數。這並不是性能問題，而是接口的健壯性很差。在實際業務場景上不會發生，但是很可能被惡意用戶用Fiddler獲取接口參數後，產生異常數據，甚至獲利（如果是充值接口存在此缺陷呢？）。
具體做法：
1. 開啓Fildder抓包工具。
2. 使用系統完成一筆業務操作。（選擇你認爲會改寫系統內數據的接口）
3. 在Fiddler中查看該操作請求的url地址和參數。
4. 使用Jmeter，在Sampler中填入url和參數，進行大量併發請求。
5. 查看Jmeter中監聽器、系統內相關記錄頁面、系統日誌來檢查是否產生了異常數據。
預期：
無任何異常數據產生。
注意：
接口測試應該完全基於惡意用戶也能獲取到的信息來進行測試。就如同本格推理，你不應該比惡意用戶知道更多情報來輔助測試。
安全性
- 交易接口是否有sign簽名參數
- 帳號爲手機號的系統，是否有接口會直接暴露用戶庫
- 多次登錄失敗後是否有防禦機制
- …
交易接口是否有sign簽名參數
經常網上看到有人說FD擼東西，什麼1分錢買東西啦，這裏FD指的就是Fiddler。有些電商網站或APP對創建訂單的接口沒有sign簽名參數，這導致用戶修改了金額一樣可以被服務器接受。（簽名的用處在於，將請求中的參數以某種形式排列後加鹽再加密，然後作爲參數一起發出。）
具體做法：
1. 開啓Fildder抓包工具，開啓breakpoints - before requests。
2. 使用系統發起一筆交易操作。
3. 在Fiddler中找到該請求，修改其金額後，點擊run to completion。
4. 在Fiddler中查看響應結果。
預期：
- 訂單創建失敗，給予友好提示，例如”訂單異常”。
多次登錄失敗後是否有防禦機制
在網頁上，普遍登錄需要驗證碼。但在手機APP上，驗證碼由於輸入麻煩，並不多見。但是仍然應該在一定次數登錄失敗以後，出現驗證碼或者凍結30秒等防禦機制。如果沒有防禦機制，那麼惡意人員就能使用密碼字典來對帳號嘗試硬破。
具體做法：
1. 使用手機APP進行登錄操作，填入正確帳號和錯誤密碼。重複10次。
2. 查看每一次的登錄失敗的提示信息。
預期：
- 登錄一定次數後，提示”請輸入驗證碼”或者”登錄次數過多，請30秒後重試”。
登錄帳號爲手機號的系統，接口是否會暴露用戶庫
工作中遇到過一個APP，在登錄和註冊時，對於沒有註冊的手機號，會有一個友好提示。這本並無不妥，但是手機號是純數字的，這很容易進行大量參數遞增請求。惡意人員可以通過對11位數字進行遞增循環來進行請求，從響應內容中篩選出系統註冊用戶。
具體做法：
1. 閱讀接口文檔，在不需要登錄的接口中，查找有可能會暴露識別信息的接口。（如註冊/ 登錄等）
2. 使用Fiddler抓包工具，獲取註冊接口的url地址和參數。
3. 使用Jmeter，在Sampler中填入url和參數（正確手機號和錯誤密碼），進行1次請求。
4. 使用Jmeter，在Sampler中填入url和參數（錯誤手機號），進行1次請求。
5. 查看Jmeter中監聽器。
預期：
- 無法從響應內容中分辨是不是系統註冊用戶。