作为一名测试人员，其真正的核心竞争力到底是什么？这个问题一直困惑着我。当我还未曾踏入这一行业的时候，听到的声音是这样的：“测试是一种很有前途的工作，需求大于供给”；也有这样的：“测试就要做接触到代码的，点点鼠标谁都行……”。

怀着对一个行业不知道是好还是坏的心理选择并进入了这个行业。期间，我承认，的确有那么一段时间，我认为作为一名测试如果能够对于代码了如指掌，能够写出一个个的工具才有可能成为武林的盟主，寿与天齐。似乎，作为测试来说最核心的竞争力就是对于代码的掌握程度，除此以外，那些什么功能测试的用例似乎就是个最低端，最没有价值的产出而已。

　　但是就我现在自己遇到和看到的一些问题和现象，我开始对自己的一些想法有了怀疑。例如：现在很多组都在做和预研一些代码级别的测试工具，例如覆盖率工具啦，代码扫描工具了（主要是遵循相关的语法规则做一些例如是否有空指针风险，是否有未定义的变量，是否if else的分支条件互斥等）、当然还有一些高端的通过业务流回溯的方式来对每一条分支进行检查，只要有风险存在就发出邮件给对应的干系人。表面看起来非常的高端，大气，上档次，一切都在自动化，一切看起来都在掌握之中。但是实际情况呢？代码在进行了自动扫描也好，覆盖率统计分析也好，最终产品外放后的质量还是体现在了功能测试的实际、实质结果上。这样说，显的有点晦涩，举个栗子吧～～～

　　XX项目，引入了hudson构建自动集成方案，并且前后台都有接入。这样，在开发提交代码转测之后，功能测试不出意外会自动进行，代码后台自动扫描，结果也会mail给对应的人。在一切具备，作为东风的版本到来之后，噼里啪啦的就开始了，然后外放，然后，然后就苦逼了，为啥？版本外放之后，游戏道具神秘消失，客户端莫名崩溃、宠物实际得到的数值与预期不一致。好吧，走紧急更新、关外网功能阀门，出公告……然后就进行了一段研发调试，测试提单，研发分析，测试分析，DAI编写，QA审计，leader审计的历程～

　　其实，在找到引起这些问题的根本原因之后，我们都会觉得，为什么？这样的问题应该很容易想到啊？我只想说，事后人人都知道赤壁之战的当晚要注意防风，不能报以黑天鹅的心态；然而在事前我们可能根本都不知道还有天鹅一说，就更加别说什么黑与白了。什么意思？别急，给我点时间打字，慢慢码～

　　首先：第一个祝福神秘消失。最后找到引起的原因为“前台客户端在网络波动较大的时候，服务器的回报没有到达客户端之前，客户端的button和相关数据没有刷新，导致玩家可以进行第二次对于button的操作，发出2个请求到服务器，服务器在处理完第一个请求，check result为success之后，扣除了玩家的初级物品，生成一个高级物品返回给玩家。注意，此时第二个请求到达了服务器，不凑巧，也是命中了成功的概率，此时服务器的处理方式为只要概率命中为了避免给我司带来损失，先扣除用于进化的低等级物品，然后再逐步扣除其余的依赖物，最终返回给玩家高等级物品。这个时候就有问题了，第一个请求的物品成功了，是需要扣除进化道具的，扣除道具后，对于第二个请求来说，实际是不满足需要的道具数的，但是后台的处理逻辑是只要命中概率，success则认为就会成功，这个时候为了避免损失，先扣物品，这个时候，到了第二步来扣除道具的时候，发现余额不足，返回失败，但是，人家第一次success成功的道具就没了～这个代码覆盖率是OK的（有对应的检查升级的用例），代码扫描也是ok的，因为判空做的很到位，但是这个问题 的root cause是设计上的缺失，导致了逻辑处理上存在问题。这个我们通过自动化，仅仅通过阅读代码扫描结果是发现不了的。只能通过用例设计的时候去发现，不凑巧，用例设计中没有这一块：弱网络的用例设计。从而，say goodbye，只能对玩家报以卖萌一笑，后台log查证再补偿玩家了～

　　其次：客户端异常崩溃。这个问题的root cause又是什么呢？先用事后的眼睛看，造成客户端异常崩溃的原因为：客户端前端的物品刷新不是实时的（这个可以理解，因为谁会闲的蛋疼，实时去跟后台做数据查询的交互，又不是对数据实时性要求很高的功能，就一个查询摆摊物品的功能，从CAP的角度来说，的确可以接受牺牲实时性。但是，就因为这个原因，当玩家选中的物品摊主在玩家点击购买前下线了，此时这个时候玩家点击购买，不好意思，空指针异常======）core。那么这个bug为啥没有通过代码前期的检查工作得以暴露呢？原因是：工具本身的不足导致在做判空检查时，遇到有break的业务流分支时，不支持业务流分支的检查（后来听说引入coverity可以解决，目前引入中，但是据说收费也不菲）。这个bug导致外网刚一更新就要走一个紧急更新，说实话，当这种情况出现多了的时候，哪怕作为测试组你前面加班个十天，半个月在项目组看来，在外人看来都觉得你们前面的付出是没有意义的，因为此时的1决定了你前面的付出等于一万个零。

好了，这样的例子不举了，总之，当我遇到的问题越来越多，对于根本原因查询进行思考后，我现在开始会问自己，作为测试的从业者来说，代码的掌握程度是否真如传说的那么高端，重要，不可替代？还是说，我们的方向错了，我们作为一名测试从业者来说，对于武器的选择上太过于神话某种道具了，以为得此神器则天下可定？可实际结果，往往大相径庭。

　　那么说了这么多，对于测试来说最主要的核心竞争力是什么呢？我个人觉得是否可以理解为以下几点：

　　1、快速学习和思考的能力，此特技主要用于需求快速理解，提升问题发现深度和效率，广度。

　　2、问题发散能力。此特技主要用于对于影响面的归纳和总结，覆盖。

　　3、沟通，协调能力。此特技主要用于推动问题的解决和资源间的合理协调，保障项目上人品配比的需求。

　　4、总结。此特技主要用于经验的获取，等级的提升，迈向高富帅。

　　最后，只想说，在知道做正确的事情之后应该要思考怎样正确的做事，只有这样才能在对的方向上越走越远，当然，我并不是就说我的理解就是对的，只是本着独思而无友，必孤陋而寡闻的心态，在此借地跟大家做一个交流。伙伴们，我们是不是又到了该思考，如何构建一个用例设计体系（通用体系）集我测试众人的精华构筑的一个用例生产体系的时候了。这样，结合我们的代码扫描和覆盖率从而更好的保障外网质量，获得更多更高的认可呢？

　　——-一个屌丝测试工作者