|
不論你何時開始接觸測試這個行業(yè)的，你首先了解到的一定是功能測試。即，通過一些測試手段，來驗證開發(fā)做出的代碼是否符合產品的需求。
當然，每個人對功能測試的理解也會存在不同。但，只要你做這行，就一定會發(fā)現(xiàn)一個現(xiàn)象：很多同學覺得功能測試太簡單，工資不高，所以就轉行做自動化測試了，結果不僅自動化沒學會，反而越做越迷茫。
究其原因：是因為你連功能測試都沒學好，怎么可能學好自動化測試。
下面，我就自己的個人經歷，為大家分享一些測試后心得，希望對大家有用
需求分析：發(fā)揮主動性
正常需求在提出時，產品需分析需求價值、影響范圍和實現(xiàn)代價等。可是現(xiàn)在很多情況是，需求來了就組織評審，然后開發(fā)測試與上線。產品主導型的開發(fā)模式非常常見，作為測試人員，我們無法主導需求和項目。因此，在需求評審的時候，提前預估工作量，防止因評估不足造成后期測試不充分。
再者，一定要關注開發(fā)和產品討論。如果開發(fā)說其中一個部分比較難實現(xiàn)，但最后實現(xiàn)了。那么，其中的變動和難點就是測試的重點關注部分。
另外，需求評審結束后，需向產品提出評審改動部分，同時更新自己的測試方案。最后，根據(jù)產品需求，在設計測試方案及時間安排上，可粗粒度預估，時間上要合理，并在會上與所有與會人員交流。
用例設計與評審：做到不遺漏
測試用例是每個測試人員工作中必不可少的環(huán)節(jié)。不管你是用Excel，還是FreeMind來寫，都應編寫并存檔?？赡芎芏嗳瞬辉谝鉁y試用例編寫規(guī)范，但我認為這個觀點須糾正。
編寫測試用例，我認為最重要一點，就是從用戶的角度出發(fā)。首選，測試用例的編寫，必須具備：測試用例名、執(zhí)行步驟、預期結果這三個元素。再者，測試方案選擇必須全面。作為功能測試人員，你可能不會編寫自動化測試腳本、性能測試、安全測試等腳本，但是你必須知道需進行哪些測試。
如：面試的時候給你一個場景：一個全新的App要發(fā)版，如果讓你來測試，你能想到哪些測試方案？
如果你只關注如何測試App的功能，那你很可能會面試失敗。此時App的功能、性能、數(shù)據(jù)傳輸安全性、接口或服務的測試（包括：功能測試、自動化測試與監(jiān)控、性能測試），底層數(shù)據(jù)存儲與容災情況等，都須考慮在內。
另外，設計用例時要設計兩類。一類是關于開發(fā)自測和驗收測試標準的冒煙測試用例；另一類是針對需求的全面測試用例。寫完用例要主動聯(lián)系相關人員進行用例評審，強調開發(fā)自測。在評審時，還要及時修改不合適的用例。
測試流程：注重項目控制
其實，項目的流程控制在需求開始時就應該重視起來。只是很多時候，我們容易忽略這個問題。測試人員是一線工作人員，不管你工作了多久，都必須有關注項目整體的意識。如果你不關注項目進度，很可能會導致加班返工。
需求一旦明確由你負責，就要時刻排期來關注項目的進度情況。同時，在測試過程中，發(fā)現(xiàn)了bug必須詳細的描述問題，不管是jira,禪道或是其他的bug管理方式。發(fā)現(xiàn)bug一定要寫清楚以下幾點：Bug問題描述，bug重現(xiàn)步驟，是否有前置條件，預期結果，實際結果，以方便開發(fā)去進行修改。另外，還要給bug準確分級，實時跟蹤進度，保證項目按期完成。
上線回歸與項目總結
需求上線完成后，要及時進行線上回歸。如果有必要，須提醒相關人員進行自動化線上回歸或是監(jiān)控工作。同時，必須回歸由bug修復導致的原有功能喪失問題，以確保新功能的成功上線。作為功能測試人員，我們還需通過問題記錄、解決措施記錄等內容，將整個新功能上線過程做成文檔，便于后期查閱使用。
總結和沉淀
在應聘時，很多有著多年從業(yè)經驗的功能測試人員，面臨無法被錄用的窘境。究其原因，是因為：你不具備相應工作年限該具備的工作能力。
多個測試工具在使用時，有哪些關聯(lián)性？在遇到同種類型的bug時，有幾種應對策略？在做完項目后，你是否做過完整的梳理和總結？對于這些問題的處理態(tài)度，將決定著你工作能力的提升與否，也決定著你未來的求職成功率。
另外，請時常問問自己：離開現(xiàn)在的公司，我還有什么？你還有的內容，才是你價值的體現(xiàn)。不要想通過調換工作方向，逃避自己能力不足這個問題。只有充分認清自己的能力，正確看待問題的人，才能走的更長遠。
 |
