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