第一个是业务流程；第二个业务细节

1.业务流程

对刚开始入职的新人来说，刚开始一定是先从公司业务框架和业务流程学起，这个时间段需要做的就多看，多问，多做。

01 多看

多看指的是多看公司需求文档，需求文档包括任何一切有关公司业务的文档，可能是公司业务背景，公司框架说明，以前的测试用例，测试报告，原型图，公司系统等等。

尽自己的可能多找与公司业务相关的文档、数据查看。

02 多问

多问就是指多向同事请教，不是不耻下问，而是不要害羞上问，其他人都可能比你懂得多。

现在企业对新人，可能会安排一个老同事带你，也可能没有，直接就安排你进项目做，但前期一定会给你留一点时间熟悉公司业务，如果有同事带你，那是好运，但要明确一件事情就是别人带你，并不是他的主要工作，而是额外工作；如果没有，也不必急，学会自己去梳理，去掌握需求。

向同事问问题也是一门学问，不是遇到问题就开始问，也不是逮着谁都问，能自己解决的就最好自己解决，需要多观察，通过观察确定问问题的时机。

刚才王豆豆说过带你的工作是额外工作，如果项目任务很忙的时候，带你的测试人员既要完成平时的工作，又要解决你的问题，会给他造成一定的困扰，所以一定不要有问题就问。

王豆豆使用的办法就是：

1.先将不紧急解决的问题记录下来，然后找一个时间统一问；

2.紧急问题，如果这个问题不解决就没办法继续下面的流程，那这样的问题就必须立马解决，如果带你的人在忙着测试，那你可以先找其他人解决，如果不忙，那就正好。

王豆豆就是很好运的那个，王豆豆能这么快掌握公司业务，很大程度上都是因为遇到很nice的同事，每遇到的一个问题都能很好解决，解决不仅仅是告诉答案，而是从流程，从结构，从根本原因，从设计目的去分析这个问题，解答很详尽，基本问一次就相当于把一个流程或一个功能点吃透。

03 多做

不管你问得再多，看得再多，如果自己不动手去尝试，那都是白费。

第一个做：

看文档或系统时，动手画出大致地系统流程图来，也可以是系统框架，系统功能模块等。

第二个做：

在问问题时，记录下自己问的所有问题，避免重复问，如果你是第一次，我能给你详细的解答，但如果是第二次，那我会记得我曾经给过你解答，如果还有第三次呢？那是不是我对你的印象就不会那么好，我会觉得你对工作根本不上心。

第三个做：

执行---跑业务流程，分析流程的动作背后原因

假设公司业务有付款的功能，那就自己动手从用户注册-〉登录-〉账户存钱-〉付款的业务场景来做，一个个完整的流程跑，一边跑一边记录页面交互点，每一个动作引起界面或任务或数据库的变化，然后修改一点再跑再记录。

比如付款账户有钱或没钱的界面返回，数据库的变化，同时了解每执行一个动作，所需要的前置条件，执行所需要的数据从哪些地方取等等。

关注点较多时，不一定只执行一次就全部了解，可以多次重试，但最终结果是每一个动作，你都需要掌握，这也是我们业务细节部分需要掌握的。

2.业务细节

这个阶段一定是建立在你对公司系统框架，业务流程，产品类型都是相当清楚的前提下再关注的点。

首先要清楚什么是业务细节？

王豆豆以为业务细节就是通过表象所看不出来的，而是需要根据数据，任务，动作共同去分析的。

王豆豆目前觉得应该二个办法：

第一个方法是多跑业务流程

前面已经讲过了，根据前面所讲的方法来分析每一次执行动作，记录执行前的前置条件和取数据的表，以及执行后的变化，包含数据库，界面，测试环境记录的日志等。

第二个方法是看代码

学会看代码是每一个测试人员都应该掌握到的。

如果公司没有完整的需求文档，测试人员可以通过看代码分析需求，业务流程的变化，自己就能梳理出需求来。

看代码可以发现测试人员在前端和业务流程上发现不到的问题，同时还能提高测试人员在某类功能点上测试的效率。

以测试人员测试Mapping类业务为例，大家都知道Mapping（映射）是指各系统或子系统中相同点的不同映射。

例如1在A系统中表示小学生，在B系统中表示中学生，2在A系统中表示中学生，在B系统中表示小学生，在A系统中输入1，在B系统界面需要显示小学生。

如果要测试这样的业务，功能测试至少需要二条测试用例来覆盖，那如果是看代码呢，是不是直接就可以看出来了，你又可能会说不就是多二条测试用例么？那如果这样的Mapping值很多呢，功能测试就需要测试很多次，而通过看代码能很快发现AB系统的映射是否正确，是不是效率提高很多。

同时看代码可以清楚更多业务设计细节和流程的跳转及条件等。

以前没有看过代码，刚开始看似确实很难，但看得越多就越容易，学会看代码的前提是对相应编程语言的基础了解，知道如何使用。

以上就是王豆豆熟悉业务的方法，欢迎大家和我讨论更多更有效的方法。