1、請描述一下你上家公司的測試流程
首先營銷部門會將所需要的需求反應給產品，產品制定需求文檔–》需求評審會議（有開發人員、產品經理、測試人員、UI設計人員、項目經理）—》需求確定（出一份確定的需求文檔）----》開發設計文檔（開發人員在開始寫代碼前就能輸出設計文檔）-----》制定測試計劃，寫出測試用例------》發給開發和測試經理看看（非正式的評審用例）----》接到測試版本（可能測試的代碼，通過冒煙測試）—》執行測試用例（中間可能會補充測試用例）----》提交bug(有些bug需要開發人員確定（嚴重級別的，或突然發現的載測試用例範圍之外的，難以重現的，有些可以直接提交到禪道）)------》開發人員修改（可以在測試過程中快速修改）-------》迴歸測試（可能又會發現新問題，再按流程開始跑）-------》最後再上線之後再看看線上是否運行正常，以及測試用例的補充。
2、對於測試流程中每個階段測試人員的職責，談談個人見解
-
需求階段
需求階段，產品人員發出需求文檔，測試人員要對需求文檔進行評審，指出需求文檔不明確或者邏輯上有錯誤的地方，建立需求模型，確定測試範圍和測試的優先級。 -
軟件總體階段
需求確定，結合之前制定的測試的優先級 ，確定每種測試需求採用的測試技術。 -
測試準備
（1）確定測試需求點
（2）編寫測試用例和測試工具
-
測試執行
執行測試用例，做好全迴歸測試 -
上線之後
線上運行情況查看。以及測試用例補充和測試總結
3、如何進行有效的測試需求分析
一、什麼是需求分析
要弄清楚用戶需要的是什麼功能，用戶會怎樣使用系統。這樣我們測試的時候才能更加清楚的知道系統該怎麼樣運行，才能更好的設計測試用例，才能更好的測試。測試需求分析是測試工作的第一步，經過需求分析，對原始需求列表中列出的每一個需求點，找到我們需要測試的測試要點；針對所確定的測試要點，分析測試執行時對應的測試方案/方法。
二、爲什麼要做需求分析
1、需求分析的必要性
如果要成功的做一個測試項目，首先必須瞭解測試規模、複雜程度與可能存在的風險，這些都需要通過詳細的測試需求來了解。測試需求不明確，只會造成獲取的信息不正確，無法對所測軟件有一個清晰全面的認識，測試計劃就毫無根據可言，只憑感覺不做詳細瞭解就下定論的項目是失敗的。
測試需求分析越詳細精準，表明對所測軟件的瞭解越深，對所要進行的任務內容就越清晰，就更有把握保證測試的質量與進度。
如果把測試活動比作軟件生命週期，測試需求分析就相當於軟件的需求規格，測試策略相當於軟件的架構設計，測試用例相當於軟件的詳細設計，測試執行相當於軟件的編碼過程。只是在測試過程中，我們把”軟件”兩個字全部替換成了”測試”。這樣，我們就明白了整個測試活動的依據來源於測試需求，所以需求分析是整個測試活動必不可少的環節。
不做需求分析的後果：
（1） 浪費時間和資源實現了用戶不需要的需求；
（2） 遺漏了需求文檔中沒提到，但很重要的需求，導致客戶滿意度降低。
（3） 需求分析不到位，錯誤的估計了測試的工作量，導致延誤發佈週期，可能會降低發佈質量。
以上的幾個問題，在實際開發中是比較常見的，主要的原因就是需求分析不到位，會導致影響客戶的滿意度。
三、怎麼做需求分析
1、 通過需求文檔瞭解需求的實現背景
拿到一個需求後，我們首先應該通讀需求文檔，先通過需求文檔，對要做的需求的背景有個整體的瞭解，其實這個過程也是對需求文檔測試的過程，對需求整體的瞭解後，我們可以先記錄自己的一些疑惑，爲後面需求的分析做一個準備工作，這個環節我們應該更多的瞭解一些需求的目的和一些用戶的使用場景。
2、 分析需求合理性
可以通過業務知識來分析需求的合理性，而不是單單通過系統是怎樣實現的來判斷需求是否合理，這也是測試人員必備的技能之一，即需要我們有深厚的業務功底，然後在通過結合系統現有的實現來分析需求的合理性。
在我看來需求是否合理主要包括兩個方面：第一，滿足客戶需求。第二，在系統原有的基礎上，儘量減少改動成本。
3、 確定測試的範圍和優先級
通過以上對需求的分析，我們就可以確定測試的範圍和優先級了。首先我們要確定好這個需求所涉及的全部測試點，然後通過分析，分析出測試範圍的優先級。
4、 細化測試點並確定測試方法
確定了測試範圍和優先級後，就可以對各模塊進行細化，可以用MindManager列出個模塊下的測試點，各模塊或大的測試點需要寫出對應的測試方法，或測試策略。是否需要性能測試、白盒測試，是否需要提前準備數據，或會遇到什麼樣的測試難點，採取怎樣的應對措施。
5、 確定哪些工作測試人員可以提前介入
根據以往的經驗我們都知道，在開發一個比較複雜的需求的週期中，測試的前期準備工作通常都是比較充足的，當然特殊情況除外，因此在確定了測試範圍和優先級後，測試人員和測試負責人應該先確定一下哪些需求測試是可以提前介入的，比如，15FB新增新案件來源和新結案方式字段的需求，前期的新舊關係對應文檔，測試就是可以提前進行介入，在需求完成了對應關係文檔後，測試在進行重新梳理一下，這樣既提高了文檔的可靠性，也相當於測試提前介入測試了，規避了後面的測試的進度風險和質量風險。
6、 查缺補漏
做完了需求的細化後，要對自己做的需求分析從頭到尾在捋一遍，查看有沒有什麼遺漏的，因爲需求也又可能遺漏的地方。主要關注有沒有場景需求沒有考慮全面， 涉及的修改範圍被遺漏了，以及一些特殊的關聯配置沒有考慮到的，另外如果需求做了一些變動也要及時補充需求分析，主要是分析變動可能帶來的風險，以及準備哪些應對之策。
四、如何提高需求分析能力
1、熟悉業務，瞭解系統
任何系統都有大的業務背景，只要熟悉了業務知識才能更有效的使用系統。
任何系統在使用過程中，都有一個熟悉的過程，對系統越熟悉，越容易發現系統問題和業務問題。
2、用客觀的思考方式站在用戶的角度分析
作爲測試人員如果想提升需求分析能力，首先應該做到的就是站在客戶的角度分析客戶需要什麼和客戶想要什麼，至於這個需求該不該做，那是需求人員的職責，這個需求做起來複不復雜那是開發人員的事情，作爲測試人員需要考慮的事就是在滿足客戶要求的基礎上（這個很重要），然後在站在業務或者系統現有實現的角度，給需求和開發人員一些設計上的建議，換句話說就是如果拋開客戶，你這個需求做的在高大上，在酷炫，都是沒有意義的。
3、多思考，不要拘束於慣性思維
我們知道一個人做一個工作時間越久，也就是我們說的經驗越豐富，可能這個思維方式就會越被限定住。比如，測試的統計表多了，當拿到一個新增的統計表的時候，首先想到的是公用用例上所列的測試點基本上就是最全的了，我都不用思考，直接用就行了。
其實這是一個誤區，公用用例的目的是幫助我們減少一些不必要的內耗，但是我們的思維不要被它所限定，如果公用用例中某個點是錯的，那我們豈不要一錯再錯了。所以作爲一個測試人員如果想要提升自己的需求分析能力，一定要多思考，不要被這種慣性思維束縛，不要被所謂的經驗束縛。
4、不要閉門造車，利用好網絡資源
提升需求分析能力，多思考是非常重要的，但是不是讓你傻思考，當你的進步遇到瓶頸的時候，不要閉門造車，做井底之蛙，要充分利用網絡上的學習資源，學習一些前輩的經驗，並把這些運用到實際的需求分析中去。山外青山樓外樓，多瀏覽和關注一些關於需求分析的網站或者微信公衆號，廣開言路，相信會對你的需求分析能力有非常大的提升。
5、善於總結分享
基於以上四點我們還要做到善於總結，樂於分享，把經常見到的用例設計的誤區和一些好的需求分析實例，和需求分析習慣分享給周圍的小夥伴，這樣可以集衆人之所長，不斷提升我們的需求分析能力。
4、制定測試計劃都考慮哪些因素
測試範圍、測試策略、測試資源、測試進度、測試預估
5、測試計劃編寫6要素
- why—爲什麼要進行這些測試
- what—測試哪些方面，不同階段的工作內容
- when—測試不同階段的起止時間
- where—相應文檔，缺陷的存放位置，測試環境等
- who—項目相關人員組成，安排哪些測試人員進行測試
- how—如何去做，使用哪些測試工具以及測試方法進行
6、如何估算測試周期
在測試製定測試周期時，首先,要求開發人員必須對主要功能做測試,保證提交過來的測試程序可以測試,不出現不可安裝卸載,功能沒實現或者存在重大功能缺陷的問題.
其次， 通過測試標準:測試達到什麼程度,缺陷修復到什麼程度,即可通過測試.一般從BUG的級別上來判斷(要對BUG級別有個明確的定義哦).
還有，中止測試標準:如果測試過程中出現那些問題,就要中止測試.一般指出現不可安裝,功能性重大缺陷導致測試無法進行下去.
再者就是，進入下一輪測試標準: 如果一輪次測試沒有通過,那麼就要進入下一輪測試.就是什麼情況下,有多少測試用例沒有通過,需要進入下一輪測試.
我們在估算測試周期的時候,需要考慮進這些意外事件.我們通過表格簡單說明下:
當出現以下情況時,該內容生效.事件、細分、需要時間 、測試周期 、責任方、沒有達到測試提交標準 、具體什麼原因 、開發方解決問題的時間 、順延 、開發方、中止測試 、 原因 、同上 順延 、開發方、測試資源變更 、測試人員請假,調崗等 、該測試人員剩餘工作量的時間 、順延或其他人員頂替 、測試方、多輪次測試 原因 、下一輪測試時間 、啓用下一輪測試周期 。