項(xiàng)目的第一階段是需求定義。需求定義遠(yuǎn)比我們尋常的理解要復(fù)雜得多：它不等同于用戶需要什么功能，我們把這個(gè)定義成一個(gè)產(chǎn)品需求。很多時(shí)候，用戶都并不清楚他們真正想要的是什么。用戶說(shuō)，我很熱。你可以給他一個(gè)風(fēng)扇，甚至給他一臺(tái)空調(diào)，但也許你給他一杯水能解決問(wèn)題。用戶說(shuō)，你們產(chǎn)品的更新過(guò)程太慢了，需要十幾分鐘！你可以去優(yōu)化下載流程，壓縮下載包尺寸，但也許你只要把更新工作放在后臺(tái)執(zhí)行而不影響用戶的正常操作，他很滿意了。需求定義的工作一般是PM的職責(zé)，但是，開(kāi)發(fā)團(tuán)隊(duì)是終把需求轉(zhuǎn)換成產(chǎn)品的人，開(kāi)發(fā)對(duì)產(chǎn)品需求的理解和定義，也在很大程度上決定了產(chǎn)品在用戶面前是什么樣。這個(gè)時(shí)候，測(cè)試需要參與進(jìn)來(lái)，和開(kāi)發(fā)一起來(lái)理解需求，定義需求，Review需求。這個(gè)過(guò)程，在有些公司，叫做SRS（Software Requirement Specification）的形成。

　　開(kāi)發(fā)在理解需求之后，要開(kāi)始設(shè)計(jì)了。設(shè)計(jì)決定了他將來(lái)的代碼會(huì)寫成什么樣。好的開(kāi)發(fā)流程，測(cè)試一樣需要參與設(shè)計(jì)的Review；即使很多國(guó)內(nèi)公司把這個(gè)都省了，開(kāi)發(fā)直接寫代碼了，測(cè)試仍然有機(jī)會(huì)參與。可以跟開(kāi)發(fā)聊聊他會(huì)如何實(shí)現(xiàn)，如果你經(jīng)驗(yàn)豐富，他一樣會(huì)很感激你給予他的反饋和幫助。代碼寫好之后，在正式Check In之前，還會(huì)有一個(gè)非常重要的環(huán)節(jié)：Code Review。作為測(cè)試，你如果想要知道你將來(lái)的測(cè)試用例該如何更有效率、更有針對(duì)性，你得好好利用這個(gè)機(jī)會(huì)，好好Review。

　　測(cè)試參與CodeReview的好處遠(yuǎn)不止幫助開(kāi)發(fā)發(fā)現(xiàn)一些顯而易見(jiàn)的代碼錯(cuò)誤或是其他一些Code Review可以發(fā)現(xiàn)的Bug。Code Review可以幫助測(cè)試從設(shè)計(jì)上更好的理解產(chǎn)品。也許你不需要理解具體每一行代碼他為什么要這樣寫，但你必須了解他的大體程序邏輯，有哪些輸入場(chǎng)景、輸出場(chǎng)景，有哪些條件判斷，有哪些是復(fù)用穩(wěn)定的舊的代碼、哪些是全新寫的代碼，還有哪些是會(huì)被其他模塊、甚至是需求從沒(méi)講過(guò)模塊調(diào)用的代碼功能......這些都是你后面設(shè)計(jì)測(cè)試用例的絕好素材。同時(shí)，你還可以根據(jù)你的經(jīng)驗(yàn)，提醒開(kāi)發(fā)應(yīng)該把某些適合的基礎(chǔ)場(chǎng)景實(shí)現(xiàn)單元測(cè)試，或是讓開(kāi)發(fā)自己做一些基礎(chǔ)的冒煙測(cè)試。這些都對(duì)你后面的測(cè)試工作大有幫助。

　　好的開(kāi)發(fā)流程對(duì)于軟件質(zhì)量的保障作用是非常大的。也有人抱怨，如果公司的開(kāi)發(fā)很不講流程怎么辦？我個(gè)人的答案是，別人可以不講流程，但如果你是一個(gè)的測(cè)試，如果你懂流程、你可以證明按照你的流程結(jié)果更好，你還有一個(gè)責(zé)任，是需要你去推動(dòng)別人來(lái)遵循流程。不要以為那是經(jīng)理們的事情；很多經(jīng)理在這方面經(jīng)驗(yàn)也許都沒(méi)有你多；但好的經(jīng)理他們會(huì)看清什么是對(duì)的，如果你在做對(duì)的事情，你肯定能夠得到他們的支持。重要一點(diǎn)還在于，如果你一直能夠在帶頭做對(duì)的事情，在做你認(rèn)為是TL、經(jīng)理該做的事情，你離經(jīng)理的位置也不會(huì)遠(yuǎn)。況且，測(cè)試流程也不是只有經(jīng)理們才需要關(guān)注的事情。

　。ㄟ@部分按照開(kāi)發(fā)流程，應(yīng)該寫到設(shè)計(jì)用例的前面。）

　　如果這三個(gè)工作都做好了，可以說(shuō)測(cè)試工作的大部分工作都完成了；剩下來(lái)的是測(cè)試用例的執(zhí)行了，以及為了提高效率的自動(dòng)化、一些工具的實(shí)現(xiàn)、測(cè)試框架的精煉和使用，或其他一些瑣碎的事情了。現(xiàn)在很多公司開(kāi)始把測(cè)試用例執(zhí)行外包了，說(shuō)明這確實(shí)有需求市場(chǎng)；也有人在討論這樣會(huì)不會(huì)讓外包公司的測(cè)試人員覺(jué)得測(cè)試低級(jí)而無(wú)趣了？我覺(jué)得對(duì)也不對(duì)。對(duì)確實(shí)是因?yàn)橄啾葴y(cè)試用例設(shè)計(jì)而言，單純的測(cè)試執(zhí)行在技術(shù)程度上要求要低；但不對(duì)，是想說(shuō)，盡管是執(zhí)行，測(cè)試人員一樣有很多空間可以發(fā)揮。誰(shuí)說(shuō)測(cè)試執(zhí)行過(guò)程中間不能擴(kuò)展更多、更有效率的測(cè)試用例了？被大家一直都看好的自動(dòng)化測(cè)試難道解決的不是測(cè)試執(zhí)行的問(wèn)題嗎？探索性測(cè)試（ET）研究的重點(diǎn)不也是單純的測(cè)試執(zhí)行問(wèn)題么？同一條測(cè)試用例，好的測(cè)試人員和普通的測(cè)試人員的執(zhí)行結(jié)果和價(jià)值也是有很多不一樣的。

　　這些工作做好了并不意味著，這些工作在前面階段做完了，后面再不需要做了。實(shí)際上，很多問(wèn)題都是在測(cè)試過(guò)程中，根據(jù)自己經(jīng)驗(yàn)調(diào)整原有的測(cè)試用例、甚至新增加一些測(cè)試用例發(fā)現(xiàn)的。我強(qiáng)調(diào)的是這些工作內(nèi)容應(yīng)該是測(cè)試人員日常工作中的主體。在整個(gè)開(kāi)發(fā)流程上，它們往往會(huì)呈螺旋疊加的。

　　所以，我們用什么來(lái)做測(cè)試？答案絕不應(yīng)該是某一個(gè)測(cè)試框架，或是某一個(gè)自動(dòng)化工具。

　　如果你也是測(cè)試，你的答案是什么？