不管在傳統(tǒng)軟件公司還是互聯(lián)網(wǎng)公司，測試用例的設(shè)計(jì)和編寫一直是測試人員一個(gè)非常重要的基本工作。 但是在是否需要編寫測試用例和編寫測試用例粒度問題一直有著爭論和探討。

在聊測試用例是否需要編寫時(shí)，我們先聊聊大多互聯(lián)網(wǎng)公司的研發(fā)流程，基本上簡單說就是：產(chǎn)品經(jīng)理編寫需求=>產(chǎn)品、研發(fā)、測試等進(jìn)行需求評審=>開發(fā)設(shè)計(jì)，編碼，同時(shí)測試編寫用例并評審=>開發(fā)提交測試=>測試執(zhí)行測試=>產(chǎn)品發(fā)布。 這是個(gè)大體的流程，當(dāng)然每個(gè)公司會根據(jù)自己的情況做一些調(diào)整，更加符合自己的團(tuán)隊(duì)，并隨著項(xiàng)目的進(jìn)行不斷的進(jìn)行總結(jié)，調(diào)整，好的團(tuán)隊(duì)還會盡可能的把測試提前。

從大體流程曉得，測試編寫用例是在需求評審結(jié)束，項(xiàng)目立項(xiàng)后，那這個(gè)測試用例編寫是否真的是必須的呢？

就個(gè)人觀念看：測試用例的編寫是必須的！ 很多測試人員會覺得測試用例的編寫是很浪費(fèi)時(shí)間，因?yàn)樽詈筇峤粶y試執(zhí)行時(shí)很難按照預(yù)先編寫的測試用例執(zhí)行。

測試很難按照預(yù)先編寫的用例執(zhí)行，個(gè)人覺得最主要的原因是：在需求評審階段沒做好或者根本就沒有做需求評審，造成開發(fā)，產(chǎn)品和測試三者之間沒有對需求達(dá)成一致的理解，也可能需求不完善，不明確，有疑問點(diǎn)等，在編碼過程中還在不停的變更需求。

但是我并不以為這是不可控的，至少可以控制在可接受范圍內(nèi)，這里可能又得花費(fèi)很多時(shí)間去聊需求評審的必要性和重要性，明顯不是我們現(xiàn)在想要聊的內(nèi)容。

就個(gè)人待過的研發(fā)團(tuán)隊(duì)而言，即使有詳細(xì)的需求評審流程，但是往往測試人員在去編寫測試用例時(shí)，為了使用例能盡可能的覆蓋到更多的測試點(diǎn)，會不停的從各種角度的去理解需求，還是常會發(fā)現(xiàn)需求的一些遺漏點(diǎn)，疑問點(diǎn)，然后通過及時(shí)的溝通，可以及早的發(fā)現(xiàn)問題，減低研發(fā)過程的風(fēng)險(xiǎn)，減少用例編寫完到最后執(zhí)行用例期間變動，這樣編寫用例的過程反而有助于測試?yán)斫庑枨蟆?/p>

編寫用例還有很大的好處就是避免盲目的執(zhí)行測試。用例就好像是一本劇本，測試員可以根據(jù)劇本的設(shè)定能對被測系統(tǒng)做到較為全面的測試。

編寫測試用例是必要的，編寫測試用例時(shí)用例的粒度也是一直有爭論的。就好比這個(gè)劇本，寫細(xì)了容易束縛了表演者的自我發(fā)揮，寫粗了又擔(dān)心表演者遺漏某些重要環(huán)節(jié)。但就我個(gè)人觀念，如果你是一家傳統(tǒng)軟件公司，一個(gè)項(xiàng)目可能幾個(gè)月甚至半年、一年才一次交付，那么你擁有充足的時(shí)間去設(shè)計(jì)你的測試用例，那么我建議你的用例能盡可能描述詳細(xì)，不停的修復(fù)、補(bǔ)充、完善。

