在國內(nèi)做過項(xiàng)目管理，做過架構(gòu)，做過開發(fā)，也做過測(cè)試，一直在反思每一種類型的工作本質(zhì)到底是什么？應(yīng)該怎么做才是的？這里想總結(jié)一下在軟件測(cè)試這個(gè)領(lǐng)域個(gè)人的一些心得。

　　軟件測(cè)試是為了保證軟件項(xiàng)目的工程質(zhì)量而從事的一系列測(cè)試行為，本質(zhì)上來說，尋找產(chǎn)品的缺陷，分析產(chǎn)品的性能，保證產(chǎn)品的功能符合需求，評(píng)估產(chǎn)品的易用性等等，都是測(cè)試人員應(yīng)該做的。我們經(jīng)？吹降囊粋(gè)測(cè)試人員的工作流程是：

　　1、分析理解產(chǎn)品的需求

　　2、設(shè)計(jì)Test Scenario和Test Case

　　3、構(gòu)建Test Plan -> 執(zhí)行測(cè)試

　　4、總結(jié)缺陷和質(zhì)量評(píng)估報(bào)告

　　在筆者從事的公司所體會(huì)到的這個(gè)流程中容易出現(xiàn)的誤區(qū)和問題主要有這么幾個(gè)：

　　1、Tester設(shè)計(jì)的Test Case是否有質(zhì)量？能否高效的測(cè)出產(chǎn)品的功能質(zhì)量？

　　要寫出高質(zhì)量的Test Case，當(dāng)然首先要對(duì)產(chǎn)品有非常深的理解，知道某個(gè)功能的作用，甚至了解此功能的核心技術(shù)是什么。筆者見到容易犯的錯(cuò)誤，是設(shè)計(jì)場(chǎng)景和用例的人是完全根據(jù)自己的經(jīng)驗(yàn)和能力來思考，很多時(shí)候他已經(jīng)默認(rèn)了這個(gè)用例后是自己來執(zhí)行，所以會(huì)按照自己能理解的范疇來描述步驟，并且主觀上判斷某些方面的測(cè)試做不到，或者憑現(xiàn)有的環(huán)境、測(cè)試人員的技術(shù)（更多的時(shí)候以自己做參考），達(dá)不到更深入測(cè)試的要求，所以會(huì)自然而然的降低用例的繁瑣程度或者測(cè)試執(zhí)行的難度。

　　真正的測(cè)試用例設(shè)計(jì)者應(yīng)該牢牢把握客戶的需求是什么，體現(xiàn)在產(chǎn)品功能上的要求是什么。應(yīng)該回避思考測(cè)試的執(zhí)行者，回避現(xiàn)有測(cè)試環(huán)境和技術(shù)的瓶頸，站在客戶的角度，描述希望看到產(chǎn)品這塊功能能做什么，期望的性能怎樣？可能出現(xiàn)的情況有哪些？這并非說測(cè)試用例的設(shè)計(jì)是夸夸其談，而是充分尊重客觀實(shí)際的原則。當(dāng)然測(cè)試人員可以根據(jù)自己的經(jīng)驗(yàn)來改變測(cè)試步驟，突出某些側(cè)重點(diǎn)。但側(cè)重點(diǎn)的不同一定是根據(jù)對(duì)需求的理解來引導(dǎo)的。

　　2、Test Plan構(gòu)建出來是否合理，覆蓋率，側(cè)重點(diǎn)是否合理？

　　做過測(cè)試的人都知道，測(cè)試要想的覆蓋是不可能的，那么每次新功能的發(fā)布，版本的更新，又如何來引導(dǎo)測(cè)試覆蓋范圍和各個(gè)模塊功能路徑覆蓋的比例呢？每次發(fā)布周期也不會(huì)完全相同，有的三個(gè)月，有的半年，有的甚至1年之久，即使預(yù)計(jì)了周期，在未來也可能發(fā)生變化，那么Test Plan又如何靈活的設(shè)計(jì)來適應(yīng)可能出現(xiàn)的任何情況呢？

