如何作好功能測試

      不論你是何時開始接觸測試這個行業的，你首先據說的應該是功能測試。經過一些測試手段來驗證開發作出的代碼是否符合產品的需求？固然你也有本身對功能測試的理解，可是最近兩年感受功能測試好像不太受歡迎，同時很多同窗真的是功能測試都沒有作好，就去嘗試自動化測試，測試開發什麼的，結果是越學越迷茫，這是爲何呢？究其緣由是，你功能測試尚未學好呢！

      咱們一般認爲的功能測試是根據需求，採起以下測試流程：需求分析，用例編寫，用例評審，提測驗證，Bug迴歸驗證，上線與線上迴歸等來進行測試。如此日復一日，年復一年，響應了不少需求，但是想換工做的時候卻得不到承認,你們想一想是否是這種狀況？下面我就以一個功能測試人員如何進行工做，來介紹一下功能測試應該用到的知識及相關的提高建議。

一，  需求分析，發揮主動性

      正常的需求在產出的時候，產品是要分析這個需求的價值，影響範圍和實現代價的。但是如今不少狀況是，需求來了就組織評審，而後開發測試與上線。產品主導型的開發模式很是常見，做爲測試咱們沒法主導需求和項目。在需求評審的時候，做爲一個測試人員必須瞭解此次需求的內容，影響到哪些現有的功能，涉及到的操做系統或是類別等，而後準確的評估出工做量，防止因評估不足形成後期測試不充分。再者，關注開發和產品的討論，若是開發說哪一部分比較難實現，最後如何實現？其中作出的變更和難點就是測試的時候必須重點關注的部分。不能由於這些暫時和你沒有關係就不去關注，後期會帶來麻煩。第三，需求評審結束後，要求產品更新這次評審過程當中的全部改動部分，同時給出方案確保產品的任何改動都及時更新。第四，根據產品需求，設計測試方案及時間安排，此時能夠粗粒度考慮，時間上要合理；同時與在會人員進行探討。

二，  用例設計與評審，作到不遺不漏

      測試用例是每一個測試人員工做過程當中必需要完成的工做，無論你是用Excel,仍是用FreeMind來寫，在測試工做中一是用來指導測試工做，並且是相關業務的一個文檔沉澱。可能你不太在乎測試用例的編寫，但是在我以往面試的經驗中，有超過一半的人寫的測試用例是不達標的。不少人寫用例是用書本上的方法，什麼邊界值法，條件覆蓋法等等，其實咱們更應該關注用戶，從用戶的角度來寫用例纔對。

      測試用例必須具有的測試用例名，執行步驟，預期結果這三點是必需要寫清楚的。再者就是測試方案選擇必須全面，做爲功能測試人員你可能不會編寫自動化測試腳本，不會性能測試，安全測試，可是你必須能根據需求想到要實施哪方面的測試。如面試的時候給你一個場景：一個全新的App要發版，若是讓你來測試，你能想到哪些測試方案？若是你只能想到如何去測試app的功能的話，那你做爲功能測試人員就是考慮不全面。此時的App的功能，App的性能，數據傳輸的安全性，接口或服務的功能測試，接口或服務的自動化測試與監控，接口或服務的性能測試，底層數據的存儲與容災狀況都必須考慮在內。

      設計用例的時候要設計兩類， 一類是開發自測和驗收提測試標準的冒煙測試用例，一類是針對需求的全面測試用例。寫完用例要主動聯繫相關人員進行用例評審，強調開發自測，在評審過程是及時修改不合適的用例。

