博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
致所有测试人员的信
阅读量:6616 次
发布时间:2019-06-25

本文共 2706 字,大约阅读时间需要 9 分钟。

我两年多的测试生涯到头了。我想再这里总结一下点点滴滴。以及我也会说明我为什么选择离开。在中国有着很多很多的软件测试,很多迫于环境,迫于leader,迫于很多原因,导致只是一个“执行者”。以下只是我个人的一些经历。大家可以借鉴,也可吐槽,大家随意。

  首先在测试的时候需要有一些心理暗示,其实未必是暗示,可能是给自己的一些自信。
  第一:产品一定是有bug的。
  无论你测试什么产品,一定是需要报有这样的心态。为什么?其实就如一句说的“如果自己都不爱自己,那么就不要奢望别人来爱你”。如果连测试潜意识里面都觉得产品是没有bug的那么还能有谁认为产品是有bug的呢?
  测试的历史上有两种验证方法,一种是测试是用来验证产品一定是没有bug的,一种是测试是用来验证产品是有bug的。无论哪种你都要有一种原则,要有一种信念。就如人生漫漫长路一样,我们必须坚信自己的梦想,坚信自己是能够成功的。那么才有可能,才有希望。当碰见挫折的时候,当迷茫的时候,才不会真的被打败。
  一个新的feature,一个刚刚fix的bug,一个用户反馈,一个不起眼的问题。我们都需要坚信里面有缺陷的。没有任何一个产品,任何一个细节是完美的。
  许多公司从上级到下属对于产品的质量根本没有概念,又或者对于质量不重视。在这种情况下,就需要测试产生力量,需要用各种事实依据去告诉公司,告诉大家这样一个产品质量的真想。国外的公司相对好点,国内有很多公司是需要有这种有责任感的测试存在。
  第二,任何的bug都是能够repro的
  无论你面对一个很小的功能测试,还是很复杂的场景化的测试,又或者说某个用户很简单明了的描述了一个问题。我们需要坚定不移的告诉自己,只要是一个bug就是有重现步骤的。
  微软曾经有测试,一个问题的重现步骤长达50步。虽然可能不是最佳的步骤,但是依然对于解决问题起到了决定性的作用。
  自然,在实际中很多情况下的确会碰见一下子找不到重现步骤的方法。找不到方法意味着什么?意味着你可以开bug,dev可以fix这个bug。但是谁都不知道到底有没有真的修复这个问题。还可能因此出现很多regression的bug。所以找到一个bug的repro step可以说是一个测试基本功也是体现价值的地方。
  和第一点一样,只有你自己信念中去相信了,那么你才有可能成功。
  第三,只相信自己看到的
  在很多情况下,dev或者同事会告诉测试“这个功能很小,没有bug的”“简单测一下就好啦”等等的话。我主张还是不要太相信任何一个人。
  面对bug,我们需要好好的理清问题的根源逻辑,在进行一个完全的测试之后告诉自己“这个功能基本上不会有很大,或者很block用户的问题”;面对一个讨论,不要听到别人说什么就是什么,任何的决定都没有完全正确的。我们需要自己亲手去验证很多决定和设计,小到你可以google,找出各种证据来证明某些事情。大到你可以进行用户数据搜集,很多企业不会去做。但是如果一个有sense的测试,我相信必须什么事情都亲手去实践去证明!
  以上说了这么多,可能很多人觉得,这个还是测试么?ok,我认为真正的一个测试满足以上三点是远远不够的。以下是我认为一个有sense的测试,记住是有sense的测试需要做到的。
  第一:探知精神 乐于学习
  为什么我将这两个放在一起呢。两者密不可分。我所在公司是做android产品的。目前中国国内很多企业也是一样的问题,就是只是在乎自己的产品怎么样,并不会很关心你的发展。作为测试,必须有探知精神,必须乐于学习。比如你测试A平台的B产品,如果只是一味的测试,只是一味的报bug。的确你会有进步,做任何一行你都会有进步,行行都能够出状元。但是几年光阴一过去,当别人或者自己问问自己,自己真的知道了多少?可能对于自己公司做的产品很了解之外,一无所知。那么这样对于自身发展又有什么好处呢?
  探知,对于任何一个design,任何一个bug,任何一个细节都需要去探知。这样无论你做了多久,无论你是否做多少个项目都会依然有进步。时不时的问问自己,对于这个产品feature真的了解很透彻么?对于产品功能逻辑很清楚么?对于这个产品所在平台了解么?业内是不是主流的tools都清楚了呢?是不是自己已经没有了进步的余地了。这样自己会明了很多。
  第二:责任
  这点可能很多人会说,测试最基本的不就是责任么?没有责任怎么去做一个测试呢?是的,责任每个人都有,程度是不同的。你作为一个tester,需要保证产品的质量。勿以bug小而不重视,本质上依然是不负责任的表现。
  相反的,很多测试对于产品是负责了,对于自己却是不负责任的。因为他们只是一个傀儡,天天被人操控着。做这个做那个,我觉得这种是更加可悲的。
  如果你作为一个tester leader,那么你的责任不是去指挥别人做事情,不是去拍老板马屁。而是自己不要忘记进一步的学习,不要忘记对于任何的细节去了解。更不要忘记如果出了什么问题,自己勇于承担这个责任。真正的leader是什么?需要在流程以及技术上面有自己的sense,需要不停的去完善项目流程,从而提高测试team的效率以及项目的效率。
  第三:通过各种渠道找到bug repro step
  bug会从各个渠道发现。公司内部bug bash的时候,用户反馈的问题,自己找到的问题。老板发现的问题等等。这个时候能否找到repro step就是体现一个测试的价值所在了。
  测试往往碰见的问题是这样的。突然发现一个问题,欣喜若狂!但是然后问问自己“我刚刚做了什么”,基本上很多人都不知道。有的时候是有log可以取,但是log只是一个告诉开发如何dev去解决bug的。所以找出重现步骤才是王道。并非要时时刻刻保持警惕,可以有两个做法,一个就是自己在测试的时候留个心眼,养成时不时回忆自己做了哪些操作。一个就是养成一边测试一边记录log的方法,这个方法相对很保险,不过前提是自己需要有完全看得懂log的能力。
  另外一类bug是从用户这里报出。用户一般是无知的,根本不会懂你产品的逻辑,可能描述出来的错误和真正的错误根本就是天差地别。这个时候就需要测试去按照经验以及各种方法去判断。判断出用户说的产品的真正的问题在哪里,然后使用各种方法(automation.etc)去模拟bug产生的环境。这样一来,bug在修复的情况下能够在公司内部马上得到confirm。这样无论是对于产品,用户,还是公司都是一种无限大的利益。

最新内容请见作者的GitHub页:

转载地址:http://wxrso.baihongyu.com/

你可能感兴趣的文章
Heartbeat+DRBD+NFS高可用实例配置
查看>>
Linux Iptables 简析
查看>>
设计模式(创建型模式)——工厂方法模式
查看>>
我的友情链接
查看>>
CPU个数、核数、逻辑个数
查看>>
浅谈运维必备技能
查看>>
Go 并发非阻塞缓存
查看>>
过时的广东省教育技术中级培训题答大全
查看>>
happyhbase 基本操作和增量操作
查看>>
JAVA API集
查看>>
开源类型
查看>>
onSaveInstanceState() 什么时候调用
查看>>
双十一高并发场景背后的数据库RDS技术揭秘
查看>>
数据流被污染?数据质量不高?蚂蚁金服数据资产管理平台了解一下
查看>>
我的友情链接
查看>>
DES 算法报告
查看>>
iscsiadm命令使用方法
查看>>
双机热备篇 VGMP招式详解.2
查看>>
使用recon/domains-hosts/baidu_site模块,枚举baidu网站的子域
查看>>
解决 Warning: Permanently added (RSA) to the list of known hosts.
查看>>