测试人员和测试工具

发布时间:2020-06-19 16:35:47 作者:hehe_debbie
来源:网络 阅读:655

今天想谈谈测试人员和测试工具的关系问题。

从02年开始接触测试,我用过了无数的测试工具,通信行业需要的测试工具要比互联网复杂得多,因为需要仿真通信时遇到的各种问题。测试工具可以定制各种消息,各种网络环境,还有各种异常。一般非常专业的测试工具都是需要购买的,价格不菲。基于自动化回归,诺西做过robot,让测试人员通过表格化的方式来写测试用例。手工测试和自动化测试花费的时间比差不多是1:5到1:10(《人件》当中有详细的阐述)。自动化回归发现的bug是相当少的,也没有人会去统计这个数值。我相信除非禁止了手工测试,否则自动化回归发现的bug永远都是相当少的。自动化覆盖率大幅提高的同时,customer pronto的数量也在大幅提高。但我并不清楚其中有没有必然的联系。很值得去分析一下。

到了互联网企业,测试工具就要简单得多,基本上用于自动化回归。TC的管理也没有通信行业复杂,不需要把用例和需求关联起来,也不需要统计用例对需求的覆盖率。

互联网企业喜欢自己写测试框架,这可以理解,因为相对来说功能比较大众化,比较简单。用开源的框架就可以了。自己写框架,可以提高响应速度,任何个性化的需求都可以得到快速的满足,这挺好的,对测试人员来说也是一个写代码的锻炼机会。

但是工具仅仅是工具而已,测试人员会用工具,可以提高测试的工作效率,就够了。测试人员更重要的工作是发现bug,当我需要用工具的时候我就用工具,当我不需要工具的时候,我完全可以不用。

这么简单的道理,我相信人人都明白的吧。

可是,现在好像很多人都不明白这个道理了。

首先,我们来谈谈我们为什么要用工具。有句话叫做,磨刀不误砍柴工,磨刀是为了提高砍柴的效率。对吧?那么,到底是磨刀好呢,还是砍柴好呢?没人care,大家只care最后柴砍得好不好,快不快,多不多。如果只砍柴,不磨刀,柴就会砍得慢。如果只磨刀,不砍柴,那就更糟了,没柴用了。

我会认为,一个好的樵夫,肯定会重视磨刀,但是磨完了刀他会去砍柴,磨一次刀可以砍好几天的柴。一个好的测试人员,肯定会想办法提高自己的工作效率,善用工具,没有工具的时候会创造工具,但是他还是会专注于测试。

一个好的管理者,会在乎最后柴砍得好不好,而不是看这个人会不会磨刀。会不会磨刀不重要,重要的是,是不是需要磨刀,需要磨刀的时候才磨刀,不需要磨刀的时候硬要去磨刀,也不是一个好的樵夫。对吗?

测试人员和测试工具的关系,应该是使用和被使用的关系。一个好的测试人员,更关注于自己的测试工作是否能够高效率的完成。怎么样可以更好地做好自己的工作,就怎么做。没必要做任何工具都要去给别人用,都要做成一个框架,都要有影响力。考量KPI的时候,判断晋升的时候,看这个测试人员做了多少给别人用的工具是毫无意义的。

我不希望看到测试人员为工具所累,更不希望做工具会成为考量一个测试人员的标准。一个测试人员有好的开发技能不需要体现在做了一个测试框架和测试工具上面,而是需要体现在需求评审的时候拒绝了一个无用的产品,技术评审的时候阻止了一个愚蠢的设计。我记得有个老大曾经说过一句话,测试人员要比开发懂业务,要比业务懂技术。我觉得这句话很靠谱,我也是这么做的。我也常常做工具,只是为了提高效率,但不会以此为目的。有人说过,优秀的程序员需要三个宝贵的品质:懒惰、急躁和骄傲。懒惰就是讨厌重复的工作,重复劳动用自动化来替代,急躁就是不耐烦做复杂繁琐的事情,骄傲就是相信自己能做出最优秀的产品。其实测试人员也是一样的。一个好的测试人员,会用聪明的办法解决自己的问题,会在问题中总结经验教训,会在成功的产品中留下自己的身影。

所以,当测试人员都争先恐后地去做工具的时候,我感到非常的茫然。这是怎么了?在一个开源框架的基础上做出一个几十或几百人用的日常工具就这么有成就感吗?就这么容易被认同吗?难道去和PD、开发一起做一个几百万或上亿人使用的优秀产品反而没有那么大的魅力了吗?买家和卖家认同你的产品,可以从你的产品中得到服务,得到订单,去改变现状,难道不比做一个日常管理bug和用例,管理自动化回归的测试框架更有挑战,更有意义吗?

如果你从一个公司的角度看待每一个角色,好的产品经理需要把控产品的定位、设计出满足运营需求的产品,好的开发需要运用自己的技术能力,快速开发出稳定、好用的产品,好的测试需要运用自己的测试技术和经验,及早发现所有的问题并改正。开发向前走,是为了帮助产品经理选择用最好的技术来实现产品。测试向前走,是为了帮助产品经理和开发避免犯错,让错误的代价最小。每一个角色都有自己的价值,每一个角色都很重要。开发需要精通于自己的技术,在技术领域做到最优,测试需要了解每个领域的产品和技术,在每一个环节"say no"。有的时候我甚至觉得做一个好的测试,要比一个好的开发更难。

但是,现实并非如此。大家总是觉得,创造一个产品很有成就感,说真的,我也常常会这么想。测试只有在一个产品被骂的时候才会被提及,大家会说,这个产品怎么通过测试的,这么烂!但当一个产品很出色时,没有人会说,这个产品的测试太牛了,产品这么好!这就是做一个测试最痛苦的一点。很多同事也问过我同样的问题,怎么样才能体现出一个好的测试呢?记得我刚到互联网公司的时候,有一个开发问我:这里有一百多行代码,你看不看得懂?我当时真不知道该说什么。就好像有一次一个快递问我妈,你会不会写字?我妈当时想跟他说,我清华大学毕业的,你说我会不会写字?后来想想,也懒得说了,就说,会写字。有的时候我也在想,如果我当初不去诺基亚做测试,继续留在VIA做开发,我现在会是什么?至少不会有一天,有个开发问我,你看不看得懂代码。也许正是出于这样的心理,所以测试人员才会热情高涨地去做工具,去参加无线之夜,去参加赛马。是想证明我不是没水平,我不是看不懂代码,我只是选择了测试这个岗位!但这本来就不需要去证明的啊!

记得当初我参加面试的时候,技术总监问我,你对自己的定位是什么呢?我说,是测试架构。因为在V Model里的每一个环节我都经历过,我知道如何来把控一个产品。我也会带领所有的测试人员向前走,想后走,把产品的质量管起来。

可是现在,测试人员正在不断地用测试工具来证明自己的价值和能力,公司也在用开发能力来衡量一个测试人员,这让我觉得太拧巴了。这样的衡量标准,让测试人员情何以堪?测试工具不再是工具,而是我的价值所在。工具在,故我在。我是高P,故我做工具。磨刀不再是为了砍柴,而是为了存在。这是不是很可笑呢?

推荐阅读:
  1. 网络测试工具和Ubuntu网络配置
  2. 网络性能测试工具iperf和mtr

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

测试工具

上一篇:数平精准推荐 | OCR技术之数据篇

下一篇:jQuery图片轮播的具体实现

相关阅读

您好,登录后才能下订单哦!

密码登录
登录注册
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》