然而在大多數(shù)互聯(lián)網(wǎng)公司，基本都走敏捷，講究小步快跑，快速試錯(cuò)，基本上產(chǎn)品迭代非常頻繁，就像我目前所在團(tuán)隊(duì)基本兩周一個(gè)迭代，這給我們測試留下的執(zhí)行測試的時(shí)間就極短，更別說寫用例的時(shí)間，這時(shí)我們就不得不在某種程度上做個(gè)妥協(xié)，簡化測試用例，不再對每一條用例做詳細(xì)描述，或者說我們更多的是寫測試點(diǎn)。然而這里還是建議遇到比較復(fù)雜的流程時(shí)，還是能盡可能用例描述詳細(xì)。測試點(diǎn)不表示不需要考慮各種用戶場景，而是盡可能通過一句話能描述出這個(gè)場景的概要，這樣測試人員在了解需求的前提下通過這么一句話概要就可以清楚知道需要執(zhí)行哪些用例，這對測試員的要求會相對更高點(diǎn)。

用例寫多了，總會發(fā)現(xiàn)很多功能模塊是類似的，例如查詢功能，翻頁功能，文本框校驗(yàn)，時(shí)間控件校驗(yàn)等等，這時(shí)可以學(xué)學(xué)編程思路，某段代碼多處用到，那么就提取成一個(gè)公共方法，供各個(gè)地方調(diào)用。同樣編寫測試用例時(shí)，你也可以提取類似的測試用例，形成一個(gè)公共用例庫，供相同的功能模塊引用。

其實(shí)我個(gè)人很喜歡在編寫用例之前和準(zhǔn)備執(zhí)行測試時(shí)，找開發(fā)聊聊開發(fā)是準(zhǔn)備如何實(shí)現(xiàn)和現(xiàn)在是如何實(shí)現(xiàn)這個(gè)功能。通過個(gè)人的積累發(fā)現(xiàn)，跟開發(fā)聊實(shí)現(xiàn)很容易從開發(fā)的設(shè)計(jì)中你可以把握到測試的注意點(diǎn)，并記錄體現(xiàn)在用例中。例如Ａ開發(fā)曾經(jīng)用某種方式做了ａ功能，出現(xiàn)了某個(gè)bug,現(xiàn)在B開發(fā)用了同樣方式實(shí)現(xiàn)，那么極有可能之前的bug這次還會出現(xiàn)。

產(chǎn)品走迭代，測試用例同樣也需要迭代。我目前的團(tuán)隊(duì)這個(gè)做的不好，而之前我自己帶的團(tuán)隊(duì)一直很注重這塊。這就關(guān)系到測試用例的管理，我當(dāng)前所在的團(tuán)隊(duì)，每個(gè)迭代都會新啟用一個(gè)文檔去記錄你的測試用例，這樣這份測試用例上你只能看到這個(gè)迭代的修改和新增，而無法查看到該模塊沒變化的用例，或者說根本無法拿出一份完整的測試用例，有時(shí)開發(fā)問起某個(gè)開發(fā)已久的功能邏輯時(shí)，測試甚至都沒辦法找到這個(gè)功能模塊的用例從而去推斷當(dāng)時(shí)的邏輯。而如果用例走迭代，每個(gè)新迭代都居于上個(gè)迭代的用例上做增刪改。例如假設(shè)我通過excel來管理我的用例，那么我每次新迭代開始時(shí)，我就復(fù)制一份舊的用例，居于復(fù)制而來的用例上做修改形成最新版的測試用例，這樣我既能保留以前迭代的測試用例（可便于功能回溯），又可以有一個(gè)完整的當(dāng)前系統(tǒng)的測試用例。

最后，用例評審也是非常必須的，特別是一些經(jīng)驗(yàn)老道或者業(yè)務(wù)熟悉的老司機(jī)，可以在用例評審上快速的幫忙指出用例的遺漏點(diǎn)，有助于測試人員打開思路，盡可能多的覆蓋用戶場景，值得注意的是用例評審上遇到不確定的，應(yīng)立即記錄下來，結(jié)束后及時(shí)找相關(guān)人員確認(rèn)，避免猜測。