1、这个bug我这边重现不了程序员
解决办法工具
Bug应该简明扼要,重点突出。若是描述存在歧义,必定要总结并尽快改进。有时会遇到几率性的bug,要告诉开发几率是多少,尽量多的提供重现的条件。测试
在复现问题时,但愿能大体判断几个问题点,而后和测试人员沟通下,须要如何捕获信息,捕获那类信息?是否是提供debug版本进行复现,或者根据预判的点增长打印信息版本进行复现?spa
2、这个不是代码问题,需求这么定义的debug
解决办法开发
需求也是人定的,若是以为有异议,能够找需求人员询问清楚,为何这样定义,把本身的想法告诉他们,看他们怎么决定。若是被需求说服了固然是最好的,若是本身仍是不一样意需求的见解,需求又不一样意个人提议,那只能听他的,毕竟权力在他那里。可是咱们能够保留交流的记录,证实曾经在这里发生过歧义。get
3、这块是别人负责的,我负责的部分没有问题自动化
解决办法自动化测试
若是bug是由开发的项目经理来分发到程序员,那就是项目经理来面对这样的问题,而不是测试。固然,项目经理固然有项目经理的处理办法。但是,测试遇到这样的问题怎么办呢,把负责相关内容的开发都邀请到一个讨论组里,让他们本身讨论,这样更清楚,没必要在测试这里中转。若是他们都以为代码没问题,而我也有强有力的截图和真相,那就只有上交给上级领导,让他们来决定怎么解决。软件
4、有问题吗?(也就是开发不认为这是个问题)
解决办法
测试人员必定比开发要敏感,对bug的容忍度也要低一些。特别是一些不符合用户习惯的bug,开发总以为无大碍。好比,一个列表默认的宽度过小了,致使初次打开,有一些内容被隐藏在后面,可是这个宽度能够手动调节。开发以为问题很小,不影响功能,并且也有解决办法,因此不认为是bug。这个时候,就要发挥测试的本事了,嘴甜一点,说说好话,态度柔和一些。由于既然是小问题,解决起来必定不难,耐心地催开发的改过来就好。催一次不行催两次,记住态度必定要好。
5、用户不会像你这样操做的!
解决办法
用户怎么操做,谁都预料不到。咱们不可能覆盖全部可能性,可是大多数用户会出现的操做,咱们固然要测试。慢慢地把开发从代码的世界里带出来,带到用户的世界里,让他换个角度思考问题,毕竟软件开发不是为了实现功能,是要知足用户需求的。若是最后仍是没能说服他,第一贯上级反映,第二作好沟通的记录,未来备份在测试报告里。
以上就是软件测试中遇到的常见问题及沟通方法,若是以为麻烦能够考虑用一些APP自动化测试工具:www.ineice.com