中關于測試用例改進問題

第第頁中關于測試用例改進問題中關于測試用例改進問題

發(fā)表于：2023-09-16來源：：點擊數(shù)：標簽：改進

目前我們設計的測試用例只是表面上的呈現(xiàn)，對測試指導的作用不是很大，我們思想里也認為測試用例編寫只是在熟悉系統(tǒng)的過程，在測試時測試用例會被我們撇在一邊。個人總結一下原因和改進方法：1.沒有合適的規(guī)范：大家都是來自不通的公司，在編寫測試用例

目前我們設計的測試用例只是表面上的呈現(xiàn)，對測試指導的作用不是很大，我們思想里也認為測試用例編寫只是在熟悉系統(tǒng)的過程，在測試時測試用例會被我們撇在一邊。個人總結一下原因和改進方法：

1.沒有合適的規(guī)范：

大家都是來自不通的公司，在編寫測試用例時可能會帶著以前的習慣，我們也沒有在現(xiàn)在的項目中找到明確且合適的規(guī)范，于是只是根據(jù)自己以前的經(jīng)驗復制，但這些有時候并不適合我們目前的項目。比如在測試UUM時，個人自己就犯著以前不好的測試思維和習慣。

改進方法：

指定合理的規(guī)范，統(tǒng)一大家思維，有待討論。

2.功能與業(yè)務分離：

這個是在測試ES-iVision存在的問題，在測試系統(tǒng)時可能只關注了功能而沒有整體業(yè)務的把握測試，只注重了某個功能表單上單一的測試，而整個業(yè)務可能才是我們測試的重點。

改進方法：

功能用例和業(yè)務用例分開組織編寫。A）功能用例依據(jù)需求界面描述，根據(jù)等價類、邊界值、錯誤推斷編寫，必要時建立數(shù)據(jù)庫，存放測試數(shù)據(jù)，而這些測試用例都與業(yè)務無關。并且可以利用資源找到相關的測試用例，來補充我們設計的不足。B）業(yè)務測試用例關注的是表單的執(zhí)行路徑，執(zhí)行后在系統(tǒng)上產(chǎn)生的一系列反應。這個可依據(jù)需求在開發(fā)前或與開發(fā)同時進行。但此業(yè)務功能必須是開發(fā)確認正確的。

PS:以前我們在業(yè)務這塊有場景測試用例。如發(fā)文流程中有多流程時，分場景測試流程。

3.測試跟不上變化：

開發(fā)人員在開發(fā)時可能會對需求進行調整，這個問題是在測試UUM時系統(tǒng)管理角色需求就進行調整，所以我們被動的只能跑在開發(fā)的后面，我們也做了許多不必要的工作。

改進方法：

有問題及時與開發(fā)討論，走在開發(fā)前面調整我們測試用例，測試進度。

4.發(fā)布前輪詢很多版本：

某一產(chǎn)品在經(jīng)過幾輪測試后，在發(fā)布前可能會為一兩個bug要輪詢很多版本，在輪詢時測試人員不可能再把所有功能、業(yè)務全部再過一遍，但是我們此時會對發(fā)布版本沒有信心，而再走一遍浪費時間精力。

改進方法：

用用例標明測試優(yōu)先級。這個是在oa1.9中用到的，但可能在后期執(zhí)行時沒有執(zhí)行。所有在編寫測試用時標示優(yōu)先級，把系統(tǒng)的重點劃分出來，在發(fā)布前多次輪詢版本中只要檢查優(yōu)先級高的就可。

5.用例審核力度不夠：

編寫的測試用例無人評審，這也是我們在編寫測試用例的隨意性、懶惰性滋生，草草了事，沒有覆蓋全部功能點、業(yè)務點。導致產(chǎn)品在發(fā)布后存在意想不到的缺陷。

改進方法：

測試用例編寫完成后增強評審，先是小組里討論，然后再外部評審。

6.易忽略問題：

在執(zhí)行設計測試用例執(zhí)行測試，我們可能