奇技指南
在上篇文章中笔者介绍了《再谈软件测试经验图谱》，本文趁热打铁，继续聊聊这个图谱的第二层级之硬技能，希望能继续引起共鸣。
本文来自公众号“sylan215”
硬技能有哪些？
先上干货，下图是我对硬技能做得分类：
今天我主要想聊聊硬技能之业务逻辑。
业务逻辑的重要性再怎么强调都不为过，可以直白的说，我们所有的工作都是为业务目标服务的，所以一定要明白这个前提。
既然业务目标是重中之重，那么对业务逻辑的熟悉程度当然是越高越好了，只是这么去形容，没法量化，所以今天我提供两个量化的标准。
1
一个标准是从广度方面去衡量
广度又可以分成体、面、线、点这么几个级别。
体，就是从公司层面去考虑对业务了解的广度。
比如北境是一个大公司，临冬城和绝境长城是两个业务，我是临冬城的大厨，我到南境后，不管我告诉别人我是大厨，还是临冬城来的，在对方眼里，我都是北境的人，那么关于北境公司的一切问题都可能袭来，比如：
你们老板身价多少？
你们那个路由器有内部价不？
你们公司招保洁不？
龙妈是囧恩·雪诺的姑姑不？
记住，这时候千万不要去抗拒、去解释，事实证明所有的狡辩都是徒劳，我们给出答复就行了，对于自己不清楚的，就是自己需要搞清楚的。
面，就是从业务部门层面去考虑对业务了解的广度。
比如我是北境公司绝境长城部门的学士，那么对于北境临冬城的人来说，才不管你是学士还是战士，反正你是长城的人，你代表的就是长城这个部门，他们会问一切和这个部门业务相关的问题，比如：
你们新版的主界面好丑，是测试设计的吧？
你们那个可以抢钱的功能抢的钱太少了，可以增加十倍么？
你们功能是不是没经过测试？我经常点点点然后就崩溃了。
长城能挡住夜王不？
记住，千万不要解释说你不是设计师，不是产品经理，你就默默的记下他们的问题去跟进解决就是了，你这时候就代表的是这个业务。
线，就是从职能层面去考虑对业务了解的广度。
比如我是测试工程师，那么对于同一个业务内的人来说，测试相关的问题我都多少知道一些，其他角色的人会问你一切和测试相关的问题，比如：
这个模块现在测试进度如何？
这个性能测试做了么？
为什么这个 bug 又漏出了？
为什么这个项目还没安排人测试？
千万不要去解释说这个模块不是你测的，你就去找对应的测试去确认问题就好了，或者让对应测试负责人过来对接，因为你这时候代表的就是测试部门。
点，就是从个人工作职责去考虑对业务了解的广度。
这次终于到自己最擅长的事情了，这个指的就是自己日常工作所负责的具体项目，所有自己经手的项目逻辑都要非常熟悉，所有经手过的项目之间的内在关联关系要进行清晰的梳理，在出现任何问题时，都会有人去找你问各种问题，比如：
我这个功能怎么和预期不符，你看下是不是你的逻辑影响的？
外网出现了一个反馈，你要看下是设计如此还是确实逻辑 bug？
用户这样的操作场景，咱们当时为啥没考虑到？
这个场景操作下，不是因为得到 A 的值么，为啥返回的是 B？
这次当然更没法解释了，自己职责范围内的事，必须要比任何人都更加的清楚，不会的赶紧加把劲搞明白。
总之，我们可以通过体、面、线、点的层次划分，去分别衡量自己对业务了解的广度（不出意外，大部分人都是集中在点的层次，并且还不一定达到熟练，所以要做的事情很多）。
2
另一个标准是从深度方面去衡量
深度可以分为表示层、逻辑层和数据层这三个层次。
具体的解释，我之前在文章《如何利用分层测试概念设计针对性测试用例》已经做了详尽的说明，可以点击链接再回去回顾下。
总之，我们可以借助这三个层次的概念，去评估我们对业务逻辑的挖掘到底够不够彻底，到底够不够深入，这也就是我说的深度。
以上，其实我本来打算一次性把硬技能的五个方面全都说完呢，回头一看已经写了 1000+ 字了，剩下的还是等下次再详聊吧。对于本次提到的广度和深度分析的两个理论工具，不知道你是否认可？或者你都是用什么标准来进行衡量的呢？
联系客服
