【测试开发必看】三点思考总结

发表于:2018-5-14 17:50  作者:Deadwalk   来源:51Testing软件测试网采编

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 软件测试技术 其他相关

  前言
  对于功能测试自动化测试以及测试开发的发展与选择,一直以来存在着诸多争论,本篇文章想借此机会抛砖引玉,聊聊对于测试开发的三个思考总结。
  提出问题
  最近脉脉上发起的一个问题讨论很有意思:
  楼主发起的问题核心讨论点在于:
  做功能测试的人越来越少了。
  大家都在向自动化测试、测试开发等高大上的方向发展。
  基于问题,引发了比较激烈的讨论,摘抄其中部分观点如下:
  “曾几何时我也是这样的测试人员,瞧不上功能测试,盲目追求所谓的高大上自动化,性能测试。如今回头看看以前的我,以及每次面试时展现在我面前的求职者,真的就如楼主所说,大家都在浮躁。工具可以复用,代码可以套用,唯独分析能力无法复制…而功能测试真正的精髓就是强悍的逻辑分析能力,场景构造。一个合格的功能测试工程师,不仅要对测试理论知识熟知,熟用,还要具备产品人员的业务分析能力,具备开发人员的逻辑设计能力,其次,前后端代码要略懂,至少走读代码时你大概能懂、数据库操作能力必备不少、日志查看、测试辅助工具、BUG追踪分析能力…等等…而自动化工具学习一两个星期足以…
  所以还是踏实测试吧,好高骛远,走不远…”
  "只要是能促进测试生产力,提好测试生产效率的,都可以拿来用。说到底,功能测试,自动化测试,性能测试等,都是保障产品质量的,但功能测试是基础,自动化测试是辅助,作用都不一样,并不是所有的产品都需要自动化测试、性能测试等,而功能测试是所有产品都必须有的一个手段。ps:行业确实浮躁,但自己不能浮躁,慢慢积累,慢慢沉淀,自动机测试框架啥的,脚本语言啥的,该学还是要学的,至少不能拒绝,不能固步自封。"
  "只会纯测试就是low,这是不争的事实。既然现在大趋势就是自动化,一群人还在这里反驳趋势,我也是醉了。专研技术也没有错,但是要紧跟时代的步伐。你们说的只是行业里的部分现象,真正的大牛都在认真做测试。"
  以上问题的讨论,反映出业界对于测试未来的发展在进行深入反思和思考,这是非常值得高兴的一件事。借此机会,笔者也分享一些关于测试开发的思考总结,希望能够对各位读者有帮助。
  抛出观点
  追求技术是大势所趋,但追求技术≠做自动化测试,而是通过各种技术手段解决实际工作的问题(覆盖度和效率)。
  解决实际问题是根本,但解决问题的前提是能够发现问题,从而分析问题,针对问题提出解决方案并使之成效。
  发现问题的最好办法是付诸实践(做具体的测试),所以测试与测试开发的关系不应分而治之,而是相辅相成。
  追求技术是大势所趋,但追求技术≠做自动化测试,而是通过各种技术手段解决实际工作的问题(覆盖度和效率)。
  面试中,十位候选人有九位在回答为什么要做测试开发时,给出的答案都是要做自动化测试,但是殊不知自动化测试只是手段,并不是目标。
  测试开发的核心目标是提升产品的测试覆盖度和测试效率。如果站在提升测试效率的角度去看的话,我们可以做很多的事情。
  举个例子:
  搜狗手机输入法的按键响应时间评测一直是一个重要的指标,为了保证以用户感知的视角和竞品对比分析,这一评测采用的是高速摄像方式进行。
  高速摄像中不得不克服的一个问题是如何知道用户在屏幕上按下和抬起。
  以前方法是利用镜子反射+摄像的方式得到,但是这一方法耗时耗力。
  为此,我们利用Hook技术侦测到用户在手机屏幕上按下和抬起的动作并用一个色块来显示,大大降低了测试成本。
  因此,追求技术不是只做自动化测试,站在解决实际工作中的覆盖度和效率问题来看的话,我们可以开展工作有:
  解决实际问题是根本,但解决问题的前提是能够发现问题,从而分析问题,针对问题提出解决方案并使之成效。
  根据笔者多年观察,存在着这样一种通病:
  大多数同学对于工作中的问题(特别是效率问题)的发现和思考不够,每天只是以完成任务为目标,所以最终忙活大半年之后觉得自己的工作没有技术,自身没有得到成长。
  举个例子:
  小明同学在测试输入法的Pingback功能(统计用户关键操作次数的一项功能)时,每次都是checkout输入法的代码,然后在debug运行模式下加入对应的断点,当执行用例中的操作之后查看IDE中断点是否进入,断点处的变量与预期值是否一致。
  这一方法因为涉及到check代码、打断点、查看变量、恢复断点运行等一系列繁琐操作,效率巨慢。
  但是小明同学不以为然,没觉得这是问题。
  后来当Leader提出打log的方式来替代debug查看断点变量之后,效率相比要快许多。
  虽然只是一个很小的事情,但是小事情里面能够看到大问题。小明同学的测试方法继承了之前一直以来的测试方法,但是没有思考原有方法有什么问题,所以改进方案更无从谈起了。如果希望去通过技术改进测试工作,应该要有一双能够发现问题的明亮大眼睛。
  发现问题的最好办法是付诸实践(做具体的测试),所以测试与测试开发的关系不应分而治之,而是相辅相成。
  既然发现问题是前提,那么该如何做到发现问题呢?之前Leader有句话这么说:"谁痛苦谁解决问题",对此我深以为然。试想如果你不做具体的测试工作,天天就是对着代码,如何知道测试中的痛点在哪儿呢?
  举个例子:
  我们在PC浏览器项目做测试时,曾基于Eclipse+PyUnit+UIA封装了一套PC端的自动化测试框架。
  当框架初步完成可以完成日常自动化测试任务时,我们随之提出了下一步要完善的功能,即支持pydev的远程调试功能。做这个功能的初衷很简单,因为它很酷,而且其他知名的IDE都支持。
  当我们实际完成了这项功能之后,发现少有人问津。因为大家在写自动化脚本过程中最苦恼的问题并不是没有远程调试,而是它实际能解决什么问题。
  后来通过实际测试,发现浏览器的安装卸载验证工作重复性高,需求稳定稳定,验证的内容每次都是数字签名、文件的版本号、MD5值等内容。
  基于此我们对安装卸载过程中的动作、检查点进行了库函数的封装,使得测试同学只需要调用几个简单的函数即可完成对应的逻辑业务和验证点,安装卸载的自动化得以推广使用,直到现在仍然是浏览器每个版本上线前必备的测试环节。
  所以,测试与测试开发的关系不应分而治之,而是相辅相成。做具体测试的过程中,遇到了问题,寻找具体的问题解决办法,使用技术手段解决之,然后进行更多的测试,以此往复循环。
  综上所述,通过实践测试,以问题为出发点,以提升覆盖度和效率为目标,通过各类技术手段去达成目标,这才是测试开发核心的职责所在。


上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。

年薪30W+的大数据测试工程师,都在学习哪些技能?>>查看完整学习线路

评 论

  • zcx-testing (2018-5-16 14:56:58)

    同意!有时候测试中理清楚各个系统的调用关系,每个接口的调用关系,并根据业务知识以及逻辑分析,定位问题,分析问题,这时得到的bug,成就感最强。技术是手段,发现问题的眼睛,更重要。通过实践测试,以问题为出发点,以提升覆盖度和效率为目标,通过各类技术手段去达成目标,这才是测试开发核心的职责所在。

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2018, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道