概述：本文主要**消防演習與異常測試之間的聯絡。啥？消防演習和測試還有關係？您別著急，慢慢往下看。
火災，一輩子都不會遇到太多次的場景，但是為什麼還是要做消防演習？因為生命大於天，通過演習帶來的準備可以最大程度的減少**，減少二次傷害，增加應急處理能力。
異常測試，顧名思義，正常情況下不會出現的情況，但是功能場景下沒有問題的系統，在異常情況下表現如何？可不可靠？穩不穩定？這是我們的關注點之一。
異常測試作為軟體質量保障中的一環到底是什麼？是否需要引入？異常測試的邊界在**？這就是本文將要**的話題。
如果說測試是為了發現錯誤而執行程式的過程。那麼異常測試是指人為構造異常場景，驗證系統處理邏輯的過程。
根據墨菲定律，事情如果有變壞的可能,不管這種可能性有多小,它總會發生。假設完全沒有異常發生，那麼我們就不需要做異常測試，但事實是完全沒有異常發生是不可能的，網路，磁碟，記憶體，機器損壞，電路崩潰等等都有可能出現，所以我們需要異常測試。【反證法】
異常測試的目的是為了檢查系統在特殊情況下的表現。異常測試是保障系統穩定性的重要手段。
世上沒有完美的人，也沒有完美的軟體。
我們需要檢驗系統的穩定性，發現可能存在的瓶頸點，並制定完備的應急預案。
其實如同其他型別的測試一樣，是否需要進行異常測試，要看你對這個系統的要求。假設你需要這個系統穩定可靠，甚至能夠從錯誤中恢復，那麼異常測試是用必要的，是衡量系統的重要手段。
雖然錯誤有可能出現在軟體的任何乙個模組，但是我們還是要憑藉歷史資料，推測最有可能出現問題的場景，從而確定異常測試的邊界。邊界意味著工作量，意味著需要人力和時間，我們不可能把異常測試的範圍定義為無窮大，只有在有限集的情況下，工作才有意義。
異常測試的流程和普通測試的流程大同小異。下面具體介紹。
第一，需要了解系統的架構是什麼樣子的，知己知彼，百戰不殆。如果說系統對於測試人員來說是個完全的黑盒子，我的建議是不要去開展異常測試了。
第二，在了解系統基本架構的情況下，劃分初具體的模組，理清系統間的依賴關係
下面這張圖是乙個簡單的架構圖。
還有一張比較通用的架構圖：
第三，設計異常測試用例
如果你沒有頭緒，可以從以下幾個角度進行用例設計，業務角度與系統角度。
業務角度：功能是什麼樣子的
系統角度：
時間，空間，網路
例如 響應時間超時會怎麼樣？http超時，資料庫連線超時等等
儲存滿了系統怎麼樣？
記憶體滿了怎麼樣？
cpu過高怎麼樣？
網路延遲或者寬頻占用盡了怎麼樣？
多問幾個這樣的問題，思考系統應該有什麼樣的表現？
第四，執行異常測試
執行異常測試最主要的過程是構造場景，可以理解為對異常的模擬，觀察被測系統。
第五，分析異常測試
對發現的問題進行記錄，分析，這一步需要有經驗的測試來進行。
第六，做測試分析報告
執行完異常測試可千萬別草草結束，把你的結果展示出來，乙份靠譜的異常測試報告可抵得上千言萬語。
這樣我們就完成了乙個完整的異常測試過程了。通過執行異常測試，測試人員一定會對系統架構有更深入的了解，對軟體穩定性，報警機制等等概念有更好的體會，更重要的是發現潛在問題，讓軟體的質量更上一層樓。
消防演習其實就是一種準備，對未來可能發生的災害，提前做好準備工作，未雨綢繆。
看看這份消防演習報告，是不是有種很熟悉的感覺？簡直就是乙份簡化版的測試報告。有沒有殊途同歸的感覺呢？
當你沒有系統性思維的時候，你發現的問題是乙個個零散的點，是隨機的。當你使用系統性思維去看的時候，你發現的問題是一條條線，最後連成了面。
本文參考自：
網易小敏
考拉技術中心
測試企業安全，網路安全消防演習是否行得通？
我的公司正在考慮開展安全消防演習或者甚至網路戰遊戲來測試我們的資訊保安計畫，這似乎是一項浩大的工程，那麼，網路戰遊戲是否對企業有利？mike o.villegas 測試資訊保安計畫應該是持續進行的工作。例如，在強化裝置後，裝置應該由siem或聯合身份管理工具來監控，當發生任何可能影響企業資訊保安狀態...
軍事演習悖論與思維漏洞
在華裔數學家陶哲軒的部落格中，他討論了乙個問題叫 藍眼睛島難題 感興趣的可以看一下 我認為在藍眼睛島這個問題中，數學歸納法是有侷限性的。並想到另乙個也與資訊處理相關的難題 在第二次世界大戰期間，乙個城市做了乙個宣告 在接下來一周的某一天將進行軍事演習，但為了演習的突發性和真實性，這次演習的日期將不會...
智慧型消防報警定位軟體與消防指揮系統
智慧型消防物聯網雲平台系統依照關於全面推進 智慧型消防 建設的指導意見要求的重點內容，針對消防工作措施要求提供成熟 完善的一套消防解決方案，為城市消防管理部門進行科學管理與執法提供真實有效的依據，為科技強警提供技術保障，實現城市智慧型消防安全管理工作 人防 技防 物防 於一體的應用目標。消防指揮中心...