自动化与agile

上一篇 / 下一篇  2012-08-05 15:35:45 / 个人分类:自动化测试

 

(一)自动化真的那么难吗?

都说自动化好,自动化是银弹。谁都想做,但现实没有几个真正做好的?现实的状态:自动化测试是锦上添花,闲的时候想要,忙的时候不要。

自己也做自动化五年了,既有成功经验也有失败的经验,在这个过程中既有对大师们学习,也有自己的探索。我们成功的实现一个基于产品的DSL语言并且开发相关的调试工具。把一个产品做到自动化率从0做到85%,并把自动化测试直接新功能测试,打破了自动化测试只能做回归测试的神话。

自动化测试真的就那么难吗?先说测试与开发哪个难呢,这个问题不言自明的,普遍的都认为测试简单开发难(并且这也是为什么大部人认为测试低人一等原因,暂且不论这个观点对与不对)。自动化测试一般用脚本开发,脚本语言的开发效率要比C/C++,java等开发语言要高很多。自动化测试应该更简单才对。但为什么又总是做不好呢?因为大家都觉的开发难,所以大家集中精力为简化开发而设计多少工具和开发框架。相比来说,自动化测试方便的工具与框架是少多了吧。也更是这个“少”,所以我们才感觉自动化测试的简单,但又总是做不好。

 

从本质看是自动化测试与软件开发是一样的,只不过是用一段代码测试另一种代码。不同的是一个功能开发而另一个测试开发。所以要把自动化测试更多当作开发对待。现实中,自动化之所以难做根本原因是软件本身框架的设计不好,并且也没有考虑代码可测性,甚至不可测。软件框架设计越好,代码可测性越强,测试就越容易,产品的质量也就越好。并且代码可测性强的话,开发与测试是可以并行开始的。这也是敏捷工作模式。整个项目过程,测试要与开发一起工作:

1.        需求阶段开发思考需求的可实现性,测试思考需求的可测性,

2.        设计阶段软件框架既要包括功能框架和测试框架。

3.        开发阶段功能开发人员与测试开发人员基于共同的接口去实现各自的功能。

测试开发速度肯定会比功能开发的速度块(一是相对难度小,另一方面测试开发一般都用脚本语言,编码效率也高)。所以只要功能一开发好,测试就可以马上启动,并且自动化测试又没有回归测试的负担。执行完全放在晚上与周末跑。白天的时间都可以做测试执行的结果分析,定位问题。是bugbug.是脚本错了,改脚本。所以测试速度基本上开发两倍以上(开发只能在工作时间8个小时,自动测试却是可以7*24小时的)。你可以还用担心测试时间不够吗,你可以有更加的手工的探索性测试。而真实的情况是什么呢,大部分测试是在项目后期才开始介入的,他们只有被动的接受,软件开发并没有考虑代码可测性的问题。

(二)什么测试适合自动化以及如何自动化?

