这些天，我们组有个同学转岗，从专项测试转做系统测试。在跟他面谈之后，发现他对专项测试有所误解，我就想起来了这个话题。之后也组织团队讨论了这个话题，让大家也从内心中思考下这个问题。同时，也发现了一个附加的有趣问题，一个应届毕业生，回学校的时候，同学问起他是做什么的，他应该怎样说呢？
据我的这个应届毕业生的新同事，说当时的情境是这样的，他说，他是做专项测试的。同学说，哦，不就是测试么。他又说，不是，我们会开发工具，找性能问题。 同学又说，哦，测试开发？ 当时他竟无言以对。
对的，专项测试是什么？系统测试是什么？
有人说，测试比喻成医生，那么系统测试是体检医生，全科医生； 专项测试是专科医生，手术医生，测试开发则是医疗设备的设计和开发商。
有人说，测试比喻成忍者（火影忍者之类），系统测试是普通忍者，系统测试leader是火影，专项测试是暗部，专项测试leader是暗部头目。
有人说，测试必须成兵，系统测试是步兵，炮兵，专项测试是特种兵，测试开发是工程兵。
有人说，测试三大黄金职位，安全，性能，自动化。安全和性能归属的就是专项测试。
比喻都很生动，但我对这些职位的理解，源于历史。
只有一个职位：测试
据说盘古初开，不对，据说应该是大家发现需要有个专人验证自己的软件，因此就有专门的开发去做这个事情，慢慢测试这个岗位就从开发中分离出来的。分离出来，发展并形成独立的评价体系和目标。所以最初职位只有一个称呼，测试。
测试开发
然后HR发现，测试这个岗位招人很难。因为大家不懂和误解测试，认为测试就是点点鼠标的事情，所以招来的都很难符合技术上面的要求。不难理解，原本从开发分离出来的测试，开发技能的要求必定是不缺的。面对这个情况，有两个选择，一个是让测试确实退化成只做点点鼠标的工作。 二是再来一个职位，这个职位我们称为测试开发。挂上开发的羊头，招开发做测试。所谓不会测试的开发不是好测试。这两个选择，相信有点年岁的测试都知道。
专项测试
在很早之前，除了后台测试会测试性能，PC QQ根本就没有测试会测前端的性能，前端开发也没有会专门负责前端性能的。大家凭借对自己代码的自信，hummer框架的强大，相信性能不会是太的问题，况且，这是PC呀。但是，慢慢，随着PC的机器性能长尾越来越长，反馈QQ卡顿的用户就越来越多。因此QQ项目组成立了性能的虚拟组，里面有测试，有开发。大家集中精力去解决这些问题。但是也发现，问题仿佛永远解不完，每次上新的功能，总对性能有所挑战。慢慢这个虚拟组也就确定下来了。里面的测试，也从日常的测试工作中分离出来，变成我们早期的专项测试。但事实上，更早期的专项测试一早就存在了，并且成长迅猛，早早就脱离了测试部门，那就是“安全”。
这样总结起来，每次分离，应该都是职位中内在不同技能体系的成长导致的。系统测试是开发的测试技能的分离， 测试开发是测试的开发技能的分离， 专项测试则是测试与开发中的专项技能的分离。专项技能包括，安全，性能等等。
那样上面的问题也就解决了。专项测试是对专项技能深入理解，负责产品专项质量的测试， 存在是因为这个技能体系庞大，深入，没有专职人员无法应对。价值则是从效率和质量上说，守护专项质量的同时，提升其效率。
那对比系统测试，确实专项测试需要更加专精于专项技能，但是测试本身的能力也不能忽略。所以从某程度上说，专项测试要求更高更严格。当然，因为专项技能的技术深度也决定，专项测试相对来说，也不那么容易被应届毕业生降纬攻击。（降纬攻击，简单来说就是一个应届毕业生发现的BUG的数量和质量都远超一个两三年工作经验的测试。）
那么何为优秀的专项测试呢？一个专项测试要去做的三个事情出发，1.发现，2.分析，3.推动。那么对应引申出来三个技能，并且技能之间相互重合，去支撑这些“事”。
发现问题，主要是测试技能和专项技能的辅助，一个专项测试，要懂得基于可预见的性能风险去测试对应的场景。例如在测试图片压缩的时候，要考虑机型兼容风险，对前端高压场景的相互影响：如登陆等。另外就是，熟悉用户的行为与心理，举例之前手Q的原图接收，点击小图就直接展示原图，这时作为专项测试的你要能意识到，5M到10M的原图！？在手机终端接收，用户的心理是真的要原图么？还是要一张相对清晰与屏幕尺寸一样的图片。这里有些想法，当然需要专项技能的支撑的，例如理解何为高压场景，高CPU, 高GC, 高磁盘读写的场景等等。
分析问题，发现了问题之后，毫无疑问就是要分析问题了。就以性能专项为例，我们发现运行几个核心场景后，APP必然OOM。那应该是内存常驻或者内存泄漏导致的，这是可能会用MAT去做分析，定位究竟是什么问题导致的。然后应该是解决问题，虽然这一般都不需要专项测试去做。但是前期的专项测试，尝试解决这些问题，来验证自己的想法和思路，似乎是不能避免的，不然分析问题的自信从哪里来呢？
推动问题，推动似乎是什么岗位都需要具备的技能，但是专项测试更加需要。原因很简单，因为大部分人，都很难意识到专项风险对产品带来的灾难有多大。因此推动分两种，一种是利用技术面的分析来推动，一种是利用产品面的方式来推动。例如，前面内存的例子，分析定位到内存泄漏的问题原因，让开发去改，属于技术面推动。而产品面推动，则是证明这个问题对产品，对用户影响的严重性。无论哪种，都需要严密的逻辑和成熟的沟通能力。
总结下，专项测试要求高，压力大，“脸皮厚”，但是专项领域无疑是拓展测试领域的一个非常好的方向。放弃专项领域的拓展与深挖，就相当于放弃了一片森林。我个人起码是这样认为的。如果有同学再问你，专项测试是做什么的， 你可以说，搜索我这篇文章或者简单告诉他，我是有“专项技能”的测试。
