1、测试用例是测试工作的核心，写测试用例的时候建议先提取测试点，再编写测试用例。清晰且不容易遗漏。（写测试用例的过程中要不断的调整，之前用例覆盖到的测试点可以不写，覆盖率全且避免重复）
2、测试数据要尽量真实。
3、测试时考虑到了别人没有考虑到的问题点，最好要去一一和产品确认沟通过；或者是发现了设计上有不合理的地方也要指出，不要觉得测试的工作就只是找bug，要站在更高的层面上看问题。依稀记得产品经理说过的一句话：“如果开发没有发现产品设计上存在的缺陷并提出，只能说明开发没有站在一个更高的点看问题”。
4、搞清楚bug产生的根源。好处在于：
第一，你可以准确的分清该bug是前端的还是后端的，然后直接提给对应人，避免了开发之间问题转来转去。
第二，测试人员明白了bug的原因，测的时候才会去有意的创造环境，有针对的去测试，不至于很被动。
第三，自己可以有理有据的，不至于被开发怼~~。
第四，对于测试人员本身而言，会是一个很大的提升。会有一些测试人员觉得做测试，只需要把bug找出来提上去就可以了，的确这是测试的本职工作，但是你能知道bug产生的原因，在开发面前会更有说服力，在领导面前，也是一种能力的体现，对自己将是进阶高级测试的一个过程。建议多使用开发者工具分析。
5、描述bug时要准确，没必要的误导信息不要写，容易误导开发人员，毕竟开发爸爸的思维有时候很独特。。还有一点，遇到报错的时候，bug描述里可以把请求体和response里的内容一同写进去，这样开发可以很快速的定位问题，他们也更偏向于喜欢这样的测试人员。
6、心态方面：与开发沟通要掌握技巧，不要硬碰硬，站立自己的观点的同时，语气也要平和一些。还有就是提错bug的时候（可能是产品改需求未及时通知，可能是自身原因）也不要觉得很尴尬、觉得很委屈，或者是去争无畏的自尊心。在我看来做测试的基本条件之一就是心理素质要过硬。当然如果是产品改需求未及时通知，可以和产品提意见要求。
7、开发和运维之间的问题尽量让开发自己去沟通，只需要提交到测试人员这边是可测的就ok，提交过来不可测让开发去沟通，因为自己揽过来可能又说不明白，切记不要做个传话筒，除非自己很懂。
8、测试周期如果较短的话，一些偶然性问题不容易被发现，因此测试人员要尽量为自己争取测试时间，尽量不要让开发占用测试的时间。
测试小白的测试经验
1、在数据字段较多时，前后端容易取错字段
2、格式转换容易出现问题，前后端编码不一致，导致特殊符号、括号变成乱码；在测试之前要确认都会有那些特殊字符，建议是产品在原型上体现出来，开发和测试都可以注意到。
3、开发本地是好的，发布后测试是有bug的，一般有几种情况：开发的代码是否提交；运维发布的时候是否有更新修改点；开发本地环境与测试环境不一致；当然除了这三个原因，还会存在诸多因素，需要具体问题具体分析。
4、每次一轮回归测试完成，第二天来了工作量不大的情况下建议上午还是要继续测试，随机性探索性测试，很可能会找到昨天没发现的bug。需要不断循环的测试，不是说一轮测完就等着回归了~~
只是个人测试过程中的一些思考，如有错误望大家积极指正我哦~~~加油，在平凡的每一天给自己打气~~~
---------------------
作者：蒲公英上的尘埃
来源：CSDN
原文：https://blog.csdn.net/loner_fang/article/details/80705288
版权声明：本文为博主原创文章，转载请附上博文链接！
