先講自己遇到的兩個小故事。

　　去年底新開始負責一個項目的測試工作，這個項目在我之前，并沒有正式的測試人員，開發寫完代碼然后自己測試一下，沒問題上線。一次和相鄰團隊活動，一開發技術牛人得知我是新來負責測試的，寒暄之余，他的第一個問題是，你是用什么來做測試的？

　　聽到這個問題，我不禁一愣，他問的“什么”是什么意思？是指一種測試框架？或是一種測試工具？或是一種測試方法？還是其他？我趕緊回答，我正在準備自己的一套測試框架，也在吸取社區上的各種成熟的東西，測試用例也在建設中。

　　做測試5年多時間，之前從沒被問過這個問題。

　　進入項目的前兩個月，我在整理之前開發用到的各種測試方法和測試工具，一方面為了自己了解這個項目的狀況，另一方面也可以把以前的成果沉淀下來，為后面形成測試用例體系做準備。這時候來了一個測試的助手，因為是新人，我讓他先看下我之前先整理出來的那些個測試用例，同時也可以結合自己的經驗做一些擴展補充。他看了會，也跟我拋了個讓我很吃驚的問題：你說的測試用例是指哪幾個工具？言外之意，是覺得那幾個工具是幾個命令行，運行一下不可以了，還有什么可以擴展補充的？后來知道，原來他想寫code，想做自動化。

　　我終于意識到，原來大家對測試的理解是有很大不同的。我不能講他們的理解不對，因為他們的工作背景和經驗形成的對測試的一些看法，在某些場景下確是對的；但我覺得根據自己以前的經驗和個人認識，我對他們的理解有很大的不認同。

　　我來講講自己對測試的一些看法，完全是作為交流的目的，有講得不對的地方，懇請大家更正。

　　測試是干什么的？本著以終為始的原則來分析問題，我們首先需要了解測試的職責是什么：毫無疑問，測試存在的價值是保證產品的質量，讓產品給用戶提供好的服務。所以，這個目標決定了測試該做的事情，一切與這個目標一致的事情，都是測試需要做的；而所有對這個目標無直接用處的事情，測試需要考慮是否該做；至于違背了這個目標的事情，應該杜絕去做。

　　所以，對于測試，重要的第一件事情是需要了解產品。看上去這是一句廢話，項目中的任何人都需要了解產品！我想強調的是，測試需要比開發在某些方面更了解產品。對產品的了解分為兩個部分，一部分是需求，另一部分是設計。對測試來講，對前者的了解優先級比后者更為重要。需求定義了這個產品需要做成什么樣，它可以為用戶解決什么樣的問題，以及為用戶提供了什么樣的功能。而設計僅僅是開發為了實現需求，在基于自己對需求的理解上，用某一種方式實現了產品。需求決定了設計。

　　開發對產品的理解體現在設計上，而測試對產品的理解體現在測試用例上。

　　回到主題來，測試該做的第一件事情，是測試用例的齊備。可以沒有所謂測試框架，也可以沒有自動化，都不會從根本上影響測試質量；測試用例、測試場景不齊全，會直接導致產品潛在Bug沒有被發現，用戶拿到的產品服務質量很差。而且，我覺得如果測試場景沒有完善，急匆匆的去做一種框架或是自動化，也注定是很快要做重工的，因為很大可能你后面新加入的大量測試場景會徹底推翻你前期實現的測試框架、自動化模式。

　　當然，我也不是說要等所有測試場景都確定下來，才能開始自動化；自動化確實可以節省人力，騰出更多資源去做測試用例拓展；但要先確保基礎的測試場景完善。測試框架、自動化只是工具，它們的價值在于幫助測試人員提高工作效率，把一些勞動交給機器做，為測試人員省出時間去做更有價值的測試工作；但它們做到再好，對用戶來講，他們毫不關心；像有人提到，Windows Vista的自動化測試程度很高，而忽視了用戶體驗，結果注定是一個失敗的產品。

　　我這里的測試用例實際上是廣義上的測試用例，包含各種測試類型：功能測試用例，性能測試用例，系統測試用例，兼容性測試用例，安全測試用例，等等等等。我覺得根據產品的需求或者項目的需要，提高測試用例覆蓋度這個過程才是測試應該花大氣力去做的事情、測試工作中的重中之重。至于如何去完善測試用例，有很多很多的方法、技巧和經驗，我也在學習中，這里先不聊了。

　　齊全的測試用例是為了可以盡量的覆蓋產品邏輯，盡量可以發現潛在的Bug，或是盡量確認可以正常工作的場景。但這個過程的前提，是開發已經實現了產品，他們已經有Bug潛伏在某些地方了；事后盡早挽救是一個好的方法，但如果能夠事先預防，防患于未然，那更是大家期望的。在軟件開發中，測試在項目前期的參與，對于保障產品質量非常有益。