第一個是業務流程;第二個業務細節前端
對剛開始入職的新人來講,剛開始必定是先從公司業務框架和業務流程學起,這個時間段須要作的就多看,多問,多作。數據庫
01 多看編程
多看指的是多看公司需求文檔,需求文檔包括任何一切有關公司業務的文檔,多是公司業務背景,公司框架說明,之前的測試用例,測試報告,原型圖,公司系統等等。app
盡本身的可能多找與公司業務相關的文檔、數據查看。框架
02 多問編程語言
多問就是指多向同事請教,不是不恥下問,而是不要害羞上問,其餘人均可能比你懂得多。測試
如今企業對新人,可能會安排一個老同事帶你,也可能沒有,直接就安排你進項目作,但前期必定會給你留一點時間熟悉公司業務,若是有同事帶你,那是好運,但要明確一件事情就是別人帶你,並非他的主要工做,而是額外工做;若是沒有,也沒必要急,學會本身去梳理,去掌握需求。設計
向同事問問題也是一門學問,不是遇到問題就開始問,也不是逮着誰都問,能本身解決的就最好本身解決,須要多觀察,經過觀察肯定問問題的時機。日誌
剛纔王豆豆說過帶你的工做是額外工做,若是項目任務很忙的時候,帶你的測試人員既要完成平時的工做,又要解決你的問題,會給他形成必定的困擾,因此必定不要有問題就問。文檔
王豆豆使用的辦法就是:
1.先將不緊急解決的問題記錄下來,而後找一個時間統一問;
2.緊急問題,若是這個問題不解決就沒辦法繼續下面的流程,那這樣的問題就必須立馬解決,若是帶你的人在忙着測試,那你能夠先找其餘人解決,若是不忙,那就正好。
王豆豆就是很好運的那個,王豆豆能這麼快掌握公司業務,很大程度上都是由於遇到很nice的同事,每遇到的一個問題都能很好解決,解決不只僅是告訴答案,而是從流程,從結構,從根本緣由,從設計目的去分析這個問題,解答很詳盡,基本問一次就至關於把一個流程或一個功能點吃透。
03 多作
無論你問得再多,看得再多,若是本身不動手去嘗試,那都是白費。
第一個作:
看文檔或系統時,動手畫出大體地系統流程圖來,也能夠是系統框架,系統功能模塊等。
第二個作:
在問問題時,記錄下本身問的全部問題,避免重複問,若是你是第一次,我能給你詳細的解答,但若是是第二次,那我會記得我曾經給過你解答,若是還有第三次呢?那是否是我對你的印象就不會那麼好,我會以爲你對工做根本不上心。
第三個作:
執行---跑業務流程,分析流程的動做背後緣由
假設公司業務有付款的功能,那就本身動手從用戶註冊-〉登陸-〉帳戶存錢-〉付款的業務場景來作,一個個完整的流程跑,一邊跑一邊記錄頁面交互點,每個動做引發界面或任務或數據庫的變化,而後修改一點再跑再記錄。
好比付款帳戶有錢或沒錢的界面返回,數據庫的變化,同時瞭解每執行一個動做,所須要的前置條件,執行所須要的數據從哪些地方取等等。
關注點較多時,不必定只執行一次就所有了解,能夠屢次重試,但最終結果是每個動做,你都須要掌握,這也是咱們業務細節部分須要掌握的。
這個階段必定是創建在你對公司系統框架,業務流程,產品類型都是至關清楚的前提下再關注的點。
首先要清楚什麼是業務細節?
王豆豆覺得業務細節就是經過表象所看不出來的,而是須要根據數據,任務,動做共同去分析的。
王豆豆目前以爲應該二個辦法:
第一個方法是多跑業務流程
前面已經講過了,根據前面所講的方法來分析每一次執行動做,記錄執行前的前置條件和取數據的表,以及執行後的變化,包含數據庫,界面,測試環境記錄的日誌等。
第二個方法是看代碼
學會看代碼是每個測試人員都應該掌握到的。
若是公司沒有完整的需求文檔,測試人員能夠經過看代碼分析需求,業務流程的變化,本身就能梳理出需求來。
看代碼能夠發現測試人員在前端和業務流程上發現不到的問題,同時還能提升測試人員在某類功能點上測試的效率。
以測試人員測試Mapping類業務爲例,你們都知道Mapping(映射)是指各系統或子系統中相同點的不一樣映射。
例如1在A系統中表示小學生,在B系統中表示中學生,2在A系統中表示中學生,在B系統中表示小學生,在A系統中輸入1,在B系統界面須要顯示小學生。
若是要測試這樣的業務,功能測試至少須要二條測試用例來覆蓋,那若是是看代碼呢,是否是直接就能夠看出來了,你又可能會說不就是多二條測試用例麼?那若是這樣的Mapping值不少呢,功能測試就須要測試不少次,而經過看代碼能很快發現AB系統的映射是否正確,是否是效率提升不少。
同時看代碼能夠清楚更多業務設計細節和流程的跳轉及條件等。
之前沒有看過代碼,剛開始看似確實很難,但看得越多就越容易,學會看代碼的前提是對相應編程語言的基礎瞭解,知道如何使用。
以上就是王豆豆熟悉業務的方法,歡迎你們和我討論更多更有效的方法。