Osheep

时光不回头,当下最重要。

伪命题?听起来好有道理哦!

在实际项目过程中,存在不少对测试的误会,听着无伤大雅,但是如果真的这么做了,可能测试朋友们就要和你友尽了。我们这里摘录几条,看起来都好“有道理”啊!

说法一、测试在开发结束后才开始

这样的说法在多年前一度很占上风。开发都没结束,测试怎么进行啊,测什么呢?想想真的好有道理啊,我还能说什么呢。

不过经过这么多年的教育和熏陶,现在官方场合的言论中,已经很少这么提及了,毕竟这样的提法多少有些“政治不正确”。我们知道开发结束后,开始的是测试执行,而不是整个测试。按照伟大的测试生命周期理论,我们也是有测试需求、测试计划、测试设计、测试环境准备等很多工作要做的啊。

只是到了实际的工作中,一些行动最能体现这个想法。

比如项目资源分配的时候,各类测试服务器往往在测试执行前夜才如“及时雨”般就绪,毕竟支持部门也很忙,前面给你们也用不上啊。还别不高兴,你看隔壁的项目组是进入测试执行阶段,我们才把测试环境的准备提上日程的。

比如我们不少客户找上门的时候,都是万分焦急;为什么呢?因为开发已经基本结束,测试该进场了啊,不然赶不上上线时间表了。碰到这种情况,我真想补一句:大哥,早些时候干嘛去了啊;现在这个点进去要赶上这个时间点,臣妾表示做不到啊。

《伪命题?听起来好有道理哦!》

说法二、测试的意义就是发现缺陷

这个提法,我相信现在也非常有市场。不少测试团队一直有着“以发现BUG为荣”的指导思想。这个无可厚非,能够发现BUG,尤其能够发现别人不能发现的BUG,显然是一种技能,甚至是一种天分。一些测试团队的绩效、以及一些测试大赛也都是以发现BUG的个数(或者加权个数)为指标的。

只是,如果过于强调这一块,甚至让测试的意义与发现BUG划上等号,则有违质量保证的宗旨了。

举个例子,大家知道在功能测试中会有回归测试的部分,侧重于对原有功能的再次确认,这部分测试大概率是不会有缺陷的。那么,以缺陷为价值评判指标的话,这部分测试会显得没啥意义。但是,真相并非如此,要知道现在市场上的自动化测试绝大部分是以回归测试为对象的;如此大的投入,绝对不会用在一个没有意义的事情上。而且哪怕是全新功能的测试,但凡所测软件不是“极品巨作”,能够发现BUG而通不过的测试用例所占的也是小比例。所以,不得不很抱歉地说一句:我们又做了好多无用功啊。

其实,测试工作有很大一部分的作用是给产品盖一个“质量已检疫”之类的印章,而不是一定要证明这个产品哪里不行。江湖上有一个说法:功能测试前期是抱着怀疑的态度和找茬的信念去找系统的BUG,而后期回归测试是以严谨的作风去验证这个系统是无错的。

众所周知,在一个系统提交上线前,往往会进行多轮测试。因为第一轮测试完后,会有缺陷;那么修复缺陷后,显然得再测一轮去验证。这里问一个问题:如果系统今天就要上线了,在“最后一轮”终极验证中,作为测试的你是祈祷测试用例全部愉快地通过,系统可以顺利上线呢?还是说希望能找出一个BUG从而扬名立万,然后陪着开发加班改完BUG又来一轮终极测试呢?【请注意,一脸坏笑的测略君绝对没有诱导大家刻意去放过一些缺陷,我们的讨论是以职业操守为前提的】

说法三、提交缺陷是测试的事

看到这个说法的时候,大家是否觉得:这不是废话么? 提BUG是上帝赋予测试的神圣使命啊。感谢这个神圣的安排,提交缺陷这个事情,测试人员本来就责无旁贷啊。

我们一直在强调一个共识,就是保证质量是整个软件团队的事情,而不仅仅是测试人员的事情。那么换言之,人人都有责任去提交自己发现的缺陷。事实上,几乎所有的缺陷管理工具,对于提交BUG这个事情都是不限角色的;这些工具创造者们的理念领先我们好多团队的实践。

在这点上,用户往往是除了测试以外最热心的了。我们有好几个用JIRA或者Redmine工具的团队,经常看到用户在系统上提交各个阶段发现的BUG,只要他们在某个环境上发现了问题。与之相对的,在软件团队内部,可能做得就不够好。

前几天,在一个调研聊天中,与一位开发聊起Peer Code Review和开发测试。我就问了一下“如果发现了问题或者缺陷怎么办?”“和对方说一下,然后改掉。”我不死心地追问:“不会记录到JIRA里么?”“这个太麻烦了,开发改起来很快,马上就发新版本的。我们一般是测试发现的BUG才登JIRA。”看起来是我太过于认真了,尽管团队实施敏捷有一段时间了,但是距离人人都是QA的境界还有很长的路。

不过,身边还是有一些开发非常热心,喜欢报一些BUG的。最近,公司在推一个问题反馈系统,反馈的对象也包括公司使用的内部系统。一段时间后,我们对于热心提问题的同事发了一些奖品,排名第一的是一位QA,毕竟是本色表现么;而紧随其后的则是一位开发,这个就不得不点赞了。所以各位QA们,如果身边有乐意报BUG的开发,一定要记得对他好啊~

《伪命题?听起来好有道理哦!》

说法四、自动化测试就是使用工具

很多次,我在和人聊起自动化测试这个话题。对方就会问起:你们用什么工具的?也有一些场合建议一些测试小伙伴学点自动化测试,他们也会很直接地问:学哪个工具有前途呢?每次面临这个场景,我竟有种无言以对的尴尬。

这个就比如某外专业的同学立志转行学计算机,一上来就问:学哪种开发语言、用什么开发工具好?殊不知得提前补一下数据结构、编译原理、操作系统、数据库原理等基础知识。

而自动化本身的内容也远不是一两个工具可以涵盖的:从自动化对象上,会有测试管理、测试数据准备、测试环境搭建、测试执行等各个环节;从测试类别上,可以应用在功能测试、性能测试、安全测试、兼容性测试等;从实施方式上,可以自写脚本、可以使用工具、可以搭建框架等等;从方法上,诸如录制回放、数据驱动、关键字驱动等等;……

基本上,但凡你能想到的所有测试工作,能够替换手工的动作和方法,应该都是在自动化测试的范畴中。所以每次有客户提起要做自动化,我都会问清楚具体目标是什么,以免产生误会。

当然,通常概念上的自动化测试主要是指测试执行的自动化。具体实施确实离不开工具,所以对于工具的精通和使用绝对是一个必备技能。至于哪个工具更好,只能具体问题具体分析了。而且工具也绝对不仅仅是我们所熟知的那些被贴上自动化标签的。要知道自动化测试的本质是用代码代替手工,即我们把测试当作一个业务对象去开发一个或一套支持系统,因此任何编程工具都可能成为有效的自动化测试的工具。

举个例子,在编程界很不起眼VBA就是一个自动化测试界的神器,用以支持测试中的数据收集、数据对比等各项数据处理流程和动作,方便快捷。比如我之前团队就有成员用VBA写了一个蕴含相当复杂业务逻辑的风控报表比对测试工具,大量基于数据的计算和对比都蕴含在那一个外表平常的Excel文件中;又比如也有QA Lead觉得收集各类测试报告太麻烦,用一个宏实现特定目录下固定格式的测试执行数据收集,生成测试报告不是难事。

点赞