近來工作挺忙， 因此也都沒什麼時間總結了。當然，忙的這段時間我也發現了自己工作中的諸多問題，今天偷閒上來總結一下。
在這之前，我對測試工作的觀點是，熟悉業務加上熟練的技術能力就能很好的完成大部分測試工作，通過這次項目的追趕，我突然感覺到這之中有太多的不合理性，畢竟測試有很多不確定性，而且每個人的測試思路不一樣，很容易忽略和遺漏很多測試點，這樣下來測試的覆蓋度降低了很多，到最後產品上線的時候肯定有很多問題，所以還是不能靠感覺和思路來做事，因爲到最後沒人代理你承擔責任。所以這裏關於測試設計，我也想談談自己的一些觀點，以幫助和指導我之後的工作方向。
通常情況下，項目開始的時候，需求人員會將一堆所謂需求文檔分散到開發和測試人員手中，此時也就是說讓測試前期介入到項目進展中。當然這個時候，我們會有很多很多的問題需要跟需求確認，因爲一堆零散的需求文檔就足以說明他們是如何草率，但每到項產品交付的時候，這個時候就是開發和測試人員最痛恨需求人員的時候，因爲他們前期的需求不明確，讓我們白白辛苦並浪費了這麼多時間。但對於測試來說，在這個過程中其實就起到了承上啓下的作用，因爲只有測試人員纔會不厭其煩的去與需求人員周旋，而開發這個時候自認爲只要加工完就ok了，而測試不能向任何人說ok，不然我們的工作就變得毫無意義了。所以說，測試工作就是一項去深入理解需求，正確引導開發向着最正確的軌道行駛，可見偉大，嘿嘿！
首先，從需求文檔中，我們從中抽象出基本功能，得到一個測試人員能夠理解的文檔，這樣我們就知道我們大致要測試那些功能點了；
其次，再從需求文檔中提取出業務流程，並與需求人員深入溝通，畫出業務流程圖；
第三，通過以上兩點成果，輸出一份初步的測試計劃，包括測試目標、範圍，以及測試內容、測試流程、測試方法和測試工具，最主要全面列舉測試覆蓋範圍，比如對於客戶端軟件最後要進行系統平臺測試，包括windows 7/Vista（32/64bit）等；安裝卸載測試、殺毒軟件的覆蓋測試等等；如web頁面要執行瀏覽器兼容性測試等；
最後，就要注重測試思路的總體連貫性，“先正常，後異常”，保證正常情況下的功能能走通，異常情況下近可能的去覆蓋。
可能這裏要說還應該完成測試case的設計，以及評審，至最後的完善歸檔，不過並不是所有的項目都會有大量的時間留給測試人員，這也就是產品測試和項目測試的區別所在。如果時間充足的情況下，設計詳細的case，以及評審，那當然是最完整的流程了。這裏主要談到的測試對象是項目測試，通常都是時間非常緊急，留給測試的時間很短，無暇顧及完成軟件測試流程，那麼就需要找到更合適自己以及項目的方法和流程來完成。