墨菲定律是這樣一條定律，Anything that can go wrong will go wrong。
引申到軟件開發行業，不測試的代碼就會出錯。
假設屏幕上有一個需要輸入電子郵件地址的文本框，是否需要測試它，如何測試它？很多人告訴我，上網搜一個正則表達式就可以了。
在回答這個問題之前，我先說個我的親身經歷，我用我的一個郵箱注冊某個網站，而我的郵箱恰好是@之前有兩個.的，結果，注冊時那個網站提示我，請輸入正確的郵件地址。很顯然，這種情況沒有被測試過。
那么我們回到測試電子郵件地址這個話題，究竟要測試多復雜的地址組合才能夠放心呢？
我們上網來搜一個正則表達式吧，看看效果如何。
^\w+[-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*$
這個據說還是最佳答案。我們來測試一下它如何？
比如:
a_____186@163.com
會不會通過上述校驗呢？答案是不會。而它確實是一個合格的郵箱地址。
所以，網上搜索的正則表達式有多不靠譜可以看到了。
附帶一個測試用例集合給給大家一個參考。
正如開頭所說，可能出錯的事情就會出錯。
所以，不測試如何能夠放心呢？
那么如何才能夠最初令自己放心的測試呢。比如，頁面有三個文本框每個文本框有三種校驗，分別是，必須輸入，長度限制和格式要求，那么加在一起一共是多少種組合的測試呢？
如果你想測試三個文本框（A B C），三種測試（1 2 3），那么分開測試，每種情況至少運行一次，只要有3種測試應該就夠了。這種把各種指令都要運行一遍的覆蓋方式叫做指令覆蓋。*注：是否指令覆蓋其實嚴重依賴于代碼的書寫方式。這里的舉例主要是為了說明各種分析對于測試覆蓋率的不同影響。
A 1
B 2
C 3
但是很顯然這種測試是不充分的。那么繼續，可以擴展為9種組合。這種把各個分支都運行一遍的方式叫做分支覆蓋。
A 1 2 3
B 1 2 3
C 1 2 3
但是這就夠了嗎？并不是，往下延展當控件的輸入違背了校驗的時候，需要提示錯誤消息，為了提升用戶體驗，要將每個控件的第一個錯誤都要打印到屏幕上，那么組合的可能性就多起來了。而不僅僅是這么幾個。具體數字有興趣的同學可以自己計算一下。這種把從一點到另一點的各種可能的路徑都覆蓋的方式叫做路徑覆蓋。
而這樣的測試組合就顯得數量很多了，一想到一個大的系統有若干的界面，界面的控件數量遠超過3個，驗證組合也非常多，測試工作量豈不是大的驚人？
等價測試用例是一種用來簡化測試的手法，即對于等價的東西沒有必要反復測試。但是這個建立的前提是代碼上那些邏輯等價的東西也是等價的。如果代碼上不是等價的，那么劃分等價測試用例的方法就是一個有嚴重危害錯誤。所以劃分等價類之前最好了解一下對應的代碼是怎么寫的。
舉個簡單的例子如果代碼無法滿足 f(n), f(n+1)的等價那么就要全部測試所有的組合。舉例來說，如果上述三個文本框的這種組合測試條件的兩個文本框出錯和三個文本框同時出錯這兩個條件出現的結果不一致，那就表示代碼本身的邏輯復雜度超過了本身業務復雜度的要求（總會有程序員能想辦法寫出這樣的代碼，尤其是初級程序員）。遇到這種情況，全部測試各種可能的組合才是最安全的。
有效等價類劃分，比如，有個固定的翻頁控件，代碼結構清晰，全部采用的是除法計算頁數的，每頁顯示15條數據，那么16條和17條是等價的。不必把所有的條數全部測試。
無效等價類劃分，比如，北京管理員和上海管理員在同一個系統中，盡管處理邏輯可能完全相同。但是由于代碼書寫的時候采用了較為復雜的結構，北京管理員角色id=1，上海管理員的角色id=2，而在計算的時候使用了同一個變量做了不同的意思，恰好某個邏輯下把角色id賦值給了另外一個變量，那么這個代碼就使得這兩個同為區域管理員的情況，使用效果卻不同。
簡單的說，是否是等價類是由代碼決定的，而不是業務邏輯決定的。而如果作為測試人員你無法評估代碼是否具備等價特征，那么最好的辦法就是全部測試。因為：不測試的代碼就會出錯。
Web頁面有個性別的下拉框，是否需要測試request接收后是否做了數據范圍驗證？
屏幕都已經做了限制了，用戶只能選擇“男”或者“女”，所以沒有什么特別的了吧？相信很多人都會這么想。
可是，訪問網站的并不只有瀏覽器，HttpClient這個類也可以訪問后臺，Postman這個工具也可以訪問后臺，甚至可以寫一個自己的html來提交表單，它們是不受限制的。所以，在這種情況下，性別可以輸入的內容就沒有限制了。那么，如果輸入的是</option>會發生什么后果呢，不同的系統反應也會不一樣，試試看，也許會有驚喜。如果輸入的是;select version() 試試呢。
記住“不測試的代碼就會出錯”就更容易發現問題所在。
那么是否一定要追求測試覆蓋率100%呢？
并不是。
首先要知道測試覆蓋率是個什么東西。目前能夠度量測試覆蓋率的工具都是度量“指令覆蓋率”的。所以首先要知道即使測試覆蓋率達到了100%也不說明測試就很充分。
其次，有些代碼很難構建測試。比如，某些Exception的發生條件。所以不要追求100%這個數字，而要關注更有意義的指標。到底測試有多充分。
至于一些看似簡單的功能，千萬請不要掉以輕心，一不小心就會漏測。嘗試反復登錄系統的那個不一定是人類，也可能是段代碼。你登錄頁面就不能是個簡單用戶名密碼驗證功能。同樣的嘗試注冊的也不一定就是人類。而頻繁使用同一個IP地址訪問的可能就是用一個局域網下的用戶（往往是同一個單位的人）。
操作者的操作方式也不是單一的，而是各種可能會更靈活的可能性。比如：操作者往回按瀏覽器的回退按鈕，再繼續操作；從收藏夾訪問然后操作；直接復制url地址；
多種瀏覽器、多種不同尺寸的屏幕、多種操作系統都是發現問題的好地方。
打開瀏覽器的開發者窗口，直接修改Html，書寫javascript的用戶；采用wireshark抓包改包的用戶；自己寫個客戶端訪問的用戶；采用爬蟲訪問網絡的用戶；直接寫個iFrame把你的網站套在Ta的網站上顯示的用戶；寫個<img src>引用你的圖片資源的用戶；手機訪問的用戶；低速不穩定網絡訪問的用戶；
你能夠模擬的越多，你能夠防御的也就越多。
想想看，雖然你不打算支持IE6，但是如果有個用戶真的用IE6來訪問你的網站會如何？
