1、這個bug我這邊重現不了程序員
解決辦法工具
Bug應該簡明扼要,重點突出。若是描述存在歧義,必定要總結並儘快改進。有時會遇到機率性的bug,要告訴開發機率是多少,儘量多的提供重現的條件。測試
在復現問題時,但願能大體判斷幾個問題點,而後和測試人員溝通下,須要如何捕獲信息,捕獲那類信息?是否是提供debug版本進行復現,或者根據預判的點增長打印信息版本進行復現?spa
2、這個不是代碼問題,需求這麼定義的debug
解決辦法開發
需求也是人定的,若是以爲有異議,能夠找需求人員詢問清楚,爲何這樣定義,把本身的想法告訴他們,看他們怎麼決定。若是被需求說服了固然是最好的,若是本身仍是不一樣意需求的見解,需求又不一樣意個人提議,那隻能聽他的,畢竟權力在他那裏。可是咱們能夠保留交流的記錄,證實曾經在這裏發生過歧義。get
3、這塊是別人負責的,我負責的部分沒有問題自動化
解決辦法自動化測試
若是bug是由開發的項目經理來分發到程序員,那就是項目經理來面對這樣的問題,而不是測試。固然,項目經理固然有項目經理的處理辦法。但是,測試遇到這樣的問題怎麼辦呢,把負責相關內容的開發都邀請到一個討論組裏,讓他們本身討論,這樣更清楚,沒必要在測試這裏中轉。若是他們都以爲代碼沒問題,而我也有強有力的截圖和真相,那就只有上交給上級領導,讓他們來決定怎麼解決。軟件
4、有問題嗎?(也就是開發不認爲這是個問題)
解決辦法
測試人員必定比開發要敏感,對bug的容忍度也要低一些。特別是一些不符合用戶習慣的bug,開發總以爲無大礙。好比,一個列表默認的寬度過小了,致使初次打開,有一些內容被隱藏在後面,可是這個寬度能夠手動調節。開發以爲問題很小,不影響功能,並且也有解決辦法,因此不認爲是bug。這個時候,就要發揮測試的本事了,嘴甜一點,說說好話,態度柔和一些。由於既然是小問題,解決起來必定不難,耐心地催開發的改過來就好。催一次不行催兩次,記住態度必定要好。
5、用戶不會像你這樣操做的!
解決辦法
用戶怎麼操做,誰都預料不到。咱們不可能覆蓋全部可能性,可是大多數用戶會出現的操做,咱們固然要測試。慢慢地把開發從代碼的世界裏帶出來,帶到用戶的世界裏,讓他換個角度思考問題,畢竟軟件開發不是爲了實現功能,是要知足用戶需求的。若是最後仍是沒能說服他,第一貫上級反映,第二作好溝通的記錄,未來備份在測試報告裏。
以上就是軟件測試中遇到的常見問題及溝通方法,若是以爲麻煩能夠考慮用一些APP自動化測試工具:www.ineice.com