|
|
看来大家都非常关注自动化测试,也看清了这是今后发展的趋势,呵呵.
大家在不同公司,是否在做的比较成熟的自动化测试框架呢?以前我在公司的时候自动化测试始终是在不断摸索中寻找光明的一线,呵呵.不过还好一直在前进着.
我先来发一篇文章以供参考.呵呵.
自动化测试在企业中的实施
文章出处：www.51testing.com 作者：钱亦嵘 发布时间：2005-10-19
【摘要】本文从为什么要引入自动化测试出发，深入探讨了企业实施自动化测试的流程。
【关键词】自动化测试自动化测试工具
前言
51testing上许多期杂志都有涉及到自动化测试专题的文章,其中既有谈到自动化测试技术解决方案的文章,也有教大家如何使用自动化测试技术的文章,看了以后都使我受益非浅。
大家知道，在国内测试行业属于一个新兴行业，与国外测试行业相比，国内也只是近几年才开始重视软件测试的。之所以被关注，原因也许是多方面的，但我想最根本一点就是中国软件要发展。
中国软件这几年发展迅速，很大部分原因是借鉴了国外优秀企业的经验技术，从无到有，学习了国外企业的一整套做事的规范，的确是一种快速成长方法。当然软件测试也应该如此，从不重视到重视，更应该多学习一下如何制定测试流程，缺陷管理以及测试用例设计等优秀理念。在此笔者只想针对自动化测试在企业中的实施谈些个人意见，希望能和大家分享。
当然，自动化测试作为一项新技术，一开始往往会被一些人认为是“无所不能”的，以为一旦有了它就可以解决软件所有的质量问题。难道自动化测试就是传说中所谓的“银弹”吗？结果当然是否定的。假如在实施前没有好好的调查、做好预期准备工作就盲目开展，一旦进入推广实施阶段，往往最终会弄得无法收场的结果。下面让我们先来解决一个问题。
为什么要引入自动化测试
首先，按照笔者的观点，用自动化工具进行测试只不过是测试活动中的一种。真正要在工作中派上用场，也是因为测试工作有了人的参与，而使用工具的目的也只不过是用来减少部分手工测试，将更多人力资源投入到更有价值的工作中，决不能轻重不分。
其次，既然要跟上国际潮流，那么自动化测试技术就是将来大部分测试工程师需要必备的一项技能。这也是笔者为什么要写这篇文章的出发点，希望能帮助大家推动自动化测试在企业中的实施。当然首先要保证一点，要实施自动化测试的企业必须符合具备开展自动化测试的一些先决条件。
笔者就有这样的感受，在企业中，如果想把自动化测试技术应用到工作生产中，没有持之以恒的恒心，坚忍不拔的决心，高度的自信心，是不可能完成这个工作的。那么怎样的时机是有利于开展自动化测试的？实施过程中该注意什么？采用什么策略去避免不必要的损失，提高大家对新技术的兴趣是很有讲究的。下面笔者将一一做出解答。
企业实施自动化流程
1）至关重要的是公司的高层必须认同成立测试部门是很重要的，不是浪费公司的资源；这一点，其实很早就应该达成共识，因为像Microsoft这样的公司也说过“大多数人认为我们是一个软件开发公司，其实我们是一家软件测试公司”的话，从中可以看出测试是非常重要的。然而考虑到公司的长远发展，自动化测试将是今后的一个发展方向。由此看来，自动化测试是有必要深入开展的。
2）在公司大规模使用前，必须要有专人针对不同的自动化测试，去评估究竟该使用哪种测试工具比较好。自动化测试工具又分单元测试工具、功能自动化工具和性能自动化工具，其中又分开源的和商业工具。究竟哪种工具更适合自己公司平台的测试，还需要有专业人员进行评估。
第一、比如说公司是采用Java技术还是.NET技术开发产品的。大多数商用工具都会根据现今最流行的开发平台提供一种自动化测试的解决方案。做测试工具比较专业的有Mercury，Segue，IBM Rational，Compuware，Empirix这几家公司，根据不同测试又有相应的测试工具。
第二、如果考虑到商业软件比较昂贵，还可以考虑一下开源的测试工具。这些工具往往具有小巧，灵活多变，免费的特性，还有个好处就是它的开源。现在全世界范围已经有越来越多的人投入到开源项目中去。已经比较出名的有Apache的Jmeter，Jtest，OpenStar等等。就连全球最大的IT公司IBM现在也把目光聚焦到了这块，由IBM出资1000多万的开源项目Eclipse，在过去也许是唯一一个能和JBuilder开发环境相媲美的开源的开发环境了。但现在在此平台上有了TPTP，但我们同样可以在Eclipse上做我们的功能和性能测试
第三、也许以上工具都无法满足测试的特殊需求，那最好的方法就是自行开发测试工具；这主要集中在嵌入式系统方面。比如手机与手机之间需要做到即时、无误的发送短消息，而一般常用的工具是没有办法做到这方面测试的，那就只能考虑公司内部自己开发测试工具了。
第四、还有就是在选用工具方面，还要充分考虑到工具的可集成性、可扩展性以及平台兼容性。因为实际工作中，我们常常需要把测试流程，需求管理，缺陷管理，配置管理结合的更紧密，通过工具去统一管理。这些都是在选用工具时要考虑到的因素。
3）在全面实施之前，根据以往的经验，笔者建议最好选出几个人进行小规模的实验。这样做的好处一来可以以小见大，从几个人的反映看出自动化测试的雏形；二来可以总结不足之处，在后期的开展中尽量避免；三来，可以把实施所见的成效推广开来，为后期工作的开展做好铺垫。
笔者在企业里就有类似的经历，一个项目已经上线，以后每次发布一个补丁之前，测试人员都需要通过执行一些SIT(System Integration TestCase)测试用例来覆盖整个系统的大部分模块。而执行一遍这样的用例，至少需要花费六个测试人员一天的时间。后来在这个项目内进行了自动化测试的实验，根据SIT的测试用例转换成自动化脚本。运行一个用例脚本只需要十五分钟，而每次也只需要一个测试人员把所有脚本运行一遍就可以了，其他人就可以从中解放出来做其他工作了。像这样比较成功的例子，一定要在后期工作开展时加以宣传，要认大家认识到自动化好处，这样大家才会有积极性去学。
4）有了上面的经验，接下来该在整个部门进行自动化测试的推广了。当然适当给从业人员进行工具的使用技能以及一些相关知识培训还是有必要的。因为在工作中常常发现由于测试工程师掌握知识的差距，每个人对工具上手操作有快有慢。为了尽量给大家造成好的影响，能够更好的开展这项工作，使其能更快的应用到日常工作中去，减轻部分繁琐的重复性劳动，对测试工程师进行培训还是必不可少的。
5）正如软件生命周期有需求分析阶段一样，在录制自动化脚本之前也需要收集需求,这些需求主要是用于后期录制脚本的选取。这些需求可以根据需求人员做的需求文档，也可以选择测试人员的测试用例来转化成脚本，还可以让需求分析人员推荐几个常用的，相对简单的流程转化成脚本。总之一句话，需求就好比源头，从源头抓起才能开发出高质量的脚本。
6）做了前面一系列准备工作，已经有了一个好的开始。接下来就要求大家进行一次头脑风暴，对刚收集来的需求进行分析，设计出一个好的实现方案。这里我想强调两点：
第一、工具只能帮助测试人员去更好的进行测试，至于怎样使用才能提高工作效率，还是需要测试人员在实施前期进行更多的思考，比如思考如何把一个好的设计转化成我们后期的自动化脚本等。因为脚本是不会创造性的发现本身没有涉及到的缺陷，就好比许多测试人员编写测试用例，如果你没有把你要测试的功能点写入测试用例中，根据测试用例执行人员是不会考虑到这一点的。因此设计一个全面，详细的设计方案显得尤其重要。
第二、出于程序可复用的角度考虑，按照怎样的划分粒度，如何把脚本进行好的规划也很重要。例如：将一些使用率高的模块录制成共享脚本，使用者只需要通过一些参数进行使用，无须考虑到内部的具体实现机制。这样还可以大大减少大家的重复劳动量。
7）对工具有了一定认识以后，就到了上手操练阶段。俗话说：“拳不离手，曲不离口”。由于前期投入大量精力、人力、物力，现在正是出成果的时候。但在开发脚本之前，笔者还有几点想着重申明一下：
第一、开发脚本必须遵循一些规范化，就类似于程序员编程规范一样。我们的测试脚本就好比是我们测试人员的程序，同样要形成一个编写规范。因为养成这样的好习惯，是为了能方便维护脚本，避免增加后期的维护量和方便使用者使用；
第二、保证开发的脚本回放没有问题的基础上，适当增加出错处理来增强脚本；
第三、后期还可以在脚本中加入检查点，这样做的好处可以把原来需要人工去校验的地方让脚本去做；
第四、在脚本中增加数据驱动方法，使脚本能覆盖更多的分支路径，进一步提高脚本的集成度。因为前面已经说过了，脚本是不会执行那些没有被编写进去的功能点的，所以说后期测试人员一旦发现这个地方有必要让脚本来代替手工进行执行，就可以不断的增强我们的自动化脚本。
8）最后，切记任何工作的开展并非一朝一夕，新技术的开展将需要投入大量人力物力，而自动化测试就是我们测试工程师必须要坚持的一个长期的发展方向。为了不至于做事只做表面，建议每个测试团队中都必须要有专人去负责推动自动化工作的开展。还必须有专人负责维护脚本，规范脚本，甚至可以引入配置管理工具来统一管理脚本和把经验文档化。只有这样我们的测试财富才会从中不断积累，只有这样自动化测试才能走得更远。
以上总结了几点，都是笔者在企业中推行自动化测试的一些心得体会。最后希望能够有更多人从自动化测试中获得快乐，从繁琐的手工测试中解脱出来。 |
|
/1 
关于我们
发表于 2006-5-8 21:18:30
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
微信
收藏
置顶服务
换色服务
楼主
