你不知道的用例編寫方法
作爲一名測試人員，總會有需要進行用例編寫的時候，在進行用例編寫時都遇到過什麼問題呢？
小編詢問了一些測試人員，結合自己遇到的問題，總結了一些，一般會有以下幾個方面的問題：
1） 不知如何着手進行，千頭萬緒，不知如何理
2） 用例覆蓋度不高，不知該如何提高
3） 培訓機構學來的知識不知道如何使用
4） 用例結構不清晰，容易遺漏，且維護麻煩
這些問題都是作爲一名測試人員，在工作中會遇到的實際問題，解決的方法千千萬，搜狗輸入法的測試團隊是如何解決的呢？下面我們一起來看一下~
搜狗輸入法團隊的用例編寫可以用兩個字來概括：拆、找，主要步驟如下：
1） 將測試對象進行拆分，直到拆分爲原子對象
2） 分析原子對象，找出該對象所有的檢查點
3） 分析檢查點，找出會影響該檢查點的所有因素
這種方法產出的用例，分爲4級：對象→原子對象→檢查點→影響因素
下面我們來詳細分析看一下~
首先，拿到一個功能的需求文檔後，將這個功能當作一個大的測試對象，分析需求文檔，根據自己的理解進行拆塊，將一個大需求拆解開來，分成小塊，即將大的測試對象拆分爲一個個小的子測試對象。
一個榴蓮，無處下嘴，怎麼辦呢？我想大家的反應應該都是一樣的：鄙視的瞧着小編說，把榴蓮打開，分成一塊一塊的，不就可以了嗎？這麼簡單的問題還要問，╭∩╮(︶︿︶)╭∩╮。其實小編覺得，一個完整的需求就是整個的榴蓮，都需要將之進行拆解，然後才能進行下一步的動作。
測試對象拆分爲子測試對象後，如果還是覺得太大，不好分析，就繼續進行拆分，拆分爲原子測試對象。分析一個簡單的原子測試對象，你會覺得，原來真的這麼簡單啊，:-D
什麼是原子測試對象呢？字面上來看，就是無法再繼續拆分的測試對象，再進行拆分的話，就不是一個完整的對象了。
其次，拆分爲原子測試對象後，分析原子測試對象，找出該原子對象的所有檢查點，這一步就完成了。
有人會問了，什麼是檢查點呢？小編理解檢查點就是被測試對象的某一個屬性。如被測對象是按鈕，我們要檢查的不是按鈕本身，而是按鈕的某一屬性，如按鈕的顯示狀態，按鈕的位置，按鈕的顏色等
然後，再分析檢查點，找出所有會影響該檢查點的因素。如檢查點是按鈕的顯示狀態，什麼會影響按鈕的狀態呢？鼠標hover，鼠標點擊，初始狀態，當前窗口是否是焦點窗口等
分析到這裏，這個功能就被我們分析完了，剩下的就是整理，用例的骨架——大綱就完成了，剩下的就是體力活，給用例增加血肉——用例內容
小編寫到這裏，忽然覺得寫用例跟畫畫很像呢，先分大塊，再分小塊，然後畫架構，最後填色成形~
測試用例設計策略
一方面：
2、在任何情況下，都必須使用邊界值分析法。經驗表明，用這種方法設計出的測試用例發現程序錯誤的的能力最強。
3、可以使用錯誤推測法追加一些測試用例，這需要依靠測試工程師的智慧和經驗。
4、對照程序邏輯，檢查已設計出的測試用例的邏輯覆蓋程度。如果沒有達到要求的覆蓋標準，應當再補充足夠的測試用例。
5、如果程序的功能說明中含有輸入條件的組合情況，則一開始就可以選用因果圖法和判定表驅動法。
6、對於參數配置類的軟件，要用正交試驗法選擇較少的組合方式達到最佳效果。
7、利用功能圖法，我們可以通過不同時期條件的有效性設計不同的測試數據。
8、對於業務流清晰的系統，可以利用場景法貫穿整個測試案例設計過程，在案例中綜合使用各種測試方法。
另一方面：
1、站在用戶的角度,優先使用場景法
2、任何情況下都必須使用邊界值分析,因爲它發現程序錯誤的能力最強
3、用等價類劃分方法減少用例數
4、使用錯誤推測法追加測試用例
5、多條件組合輸入,建議使用正交實驗法或決策表
6、複雜的業務流程,可以結合業務流程圖和狀態轉移法設計用例
7、檢查程序邏輯,可以使用邏輯覆蓋法
8、探索性測試
