衆所周知，系統測試是需要編寫測試用例的，它是保證測試執行正确性、有效性的基礎。但是，大家可能很難想象神秘的黑客在挖掘漏洞的時候會提前編寫測試用例，然後按照用例去執行。因為他的漏洞挖掘思路是存在腦海中，并且不斷的根據實際情況進行調整的。

當然，關于黑客單打獨鬥挖掘漏洞的這種想象，顯然已不大符合當前安全界的實際情況。從網絡及信息安全的攻擊角度來說，惡意攻擊分子已經逐漸形成了目标精準、分工明确、技術先進的網絡黑色産業鍊條，相應的從安全保護和防禦角度來說，國家加大了對網絡攻擊等犯罪行為的打擊力度，企業也逐漸加大了網絡安全投入。

那麼，當安全測試成為企業安全建設中的一個重要環節，安全測試需要寫測試用例麼？

要解決安全測試是否需要編寫測試用例的問題，需要先理清安全測試的目的。

當前業界對于安全測試并沒有特别權威的定義。"安全測試是在IT軟件産品的生命周期中，特别是産品開發基本完成到發布階段，對産品進行檢驗以驗證産品符合安全需求定義和安全質量标準的過程。"這個定義雖然有一定的局限性，但是定義相對清晰，安全測試的目的就是進行安全的度量和盡量在發布前找到盡可能多的安全問題并進行修複從而提升産品的安全質量。

那麼，基于度量的目的就引申出兩個問題：

· 一是如何度量，度量是需要标準的，不管是對于産品安全性的度量，還是安全測試效果的度量；

· 二是各企業的安全測試團隊普遍偏年輕，假如安全測試僅依據個人經驗，效果各一，如何達到在發布前找到盡可能多的安全問題的目标。

此時就需要一個既可以作為安全測試執行的指南，又能依據執行結果進行産品安全度量的文檔。安全測試用例正好符合這個要求。需要說明的是，此處提到的安全測試不含使用漏洞掃描工具進行的純自動化掃描。

從表現形式上看，安全測試用例和系統測試用例類似，也需要有測試用例編号、測試用例名稱、測試目的、測試前置條件、測試步驟、預期結果等要素，以便于安全測試人員在看到測試用例就可以清楚的知道要測什麼，怎麼測，如何判斷是否存在漏洞。這樣就可以達到指導安全測試執行的目的。

從測試用例設計方法的角度，系統測試用例設計的方法諸如等價類劃分、邊界值、場景法等并不适用于安全測試用例設計。目前業界較常用的可借鑒的方法有微軟的STRIDE威脅建模方法、基于攻擊圖的分析設計方法等。一種比較實用的方法是從漏洞的維度進行設計，分析彙總歸納常見漏洞，可以參考OWASP的測試指南，整理成測試的checklist（圖1），然後将checklist轉化成測試用例（圖2）。

圖1：checklist樣例

圖2 安全測試用例樣例

從度量的角度來說，通過執行安全測試用例，記錄執行結果，以及進行發現的安全漏洞的管理，可以從測試的進度、安全漏洞的密度等多個維度進行安全度量。

· 測試用例執行的進度=已執行的用例數/總用例數

· 測試用例執行通過的情況=執行通過的用例數/總用例數

· 剩餘漏洞數=發現的漏洞總數-已解決漏洞數

· 漏洞的存活時間=漏洞從提交到結束的時間間隔

· 漏洞密度=漏洞總數/被測系統總功能點數

綜上所述，當安全測試作為企業中一個保障産品安全質量的常規環節時，從流程的規範化和實施的規範化角度來說，是有必要編寫安全測試用例的。安全測試用例可以提供一份安全測試執行的标準化的指南，從而可以結合産品的其他因素進行安全的度量。

但是，如果安全測試僅依賴于安全測試用例則仍然存在一定的局限性，比如不同的産品或者系統由于其應用場景不同，功能不同，系統架構不同等，可能存在的安全風險也是不同的，在測試用例編寫的時候無法考慮到所有的風險，覆蓋到所有測試要點。所以在實際的安全測試過程中，規範的測試用例為指南也需要和人的主觀能動性相結合。

IT工作是辛苦的，軟件測試當然也不例外。每天執行用例、跟蹤Bug，還要與開發、産品同學争吵PK，與人鬥其樂無窮~

但正是因為這些默默的付出，你讓一場本該在用戶面前發生的災難，提前在自己面前發生了，你是否有一種救世主的感覺？

你拯救了用戶，也拯救了這一軟件，避免了她被撇棄、卸載的命運。既然選擇了測試這一行，何不一站到底~~

現在我邀請你進入我們的軟件測試學習交流群，關注 私信我“測試”，即可拉你入群喲~~

大家可以一起探讨交流軟件測試，共同學習軟件測試技術、面試等軟件測試方方面面，還會有免費直播課，收獲更多測試技巧，我們一起進階Python自動化測試/測試開發，走向高薪之路。

那我邀你進群吧！記得：關注 私信我“測試”，即可拉你入群喲 免費送你軟件測試學習資料包！