引言

不論你是什麼時候開始接觸測試這個行業的，你首先聽說的應該是功能測試。通過一些測試手段來驗證開發做出的程式碼是否符合產品的需求？當然你也有自己對功能測試的理解，但是最近兩年感覺功能測試好像不太受歡迎，為什麼呢？主要是不少同學真的是功能測試都沒有做好，就去嘗試自動化測試，測試開發什麼的，結果是越學越迷茫。究其原因是，你功能測試還沒有學好呢！千萬別小看功能測試

我們通常認為的功能測試是根據需求，採取如下測試流程：需求分析，用例編寫，用例評審，提測驗證，Bug迴歸驗證，上線與線上迴歸等來進行測試。如此日復一日，年復一年，響應了很多需求，可是想換工作的時候卻得不到認可，大家想想是不是這種情況？

下面我就以一個功能測試人員如何進行工作，來介紹一下功能測試應該用到的知識及相關的提升建議。

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

正常的需求在產出的時候，產品是要分析這個需求的價值，影響範圍和實現代價的。可是現在很多情況是，需求來了就組織評審，然後開發測試與上線。產品主導型的開發模式非常常見，作為測試我們無法主導需求和專案。在需求評審的時候，作為一個測試人員必須了解這次需求的內容，影響到哪些現有的功能，涉及到的作業系統或是類別等，然後準確的評估出工作量，防止因評估不足造成後期測試不充分。

再者，關注開發和產品的討論，如果開發說哪一部分比較難實現，最後如何實現？其中做出的變動和難點就是測試的時候必須重點關注的部分。不能因為這些暫時和你沒有關係就不去關注，後期會帶來麻煩。

第三，需求評審結束後，要求產品更新此次評審過程中的所有改動部分，同時給出方案確保產品的任何改動都及時更新。

第四，根據產品需求，設計測試方案及時間安排，此時可以粗粒度考慮，時間上要合理。同時與在會人員進行探討。

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

測試用例是每個測試人員工作過程中必須要完成的工作。不管你是用Excel，還是用FreeMind來寫，在測試工作中一是用來指導測試工作，而且是相關業務的一個文件沉澱。可能你不太在意測試用例的編寫，可是在我以往面試的經驗中，有超過一半的人寫的測試用例是不達標的。很多人寫用例是用書本上的方法，什麼邊界值法，條件覆蓋法等等，其實我們更應該關注使用者，從使用者的角度來寫用例才對。

測試用例要素：

必須具備的測試用例名，執行步驟，預期結果這三點是必須要寫清楚的。

再者就是測試方案選擇必須全面，作為功能測試人員你可能不會編寫自動化測試指令碼，不會效能測試，安全測試，但是你必須能根據需求想到要實施哪方面的測試。如面試的時候給你一個場景：一個全新的App要發版，如果讓你來測試，你能想到哪些測試方案？如果你只能想到如何去測試app的功能的話，那你作為功能測試人員就是考慮不全面。此時的App的功能，App的效能，資料傳輸的安全性，介面或服務的功能測試，介面或服務的自動化測試與監控，介面或服務的效能測試，底層資料的儲存與容災情況都必須考慮在內。

設計用例的時候要設計兩類：

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

三、測試流程，注重專案控制

其實專案的流程控制在需求開始的時候就應該重視起來，只是很多時候我們沒有意識到這是測試的工作，有的是產品來控制，有的是專門的專案經理來控制。測試人員是一線的工作人員，不管你工作了多久，必須有關注整體專案的意識。如果你不關注專案進度，什麼時候提測你什麼時候開始測試，在測試過程中你就會遇到測試的內容和最初的需求不一致，增加新的內容從而增加工作量，或是產品和開發一起來壓縮測試時間的情況，到時你想不加班都難。

需求一旦明確了由你來負責的時候，就要時刻按排期來關注專案的情況。中間變更需求的時候，要評估是否影響專案進度，如果影響了重新進行排期。如果開發提測試晚了，是否影響上線時間，如果可能會影響，馬上就要給相關的人員發預警郵件，通知大家詳細的情況。

同時在測試過程中，發現了bug必須詳細描述問題，不管是jira，禪道或是其他的bug管理方式，一個bug要寫清楚以下幾點：Bug問題描述，bug重現步驟，是否有前置條件，預期結果，實際結果，以方便開發去進行修改。同時給bug準確分級，實時跟蹤進度，保證專案按期完成。

四、上線迴歸與專案總結

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

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

五、能力的總結和沉澱

在我們找工作的時候，很多做功能測試多年的同學一般很難通過面試，這裡面的原因究竟是什麼？其實最核心的原因是，你不具備相應工作年限應該具備的能力。

01、測試工具的使用

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

02、問題的總結

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

03、技術的沉澱

技術不僅僅指的是編碼能力，像平時我們部署環境出現問題後，最後的解決方案的總結；測試過程中日誌出現空指標的排查；專案測試過程中遇到的問題及解決方案；一些常見問題的排查及解決方案等等。要在工作中善於積累，從而指導自己的工作或是為同事提供解決問題的思路與辦法。

04、時常問自己一句話

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

想了解更多軟體測試知識歡迎評論區留言或私信我！