此文只給初入職場的測試小白一點點小小的建議，大佬們請繞行~
前言：
初入測試行業的小白們，可能當前都在從事業務測試，也就是點點點，大都對測試行業抱有一絲絲的幻想和憧憬，都想着有一天成爲業務專家或者測開大牛，但是千里之行始於足下，只有一步一個腳印的實踐，去學習才能到達目的地。
正題：
不論是何原因，踏上了測試之路，就註定要一直不斷的充實自己，測試目前在企業中，尤其是大廠，受重視的程度也在增加，測試的資源也在不斷的豐富，給有理想的小夥伴們充分發揮自己聰明才智的機會。
測試，做好了不比開發差！小白們，一定要給自己信心，不要在意當下工資是不是比開發少，但是當你成長爲測試專家或者成長爲你所在的業務領域的業務專家，薪資方面一定不會比開發差！
所以初入測試，一定要把基礎打紮實了，才能更好的爲以後的發展奠定良好的基礎，學習沒有捷徑可嚴，只有不斷的探索前進！
接下來，說一說測試的流程，不論你在什麼公司，測試流程都大同小異，無非就是：需求評審—>根據需求編寫測試用—>測試用例評審—>執行測試用例—>發現問題—>提出問題—>待開發修改後迴歸問題—>上線前回歸—>上線後迴歸等幾大部分。
說到需求分析，一般都是由產品經理畫好原型圖或者寫好需求文檔，會叫上相關的開發負責人和測試負責人組會。需求分析會，是整個測試周期的開始，清晰明確的需求會決定後面開發以及測試的進度和質量，所以小白們一定要認真聽，好好分析需求。
這裏有這麼幾點需要注意：
完整性：每一項需求都必須將所要實現的功能描述清楚，以使開發人員獲得設計和實現這些功能所需的所有必要信息。
正確性：每一項需求都必須準確地陳述其要開發的功能。
一致性：一致性是指與其它軟件需求或相關標準規定不相矛盾。
可行性：每一項需求都必須是在已知系統和環境的限制範圍內可以實施的。
無二義性：對所有需求說明都只能有一個明確統一的解釋，由於自然語言極易導致二義性，所以儘量把每項需求用簡潔明瞭的語言表達出來。
健壯性：需求的說明中是否對可能出現的異常進行了分析，並且對這些異常進行了容錯處理。
必要性：每項需求的制定都是必要的且能夠追溯的。
可測試性：每項需求都能通過設計測試用例或其它的驗證方法來進行測試。
可修改性：每項需求只應在軟件需求說明書中出現一次，這樣更改時易於保持一致性。
可跟蹤性：應能在每項軟件需求與它的根源和設計元素、源代碼、測試用例之間建立起鏈接，這種可跟蹤性要求每項需求以一種結構化的方式編寫並單獨標明。
以上就是小白們在聽需求評審的時候要注意的點（後面如果想到，會再補充），當然需求評審是枯燥的，見識了好多人需求評審的時候都是玩手機，事後呢再找產品經理去問，這時候效率會有所落後。聽好需求，對自己測試有很大的幫助，如果你不能很好的理解需求，那你又怎麼能測試好這個需求呢？
爲什麼重視需求評審，並且在需求階段需要測試參與並指出需求中的漏洞，因爲在需求階段發現問題，需要修改的成本最低，舉個例子，如圖所示：各個階段發現bug所需的成本。
所以說需求評審階段至關重要！
一個好的測試，哪怕不會代碼，做到了業務測試的專家，也是很牛*的存在，這個時候，就是幾乎就是一個項目經理的角色了，比產品懂技術，比開發懂業務，hold全流程，可以給其他人提出你的經驗和意見。懟的了開發，罵的了產品（罵人不對的）
後記：
一步一個腳印，紮紮實實的穩步前進，不要三天打魚兩天曬網 ，要給自己定個階段性的目標，每天朝着目標進步一點點，加油未來的大牛！