三，  測試流程，注重項目控制

      其實項目的流程控制在需求開始的時候就應該重視起來，只是不少時候咱們沒有意識到這是測試的工做，有的是產品來控制，有的是專門的項目經理來控制。測試人員是一線的工做人員，無論你工做了多久，必須有關注總體項目的意識。若是你不關注項目進度，何時提測你何時開始測試，在測試過程當中你就會遇到測試的內容和最初的需求不一致，增長新的內容從而增長工做量，或是產品和開發一塊兒來壓縮測試時間的狀況，到時你想不加班都難。

      需求一旦明確了由你來負責的時候，就要時刻按排期來關注項目的狀況。中間變動需求的時候，要評估是否影響項目進度，若是影響了從新進行排期。若是開發提測試晚了，是否影響上線時間，若是可能會影響，立刻就要給相關的人員發預警郵件，通知你們詳細的狀況。同時在測試過程當中，發現了bug必須詳細描述問題，無論是jira,禪道或是其餘的bug管理方式，一個bug要寫清楚如下幾點：Bug問題描述，bug重現步驟，是否有前置條件，預期結果，實際結果，以方便開發去進行修改。同時給bug準確分級，實時跟蹤進度，保證項目定期完成。 

四，  上線迴歸與項目總結

     一個需求上線完成後，要及時進行線上迴歸，若是有必須提醒相關的人員進行自動化線上迴歸或是監控工做。同時必須迴歸咱們在需求評審的時候考慮到的可能影響到的原有的功能，以確保新功能的徹底上線成功。而做爲功能測試人員，在一個項目完成後，無論公司有沒有要求，要對項目作相應的文字總結。總結整個項目過程當中遇到的問題，最後的解決辦法或是當時討論的處理辦法，有哪些須要注意的問題？有什麼能夠借鑑的方案或是改進策略？項目中有沒有通用性的問題等等。

       若是公司有相應的項目總結方案，那測試的時候就要多關注一些數據，如冒煙測試是否一次經過，Bug數及不一樣級別的bug數，參與開發人員對應的Bug數，提測試次數，上線次數等等。然後藉助於第三方工具進行圖表化相應的數據，而後相關問題的總結，改進方案都須要進行詳細的總結。

五，  能力的總結和沉澱

     在咱們找工做的時候，不少作功能測試多年的同窗通常很難經過面試，這裏面的緣由到底是什麼？其實最核心的緣由是，你不具有相應工做年限應該具有的能力。

     測試工具的使用：在你以往的工做經驗中，有沒有總結過什麼樣的需求或是項目應該使用什麼樣的測試工具，而不是僅僅使用公司提供或是指定的工具？有沒有分析過同類的工具的優缺點？若是一個相似的全新的產品，你可否圍繞着工做需求，準備相應的測試工具來輔助測試？什麼樣的測試工具在測試項目的時候可能存在問題，問題的解決辦法是什麼？

     問題的總結：在測試工做中總結部署環境出現502或是404產生的緣由及解決辦法？產品的哪兒塊功能容易出現問題，或是開發怎麼實現相應的功能可能出現問題？產品的功能模塊之間是如何工做的，修改部分功能後可能會對其餘模塊產生影響？哪一個版本的編譯器打包的產品容易在哪些方面出現問題？等等相應的問題總結有沒有作，若是作了，在接到相應的需求後就能快速的評估測試範圍，選擇測試方案，規劃測試時間等。

    技術的沉澱：技術不只僅指的是編碼能力，像平時咱們部署環境出現問題後，最後的解決方案的總結；測試過程當中日誌出現空指針的排查；項目測試過程當中遇到的問題及解決方案；一些常見問題的排查及解決方案等等。要在工做中善於積累，從而指導本身的工做或是爲同事提供解決問題的思路與辦法。

      時常問本身一句話：離開現有的平臺，我還有什麼？這個纔是你的資本，對公司業務的熟悉，公司如今工具的使用等等，對你來講是沒有任何優點可言的。而對同類業務流程的掌握，項目的總體把控，快速瞭解業務並能根據需求選擇測試方案，引進現有的測試工具提升測試效率，測試過程當中遇到問題的預判和解決辦法等纔是功能測試人員必須具有的能力。這些方面你作到了嗎？業務專家也是不想作編碼的測試人員一個很好的選擇，不要成天抱怨功能測試如何如何，要充分認清行業現狀和本身的優缺點，作好職業規劃。