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