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

发表于:2014-07-16来源:DiggerPlus作者:陈永达点击数: 标签:
作为一名测试人员,到底其真正的核心竞争力是什么?这个问题一直困惑着我,当我还未曾踏入这一行业的时候,听到的声音是这样的:“测试是一种很有前途的工作,需求大于供给”、还有一种是这样的“测试就要做接触到代码的,点点鼠标谁都……”怀着对于一个行业我也不知道好还是坏,到底是个什么玩意的心理选择并进入了这个行业。期间,我承认,的确有那么一段时间,我认为作为一名测试如果能够对于代码了如指掌,能够写出一个个的工具才

  作为一名测试人员,到底其真正的核心竞争力是什么?这个问题一直困惑着我,当我还未曾踏入这一行业的时候,听到的声音是这样的:“测试是一种很有前途的工作,需求大于供给”、还有一种是这样的“测试就要做接触到代码的,点点鼠标谁都……”怀着对于一个行业我也不知道好还是坏,到底是个什么玩意的心理选择并进入了这个行业。期间,我承认,的确有那么一段时间,我认为作为一名测试如果能够对于代码了如指掌,能够写出一个个的工具才有可能成为武林的盟主,寿与天齐。似乎,作为测试来说最核心的竞争力就是对于代码的掌握程度,除此以外,那些什么功能测试用例似乎就是个最低端,最没有价值的产出而已。

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

  XX项目,引入了hudson构建自动集成方案,并且前后台都有接入,这样,在开发提交代码转测之后,功能测试不出意外会如期进行,代码后台自动扫描,结果也会mail给对应的人。在一切具备,作为东风的版本到来之后,噼里啪啦的就开始了,然后外放,,,然后,,,,然后就苦逼了,~~~为啥?版本外放之后,“游戏道具神秘消失,客户端莫名崩溃、宠物实际得到的数值与预期不一致,,,,”好吧,你niubility,,,走紧急更新、关外网功能阀门,出公告…….然后就进行了一段研发调试,测试提单,研发分析,测试分析,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决定了你前面的付出等于一万个零。

原文转自:blog.csdn.net/yzongyu/article/details/25075385#1536434-tsina-1-62095-66a1f5d8f89e9ad52626f6f40fdeadaa

评论列表(网友评论仅供网友表达个人看法,并不表明本站同意其观点或证实其描述)
  • 甘荣娟
    2017-01-17 19:01:19发表

    传奇娱乐?赠58元彩金 BWIN国际?送88元 盈和亚洲?开户送88元 申博娱乐场?送88元现金 http://t.cn/RMRkMoi

  • 送现金
    2017-01-17 07:54:16发表

    金沙中国?领88元现金 新奥博?领现金 118T.NET