测试人员需要的几个素质

测试人员需要的几个素质

一)好奇
       新生的小孩对世界都充满好奇,来到成人的世界,好奇心失去了。好奇会不会害死猫我不知道,但是不好奇一定害死测试。
      测试用例通过了,但是系统运行一定正确吗?  
      测试运行失败了,又为什么不能重现了?
      还有类似的问题存在吗?  
      如果这些失效是相同的,他们由于相同的机制导致的吗?
      如果类似的缺陷很多,是不是设计本来就应该优化?
      看看这些缺陷引入的原因,开发为什么会犯这个错误?
      如果没有发现问题,那么这些测试运行是不是本来就不需要的?
  
       测试工具脚本只是工具而已,千万不要将写出脚本看做是唯一的目的和产出。测试工作是要在开发容易犯错误的提前构筑缺陷拦截的能力。
  
       2002年我也在写脚本,我就想看看这个系统在处理这个新的编解码的时候,输入一个0长度的信元会如何?呵呵,僵死的像冻毙的蜈蚣,一个Jump ptr+len 的跳转会产生什么后果?
       但是为什么有些维护功能还可以直通前台呢?现在的OS不是以前那个系统了,多进程的隔离已经让不同的模块位于不同的进程中了?
      有测试的时间安排这个测试吗?没有!
      有文档和培训告诉你这个系统的事实吗?没有!
      要把所有的零星探索的行为都变成TestCase吗?不需要!不可行!
      有一种测试的手段叫探索测试,但是我觉得与其将探索测试搞得轰轰烈烈,不如鼓励一种“探索AnyWhereAnyTime”的文化。我理解的探索测试,看不过是将测试的这种行为予以
            承认(分配固定测试周期),经验分享(探索方法),和协同(探索区域划分)。

       测试工作的性质和环境决定,如果没有好奇心,没有探索的欲望,我们的知识的边界,我们工作的效能都会受到很大的限制。
       也许优秀的测试人员区别于普通的测试人员,就在于有好奇心多问一下问什么,多探索和探讨一下产品真正的表现应该是怎样的,多看看这些缺陷的成因。   
   
  
二)质疑
     规格写的就一定正确吗?是不是系统一定要设计成这个样子呢?
     尼采说上帝死了,因此规格一定不是上帝写的,肯定会有错。  
    
     我居然听到这样的对测试的批评:按照过程框架的理论,你们决定有这种需求应该在前端提清楚。纠正一个观点,有些关键的缺陷之所以在测试阶段发现,是因为很多原因
     1)测试没有足够的人在前端投入,这个问题的成因可以再写一篇文章,但是即便如此,掩耳盗铃就不是盗了吗?
     2)有些缺陷只有在测试阶段发现,系统测试人员在前端多投入没有效果。
          状态保护不足资源泄露的问题,测试这系统设计阶段只能提出:你们都要做单元测试。你们认为这个有效果吗?
          一些涉及体验的东西,在成为初始成品的时候,才看出设计的荒谬。
       ......
  
       所以,合理的质疑是测试成功的第二个品质。如果一个产品走向成熟前整个团队开发测试和和气气,不挣不抢,是产品走向质量灾难的前奏!       
 
三)学习
      优秀的开发不一定是技术全面的人,而可能是技术很专的人,但是每个优秀的测试人员一定技术全面的人。安全测试的最高境界是成为黑客(我一直觉得黑客是类似测试的破坏者,而不是开发),
      要攻击你得熟悉业务管理流程,网络,OS, 编程弱点,这样你才能成为一个优秀的黑客。测试也是如此。
   
   
      你必须学习业务的知识,协议,业务,网络,技术方案书等等,只有理解客户的需求,你才知道自己的质疑是否合理。
      你必须学习开发的技术,包括工程理论,编程技术等等,否则做不到料敌在先,就像你不知道java有GC机制,就不会通过长时间的观察来确定性能数据的稳定值在哪里。
  
      不管如何在项目管理上努力,测试相对开发晚投入是现实,这意味着你必须在短时间内学习,达到可以和开发SE相同的技术水平。
      因为你的时间很短,你必须掌握学习的时候抓住主要脉络,建立整体视图的学习方法。
  
      如果没有学习,你所有的质疑都很难有依据,你所有的好奇都只能获得一次性成功的经验,就像中国的古典技术永远成不了科学。
  
      很奇怪现在有些测试连协议都不再阅读,遑论开发技术。
  
      学习,是测试人员可以长期发展的基础。
   
