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

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

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

更新:我的同事Scott

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

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

謝謝Scott。

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

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

錯(cuò)了!

讓我們回到正題。

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

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

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

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

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

這時(shí)候你可能會(huì)說，這是沒有問題的，那是因?yàn)槟銢]有實(shí)際運(yùn)行所有的測試用例。

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

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

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

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

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

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

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

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