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

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

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

　　2、設計Test Scenario和Test Case

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

　　4、總結缺陷和質量評估報告

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

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

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

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

　　2、Test Plan構建出來是否合理，覆蓋率，側重點是否合理？

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

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

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

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

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

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

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

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

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

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

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

　　End

　　筆者只是談談自己對測試的一些看法，一直認為沒有什么理論是完美的，理論再先進，如果不能跟每個公司實際的情況充分結合進而演化，那么先進的理論也只不過是象牙塔石碑的文字，毫無用處。