一、什麼是測試用例?
測試用例是爲某個特殊目標而編制的一組測試輸入、執行條件以及預期結果,以便測試某個程序路徑或覈實是否滿足某個特定需求。
通俗的講:就是把我們測試系統的操作步驟用按照一定的格式用文字描述出來。
二、寫測試用例有什麼好處?
理清思路,避免遺漏
這裏是我們認爲最重要的一點,假如我們測試的項目大而複雜,我們可以把項目功能細分,根據每一個功能通過編寫用例的方式來整理我們測試系統的思路,避免遺漏掉要測試的功能點。
跟蹤測試進展
通過編寫測試用例,執行測試用例,我們可以很清楚的知道我們的測試進度。
歷史參考
在我們所做的項目中,也許會有很多功能是相同或相近的,我們對這類功能設計了測試用例,便於以後我們遇到類似功能的時候可以做參考依據。
重複性
我們測試一個系統不是一個人測一遍就算測完的,需要多人反覆的進行測試,那麼我們就需要測試用例來規範和指導我們的測試行爲。
告訴領導,這事俺幹過,不然別人怎麼知道你測沒測,測的全面不全面,拿測試用例給他們看唄!俺就是照着這個幹活,呵呵!
三、測試用例的方法
好吧,咱知道啥是測試用例了,也是知道爲什麼要寫測試用例了,那到底應該怎麼寫?無從下手啊。我們在寫測試用例之前,先學習幾種方法,它是我們寫測試用例的指導思想。
1. 等價類劃分
在某個輸入域的子集合,在該子集合中,各個輸入數據對於揭露程序中的錯誤都是等價的。假如有一個輸入框要求輸入1-10000個數,我們不可能用每一個數去試,我們輸入5 和輸入6去驗證和揭露輸入框的錯誤可以看做是等價的。那麼這個時候我們就可以隨機的抽取一些數據來進行驗證。如:10 、99、7777......
等價類分:有效等價類和無效等價類
輸入框要求輸入1-10000的數
有效等價類:可以輸入1-10000之間的數來驗證,如:2、5、99、8495......
無效等價類:可以輸入1-10000之外的任意字符驗證,如:20000、字母、下劃線、特殊符號、空格、回車.....
2. 邊界值
邊界值是對等價類的補充,測試工作經驗告訴我們,大量的錯誤是出在輸入輸出的邊界價上。我們還拿上面的例子,一個輸入框要求輸入1-10000之間的數。我們要測它有沒有超出這個範圍,如:0、-1、-2、1000、10001.....等等,來判定是否超出了我們的範圍。
3. 因果圖
因果圖方法最終生成的就是判定表,它適合於檢查程序輸入條件的各種組合情況。舉個例子:原因:A=0,B=0,結果我就可以判定:A=B。確切的說他是一種因果關係思想。它會無形中指導這我們的測試。當然了,我們爲了以免遺漏,可以把系統中的因果關係用圖畫出。不過系統大而複雜的話就是個體力活了。呵呵。
4. 錯誤推測法
基於經驗和直覺推測出系統可能存在的錯誤,從而有針對性的設計測試用例的方法。
5. 其它
設計測試用例的方法有很多,我們常用就上面幾種,其它的方法還有:狀態遷移圖、流程分析法、正交驗證法等等。
四、測試用例的格式與要素
一個測試用例應該包括:編號,標題,測試場景,測試步驟,預期結果。
當然還可加入一些它選項,如:優先級、測試階段....
------------------------------------我們還需要知道的,關於測試用例的-------------------------------
一、.我們在什麼時候可以設計測試用例?
當根據客戶的需求整理出項目需求分析文檔時,我們就可以根據需求文檔來編寫測試用例了。但是,一般我們(國內大多小公司)項目需求文檔都非常“簡陋”,所以,很難根據需求文檔設計測試用例。
我們只有等到項目開發人員把項目開發出來,給我們系統文檔、部署環境、數據庫結構(如果系統牽涉到數據庫的話),我們根絕這些文檔來設計測試用例。
二、測試用例的評審與更新
我們設計的測試用例設計完成之後,是否完整?是否符合系統?符合客戶要求?對用例做一個評審是必不可少。關於評審的方式,不同的公司有不同的流程。
我們編寫的測試用例也不是經過評審之後就不變了,隨着需求的變更、功能的改進,測試用例當然也需要更新和變動。
三、什麼情況下不適合寫測試用例
文件時間
如果一個功能我很快就測試完了,而且只需要測試一遍,但我們設計測試用例時卻比較麻煩,花時間也長。這個時候就沒必要編寫測試用例了。
需求變動大且頻繁
需求的功能變動非常頻繁,而且變動很大,之前編寫的測試用例根本沒法使用,必須要重新編寫,這個時候也沒必要去設計測試用例了。
項目時間不允許
這一項是不太厚道的做法,如果不是急需交付客戶的話,儘量不要這樣做;當然了,如果只是給客戶展示或試用,可以在之後進行補充和完善測試用例。
不要編寫不完整或別人看不懂的測試用例,那樣就沒有意義了。
============個人閒聊內容,歡迎指正========
四、停止軟件測試的標準。
語句覆蓋最低不能小於80%,測試需求覆蓋率達到100%,測試用例覆蓋率達到100%,一、二級缺陷修復率達到100%,三、四級修復率達到80%。
(上面一句是再網上找的,不是標準,只是個參考)
bug等級:
一級:非常嚴重的bug
二級:嚴重的bug
三級:一般性的bug
四級:建議性問題
五、關於探索性測試
完全的執行測試用例時一件非常枯燥的事情,個人在執行測試用例時會做一些,其它的非常規性的操作,看系統是否會有相應的處理和提示。我的一部分bug就是再這種非常規操作下發現的。
當然了真正的探索性測試需要對產品的深入瞭解,以及軟件開發技術有一定的深度和寬度。姑且把我們的探索性測試看成是瞎搗鼓吧!呵呵。
六、 交叉測試
有木有發現,當我們第一遍測試系統時,會非常認真,但要我們測試第二遍時,我們不願意像第一次那樣認真的去測了,這不能說明我們不負責,而是每個人都有的心理現象。這個時候,我們可以和其它測試人員交換功能來測試,提高效率,而且更容易發現問題。
七、測試的目的
1. 我們讓它做的它必須會做。
2. 我們不讓它做的它必須不會做。
可能你會發現有附加功能的時候,就是客戶沒有要求,我們加了這樣的功能,可能加了這點功能系統看上去會更好。這時怎麼辦?算問題麼?
作爲開發人員,中規中矩的做東西最好,如果真的有非常好的功能要加的話,需要和客戶溝通,然後寫到需求裏。畢竟多一點功能多一點風險。呵呵
作爲測試人員,凡是不符合需求文檔的都需要當問題點提出。責任分明,以免後續麻煩。
----------------------------------------------------
修改:
1.測試用例的格式的要素,去掉“實際結果”
2.關於測試方法“等價類劃分”的解釋。
------------------------------------我們還需要知道的,關於測試用例的-------------------------------
一、.我們在什麼時候可以設計測試用例?
當根據客戶的需求整理出項目需求分析文檔時,我們就可以根據需求文檔來編寫測試用例了。但是,一般我們(國內大多小公司)項目需求文檔都非常“簡陋”,所以,很難根據需求文檔設計測試用例。
我們只有等到項目開發人員把項目開發出來,給我們系統文檔、部署環境、數據庫結構(如果系統牽涉到數據庫的話),我們根絕這些文檔來設計測試用例。
二、測試用例的評審與更新
我們設計的測試用例設計完成之後,是否完整?是否符合系統?符合客戶要求?對用例做一個評審是必不可少。關於評審的方式,不同的公司有不同的流程。
我們編寫的測試用例也不是經過評審之後就不變了,隨着需求的變更、功能的改進,測試用例當然也需要更新和變動。
三、什麼情況下不適合寫測試用例
文件時間
如果一個功能我很快就測試完了,而且只需要測試一遍,但我們設計測試用例時卻比較麻煩,花時間也長。這個時候就沒必要編寫測試用例了。
需求變動大且頻繁
需求的功能變動非常頻繁,而且變動很大,之前編寫的測試用例根本沒法使用,必須要重新編寫,這個時候也沒必要去設計測試用例了。
項目時間不允許
這一項是不太厚道的做法,如果不是急需交付客戶的話,儘量不要這樣做;當然了,如果只是給客戶展示或試用,可以在之後進行補充和完善測試用例。
不要編寫不完整或別人看不懂的測試用例,那樣就沒有意義了。
============個人閒聊內容,歡迎指正========
四、停止軟件測試的標準。
語句覆蓋最低不能小於80%,測試需求覆蓋率達到100%,測試用例覆蓋率達到100%,一、二級缺陷修復率達到100%,三、四級修復率達到80%。
(上面一句是再網上找的,不是標準,只是個參考)
bug等級:
一級:非常嚴重的bug
二級:嚴重的bug
三級:一般性的bug
四級:建議性問題
五、關於探索性測試
完全的執行測試用例時一件非常枯燥的事情,個人在執行測試用例時會做一些,其它的非常規性的操作,看系統是否會有相應的處理和提示。我的一部分bug就是再這種非常規操作下發現的。
當然了真正的探索性測試需要對產品的深入瞭解,以及軟件開發技術有一定的深度和寬度。姑且把我們的探索性測試看成是瞎搗鼓吧!呵呵。
六、 交叉測試
有木有發現,當我們第一遍測試系統時,會非常認真,但要我們測試第二遍時,我們不願意像第一次那樣認真的去測了,這不能說明我們不負責,而是每個人都有的心理現象。這個時候,我們可以和其它測試人員交換功能來測試,提高效率,而且更容易發現問題。
七、測試的目的
1. 我們讓它做的它必須會做。
2. 我們不讓它做的它必須不會做。
可能你會發現有附加功能的時候,就是客戶沒有要求,我們加了這樣的功能,可能加了這點功能系統看上去會更好。這時怎麼辦?算問題麼?
作爲開發人員,中規中矩的做東西最好,如果真的有非常好的功能要加的話,需要和客戶溝通,然後寫到需求裏。畢竟多一點功能多一點風險。呵呵
作爲測試人員,凡是不符合需求文檔的都需要當問題點提出。責任分明,以免後續麻煩。