1、熟悉项目的业务
多问产品经理，自己多想，如果能将业务讲给别人听，自己顺几遍，基本可以判定了解很大一部分。再通过每次提测，加深自己对被测系统的理解。再不济，可以写出来，每天看几遍，这几个步骤基本能熟记于心了。
2、测试用例设计能力
用例设计能力是最重要的了，奈何都不写，不用写，领导不需要写，写也不看，嗯...
总之，借口总比办法多。
**两点：
熟悉业务流程闭环，
灵活应用用例设计方法，
3、注意数据流转
三类数据：新数据，历史数据，脏数据；
对于新数据，就是要把本次提测中涉及的点，全部走通，走对；
对于历史数据，在新版本上操作历史数据，观察有什么问题；
对于脏数据，可以在备注中加上标记，防止测试人员当成 Bug。
数据怎么流转的，客户端的数据通过什么协议传给服务端，中间又经过哪些中间件，用了什么数据库。数据库中的数据又是怎么相互流转的，又是怎么传回客户端展示给用户的。
4、多向同事请教各自负责的业务
基本上，我们都会对自己所测业务比较熟。但，同事测的业务，与我们也有很大的关联。如果能做到交叉测试，确实降低所做业务的盲区，这样我们也能考虑更全面了。
就算不需要你去测试某些模块，也要清楚自己当前测试模块的上下游，上游什么操作影响我这里。自己的模块影响下游的哪些模块。
5、养成记录的习惯
这里说的纪录，不单是指记录自己未发现的问题。还可以看其他人的测试用例、测试报告，这样我们也能举一反三，使用到要测的系统中。
以前上线出现的问题重点记录，分析，上线出现的问题基本是用户常用的功能。分析，为什么会漏测，业务不熟覆盖不全，还是用例没有设计到，还是场景少了等。
6、反向思维
两点：
针对客户，
针对捣乱的人 - 安全测试，
产品做出来给谁用，你就把自己当成真正的客户。试试去做客服，看看客户反馈回来什么问题，像以前我们做超市收款机，自己亲自去体验一下超市收款，在这过程中，想想什么是核心的业务，哪些操作可以优化，哪些操作是需要的，不需要的。
产品做出来的，别人眼红，得防吧，害人之心不可有，防人之心不可无。
标签：模块,业务,自己,用例,测得,测试,全面,数据 From： https://www.cnblogs.com/wwho/p/16943445.html