也谈測试核心竞争力

作为一名測试人员，究竟其真正的核心竞争力是什么？这个问题一直困惑着我，当我还未曾踏入这一行业的时候，听到的声音是这种：“測试是一种非常有前途的工作，需求大于供给”、另一种是这种“測试就要做接触到代码的，点点鼠标谁都……”怀着对于一个行业我也不知道好还是坏，究竟是个什么玩意的心理选择并进入了这个行业。

期间，我承认。的确有那么一段时间，我觉得作为一名測试假设可以对于代码了如指掌，可以写出一个个的工具才有可能成为武林的盟主，寿与天齐。

似乎，作为測试来说最核心的竞争力就是对于代码的掌握程度，除此以外，那些什么功能測试的用例似乎就是个最低端，最没有价值的产出而已。

可是就今天看来。就我如今自己遇到和看到的一些问题和现象，我開始对自己的一些想法有了挑战。

比如：如今非常多组都在做和预研一些代码级别的測试工具，比如覆盖率工具啦，代码扫描工具了（主要是遵循相关的语法规则做一些比如是否有空指针风险，是否有没有定义的变量。是否if else的分支条件相互排斥等）、当然另一些高端的通过业务流回溯的方式来对每一条分支进行检查，仅仅要有风险存在就发出邮件给相应的干系人。

表面看起来非常的高端。大气，上档次，一切都在自己主动化，一切看起来都在掌握之中。

翻手为云，覆手就可以为雨。

可是实际情况呢？代码在进行了自己主动扫描也好，覆盖率统计分析也好。终于产品外放后的质量还是体如今了功能測试的实际。实质结果上。这样说。显的好晦涩，举个栗子吧～～～

XX项目，引入了hudson构建自己主动集成方案，而且前后台都有接入，这样，在开发提交代码转測之后，功能測试不出意外会如期进行，代码后台自己主动扫描。结果也会mail给相应的人。

在一切具备，作为东风的版本号到来之后，噼里啪啦的就開始了。然后外放。，。然后。，。，然后就苦逼了，～～～为啥？版本号外放之后，“游戏道具神奇消失。client莫名崩溃、宠物实际得到的数值与预期不一致，，，，”好吧，你niubility。，，走紧急更新、关外网功能阀门，出公告…….然后就进行了一段研发调试，測试提单，研发分析，測试分析。DAI编写。QA审计，leader审计的历程～～～

事实上。引起这些问题的根本原因在找到之后，我们事后来看。都会认为。为虾米？这种问题应该非常easy想到啊？我仅仅想说，事后人人都知道赤壁之战的当晚要注意防风，不能报以黑天鹅的心态，何况在事前我们可能根本都不知道还有天鹅一说。就更加别说什么黑与白了。什么意思？别急，给我点时间打字。慢慢码～～～

首先：第一个祝福神奇消失，最后找到引起的原由于“前台client在网络波动较大的时候，server的回报没有到达client之前。client的button和相关数据没有刷新，导致玩家能够进行第二次对于button的操作，发出2个请求到server，server在处理完第一个请求，check result为success之后，扣除了玩家的0基础物品，生成一个高级物品返回给玩家，，，注意，此时第二个请求到达了server，不凑巧，也是命中了成功的概率。此时server的处理方式为仅仅要概率命中为了避免给我司带来损失，先扣除用于进化的低等级物品。然后再逐步扣除其余的依赖物。终于返回给玩家高等级物品。这个时候就有问题了，第一个请求的物品成功了，是须要扣除进化道具的，扣除道具后。对于第二个请求来说，实际是不满足须要的道具数的。可是后台的处理逻辑是仅仅要命中概率，success则觉得就会成功，这个时候为了避免损失。先扣物品，这个时候，到了第二步来扣除道具的时候，发现剩余金额不足，，，返回失败，可是，，，亲。人家第一次success成功的道具就特么的，。，没了～～～这个代码覆盖率是OK的（有相应的检查升级的用例）。代码扫描也是ok的，由于判空做的非常到位，。，可是这个问题 的root cause是 设计上的缺失，导致了逻辑处理上存在问题。

这个我们通过自己主动化，仅仅通过阅读代码扫描结果是发现不了的。仅仅能通过用例设计的时候去发现，不凑巧，用例设计中没有这一块：弱网络的用例设计。。。从而，say goodbye，仅仅能对玩家报以卖萌一笑，后台log查证再补偿玩家了～～～

其次：client异常崩溃。这个问题的root cause又是什么呢？先用事后的眼睛看，造成client异常崩溃的原由于：client前端的物品刷新不是实时的（这个能够理解，由于谁会闲的蛋疼，实时去跟后台做数据查询的交互，又不是对数据实时性要求非常高的功能，就一个查询摆摊物品的功能，从CAP的角度来说。的确能够接受牺牲实时性。

可是，就由于这个原因，当玩家选中的物品摊主在玩家点击购买前下线了，此时这个时候玩家点击购买，不好意思，空指针异常======）core。那么这个bug为啥没有通过代码前期的检查工作得以暴露呢？原因是：工具本身的不足导致在做判空检查时。遇到有break的业务流分支时，不支持业务流分支的检查（后来听说引入coverity能够解决。眼下引入中，可是据说收费也不菲）。

这个bug导致外网刚一更新就要走一个紧急更新。说实话。当这样的情况出现多了的时候，哪怕作为測试组你前面加班个十天。半个月在项目组看来，在外人看来都认为你们前面的付出是没有意义的。由于此时的1决定了你前面的付出等于一万个零。

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

那么说了这么多，对于測试来说最基本的核心竞争力是什么呢？我个人认为能否够理解为下面几点：

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

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

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

4、  总结。

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

最后，仅仅想说，在知道做正确的事情之后应该要思考如何正确的做事。仅仅有这样才干在对的方向上越走越远，当然，我并非就说我的理解就是对的，仅仅是本着独思而无友，必孤陋而寡闻的心态，在此借地跟大家做一个交流。

伙伴们。我们是不是又到了该思考，如何构建一个用例设计体系（通用体系）集我測试众人的精华构筑的一个用例生产体系的时候了。

这样，结合我们的代码扫描和覆盖率从而更好的保障外网质量，获得很多其它更高的认可呢？

-----------------一个屌丝測试工作者