链接：https://zhuanlan.zhihu.com/p/34061937
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
第一个是业务流程；第二个业务细节
1.业务流程
对刚开始入职的新人来说，刚开始一定是先从公司业务框架和业务流程学起，这个时间段需要做的就多看，多问，多做。
01 多看
多看指的是多看公司需求文档，需求文档包括任何一切有关公司业务的文档，可能是公司业务背景，公司框架说明，以前的测试用例，测试报告，原型图，公司系统等等。
尽自己的可能多找与公司业务相关的文档、数据查看。
02 多问
多问就是指多向同事请教，不是不耻下问，而是不要害羞上问，其他人都可能比你懂得多。
现在企业对新人，可能会安排一个老同事带你，也可能没有，直接就安排你进项目做，但前期一定会给你留一点时间熟悉公司业务，如果有同事带你，那是好运，但要明确一件事情就是别人带你，并不是他的主要工作，而是额外工作；如果没有，也不必急，学会自己去梳理，去掌握需求。
向同事问问题也是一门学问，不是遇到问题就开始问，也不是逮着谁都问，能自己解决的就最好自己解决，需要多观察，通过观察确定问问题的时机。
刚才王豆豆说过带你的工作是额外工作，如果项目任务很忙的时候，带你的测试人员既要完成平时的工作，又要解决你的问题，会给他造成一定的困扰，所以一定不要有问题就问。
王豆豆使用的办法就是：
1.先将不紧急解决的问题记录下来，然后找一个时间统一问；
2.紧急问题，如果这个问题不解决就没办法继续下面的流程，那这样的问题就必须立马解决，如果带你的人在忙着测试，那你可以先找其他人解决，如果不忙，那就正好。
王豆豆就是很好运的那个，王豆豆能这么快掌握公司业务，很大程度上都是因为遇到很nice的同事，每遇到的一个问题都能很好解决，解决不仅仅是告诉答案，而是从流程，从结构，从根本原因，从设计目的去分析这个问题，解答很详尽，基本问一次就相当于把一个流程或一个功能点吃透。
03 多做
不管你问得再多，看得再多，如果自己不动手去尝试，那都是白费。
第一个做：
看文档或系统时，动手画出大致地系统流程图来，也可以是系统框架，系统功能模块等。
第二个做：
在问问题时，记录下自己问的所有问题，避免重复问，如果你是第一次，我能给你详细的解答，但如果是第二次，那我会记得我曾经给过你解答，如果还有第三次呢？那是不是我对你的印象就不会那么好，我会觉得你对工作根本不上心。
第三个做：
执行---跑业务流程，分析流程的动作背后原因
假设公司业务有付款的功能，那就自己动手从用户注册-〉登录-〉账户存钱-〉付款的业务场景来做，一个个完整的流程跑，一边跑一边记录页面交互点，每一个动作引起界面或任务或数据库的变化，然后修改一点再跑再记录。
比如付款账户有钱或没钱的界面返回，数据库的变化，同时了解每执行一个动作，所需要的前置条件，执行所需要的数据从哪些地方取等等。
关注点较多时，不一定只执行一次就全部了解，可以多次重试，但最终结果是每一个动作，你都需要掌握，这也是我们业务细节部分需要掌握的。
2.业务细节
这个阶段一定是建立在你对公司系统框架，业务流程，产品类型都是相当清楚的前提下再关注的点。
首先要清楚什么是业务细节？
王豆豆以为业务细节就是通过表象所看不出来的，而是需要根据数据，任务，动作共同去分析的。
王豆豆目前觉得应该二个办法：
第一个方法是多跑业务流程
前面已经讲过了，根据前面所讲的方法来分析每一次执行动作，记录执行前的前置条件和取数据的表，以及执行后的变化，包含数据库，界面，测试环境记录的日志等。
第二个方法是看代码
学会看代码是每一个测试人员都应该掌握到的。
如果公司没有完整的需求文档，测试人员可以通过看代码分析需求，业务流程的变化，自己就能梳理出需求来。
看代码可以发现测试人员在前端和业务流程上发现不到的问题，同时还能提高测试人员在某类功能点上测试的效率。
以测试人员测试Mapping类业务为例，大家都知道Mapping（映射）是指各系统或子系统中相同点的不同映射。
例如1在A系统中表示小学生，在B系统中表示中学生，2在A系统中表示中学生，在B系统中表示小学生，在A系统中输入1，在B系统界面需要显示小学生。
如果要测试这样的业务，功能测试至少需要二条测试用例来覆盖，那如果是看代码呢，是不是直接就可以看出来了，你又可能会说不就是多二条测试用例么？那如果这样的Mapping值很多呢，功能测试就需要测试很多次，而通过看代码能很快发现AB系统的映射是否正确，是不是效率提高很多。
同时看代码可以清楚更多业务设计细节和流程的跳转及条件等。
以前没有看过代码，刚开始看似确实很难，但看得越多就越容易，学会看代码的前提是对相应编程语言的基础了解，知道如何使用。
以上就是王豆豆熟悉业务的方法，欢迎大家和我讨论更多更有效的方法。