身处职场，学习新业务在所难免，尤其是测试人员，具备良好的业务知识是我们做好质量保障的前提，不管是职场「新人」还是「老人」，快速熟悉业务的能力都是不可或缺的，这是我们安身立命的根本。
但，这样的能力并不是很显性，笔者有着十几年的测试经验，负责过 C 端、B 端和 G 端的业务，本文尝试梳理出一些快速熟悉新业务的方法，希望能够带给大家一些启发。
有两种学习模式
在学习新业务时，通常有两种模式：
- 授课式： 老师/师兄/师姐带着你学习，言传身教划重点，苦口婆心加考试；
- 自学式：自己看一堆的学习资料、测试沉淀、业务文档，有问题再找人问；
授课式是被别人带着走，自学式是按自己的方式走。从人性的角度来讲，显然有人教更好，也更快，直接告知重点，躲避深坑，有老师傅带着一路过关斩将，打怪升级。
可事实上，专家没那么多，也没那么闲。因此，大部分情况下，我们都处于第二种：自学式， 师傅领进门，修行在个人，按自己的方式学习，方法就尤为重要了。
要学会打怪升级
当个人修行时，学习跟打怪升级似有异曲同工之处。
不停重复打怪的过程，就是积累经验的过程。业务中的新怪层出不穷，都带有新的技能，那么，要想打败它，就得提升自己的技能。不同级别，你面临的怪是不同的，晋级之后，再遇新怪，我们总要问一下：这是个什么？我要怎么打败它？打败它之后，我会获得什么技能？
这很像保安师傅的哲学三问：你是谁？从哪儿来？到哪去？
如果是唐僧，他会这样回答：贫僧法号三藏，自东土大唐而来，要往西天取经去。
如果是我们的「新业务」，应该思考得更多一些：
你是谁？
- 新业务是什么？在公司那么多产品里面处于一个什么样的位置？前台？中台？后台？
- 它依赖谁？谁依赖它？它面向的用户是 B 端？C 端？还是 G 端？
- 它的产品形态是 APP？小程序？网站？H5？PC客户端？公众号？还是接口？
从哪儿来？
- 为什么会有这项新业务？它的定位是什么？
- 价值是什么？衍变路径是什么？
到哪里去？
- 新业务的目标是什么？
- 发展路径是什么？
- 阶段性目标是什么？
所以，学习新业务就像打怪升级，搞清楚这三个业务背景问题，会让你接下来进入业务细节更加胸有成竹。
熟悉业务三部曲
1、看懂业务：由表及里
① 看功能：从直观的角度来看，新业务展现的产品功能和业务规则是什么？
比如电商大促，各种优惠商品直接打折降价，再叠加平台的满减活动，再叠加 88 会员的折扣等等，你首先得理解这些产品功能和业务规则。
② 看结构：从业务的结构来看，新业务在公司的整个业务板块中处于哪一层，它依赖的上下游业务是什么？
③ 看细节：从产品的细节来看，每个操作步骤都会包含很多的系统交互。
比如上面提到的优惠业务，包括了：单品优惠、商家优惠、平台优惠。那么大促期间，这些其实是混合在使用的，每一种优惠都会有不同的应用场景；那么，每一种优惠它的操作入口， 它涉及到的交互系统有哪些， 他们通过什么接口进行交互等等，都是要去熟悉和学习的。
④ 从用户角度看：不同的用户对产品的功能会有不一样的诉求，也决定了我们在进行业务测试的时候，除了业务的准确性外， 测试重点也不同。
比如电商大促， 对于招商系统而言，它是 To B 的业务，主要的诉求在于：系统稳定、便于操作，用户量可能在百万级别， 用户的主要使用场景是通过 Web 端来操作；
对于交易系统而言，它是 To C 的业务， 主要的诉求在于：系统稳定、实时性要求高（各种优惠及时更新、库存更新等）、并发量高，用户量在千万及亿级别，用户的主要使用设备是通过手机 APP 端来操作；
当了解我们的用户人群后，在做基本的业务功能验证后，还需要验证非功能性的需求，比如高并发如何保证系统的可靠性， 比如大促期间的实时性(库存、优惠等)，如何来保证准确性？不同的客户端，需要做哪些兼容性验证？
⑤ 从业务价值看：谈业务价值，其实就是谈我们这块业务存在的目的，它能带来什么价值，它的目标是什么？是补充公司的业务空白，扩大商业版图，还是为公司增加营收。
当一个产品的目的是为了快速占有市场， 那么，我们就需要快速迭代， 测试的侧重点，就会在效率上，如何在保证质量的基础上，快速发版， 可能会忽略一些并发性，或者是用户体验的功能；如果是一个稳定的业务，比如电商大促，这么几年走下来，它就是个稳定的业务，那如何提升用户的体验，保证实时性，就会成为我们的测试重点；
⑥ 从盈利模式看：在资本市场中，不盈利的产品很容易就被淘汰掉。
我们要熟悉的新业务的盈利模式是什么？是卖产品？卖服务？还是卖广告？于测试人员而言， 根据不同的盈利模式来进一步了解产品的价值，反向驱动我们去思考业务的测试重点，这是一件很有价值的事情；
2、看透业务：系统剖析
看懂业务之后，我们需要看透业务，通过解剖系统来加深对系统的理解。
在这个过程中， 我们需要了解到：
① 所负责业务的系统交互
系统如何和上下游系统交互，这种更直白的是，看一下时序图，清晰的了解各个系统之间是通过什么接口进行交互的，交互的出入参是什么？带着业务验证的目的来了解系统。
② 系统内部各个模块的划分，哪些是公共模块，哪些是业务实现层？
从上面俩张图都可以看出应用中各个模块所承担的功能，以及一些公共的服务及流程，我们所负责的业务流程是不是也是这么走的，一旦改动到公共模块或者公共服务的话，我们除了验证当前的业务流程外，还需要验证哪些关联流程；
③ 数据流向怎么走？数据如何变更？
每一条数据都有它存在的意义，每一个字段都有它的特定含义，不同的表代表不同的含义，不同的字段也有不同的业务逻辑。我们需要将业务流和背后的数据流关联起来，以便更好的理解每一次的数据变更，更好的为后续做功能测试打下基础，知道哪些是关键验证字段， 避免功能场景遗漏。
如果很有幸，你一进来，跟进的就是一个纯新的系统，从需求到方案设计到系统上线的话，那你真的很幸运，可以从头了解这个系统的搭建，按上面的方式来了解你即将负责的系统及业务；
假如你负责的是一个老的业务系统，要在老的系统上做迭代，那么， 你仍然可以遵循上面的 3 个方面来梳理你对业务的理解。同时，找历史资料，找资深的同学来了解系统架构、系统模块功能、数据流等， 请多问、问、问！
这个阶段，还有一个问题没讲：问题排查的方案及手段，这些内容接下来我们会讲到。
3、看好业务：动手实践
在看懂业务、看透业务之后，我们就需要履行本职：看（kān）好业务了，假设我们要独立测试这块业务，要怎么测试，怎么设计测试用例，用什么方式来进行测试，如何验证功能的准确性，遇到错误，如何排查呢？
基于上述问题，我们需要做的事情：
① 测试用例设计：基于产品的 PRD，研发的设计方案及我们自己对系统的了解、时序图等进行用例设计，考虑基本的：正常流、分支流、异常流三类。对于本次的改动范围要评估是否需要做老功能的回归， 对于一些新增的开关、或缓存等，要做对应的专项验证；
② 测试方法：手工验证 or 自动化验证？
- 数据准备：是否已有现成的工具或脚本可以快速生成测试数据？如果没有的话，怎么造测试数据？(造数据的过程？)
- 结果验证：业务展示是否符合预期，DB 中的数据是否符合预期？
③ 是否需要做非功能性验证：兼容性、安全性、性能压测等；
④ 问题排查：遇到问题，如何排查？（定位根因，积累经验的最快速的方法）
- 系统现象：页面报错、服务调用失败等这一类都是直观的展示，还有一类是流程链路比较长，看起来页面都是正常的， 但是 DB 数据不符合预期，会导致下一个环节报错的场景；
- 日志排查：根据业务操作，看下后台日志访问，有无错误日志打印，日志告诉你错在哪一行，根据日志的错误提示，去对应的分支代码中查看对应行的代码；
- 数据排查： 根据数据反查， 根据你对系统的了解， 梳理哪里会涉及到这块 DB 数据的变更，反查回去看看具体的代码逻辑，看具体走到哪个分支里去，再参照对应的系统日志，跟踪定位到具体的出错的代码行；
- 翻看代码：不管是从日志排查还是根据数据排查， 都需要去翻代码看看， 有时候，这一行报错，不是因为这一行有错，而是中间过程中，由于入参问题，导致走到其他分支了，这种时候就需要深究下去，到底是从哪里开始出错。
于测试人员而言，不一定要完整的定位出根因，但是希望通过这样的排查过程，对系统的实现有所了解，在后续的业务改动中，也能够了解到改动影响的范围，有自己的判断，而不是等待他人的输入。
当我们能完整的走过上面的三步，再回过头来看业务，可能会有一种恍然大悟的感觉，会有一种“原来如此”的感悟。但我们可能仍然只是处于刚入门的阶段，后续需要通过不断的重复、加深记忆的过程来不断的完善我们对业务的了解。
我们的脑海中对业务的构建，是不断具象的过程，其实，也可以同步思考下：我们原来的测试模式有没有可以优化的地方？我们有哪些步骤是可以通过工具化的手段来实现的？假设要你来做一个提效的工具或者要提升你负责模块的项目质量， 你会从哪些方面入手，你需要做哪些的知识储备。。。等等，通过不断深入业务，深入系统，深入思考，才能更好的激发创意，为工作带来持续的正反馈！
总结
新业务的学习，是一个不断积累的过程，只有在经过不停地学习、实践、问题排查，这样的重复过程后，才会加深我们对业务的理解。随着业务知识、系统架构等方面的提升，也会反哺我们对业务的了解，从而达到陌生到熟悉的变化。
最后，再送大家一句话：好记性不如烂笔头，随时记录，思考，梳理，重构，会有惊喜噢！