1.没有什么常理上不可能发生的bug
2.时刻要记住测试的是程序,是代码逻辑,一切都有迹可循,而不是一个自然事物
3.前期的用例编写尽可能细腻,覆盖度全面,并提前清除需求不确定项
4.测试过程中要进入用例深处,同时也要跳出用例之外,在测试后期要有段时间专门站在用户角度使用软件
5.清楚你所测项目的核心业务是什么,需要保证核心业务。明确核心业务,需要你理解你测试的东西的作用,从用户角度去确定什么是最重要的,什么是次重要的,而不是想当然
6.某种意义上,bug没有偶现,只有在一定条件下出现的必现,所以不要轻视每一个突然出现的错误现象,尤其这个现象一旦出现就会比较严重时,要保持警惕性和敏锐性
7.很多遗漏bug有时候不发生在你经常盘查的地方,而是在你完全没有考虑到的地方,时刻记得这一点 ,在测试过程中阶段性问自己是否有那些case完全没想到,有利于避免严重问题遗漏
8.在你提bug的时候,一旦有“这问题太小了,开发是不是不愿意改”的想法时,那么bug一定要提,测试负责的是问题暴露,先暴露出来
9.之所有有第五条,在于有时候你以为问题比较小,其实有可能会在别的场景产生别的大问题
10.保持测试环境的稳定性对于测试的进行十分重要,在稳定的环境下测试有利于排除外因,定位问题
11.根据具体项目以及具体测量周期,调整自己的测试节奏,保持头脑清醒,把控测试节奏,清楚自己测到哪种地步
12.一些测试盲点:容易忽略可变化的大前提条件,比如环境、当前定位等
13.遇到问题不要慌,问题再严重但是如果已经在测试周期发现,那么就在可控范围内,要做的是冷静收集信息,确认问题根源,记录并通知RD
14.在测试期间,阻碍整体测试进行下去的问题严重性会更大一些
15.如果是在线上反馈之前发现了一些严重问题,那么此时第一要务是要通知相关RD,进行回滚等操作,先处理线上问题,并事后复盘
16.h5/web/App测试,其实都是客户端+后端测试,即前端+接口测试
17.适时地进行探索性测试,不去死板遵循前期的测试用例
18.bug是有优先级的,需求也是有优先级,要有这个意识,如果全部不分优先级一把抓,对于不同优先级的位置分配不同的精力,不只是测试要这样,人的精力是有限的,时间是有限的,在有限时间的保证核心功能正常
19.一般来说,需求-需求审查-用例书写-接口测试-功能测试,对于刚接手的需求迭代的话,需要在自己理解整个系统的前提下,自我评审下这个逻辑是否有问题,不清楚的地方与PM确认;接口测试期间与RD确认接口设计,尽可能少地把产品设计问题和接口设计问题拖到功能测试阶段
20.问题记录很重要,记录在缺陷管理工具上,包括一些讨论过程讨论结果,有利于后期问题跟进
21.是人都会犯错,不一定谁都想犯错,给RD信任,对RD同学好一些体谅一些。。
22.5W1H原则与二八定律
23.自我提升,工具学习与代码学习
24.双客户端对比测试一个很有用的测试手段,某端出现了问题后要留意另一客户端是否有同样的问题
文章来源:博客园 版权归原作者所有
上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编,我们将立即处理。