自动化测试与CIagileDNA。所以要想用好agile就要在一开始打上自动化测试的DNA.这样也是最轻松的,代价最小的。一般agile在公司创业初期最容易引入的,因为这个时候,基本是一个人要身兼数职,需求分析,开发,测试都要自己做。对于你说,只能自动化了,别无他法,因为你没有钱去雇更多人给你做测试(并且有现例,我一个朋友自己创业开了软件公司,我们聊天的时候,他经常报怨开发测试都要自己做忙不过来,让我帮忙想想办法,我给了他一些自动化测试建议与解决方案,现在我们聊天的时候,再没有听到类似的报怨了,因为他产品编译,测试,部署都已经自动化了,现在常聊的话题,对于遇到的新问题,有什么可以自动化的solution?.

 

要想自动化,首先要有一个好的可测性的软件架构,采用分层模块化设计框架,并且每一个模块的输入与输出都可以直接控制。以及持续集成CI也做好了。就开始测试的自动化了。但是不所有测试都都适合自动化。测试可以分为四大类如图:

并且我们从哪里开始自动化呢,要根据ROI来决定:

为什么会有这么一个层次的图呢,一方面是bug的反馈速度与其维护成本的大小决定的:

1.      大家都知道bug发现的越早,修复bug的成本越低。自动化测试越靠近底层,发现错误的也就越早。

2.      越往上层变化就越多,所以维护成本了也就越高。

人们会潜意识从GUI测试开始自动化并且大多都是失败而归。一方面是由于本身变化大,维护成本太高,另一方面开发就没有考虑代码的可测性。我们也试过GUI自动化,也是失败而归。后来自动化从API层开始的自动化,取得了成功,但是早期也是特别艰辛,由于没有unit TestsComponent Tests,产品质量不是很稳定,自动化做起来也是异常吃力。软件开发更是辛苦,因为版本一发布,就会巨量的bug,他们每一次的版本发布,都是提心吊胆的。因为自动化一晚上就可以所有case跑完。测试每天忙着提bug,开发忙着解bug,,测试与开发都陷入了人机赛跑的怪圈,甚至引起了大家对自动化的恐惧与仇视。不过,还好大家最终还是熬过去了。到了项目后期,产品稳定了,回归测试的bug的少了,测试摆脱了人机赛跑的怪圈。并且每天也有了大量的时间开始做探索性测试,发掘出越来越多深层次bug.而开发头疼依然,因为发现bug越来越难解了。最后项目结束后一年里,软件开发人员差不多走了快一半的人(这部分都是在公司工作以了5年以上的老员工)。基于此公司也开始去补unit tests/components测试了。

(三) 自动化测试的策略?

每家公司情况都不一样,没有什么一个万能的方法,包治百病。条条道路通逻马,但是每条道的难易程度是不一样的。只能根据一些策略,然后去走适合自己那条路吧。

从最疼痛的地方开始,整个team一起往前走。

从最疼痛的地方开始,因为这样才有动力。为什么要求整个team一起努力呢,因为解决一个问题的很多种,可以从开发入手,也可以测试入手。你不能要求一个人把工作做到极致。并且一些隐性的工作,得不到大家的认可,慢慢个人就会失去改进的动力,本来这些工作就是可做可不做的,为什么要白费力气呢。

举两个人的例子吧,不能要求一个人把工作做到极致。

事例1测试遇到异外情况下,我经常是保留现场找来开发一起study,尽快走出问题根源。特别是遇到复杂的stress,performancecase,环境配置搭建就费时经常准备测试环境就要几个小时,有些深层次问题也不是必现的。但是有些开发人员不够professional,一上来就看也不看,就说能重现吗,你清配置,重头开始再做一遍,打起官腔啊。你说你能不气愤,遇到这种人我的态度,重现可以,但是只有这一次。我会把重两步骤,相关的log都写在bug里。回去你自己重现分析吧。让我重现可以,前提是,你照着我的step做了,并且证明我step错了没能重现,因为对于测试来说,能够保证bug的重现,后面的事情就不是我份内的事了。合作是相互的,不是单方面的。

事例2,在之前的一项目组,大家的交流经常是邮件来邮件去,效率非常低,大家对此意见也非常大。我主动把邮件内容整理好放在wiki上,方便大家的交流。但是,这个小组的lead却说,不务正业。既然如此,哥也只好回到正业,继续看着效率低下(也正为这个效率低下,这位lead每天加班很晚,每天最后一个走,显的只有他才是努力的,毕竟加班是人人能看的见的)。最后哥只能用脚股票,换了一个项目组。

 

以下往上,小改进,持续化

自动化不是一开始规模做战,自动化可以是随时随地的,把日常工作一些重复的工作,用自动化实现。这样才能有时候时间去做更多的自动化。例如可以先从CI做起,然后如图从下从图逐层往上。如果开发测试在同一个team,unit测试开始,如果是测试与开发是独立的,从API层开始,相对经济一些。

 

加强沟通

要尽可能让每个人发出自己的声音,而尽可能避免这样的沟通:A说,我认为B会觉得这么做会更好。B觉得好不好,还是留给B自己决定吧。这也是测试难做一原因,什么东西都知道的最迟的,也经常不是自己所期望的。经常是开发与需求分析人员讨论问题,他们认为他们能够真正知道测试想要什么。

遇到问题时,尽可能开发,测试,需求分析人员一起讨论,让每个人表达的自己的意思,有可能得到解决方案是不是最完美的,但肯定是最实际可行的,因为兼顾与平衡各方的利场与想法。

 

当然要想做好这些,包括工具的开发,部署等等一系列的问题,放在别的文章再慢慢总结讨论。


相关阅读:

TAG: Agile agile 敏捷 自动化测试

 

评分:0

我来说两句

日历

« 2024-03-14  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 11532
  • 日志数: 11
  • 建立时间: 2012-04-18
  • 更新时间: 2012-08-06

RSS订阅

Open Toolbar