軟件測試人員天天的工做平常

王豆豆如今天天9點左右從家裏出發，9點半左右到公司，到公司以後王豆豆首先用養生壺煮一壺好茶，工做忙碌時也要記得多喝水，而後一邊聽着煮茶聲一邊寫着當天的工做計劃，工做計劃主要包括當天工做內容、學習計劃和總結。

 

計劃並非天天都能完成，在工做結束以後根據實際完成內容標註和總結，同時寫當天遇到的問題，方便次日跟蹤，寫工做計劃的好處就是能夠隨時查詢天天都作了什麼，這些是天天的固定的工做內容，軟件測試人員天天的工做內容會根據項目的實際狀況而有所不一樣。

 

王豆豆今天就以測試階段分析一下軟件測試人員天天基本工做內容，總的分爲如下幾個階段：

 

1.項目開始之初，也能夠是一次迭代開始之初

 

這個時候天天基本都是以熟悉本次項目或本次迭代功能模塊需求爲主。

 

方式：通常就是看文檔，有時就是看一天文檔，或參加不一樣的評審會。

 

根據不一樣人理解需求方式的不一樣，王豆豆喜歡用XMIND梳理測試點需求，王豆豆無論作什麼事都喜歡用筆去整理一番。

 

這階段主要是理解需求，分析功能模塊的業務流程，儘量將測試點梳理得更細，在梳理過程當中若是遇到不理解，或須要作的需求與之前的需求邏輯不符時，能夠先找產品經理討論，並肯定，方式能夠是當面討論，也能夠以郵件的方式肯定，推薦以郵件的方式肯定。

 

若是項目流程完善的團隊，這時通常會由產品經理開始組織需求評審，用通俗的話講就是過需求，之前公司是由SE組織需求評審，而後開發人員組織評審Story，目前是開發人員有時會組織，不一樣人組織評審內容有所不一樣，測試人員關注的重點也會隨之變化。

 

2.項目中前期工做內容

 

這時階段軟件測試人員主是寫文檔。

 

由於前期已經將需求的範圍和測試點整理OK 了,那這個時候基本就是輸出這些東西爲主，輸出的文檔測試人員稱之爲測試用例。

 

方式：通常是用excel寫，有可能會寫上幾天的測試用例。

 

測試用例寫完以後，測試人員會組織測試用例評審，能夠用正式的會議形式組織，也能夠以郵件的形式發給開發和產品評審，若是是以郵件的形式，那必定要跟蹤，由於大部分開發人員都不喜歡看郵件，能夠用即時通信提醒開發人員和產品經理去評審測試用例。

 

這個階段開發人員通常都在編碼，也是很是忙的時候。

 

測試用例並非必定要用excel寫，像如今項目測試用例大部分都是用XMIND寫，王豆豆如今習慣了用這種方式寫，用XMIND寫更能發散測試人員的思惟。

 

如今不少公司都不喜歡寫測試用例，以爲太花費時間了，也多是因爲項目緊的緣由，但王豆豆以爲測試用例在執行測試以前必定去有這樣一個過程，雖然花費時間，可是在執行測試時只須要根據前面梳理的測試點去執行就OK了，同時不容易形成漏測，就算公司不要求，王豆豆在測試以前，必定會作這樣的事，不管項目時間是否緊迫，這也算是成爲一種習慣了。

 

3.項目中期工做內容

 

這個階段是軟件測試人員最辛苦的階段—測試執行階段。

 

方式：根據測試類型的不一樣，執行測試也有所不一樣

 

功能測試時，執行測試主要就是測試軟件的功能，界面以及軟件體驗性等；作接口測試時，執行階段就是經過工具調用各類接口，測試各種接口傳值、取參、返回等測試點。

 

這個階段不只要測試，還有一件很是重要的事情就是提交BUG。

 

大概分爲：在缺陷管理工具上編寫BUG，和開發人員討論BUG，復現BUG，跟蹤BUG的處理流程。這個時期須要作的事情不少，不斷地測試，不斷地與開人員溝通，復現BUG。

在進行第二三輪測試時須要對前期提交的BUG，進行迴歸測試。

 

軟件測試人員不只要有發現BUG的能力，也須要有分析BUG，定位BUG的能力。定位BUG能夠經過查詢數據庫、後臺日誌或者查看源代碼等不一樣的方式去分析和定位。

 

4.項目後期工做內容

 

這個階段測試人員主要作的事情有寫測試報告和項目/迭代總結。

 

執行測試完成以後，測試人員須要對本次測試下一個結論，究竟是測試經過仍是不經過，這時軟件測試人員須要給測試結論，但不能就簡單的一句話給開發說本次項目測試經過了，能夠上線，或者說本次項目測試不經過，BUG還有不少，軟件質量有風險。

 

全部事情都講究依據，那麼軟件測試也須要，測試人員須要給項目團隊提供測試結果的依據。因此測試報告中通常包括測試用例的執行狀況、從各類維度分析缺陷、遺留缺陷等方面分析測試狀況。

 

項目測試完以後，軟件測試人員能夠利用項目間隔總結項目，通常是輸出業務需求爲主，方便其餘測試人員查閱。

以上就是根據測試階段分析了軟件測試人員的主要工做內容。

 

歡迎關注王豆豆的微信公衆號：資深Tester(zishentester)，瞭解更多的好文，和王豆豆一塊兒成長。