今天我主要想聊聊硬技能之业务逻辑。

业务逻辑的重要性再怎么强调都不为过，可以直白的说，我们所有的工作都是为业务目标服务的，所以一定要明白这个前提。

既然业务目标是重中之重，那么对业务逻辑的熟悉程度当然是越高越好了，只是这么去形容，没法量化，所以今天我提供两个量化的标准。

1、一个标准是从广度方面去衡量。

广度又可以分成体、面、线、点这么几个级别。

体，就是从公司层面去考虑对业务了解的广度。

比如北境是一个大公司，临冬城和绝境长城是两个业务，我是临冬城的大厨，我到南境后，不管我告诉别人我是大厨，还是临冬城来的，在对方眼里，我都是北境的人，那么关于北境公司的一切问题都可能袭来，比如：

你们老板身价多少？

你们那个路由器有内部价不？ 

你们公司招保洁不？ 

记住，这时候千万不要去抗拒、去解释，事实证明所有的狡辩都是徒劳，我们给出答复就行了，对于自己不清楚的，就是自己需要搞清楚的。

面，就是从业务部门层面去考虑对业务了解的广度。

比如我是北境公司绝境长城部门的学士，那么对于北境临冬城的人来说，才不管你是学士还是战士，反正你是长城的人，你代表的就是长城这个部门，他们会问一切和这个部门业务相关的问题，比如：

你们新版的主界面好丑，是测试设计的吧？ 

你们那个可以抢钱的功能抢的钱太少了，可以增加十倍么？ 

你们功能是不是没经过测试？我经常点点点然后就崩溃了。 

长城能挡住夜王不？

记住，千万不要解释说你不是设计师，不是产品经理，你就默默的记下他们的问题去跟进解决就是了，你这时候就代表的是这个业务。

线，就是从职能层面去考虑对业务了解的广度。

比如我是测试工程师，那么对于同一个业务内的人来说，测试相关的问题我都多少知道一些，其他角色的人会问你一切和测试相关的问题，比如：

这个模块现在测试进度如何？ 

这个性能测试做了么？ 

为什么这个 bug 又漏出了？

为什么这个项目还没安排人测试？

千万不要去解释说这个模块不是你测的，你就去找对应的测试去确认问题就好了，或者让对应测试负责人过来对接，因为你这时候代表的就是测试部门。

点，就是从个人工作职责去考虑对业务了解的广度。

这次终于到自己最擅长的事情了，这个指的就是自己日常工作所负责的具体项目，所有自己经手的项目逻辑都要非常熟悉，所有经手过的项目之间的内在关联关系要进行清晰的梳理，在出现任何问题时，都会有人去找你问各种问题，比如：

我这个功能怎么和预期不符，你看下是不是你的逻辑影响的？ 

外网出现了一个反馈，你要看下是设计如此还是确实逻辑 bug？ 

用户这样的操作场景，咱们当时为啥没考虑到？ 

这个场景操作下，不是因为得到 A 的值么，为啥返回的是 B？

这次当然更没法解释了，自己职责范围内的事，必须要比任何人都更加的清楚，不会的赶紧加把劲搞明白。

总之，我们可以通过体、面、线、点的层次划分，去分别衡量自己对业务了解的广度（不出意外，大部分人都是集中在点的层次，并且还不一定达到熟练，所以要做的事情很多）。

2、另一个标准是从深度方面去衡量。

深度可以分为表示层、逻辑层和数据层这三个层次。

具体的解释，我之前在文章《如何利用分层测试概念设计针对性测试用例》已经做了详尽的说明，可以点击链接再回去回顾下。

总之，我们可以借助这三个层次的概念，去评估我们对业务逻辑的挖掘到底够不够彻底，到底够不够深入，这也就是我说的深度。

今日福利

【Java11期开课啦】

8大实战案例模块，历时三年沉淀，Java4.0震撼发布！

偷偷告诉你前50名，还可获得价值300元的京东购物卡呦~

如有疑问，请留言告知，或者咨询柠檬班自动化测试培训平台：www.lemonban.com官网客服哦

留言领取100G软件测试全面课程视频。