四)开放
     因为测试的过程也是一个学习的过程。
     因为测试人员的预测也可能错误。
     因为测试需要的很多信息掌握在开发,维护,客户的手中。  
  
       一个开放的心态,主动的沟通和学习的心态,是测试人员所必须具备的品质。尤其是负责测试团队项目的人员,测试策略的方向取决于  
       业务的判断(真实的商用状态如何),
       技术的判断(是否会有关键的影响稳定的技术引入),
       对开发团队的了解(一拨开发新员工的进入就可能导致大量的质量问题),
       对网上运维过程的了解(话统的目的是什么)
       测试技术的信心(自动化能力如何)
  
       这些判断的信息,多数信息源自周边,不是测试自身可以创造的。
  
       沟通,了解,理解,预测,建议,决策,一个开放的思想,是帮助我们成功的关键要素。
  
       这些信息互有矛盾,必须综合处理,做出判断。
  
       当新产品的转型的时候,来自业界同类产品的的成功信息,则是引导测试技术转型成功的关键要素。
  
       所以,好的测试,一定是开放的测试。

 

五)创新
      测试也有创新,也需要创新。
  
      如果没有测试持续在工具和自动化上投入,很难想象现在面临全球交付的时候会存在多大的困难。  
      如果没有 NTE 工具的开发,很难想象测试仪表的购买能跟上软交换扩展的节奏。  
  
      测试的创新即体现在工具上,也体现在工程上。工具是工程想法的载体,所以我们需要TMSS。但是很多测试经理没有经过存量产品替换的恐惧,所以不清楚管理好用例是多么重要的一件事情。
      测试的创新也体现在我们对研发能力整合的贡献上,可以看看现在的自动化工厂。  
  
      并不一定是通用的工具和工程能力才体现价值。创新无所不在。  
      按照我的个人实践经验,一个良好的环境设计和测试规程设计,能够将人工测试的效率从20个提升到40个左右。  
      脚本的设计框架有很大的创新空间。  
      探索测试需要的发散思维,本来就是创新。  
      有人在执行中开发小工具检查日志,有人合理调整和开发协同的时间。  
      创新在各种层次,以各种方式体现,所以会出现同一批用例两个人执行的效果差距甚远,轻视一线执行的管理方式一定会付出代价。  
  
      测试,是一个一定需要创新的工作:工具,方法,工作流,基础设施管理,......., 只是工程能力的创新,有时不像产品开发的创新那样拉风而已。
  
      当然,好的测试,也会从自己的视角,发现产品的创新。
     GMSC33为什么改成了双CCB呼叫模型处理前转,因为0378协议上就有一个类似的图。     
     解决PER编解码的消息解释问题为什么从MDL切换成ASN.1,因为测试就在用ASN.1写ITT脚本。
     双归属为什么要引入告警沉默期,性能环境不是天天看到后果吗。   
  
六)正直
      正直也许是测试很难坚持的一个品质。
      产品缺陷不停增长,发布的压力迫在眉睫,熟悉的开发PL私了一些低级错误,
      哪些是导致产品走向灾难的行为必须叫停,哪些测试自己必须克服的困难一定要动员,哪些是可以妥协的灰度,哪些是必须打击的阴暗面。      
      纷杂的现象考验我们的测试PL, 有没有一个正直的心来平衡处理每件事情。  
  
      经常是,
            应该坚持的质量原则顶不住压力放松了,导致严重的质量后果;
            应该坚决叫停的行为不推动不解决持续恶化着;应该自我克服的困难没有对策只有抱怨;应该软化的小矛盾激化了。
  
       我坚决不允许基层开发人员或者开发PL,直接对测试人员说xxx类的问题单不要提强调规范的缺陷裁决原则,是因为这样的质量误导会导致70%以上的缺陷流失;
       我也坚决不允许测试人员擅自扩大测试范围,只有质量有其内在要求,不能在不合适的时间点开展不合适深度的测试。     
  
      正直中正,是测试最难把握的品质。
  
七)合作
     合作的心态,是测试成功的最后一个关键品质。
  
     测试发现问题,尤其是版本测试发现系统性的问题,是为了解决问题。  
     开发设计质量问题,有可能是没有采取很好的方法。
     开发联调能力有问题,也许是因为环境,工具,和组织过程的原因。
     开发转测试破坏继承性特性,也许是他们尚未构建系统级别的验证能力。
     遗留DI居高不下,可能是因为他们没有为技术负债留有人力。
     有些问题,测试可以直接给予帮助;有些问题,测试的分析能够让开发意识到改进的方向。
  
     换一个角度处理开发测试的很多矛盾,更有利于问题的解决。既然大部分的测试效率的损失源自开发的缺陷,为什么不推动开发改善自己的工作呢?  

     今年任职解读,要求测试成为产品开发的质量高参,我想主要的想法也在这里。(不过高参不是司令,来自管理层的支持和鼓励是必不可少的)。  
  
用一段微信作为结束:
       测试是质量的指针和轨道。当测试无力发声,质量就失去方向,产品研发如脱轨列车滑入万劫不复的深渊。
      是测试的缺陷而不是质量的报表,警示产品成熟道路的曲折;
      是产品测试不断地反馈,让产品开发回到正常的节奏。
      这不是让人愉悦的故事,却是颠簸不破的事实。

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 2
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值