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