zoukankan      html  css  js  c++  java
  • 有了測试工具,傻瓜仍是傻瓜

    Kaspar van Dam自2005年以来一直在測试领域活跃着,且自2009年起就专攻測试自己主动化和性能測试。

    他在很多公司当过測试工具project师和測试顾问。他的经验覆盖了測试自己主动化和性能測试的技术实施以及该工作领域的不同管理与协作任务。在他的公司(荷兰Ordina公司)里,Kaspar是測试自己主动化的思想领袖之中的一个,负责一部分公司愿景发展和建议。他还负责一些关于測试自己主动化和性能測试的业务课程。

    ?

      測试工具:人们总是觉得測试工具是每一个測试难题的解决方式。有了工具实施,測试就会进行地非常快,质量更高。自然也更廉价…… 可惜现实却是。測试工具实施要花上不少钱,并且投入还不一定有回报。究竟为什么測试工具实施常常失败呢?

      測试工具是什么?
       为了了解測试工具实际是什么,首先考虑一下我们能够识别哪种測试工具非常重要。

    人们通常觉得測试工具仅仅是用于自己主动运行測试的工具。

    可是。远不止如此,它们还是:(測试)管理工具;bug追踪工具。版本号控制工具;一般性(如:电子数据表)工具。自己主动代码測试工具。性能測试工具;当然还是自己主动运行測试的工具。
       一般来说,測试工具帮助測试员做測试工作并使之更高效。这就是说,測试员能够利用工具更快,更好。更廉价地做任务。可是。測试自己主动化的这些优点没有一个能够保证。一切要看怎么使用工具及它们该怎样被使用。

      測试工具的实实施
       大多数在IT业工作的人对很多IT实施失败一点也不吃惊。

    查一下失败率,你会发现基本超过50%。

    可是。当一个组织决定实施一个測试工具时,突然人们就会期望实施不会遇到不论什么障碍。自然,将一个大型IT实施与一个相对较小的測试工具的实施相比較是不公平的。但这两样都在终于软件实施中确是事实。也意味着有风险和失败的可能性。既然我们已经肯定了这个事实。那么看一看可能会失败的事也不错。


       在高水平上,这些能够被分为三个单独的元素: 
       ??

    人 
       ??

    流程 
       ??技术 
       我将反序谈谈这三个元素以及它们在測试工具实施中所扮角色,首先是最不重要的元素——技术。最后是最重要的——人。

      技术
       讲到測试工具,多数人立刻会想到技术。

    一份測试活儿在选定平台上吗?它适合其它工具和/或被測软件吗?有足够多的硬件去执行工具吗?显然。这些都是实施測试工具时非常重要的问题。假设工具不起作用。那它还有什么用呢?这就意味着一个測试工具的实施(或不论什么其它工具),非常有必要调查特定工具后的技术并将之放在组织内使用的技术一起。然而。正如之前所提到的。技术是实施測试工具时最不重要的元素,因此在试着实施測试工具时要最后考虑它。比它更重要的是就绪的或将被设计的流程和该工具将在这些流程中採用的部分.

      流程
       在我们開始谈论实施測试工具中流程的重要性前,让我们先看看“流程”究竟是什么。牛津字典将它描写叙述为“为了实现某特定终于目标而採取的一系列行为或步骤”。

    一个流程的行为或步骤是一系列的一部分,表明它们要按特定的顺序进行。

    这一系列动作的目的是获得特定结果。充分測试測试特定SUT以保证软件的特定质量水平。那么一个測试工具在这种流程中起着什么样的作用呢?基本上,一个工具是用来使使用它的人生活的更轻松。它应该帮助任务更高效。因此,一个工具帮助流程就绪,例:通过让用户按特定顺序採取特定动作。也能够帮助使特定动作更简单且/或更好且/或更快。谈到一个项目中的測试工具时。就必须决定应该或能够用特定工具改进流程的那个部分。

    測试工具并非一个小玩意。

    它不是要让你的同事对你用的新技术钦佩。它是改进流程以便更快、更好、更廉价地实现目标。在说不论什么工具或技术前,有必要问问你自己“为什么我们首先想要实施工具?我们真的须要工具吗?”最好再问问“我们能改进流程吗?”——丝毫不考虑使用工具!
       如今,假设组织内部现存流程其实能够改进且一个工具能够有效帮助改进,那么这时候就该决定哪个工具能够做到改进流程。将需求列出来也许是个不错的开端——考虑一下must-haves, should-haves以及could-haves。不看技术。忽略需求或要求也许非常诱人,由于你认为他们无法满足如今的技术。

    当你列出可能会改进流程的工具需求时,就是时候看看特定工具和技术了。可是,看你的(如今或将来的)流程时,一定要考虑:不论什么流程都可能会在取得目标时失败。

    这就把我们引向了看測试工具时最重要的因素:人。

      
       人能够创建或破坏随意一个项目。

    没有专注的人。终于不论什么项目都会失败。因此。人是迄今看測试工具时最重要的因素。实施測试工具时,首先要考虑的就是讲使用工具的人。当人们对如今的流程感觉惬意且不懂为什么要修改时。那么最聪明的做法就是一点儿都不要修改。

    或者你能够让相关人员看到须要改进的原因以及改进后有啥优点。审视人这一要素尤其是測试员时。不少迹象表明须要对如今的流程做出改进。測试工具的实施要适当。

    比如:
       ?

    ?測试员不再觉得其工作有挑战性了。它成了一项例行公事。 
       ??

    測试员努力找出做手头任务的动力。他们更想接触新事物而不是一遍又一遍地运行相同的老測试。

     
       ??測试员认为他们的工作过时了。 
       ?

    ?測试员喜欢新技术的挑战,甚至可能为了最先进的測试工具是日常工作一部分的工作而离开当前工作。

     
       ?

    ?

    測试员曾经已经用过測试工具且信任它们。

    当这些迹象在一个项目中呈现出来时,明智的做法是深入调查工作上究竟正发生什么。

    要做的事之中的一个就是挑剔一下如今的流程。看看它们是否仍然可行,能否够改进。

    測试工具的实施也许能够帮助改进流程并使測试员在他们的日常工作中更开心。可是,把事情安排地有条不紊非常重要。一个測试工具绝不能成为不论什么问题的解决方式,它仅仅能帮助解决这个问题。因此,审视測试工具的成功实施,总会按顺序用到人,流程,技术。

    人应该被包括在内。且大多数会选择改进流程。

    需建立流程并使之在引入新測试工具前要达到成熟的水平。做到这一点,那么就是时候考虑工具和技术。

      为何測试工具实施会失败?
       既然我们已经了解了人-流程-技术顺序的重要性,就有可能回答“为何測试工具实施会失败?”回答一般是技术被放到人和流程之前。当一个流程还不够成熟,那么工具绝对无法改进流程的。最大可能是强调流程仍没效率这一点。因此,在一个失败的流程里引入一个測试工具仅仅会使问题更严重而无法帮助解决这个问题。当优先考虑技术而非人时。更有可能測试工具实施会失败。当人们对其在做的工作不惬意时。单单一个工具也不能让他们突然惬意起来。


       生产效率低时。可能是流程出了什么问题。工具不会自己主动提高生产率。

    最后,当引入一个不被人们支持的測试工具时,实施必然失败。人们应该看到改进某特定流程的必要性,且应该意识到引入一个特定測试工具可能最后能帮助更高效地完毕他们的工作。假设一个组织没有把这三点按序排好,那么“有了測试工具,傻瓜仍是傻瓜”这句话就成真了。或者换句话说。一家仅仅为实施測试工具而实施測试工具的组织终会出丑的。

    版权声明:本文出自 SPASVO泽众软件測试网:http://www.spasvo.com/news/html/2014928133423.html

    原创作品,转载时请务必以超链接形式标明本文原始出处、作者信息和本声明。否则将追究法律责任。

  • 相关阅读:
    PHP基本的语法以及和Java的差别
    Linux 性能測试工具
    【Oracle 集群】Linux下Oracle RAC集群搭建之Oracle DataBase安装(八)
    【Oracle 集群】Oracle 11G RAC教程之集群安装(七)
    【Oracle 集群】11G RAC 知识图文详细教程之RAC在LINUX上使用NFS安装前准备(六)
    【Oracle 集群】ORACLE DATABASE 11G RAC 知识图文详细教程之RAC 特殊问题和实战经验(五)
    【Oracle 集群】ORACLE DATABASE 11G RAC 知识图文详细教程之缓存融合技术和主要后台进程(四)
    【Oracle 集群】ORACLE DATABASE 11G RAC 知识图文详细教程之RAC 工作原理和相关组件(三)
    Oracle 集群】ORACLE DATABASE 11G RAC 知识图文详细教程之ORACLE集群概念和原理(二)
    【Oracle 集群】ORACLE DATABASE 11G RAC 知识图文详细教程之集群概念介绍(一)
  • 原文地址:https://www.cnblogs.com/jzssuanfa/p/6977868.html
Copyright © 2011-2022 走看看