軟體測試工作中對問題的發現和改進

　　軟體測試並不是一項一成不變的工作，南京達內提醒大家要善於發現軟體測試中存在的一些問題，通過不斷改進的測試方法來讓自己進步。

　　一、軟體測試用例設計的不同維度

　　軟體測試用例設計的時候，可以有不同的維度來考慮。一般來說，是按照開發的流程和資料的準備過程設計的測試用例。由於邏輯較多、資料流較複雜，造成用例圖很大，分支很多。進行case評審，講解的時候比較麻煩。對case進行設計，可以按照使用者的維度或者說是功能的維度進行考慮。例如涉及到欄位邏輯的，列出來有哪些欄位，按照每一個欄位的邏輯來書寫case，這樣講解的時候會比較直觀，同時後續接手的時候看起來也會比較清晰。

　　當邏輯較少時，兩者相差無幾；但是邏輯欄位較多，第二種使用者維度的case設計就有了較大的優勢，直觀，能夠為測試執行提供一個清晰思路，不會漏測，也不會做重複的無用功。

　　二、軟體測試用例的粒度

　　軟體測試用例設計的粒度，是否應該包括測試資料的準備全過程。一個完整的測試用例，是需要包含測試資料的準備過程的。即測試用例圖中，針對每一個功能點，包含完整的資料流，可以完全按照測試用例的分支構造資料，而不需要別的文件輔助。但是這樣會有一個問題，每一個分支只能覆蓋一個功能，也就是說，每一條測試資料，僅能夠覆蓋一個功能的分支，在測試執行方面會比較花時間。尤其是同一條資料，可以驗證多個相似功能點，但由於測試用例設計中將多個相似功能的區分開，執行時需要構造多條資料。測試的時間大部分花在重複構造資料階段了。

　　對於比較複雜的邏輯，在設計軟體測試用例的時候，可以有兩份，一份是很完整的包含測試資料準備的，每一條分支劃分很細緻的用例；另一份是用來測試執行的，將能夠一次覆蓋的多個分支合併到一起的用例，兩個用例圖互相參照。對於測試人員的思維來說，是一個先分再合的過程，先將邏輯拆散，細化到每一個分支，再將相似或者相同的分支合併，這裡面使用了等價類劃分的測試執行方法，即正常用例的時候，一次儘可能多的覆蓋。

　　三、軟體測試用例傳承

　　有的時候看之前wiki的內容，雖然有軟體測試用例圖，但是看不太懂，接手的時候還是需要再問。如果需要線上上對邏輯進行驗證，花的時間很多。從需求設計文件的文字到測試用例的圖形，是有一個歸總的規程。每個人的思維不同，歸納整理的思路也是不同的。以後的業務邏輯整理到wiki的時候，能夠在保留用例圖的同時，將文字的描述也寫進去，同時寫清冒煙的時候該怎麼找驗證。即wiki包含三部分內容，一部分是從資料來源到輸出結果，即需求設計文件描述的，經過軟體測試人員思維整理細化的文字描述；另一部分是從輸出結果反推到資料來源的過程，即根據輸出，追溯到輸入資料，驗證輸出是否是由輸入資料經過規定的邏輯得來的；最後一部分是測試用例圖。這樣後續接手會方便，冒煙的時候哪怕不瞭解這個業務的邏輯，按照wiki手把手的講解，也可以順利驗證問題。

　　發現問題，找出辦法，解決問題，是每一行每一個人想要進步的普遍定律。

本文轉載自51Testing軟體測試網，檢視更多：http://www.51testing.com/html/news.html

[@more@]

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/11323760/viewspace-1059204/，如需轉載，請註明出處，否則將追究法律責任。