近來工作挺忙， 因此也都沒什麼時間總結了。當然，忙的這段時間我也發現了自己工作中的諸多問題，今天偷閒上來總結一下。
在這之前，我對測試工作的觀點是，熟悉業務加上熟練的技術能力就能很好的完成大部分測試工作，通過這次專案的追趕，我突然感覺到這之中有太多的不合理性，畢竟測試有很多不確定性，而且每個人的測試思路不一樣，很容易忽略和遺漏很多測試點，這樣下來測試的覆蓋度降低了很多，到最後產品上線的時候肯定有很多問題，所以還是不能靠感覺和思路來做事，因為到最後沒人**你承擔責任。所以這裡關於測試設計，我也想談談自己的一些觀點，以幫助和指導我之後的工作方向。
通常情況下，專案開始的時候，需求人員會將一堆所謂需求文件分散到開發和測試人員手中，此時也就是說讓測試前期介入到專案進展中。當然這個時候，我們會有很多很多的問題需要跟需求確認，因為一堆零散的需求文件就足以說明他們是如何草率，但每到項產品交付的時候，這個時候就是開發和測試人員最痛恨需求人員的時候，因為他們前期的需求不明確，讓我們白白辛苦並浪費了這麼多時間。但對於測試來說，在這個過程中其實就起到了承上啟下的作用，因為只有測試人員才會不厭其煩的去與需求人員周旋，而開發這個時候自認為只要加工完就ok了，而測試不能向任何人說ok，不然我們的工作就變得毫無意義了。所以說，測試工作就是一項去深入理解需求，正確引導開發向著最正確的軌道行駛，可見偉大，嘿嘿！
首先，從需求文件中，我們從中抽象出基本功能，得到乙個測試人員能夠理解的文件，這樣我們就知道我們大致要測試那些功能點了；
其次，再從需求文件中提取出業務流程，並與需求人員深入溝通，畫出業務流程圖；
第三，通過以上兩點成果，輸出乙份初步的測試計畫，包括測試目標、範圍，以及測試內容、測試流程、測試方法和測試工具，最主要全面列舉測試覆蓋範圍，比如對於客戶端軟體最後要進行系統平台測試，包括windows 7/vista（32/64bit）等；安裝解除安裝測試、防毒軟體的覆蓋測試等等；如web頁面要執行瀏覽器相容性測試等；
最後，就要注重測試思路的總體連貫性，「先正常，後異常」，保證正常情況下的功能能走通，異常情況下近可能的去覆蓋。
可能這裡要說還應該完成測試case的設計，以及評審，至最後的完善歸檔，不過並不是所有的專案都會有大量的時間留給測試人員，這也就是產品測試和專案測試的區別所在。如果時間充足的情況下，設計詳細的case，以及評審，那當然是最完整的流程了。這裡主要談到的測試物件是專案測試，通常都是時間非常緊急，留給測試的時間很短，無暇顧及完成軟體測試流程，那麼就需要找到更合適自己以及專案的方法和流程來完成。
免費提供軟體專案測試
以下為寫這篇文章的主要目的 為了積累更多的專案測試經驗，沒錯，我希望通過更多的專案實操來快速提公升自己的測試能力！所以，1.可以為有需求的團隊 企業提供 免費 的測試工作 2.由於我個人還是在職，這些工作只能在每天下班以後和週末時間進行，所以如果你的專案非常非常的趕時間，我可能無法按時完成測試工作，...
專案測試總結
1 測試活動路線 2 測試初衷 1 專案規劃明確 2 需求設計文件充分 3 系統整合環境部署簡易 4 測試流程規範 5 測試目標清晰 3 測試變更 1 開發環境與測試環境不同 2 開發模組與專案計畫不同 3 開發準備工作有出入 4 測試進度變更 5 測試環境的可控性 4 測試應對 搭建多套測試環境 ...
android專案測試
1 單元測試 又稱為 模組測試 是針對 程式模組 軟體設計 的最小單位 來進行正確性檢驗的測試工作。程式單元是應用的最小可測試部件。在 過程化程式設計 中，乙個單元就是單個程式 函式 過程等 對於物件導向程式設計，最小單元就是方法，包括基類 超類 抽象類 或者派生類 子類 中的方法。單元測試的步驟如...