入行軟件測試行業2年，從事過自動化的測試和手工的功能測試。兩年來一直沒有總結過自己的工作。每當一聽人問起一個簡單的問題，如何編寫好的測試用例?
如此簡單的問題一問，仔細一想，思緒凌亂無章。這就是沒有好好思考過的原因。
今天在博客總結下自己的看法，如何編寫測試用例：
1、瞭解軟件的原始需求(測試目的)
在編寫一個軟件或者模塊的測試用例時候，一定要明白這個功能的原始需求，也就是軟件的使用者(客戶)的需求。理解原始需求後，編寫的測試用例才更有目的性。
2、熟悉軟件的功能需求(測試點)
這個功能需求是指軟件的細化需求點，這個一般在需求文檔裏面都會體現。這裏要做的是把需求穩定的“粗略”的需求，細化成一個個小需求點。
熟悉功能需求後，要知道軟件是怎麼使用的，這也才能覆蓋到各種操作。
總之，測試用例一定要全部覆蓋所以的需求點，這是最基本的一點。
3、熟悉軟件的實現原理(測試點)
在理解原始需求和軟件的功能需求後，軟件有什麼功能，如何使用就基本上都知道啦。這時候在根據需求編寫測試用例，基本上都能覆蓋的比較全面。
在此基礎上，熟悉軟件的實現原理，理解軟件的內部處理。
(1)熟悉原理的過程是進一步深入熟悉軟件的過程。如果單單是從需求點上面覆蓋案例，測試用例只能覆蓋“表面”的一層。一些內部的處理流程也許沒有覆蓋到，
而這些沒有覆蓋到的代碼很可能就是一個風險點。
(2)熟悉模塊原理後，還有一點就是易於分析軟件模塊的關聯性。一個大型的軟件，都是一些小模塊的組合而成。軟件越是大型，耦合就越大。“互相影響”就會越多，
設計用例單單是從模塊本身考慮的話，很可能就會對其他模塊造成風險。
4、用戶場景和網上問題(測試點)
從用戶的使用場景考慮，這些在一些網絡設備比較重要。比如軟件後期在一些真實的使用環境中使用。
還要就是從一些網上問題總結出來的，那些地方容易出錯。在設計案例的時候需要考慮進去
5、測試用例的框架
我覺得一個測試用例的框架體現了一個測試人員在設計測試用例的整體思路。框架也是從大到小劃分下來，可以是：
UI界面，功能，容錯，兼容，性能等幾大類，每個大類在根據軟件的邏輯等進行劃分成小類，最後細分到測試點。
6、測試步驟(測試技巧方法)
前面4點都是從測試點的角度考慮，測試用例在完成測試點外，下來就是測試步驟和測試結果啦。
測試用例可以寫的很詳細，也可以寫的比較簡單。看公司的要求，有些公司要去測試步驟很細很細，包括測試結果和測試步驟一一對應。
我個人不太認同這種做法，測試用例最重要的我認爲是測試點。只要理解了測試目的後，下來的就是測試人員的執行工作啦。如果對一些非常嫺熟的測試人員，他們一般
看測試用例的標題就是知道你測試目的了，具體的操作就是根據他們的測試方法進行測試。如果測試步驟寫的很詳細的話，一會很耗時間。你要考慮到文字語音的描述，以及一些前置步驟的操作，這也會導致案例有時候像個文章，而且過於詳細的會限制執行人員的思維。
要求測試步驟寫的很詳細的公司，一般是怕執行人員的執行力不到位，導致沒有理解案例的目的，導致漏測。一般出現在新員工對軟件系統的不熟悉。
7、測試用例的一些思路
在設計案例中，我用的最多的是邊界值，等價類，正常和異常的測試。下面是我想到的幾個方面：(結合一些網上文章的觀點)
一)從單個模塊或者單個功能點考慮
(1)UI界面(易用性，提示信息，整體佈局，色彩，中英文標點錯別字)
(2)數據的多樣性
有效數據
合法的無效數據(邊界值)
非法和異常數據
各種數據的組合
(3)操作多樣性
添加刪除編輯查詢
多用戶的操作
(4)容量測試
(5)用戶權限(使用權限)
(6)升級安裝卸載(平滑升級)
(7)日誌相關(包括調試日誌)#p#分頁標題#e#
(8)軟件功能的邏輯劃分
功能上劃分未能覆蓋的代碼邏輯，可以添加白盒灰盒用例;
(9)關聯的功能
設計關聯的測試的用例
(10)可靠性，容錯性
(11)兼容性(瀏覽器，系統)
(12)安全性
(13)性能(這裏的性能是指，單個模塊或者子系統的性能)
總之
測試用例首先要能覆蓋所有功能需求點，然後搞懂軟件處理邏輯，可以找開發一起看測試用例，把沒有覆蓋到的代碼流程相應的補充用例。用例覆蓋到這2點基本不會出現基本功能的問題。
在此基礎上，可以進行一些可靠性，容錯性，兼容性等用例的設計，測試下軟件的穩定性。