今日的工作时间过的很快,感觉自己想看的自考书甚至没有翻看书本,就到下班时间了,仔细想想,自己的测试方法与取舍方法有多出不合理的地方,下面一一列出:
1、我花了至少 3 个小时的时间在重现问题上,太爱钻牛角尖了,最终问题重现出,但是消耗的时间太多,成本与得出严重不成比例。也不是说得到 bug 不严重,而是完全可以用更简单的方法得到想要的重现,而不是一遍遍的手工测试。总结就是,发现了问题,假如问题比较难重现,就将这个 bug 涉及到的地方写在纸上或者文档上,一个个去验证,假如重现 bug 期间需要等待,这个时间可以去忙别的事情,而不是一直忙着这一个 bug,毕竟还有别的 bug 等着你去发现或者是你可以充实自己的时间;觉得自己关于这个 bug 实在想不起来还需要怎么重现,要么问资深同事,要么去做别的事情,因为还有别的测试用例需要执行,可能别处有更大的 bug。bug 是不能被完全测试出来的。
1.5、 当发现 bug 时,当不确定这个是不是 Bug 时,不要纠结半天,直接找产品或者 leader 或者开发人员 (某些公司产品不给力的时候,比如我们公司,听开发的话还是可以的,因为这个时候开发和你就是需求人员。)
2、我花很多时间去重现问题的另外一个 原因是,我想直接找出 bug 所在,找出根源在哪儿,想让 DEv 对我刮目相看。现在想想,结果完全没达到,不但消耗了自己大量的时间和精力,而且当刚将 bug 描述给开发人员时,还没把我辛辛苦苦找出的原因讲述,他们就说了一句 ‘我知道了,待会儿看,先记着吧’(他们确实忙,但是遇到这话郁闷死)或者 ‘这个问题我解决不了,需要某某人员配合’(经常是外包人员配合)或者 ‘嗯,这个问题我知道,下个版本会上(继续无语)’ 或者 ‘嗯,我想想,哦,我知道哪儿出问题了。(OK,我后面想要说的话就咽到肚子里去了)’。所以,第 3 条来了
3、发现 bug,自己重现一遍后,不管这个 bug 是否下个版本是否上,或者是多 small,多 basic 的 bug,统一全部录入 bug 系统,既可以作为以后系统问题的开发总结,也可以作为发现过 bug 的证据。提出 bug 后,及时提供 bug 编号给开发人员,每日回归 bug。
4、对于有用例的执行测试,严格按照用例执行(这里就要求写测试用例的时候一定要用心啊),最后有空余时间再进行自己的 ‘暴力随机测试’
5、没有测试用例的执行,比如 leader 直接告诉你,“你今日给我测试这个点,明天要上线”、ok,open 一个 excel,记录下你每个测试点。这种测试分 2 步走,第一步首先执行自己想到的测试点,测完一个点,记录下这个测试点,直到基本完成测试,第二步,暴力随机测试,想起一个测试点,先记下测试点,然后进行测试,再想起,再记下,再执行测试,反复。


↙↙↙阅读原文可查看相关链接,并与作者交流