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.双客户端对比测试一个很有用的测试手段，某端出现了问题后要留意另一客户端是否有同样的问题
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