　　筆者認(rèn)為，Agile的一些思想可以幫助我們找到辦法。開發(fā)在每個(gè)短暫的周期里（sprint），交付一些可以使用的功能，測(cè)試的覆蓋面積，應(yīng)該圍繞著每個(gè)短暫周期里交付的功能來定義。當(dāng)然好的效果是測(cè)試對(duì)產(chǎn)品的架構(gòu)也有一定的了解，通過以往積累起來的經(jīng)驗(yàn)，或者和開發(fā)的溝通，來了解交付的功能對(duì)其他模塊的影響，這樣能果斷而且正確的減少不必要的測(cè)試。原則上，系統(tǒng)中已經(jīng)存在的功能（或者說代碼），被測(cè)試驗(yàn)證過正確健康之后，在未來的測(cè)試中可以降低覆蓋率和測(cè)試粒度，把更多的精力和主要的資源用在頻繁改動(dòng)和新出來的功能上。

　　當(dāng)然，要完美做到這一點(diǎn)，Agile的思想也提到，好能讓自動(dòng)化測(cè)試更早的介入項(xiàng)目中。對(duì)于已經(jīng)交付的功能，應(yīng)該盡早的編寫自動(dòng)化測(cè)試，把更具有經(jīng)驗(yàn)結(jié)合判斷的手工測(cè)試資源更早的釋放出來在當(dāng)前和未來要交付的功能上。（另外，如果開發(fā)能做到TDD，測(cè)試驅(qū)動(dòng)開發(fā)，其實(shí)對(duì)于質(zhì)量的保障會(huì)更加穩(wěn)妥）

　　3、整個(gè)測(cè)試周期的人員安排，時(shí)間安排和測(cè)試任務(wù)量，是否科學(xué)？在出現(xiàn)變化的時(shí)候，整體策略是否靈活？

　　過早的去構(gòu)想未來的計(jì)劃，是不明智的。當(dāng)項(xiàng)目的周期很長的時(shí)候，我們應(yīng)該合理的把整個(gè)schedule劃分更小的sub schedule，然后為近的這個(gè)sub schedule來制定計(jì)劃，安排資源。

　　筆者見過這么一種做法，具有經(jīng)驗(yàn)的測(cè)試人員把該有的測(cè)試都準(zhǔn)備好，定義為一個(gè)個(gè)的task，無論哪一次發(fā)布，都會(huì)把這些task幾乎不漏的一個(gè)接一個(gè)來完成。時(shí)間緊的時(shí)候，可能做得粗糙一些，時(shí)間充裕的時(shí)候，使勁細(xì)化每一個(gè)task。這樣容易給測(cè)試人員帶來一種，一陣不變的氣氛，比如在大學(xué)的生活三點(diǎn)一線：寢室->食堂->教室->食堂->寢室，往復(fù)循環(huán)…

　　筆者不想去否認(rèn)這種做法，但個(gè)人覺得這一定不是好的做法。當(dāng)今軟件的發(fā)布，產(chǎn)品的更新?lián)Q代，瞬息萬變，沒有什么流程是可以一沉不變的走下去的。為了能好的適應(yīng)整個(gè)周期項(xiàng)目的變化，應(yīng)該時(shí)刻保持從客戶那里，產(chǎn)品負(fù)責(zé)人那里，甚至銷售那里，聆聽有價(jià)值的信息，然后合理的調(diào)整資源。在每個(gè)task開始之前，都應(yīng)確保幾件事：

　　1、已經(jīng)傳達(dá)了收集起來的所有信息給大家

　　2、大家也都認(rèn)真思考過接下來的一個(gè)短暫周期里，開發(fā)要交付的，測(cè)試要關(guān)注的功能有哪些

　　3、之前申請(qǐng)的資源，包括人力、機(jī)器，現(xiàn)在看來還是否夠用？需要調(diào)整的，應(yīng)該盡快著手準(zhǔn)備

　　后，再保證每個(gè)短暫的周期里，參與測(cè)試的人員都能留有一部分時(shí)間來反思，對(duì)完成某些功能的測(cè)試所需要的技術(shù)，包括產(chǎn)品的核心技術(shù)上，是否還有提高的空間？而某些測(cè)試的策略是否還可以改善，以便在下一個(gè)短暫的周期里，能夠讓測(cè)試小組受益（實(shí)際上整個(gè)項(xiàng)目也會(huì)因此受益）

　　End

　　筆者只是談?wù)勛约簩?duì)測(cè)試的一些看法，一直認(rèn)為沒有什么理論是完美的，理論再先進(jìn)，如果不能跟每個(gè)公司實(shí)際的情況充分結(jié)合進(jìn)而演化，那么先進(jìn)的理論也只不過是象牙塔石碑的文字，毫無用處。