傳統(tǒng)上,我們作為測試人員，被教導要根據(jù)功能features編寫測試計劃，以及那些測試計劃。都慢慢轉(zhuǎn)換成了測試用例。

這種感覺就是,不管是管理者還是一般人在測試的時候就覺得,一個功能一個測試用例是好的,兩個測試用例是更好,和三個就更加好了....這樣如此類推。

隨著時間的推移，我們嘗試執(zhí)行了多個項目以及多個功能，所以我們慢慢收集到一定量的測試用例，就像松鼠在寒冬前收集好堅果一樣。

更新:我的同事Scott

Stanton是Electric-Cloud方面的主架構(gòu)師，他指出(完全正確的),測試和單元測試確實需要有一個區(qū)分了。

“…當重構(gòu)代碼時，大的單元測試集合就顯得有很大價值……”

謝謝Scott。

現(xiàn)在問題就在于，一旦我們吃了我們的堅果(即執(zhí)行測試用例)，測試用例不會消失。

現(xiàn)在你在想：“吃掉餡餅然后保留它!”

錯了!

讓我們回到正題。

當我們使用敏捷和使用敏捷測試時，我們需要保持靈活,我們需要能夠在第一天開始做測試時，我們的團隊就開始沖刺工作(“測試不僅僅是運行軟件”)。

這意味著提出問題,與人交談(開發(fā)人員、PO，有時甚至是客戶)。

如果我們背負我們需要連續(xù)運行的大量庫存的測試用例的重擔,那么我們就需要放慢速度。

在某個時候,我們盡了很大的努力生產(chǎn)這些測試用例,有時候時間也可以花在在一些選擇性活動上。

隨著產(chǎn)品的發(fā)展，需要有人要來維護這些用例,并讓我們不要忘記執(zhí)行這些用例腳本(哪怕是完全相同的輸入)時所付出的努力。

這時候你可能會說，這是沒有問題的，那是因為你沒有實際運行所有的測試用例。

那么，他們到底是在做些什么呢?

這其中有一個因素，就是僅僅通過大量的測試用例可能會讓他們很難找到他們正在尋找的信息。如果你是這家公司正在試圖遵循這種方式的測試新人，這就尤其準確了。

我之前引用到的“很難找到缺陷”,當我引用這句話時,我指的并不是我們要發(fā)現(xiàn)正在測試的產(chǎn)品的缺陷。

我指的是它很難在測試用例的前提下，找到缺陷。

如果你甚至都無法oversee，你打算怎樣才能夠跟得上維護你的測試用例呢?

測試用例自身也存在一些缺陷。

請聯(lián)系網(wǎng)站客服，了解詳細的優(yōu)惠課程信息~

優(yōu)質(zhì)、權(quán)威、便捷、省心