今日的工作时间过的很快，感觉自己想看的自考书甚至没有翻看书本，就到下班时间了，仔细想想，自己的测试方法与取舍方法有多出不合理的地方，下面一一列出：
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 步走，第一步首先执行自己想到的测试点，测完一个点，记录下这个测试点，直到基本完成测试，第二步，暴力随机测试，想起一个测试点，先记下测试点，然后进行测试，再想起，再记下，再执行测试，反复。