致測試同仁們：讓我們做安全測試吧！(8)

3. 針對“惡意用戶需求”設計測試用例

現在我們需要做的是努力把自己限制在“惡意用戶”的角度做頭腦風暴：“到底有什么方法可以使買家無法上傳圖片信息呢？”， “讓頁面無法正確顯示買家秀圖片又怎么做到？”嗯，也許最直接的辦法就是讓服務器所在的機房斷電、斷網之類的。這是些不錯的想法，雖然執行難度有點大。沒關系，記錄下來。除此之外，我們還可以有其他測試用例，比如：

• 使存儲圖片的磁盤空間被占滿而無法接受新的圖片；
• 使處理上傳圖片的進程繁忙而無法接受新的上傳任務；
• 上傳特別大的圖片使用戶的客戶端需要很長時間才能下載完
• 上傳偽裝成圖片的惡意代碼，進一步獲取服務器權限，刪除所有的買家秀圖片；
• 等等

如果這個時候想到新的測試用例也同樣記錄下來，比如“我想不購買也上傳買家秀圖片以獲得返現”之類的。

不用太擔心這個階段的測試用例過于“瘋狂”或者不夠完整，畢竟我們對于系統的實現還不是很了解。我們會在接下來的環節中完善具體的步驟。

4. 參與啟動惡意需求的開發（evil story kickoff）

在開發人員開始開發合法用戶需求之前，我們需要跟業務分析人員、開發人員一起溝通需求的內容。在敏捷軟件開發項目中我們叫它story kickoff，即用戶故事啟動。當有了對應的惡意用戶需求時，我們必然也要把它也加到啟動的范圍里。目的是把我們頭腦風暴出來的測試用例跟所有的角色來溝通。預防勝于檢測。

5. 在開發環境驗收惡意需求的實現

100%預防軟件的缺陷與漏洞是不太可能的，所以這個環節的存在是為了提早反饋。

我曾經經歷過一個項目，都快上線了才決定做安全測試，結果測出來的問題之一是用戶會話（user session）不能正確過期的問題，經過一番研究，發現需要對系統設計的架構進行比較大的修改，只能做個臨時的修復讓系統先上線，然后再把系統的架構給改了，重寫這部分功能，重新測試。代價非常高。所以不管是安全測試還是非安全測試，”在開發環境驗收惡意需求的實現“這個步驟都不能缺少。

原文轉自：http://www.infoq.com/cn/articles/to-test-colleagues-let-us-do-a-safety-test