先貼本文的重點圖：
簡單說吧，你們對設計測試用例有什么看法和新的補充嚒？
測試用例的設計這個問題，現在好多時候我們在面對一個功能，比如說一個幫派列表，問我們自己應該怎么測，怎么測試用例的時候你們怎么想？
直接想到的是：測試點->用例
是的，測試點->用例是傳統的做法。
你們有沒有想過測試點之上其實還能歸類呢？或者說至少在測試點同一等級的概念里應該劃分一些典型類型來進行測試。
還是拿那個幫派列表來說，所謂的幫派列表。
就是一個面板包含所需列舉信息的一個列表。
“我的測試用例都是簡單隨意的。老毛病”這是近來我經常聽到的一句話，測試員A經常嘮叨。
1、界面顯示是否正常，各種瀏覽器、分辨率，文字是否顯示正常
2、這個數據是否和數據庫一致
3、按鈕是否正常使用
4、上一頁下一頁按鈕是否正常，能不能正常翻頁
5、列表標題是否支持排序，排序功能是否正常
就是比較散亂的測試條例，寫得很隨意
所以這是個問題，在我看來，測試點這種東西過于偏重了具體測試環境和測試對象，而這個是容易造成測試人員毫無積累的窘境，或者說我們理解的只是狹義的測試點。
列舉一下，這也是我最早在以前的博文中提到的基礎方法：
傳統做法是這樣分，功能和數據，首先測功能，各個按鈕的功能是否正確，其次看數據。
你們有沒有想過測試點之上其實還能歸類呢？或者說至少在測試點同一等級的概念里應該劃分一些典型類型來進行測試——特別是我們帶新人，或者說跳槽去其他公司再次面試（別說沒有可能），遇到這種幫會列表問題的測試題目時，我們應該怎么去面試回答呢？
測試點之上或者說跟測試點平等的地位，應該還有一種關系我們是忽略了的（至少現在還沒有非常重視），那就是測試類型。
比如：界面測試用例，功能測試用例，大數據測試用例
再比如：正常測試用例，異常測試用例
再比如：異常測試用例里面要有單獨的一類測試用例，專門處理各個測試點里的掉線，頂號登陸，下線，離線，這種情況如果我們只是單純的區分功能和數據，首先測功能，各個按鈕的功能是否正確，其次看數據，這種思路很泛，我的意思是這是大道理，并不能由理論轉化成實際操作，并不能直接由說轉化成如何做，欠缺了些中間的借鑒意義，所以我覺得這方面的話測試類型劃分意義更準確些。
希望對大家有所幫助。
延伸閱讀——《探索式軟件測試》
里面作者在說到測試就用旅游來比喻，他將我們測試的系統分為商業區，娛樂區，破舊區，歷史區等，針對不同的區域有著不同的測試方法，思想就和我上面提到的差不多。
各個區域：商業區，歷史區，旅游區，娛樂區，旅館區，破舊區
商業區測試類型：
指南測試法 要求測試人員通過閱讀用戶手冊并嚴格遵照手冊的建議執行操作。
賣點測試法 找到那些最能賣錢的特性進行測試
地標測試法 先選擇地標，然后在軟件中執行類似于在森林中地標間跳躍的動作
極限測試法 向軟件提出很多難以回答的問題。如何使軟件發揮到最大程度？哪個特性會使軟件運行到其設計極限？哪些輸入和數據會耗費軟件最多的運算能力？哪些輸入可能欺騙它的錯誤檢測例程？如果軟件用于產生某些特定輸出時，使用哪些輸入和內部數據可以不斷挑戰軟件的這種能力？
快遞測試法 專注于數據，確認哪些被存儲起來的輸入數據并“跟隨”它們走遍軟件。
我這里是粘貼了一部分，畢竟那本書提到的測試法很多，有些就像我說的異常測試，和軟件對著干，希望得到更多進步的你可以去看看那本書。
他把我們測試軟件比做去一個城市旅游，于是這個測試又叫做漫游測試。