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

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

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

更新:我的同事Scott

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

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

謝謝Scott。

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

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

錯(cuò)了!

讓我們回到正題。

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

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

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

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

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

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

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

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

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

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

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

測(cè)試用例自身也存在一些缺陷。

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

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