軟體功能測試的步驟

shbwf發表於2013-07-19
　　最近有和一個初學測試的朋友聊天，他說關於測試方面的書看來不少，理論和概念也背了不少，但是實際測試時還是不知道怎麼怎麼下手，不知具體該如何做？其實關於怎麼入手做測試，沒有什麼具體的規範，以下是我的個人習慣，供大家討論一下。
　　面對一個新的專案，應該從專案的編寫需求分析時參與進去，瞭解專案的背景和使用者的需求，然後根據專案的開發進度，編寫測試計劃；測試計劃要包含以下內容：測試用例編寫時間，按照用例執行測試的時間和執行迴歸測試的時間，這個時間根據要專案進度來設定，以保證計劃的正常執行。
　　編寫完測試計劃後，不要急著編寫測試用例，要先確定需求分析是不是已經編寫完成，並經過了評審。如果確定需求分析已經評審完成，那就要儘可能多的瞭解需求分析。根據需求分析編寫測試要點，所謂測試要點，就是測試用例的框架，把需求分析中的使用者要求和使用者業務記錄下來，然後區分哪些是主要也需求，哪些是次要需求。這要便於測試的全面和測試重點的突出。
　　編寫完測試要點後，再開始編寫測試用例。所謂的測試用例，就是指測試某項功能時，所作的輸入資料或動作，並列出期望的輸入資料或動作。那麼編寫測試用例，就是用實際的操作來證明前面所寫的測試要點中的功能點和業務實現。證明測試要點時要從正反兩個方面進行，不但要證明正常情況下軟體系統的反應，還要證明在非正常情況下，軟體系統也要能作出正確的處理。對於主要的需求要儘可能全面測的測試，要考慮到各種可能性，而對於非主要需求，測試用例可以適當少一些，但是最低也要有正反兩方面的考慮。
　　測試用例編寫完成後就可以開始做測試了，做測試時要按照測試用例進行，要確保每條用例至少執行了一次，每執行一條用例就要對比一下軟體系統的實際輸出和期望輸出是否一致，如果不一致，要記錄到測試報告中。實際測試時不要漏掉任何的不一致情況，因為這些不一致就是軟體系統的問題所在。對於軟體輸出不一致的用例，最好多執行一次，儘量定位軟體問題所在，以便於開發人員的修改。
　　測試完成後，就要及時把測試報告反饋給開發人員，以便於開發人員的修改。當開發人員修改完成後，就進入到軟體測試的最後階段迴歸測試（我認為這是最麻煩的，呵呵），所謂迴歸測試，就是驗證上次測試時所發現的問題是不是已經被修改，有沒有新的問題出現。之所以認為它麻煩，那是因為軟體修改完成後可能會導致新的問題出現，如果把測試用例再重新執行一遍的話，就要花費很多的時間。如果要使用測試工具進行自動化測試，就要花費大量的時間去維護測試指令碼，無論怎麼做，都很麻煩。我的一般做法是把發現問題的測試用例和它有關聯的測試用例重新執行一遍，如果沒問題，就算測試完成，否則，再次提交測試報告，直到測試完成。
　　以上是在正常情況下，做功能測試的步驟，但是實際工作中，正常情況總是小於非正常情況的，我遇到的非正常情況有以下幾種：
　　1、軟體專案的需求分析不完整，或者沒有需求分析。
　　2、開始測試時，專案已經開發完成。
　　3、交付測試時，離專案的完成時間很短，沒有太長時間進行測試。
　　針對以上三種情況可以分別對待，第一種情況比較麻煩，沒有需求分析就意味這功能測試就沒有了依據，那麼就需要測試人員多和使用者和開發人員進行交流，要站在使用者角度考慮問題，考慮使用者到底需要什麼樣的軟體，希望軟體完成什麼樣的功能。然後，根據這些編寫測試要點，再找使用者或者開發人員確認，最後編寫測試用例。第二種情況，就相對簡單，既然軟體已經開發完成，那麼測試計劃中的測試時間就更容易安排，更利於執行。第三種情況就比較辛苦了，既然專案時間緊，那就要趕時間作，如果你有一定測試經驗的話，那就不要寫測試用例了，直接按照測試要點進行測試就行了，不過測試報告不能省，還是要詳細記錄。如果沒有測試經驗，那麼最後找以前相似專案的測試用例，對照測試要點進行測試。如果一沒有需求分析，二專案時間緊，三又沒有測試經驗和類似的測試用例，那麼哥們，我精神上支援你，你自己做好加班拼命的準備吧。
　　以上是我對於軟體功能測試的一點個人意見，肯定又不正確或者不合理的地方，供大家參考，只有具體怎麼寫測試計劃、測試用例和測試報告，我們們下篇文章再討論！
本文轉載自51testing軟體測試網，檢視更多：http://www.51testing.com
[@more@]

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/11323760/viewspace-1060752/，如需轉載，請註明出處，否則將追究法律責任。

相關文章