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

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

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

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

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

　　4、總結(jié)缺陷和質(zhì)量評估報告

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　End

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