最近有和乙個初學測試的朋友聊天，他說關於測試方面的書看來不少，理論和概念也背了不少，但是實際測試時還是不知道怎麼怎麼下手，不知具體該如何做？ 其實關於怎麼入手做測試，沒有什麼具體的規範，以下是我的個人習慣，供大家討論一下。
面對乙個新的專案，應該從專案的編寫需求分析時參與進去，了解專案的背景和使用者的需求，然後根據專案的開發進度，編寫測試計畫；測試計畫要包含以下內容：測試用例編寫時間，按照用例執行測試的時間和執行回歸測試的時間，這個時間根據要專案進度來設定，以保證計畫的正常執行。
編寫完測試計畫後，不要急著編寫測試用例，要先確定需求分析是不是已經編寫完成，並經過了評審。如果確定需求分析已經評審完成，那就要盡可能多的了解需求分析。根據需求分析編寫測試要點，所謂測試要點，就是測試用例的框架，把需求分析中的使用者要求和使用者業務記錄下來，然後區分哪些是主要也需求，哪些是次要需求。這要便於測試的全面和測試重點的突出。
編寫完測試要點後，再開始編寫測試用例。所謂的測試用例，就是指測試某項功能時，所作的輸入資料或動作，並列出期望的輸入資料或動作。那麼編寫測試用例，就是用實際的操作來證明前面所寫的測試要點中的功能點和業務實現。證明測試要點時要從正反兩個方面進行，不但要證明正常情況下軟體系統的反應，還要證明在非正常情況下，軟體系統也要能作出正確的處理。對於主要的需求要盡可能全面測的測試，要考慮到各種可能性，而對於非主要需求，測試用例可以適當少一些，但是最低也要有正反兩方面的考慮。
測試用例編寫完成後就可以開始做測試了，做測試時要按照測試用例進行，要確保每條用例至少執行了一次，每執行一條用例就要對比一下軟體系統的實際輸出和期望輸出是否一致，如果不一致，要記錄到測試報告中。實際測試時不要漏掉任何的不一致情況，因為這些不一致就是軟體系統的問題所在。對於軟體輸出不一致的用例，最好多執行一次，盡量定位軟體問題所在，以便於開發人員的修改。
測試完成後，就要及時把測試報告反饋給開發人員，以便於開發人員的修改。當開發人員修改完成後，就進入 到軟體測試的最後階段回歸測試（我認為這是最麻煩的，呵呵），所謂回歸測試，就是驗證上次測試時所發現的問題是不是已經被修改，有沒有新的問題出現。之所以認為它麻煩，那是因為軟體修改完成後可能會導致新的問題出現，如果把測試用例再重新執行一遍的話，就要花費很多的時間。如果要使用測試工具進行自動化測試，就要花費大量的時間去維護測試指令碼，無論怎麼做，都很麻煩。我的一般做法是把發現問題的測試用例和它有關聯的測試用例重新執行一遍，如果沒問題，就算測試完成，否則，再次提交測試報告，直到測試完成。
以上是在正常情況下，做功能測試的步驟，但是實際工作中，正常情況總是小於非正常情況的，我遇到的非正常情況有以下幾種：1，軟體專案的需求分析不完整，或者沒有需求分析。2，開始測試時，專案已經開發完成。3，交付測試時，離專案的完成時間很短，沒有太長時間進行測試。
軟體測試步驟詳解
軟體測試步驟按照研發階段一般分為5個部分 單元測試 整合測試 確認測試 系統測試 驗收測試，下面將不同階段需要的一些工作內容做一下梳理希望可以幫助到大家。一 單元測試的內容 白盒為主，黑盒為輔 單元測試又稱為模組測試，是針對軟體設計的最小單位程式模組進行正確性檢查的測試工作，單元測試需要從程式內部結...
軟體測試之功能測試
功能測試 功能測試在測試工作中佔的比例最大，功能測試也叫黑盒測試。是把測試物件看作乙個黑盒子。利用黑盒測試法進行動態測試時，需要測試軟體產品的功能，不需測試軟體產品的內部結構和處理過程。採用黑盒技術設計測試用例的方法有 等價類劃分 邊界值分析 錯誤推測 因果圖和綜合策略。黑盒測試試圖發現以下型別的錯...
軟體測試的步驟和內容
軟體測試的步驟和內容 軟體測試包含的內容很廣泛，從狹義的角度理解，就是將軟體編寫的漏洞發現並指導補救，廣義上講，就是按照軟體功能設計的要求逐一核對軟體編寫的功能，查詢漏洞進行補救。1.介面格式的測試 介面格式是否符合設計規範和程式原形的要求 例如 介面上文字的字型是否統一，顏色是否一致 標題的字型是...