【测试核心竞争力】也谈软件测试工程师的核心竞争力是什么

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

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

       其实，引起这些问题的根本原因在找到之后，我们事后来看，都会觉得，这样的问题应该很容易想到啊？

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

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

文章出处：



http://blog.csdn.net/yzongyu/article/details/25075385