軟件功能測試的步驟
近有和一個初學測試的朋友聊天，他說關于測試方面的書看來不少，理論和概念也背了不少，但是實際測試時還是不知道怎么怎么下手，不知具體該如何做？ 其實關于怎么入手做測試，沒有什么具體的規范，以下是我的個人習慣，供大家討論一下。
面對一個新的項目，應該從項目的編寫需求分析時參與進去，了解項目的背景和用戶的需求，然后根據項目的開發進度，編寫測試計劃；測試計劃要包含以下內容：測試用例編寫時間，按照用例執行測試的時間和執行回歸測試的時間，這個時間根據要項目進度來設定，以保證計劃的正常執行。
編寫完測試計劃后，不要急著編寫測試用例，要先確定需求分析是不是已經編寫完成，并經過了評審。如果確定需求分析已經評審完成，那要盡可能多的了解需求分析。根據需求分析編寫測試要點，所謂測試要點，是測試用例的框架，把需求分析中的用戶要求和用戶業務記錄下來，然后區分哪些是主要也需求，哪些是次要需求。這要便于測試的全面和測試重點的突出。
編寫完測試要點后，再開始編寫測試用例。所謂的測試用例，是指測試某項功能時，所作的輸入數據或動作，并列出期望的輸入數據或動作。那么編寫測試用例，是用實際的操作來證明前面所寫的測試要點中的功能點和業務實現。證明測試要點時要從正反兩個方面進行，不但要證明正常情況下軟件系統的反應，還要證明在非正常情況下，軟件系統也要能作出正確的處理。對于主要的需求要盡可能全面測的測試，要考慮到各種可能性，而對于非主要需求，測試用例可以適當少一些，但是低也要有正反兩方面的考慮。
測試用例編寫完成后可以開始做測試了，做測試時要按照測試用例進行，要確保每條用例至少執行了一次，每執行一條用例要對比一下軟件系統的實際輸出和期望輸出是否一致，如果不一致，要記錄到測試報告中。實際測試時不要漏掉任何的不一致情況，因為這些不一致是軟件系統的問題所在。對于軟件輸出不一致的用例，好多執行一次，盡量定位軟件問題所在，以便于開發人員的修改。
測試完成后，要及時把測試報告反饋給開發人員，以便于開發人員的修改。當開發人員修改完成后，進入 到軟件測試的后階段回歸測試（我認為這是麻煩的，呵呵），所謂回歸測試，是驗證上次測試時所發現的問題是不是已經被修改，有沒有新的問題出現。之所以認為它麻煩，那是因為軟件修改完成后可能會導致新的問題出現，如果把測試用例再重新執行一遍的話，要花費很多的時間。如果要使用測試工具進行自動化測試，要花費大量的時間去維護測試腳本，無論怎么做，都很麻煩。我的一般做法是把發現問題的測試用例和它有關聯的測試用例重新執行一遍，如果沒問題，算測試完成，否則，再次提交測試報告，直到測試完成……更多>>
滬ICP備07036474 2003-2012 上海澤眾軟件科技有限公司版權所有