LoadRunner性能数据结果分析连载(引言)

HP Mercury LoadRunner 是一款功能相当强大的性能测试工具,由三个部分构成, VUGen, Controller以及Analysis. 其中VUGen负责进行脚本录制, Controller是一个总控中心,负责场景的配置,监控器的选取和监控,并选择合适的负载生成器进行执行, Analysis是一个分析模块,主要负责所有执行数据的分析以及报告的生成.
之所以说LoadRunner是强大的性能测试工具,主要是因为VUGen支持大概好几十种主流的协议. 因此支持的被测对象相当广泛,另外Analysis也有超强的功能,提供非常丰富的图表,供测试结束之后分析和定位问题.
我使用Mercury LoadRunner有一年左右,2006年6月通过了LoadRunner的SP考试,并于12月底参加了CPC考试,以2分之差失败. 在这一年之内对Controller和Analysis的使用有一些心得和体会,大概能看懂一些主要的分析图表,包括事务相关的一些图表,所以希望作一个总结,对希望学习和了解LoadRunner的朋友有一些帮助. 因为时间有限,所以初步打算以系列的形式发表. 下次打算介绍Analysis提供图表的概述.

--to be continued

自动化测试的思考和总结之功利篇

上周参加公司的自动化测试研讨会，今年的主题是ROI（投资回报），个人感觉这是一个很严肃的话题，也是领导最关心的一个问题。不过谈测试自动化的投资回报似乎并不是一件容易的事情。测试自动化本身是一个需要持续投入的系统工程。他并不像开发过程一样那么容易衡量产出和回报。另外，对于测试自动化的投资回报似乎不应该在一开始提到一个很高的高度。否则对自动化的开展非常不利。

另外，测试自动化并不是简单的把手工的测试转化成自动化的代码或者脚本这么简单的过程，而是要贯穿在产品的生命周期中，进行不断地执行，只有不断地执行，才能得到收益，根据经验，回归测试的自动化测试用例在不考虑被测对象改变带来自动化测试脚本维护的前提下，反复执行4-7轮才能收回成本。如果被测对象本身不是十分稳定，或者缺陷比较多，产品不成熟，这个时候介入测试自动化是非常得不偿失的。

测试自动化在很大程度也依赖于被测对象或者被测设备的稳定性，系统的设计应该考虑到可测试性，Design for Test。测试自动化越早加入到产品的开发周期，成功的机会越大。
关于测试自动化的效果衡量不是简单的发现了多少缺陷，其实自动化测试并不能比手工测试发现更多的缺陷，如果要发现更多的缺陷，一定要进行必要的手工测试。自动化测试的效果或者投资回报可以通过其他一些方法进行衡量，比如节省的测试人力成本，可以通过统计手工测试的时间，自动化测试的开发时间，自动化测试的执行之间，执行次数，刨去维护时间，进行计算得到。另外，还可以从回归测试能加快产品的发布时间上进行衡量。

最后，关于产品的自动化程度，究竟多少比例的产品需要被自动化，这个取决于产品本身，以及这个产品本身可以被自动化的程度有关系，还要考虑自动化所需要花费的代价。一般来说，不是所有的测试用例都需要自动化，也不是所有的测试用例都能够自动化。据个简单的例子，有一个测试用例，需要重新启动机房里面一台服务器，常规来说，是不能也不需要自动化。但是有没有可能自动化呢？肯定有，不过肯定不会为了这个自动化这个测试用例而去花费巨大的代价开发一个机器人帮你完成这个任务。当然这是一个极端的例子。目的是告诉大家，不是所有的测试用例都需要自动化，也不是所有的用力都能自动化。衡量的依据是不同产品和代价得多少。

--end

自动化测试的思考和总结之工具利器篇

谈到自动化测试,自然离不开自动化测试工具. 其实自动化测试和自动化测试工具还有很大的差别,不过很多人提起来自动化测试就想到自动化测试工具,其实是不全面的，更有人提到自动化测试就想到QTP,LoadRunner,Test Manager,那就更是片面的了。

自动化测试工具是开展自动化测试的必备利器，就好像你要进行性能测试自动化，但是缺少工具。传统的方法比如压力测试是号召大伙某个固定的时间，登陆某台测试对象或者测试设备进行同时测试。这在现在看来是有些不切实际，而且实际的测试效果往往因为无法有效组织或者无法模拟实际情况大打折扣。而利用自动化测试工具就可以很好的满足这样的需求，最简单的就是模拟500用户并发测试web服务器的性能。

不单单性能测试，往往功能测试自动化也是这样的，只是性能测试表现得更加明显罢了。功能测试自动化如果能有效的利用自动化测试工具，有的时候可以收到事半功倍的效果。

简单的分析到这里，关于测试工具的一个很全面地总结，可以参考前面的一篇日志。

--to be continued

自动化测试的思考和总结之平台利器篇

上周休了一周的假, 在医院照顾老爸
这周继续自动化测试的思考系列,今天谈谈平台建设.

自动化测试一般来说,随着产品的不同,都会有不同的测试架构和测试平台,稳定和合适的平台对于一个产品的自动化测试来说,相对来说相当重要,有了合适的载体和工具,自动化测试就能很好的扩容和执行.

一般来说,自动化测试的平台包含以下一些方面:

测试管理部分--管理不同产品,不同版本的测试用例
测试执行部分--执行测试用例
测试维护部分--测试用例的维护,版本控制等
测试资源部分--测试资源特别是实验室资源的管理
测试调度部分--测试的调度,控制和执行中心

一般来说,这几个部分可以集成于一个平台本身,也可是独立的子系统,通过接口有机的结合起来,其实市场上也有很多商用的产品,比如Mercury的QC(Quality Center, Test Director的后续版本)就覆盖了其中的测试管理,测试执行等, Rational的Test Manager覆盖了另外一些部分等等.

因为这些商业工具相对来说,价格比较昂贵,而且对具体产品的适应能力等方面的考虑,不一定适合所有的公司,因此我们自己开发了自己的相应的系统.

测试执行平台:我们的测试执行平台其实覆盖了测试执行部分,测试维护部分和测试调度部分,是一个很强大的平台,从最初的1.0版本,到现在的2.1.1版本,基本可以支持我们公司的绝大多数的产品,另外测试管理的部分也有一些涉及,但是相对来说比较薄弱,特别是版本管理部分,目前是通过和测试管理工具的接口来实现的,我们正在改进这些薄弱的环节.

测试资源平台:我们也有一个自己开发的资源管理平台,可以预定实验室的各项资源,并用于测试,目前我们在测试执行平台预留了资源的相关接口.这部分跟具体的产品联系比较密切.

总体来说,下面这个图能详细说明这些部分之间的一个关系和接口.




下图是我们自己的测试执行平台的架构:



其中
ATS: automated testing system
LRMS: lab resource management system
TMS: test management system
(转载请注明出处)


--to be continued

自动化测试的思考和总结之天下三分篇

对于自动化测试的组织划分,一般来说,在企业内部,有两种结构: 隶属于系统测试部门或者专门的自动化测试部门.

我所经历的自动化测试部门,就经过这么一波三折的过程,首先始于系统测试部门的一个team,专门为这个产品的系统测试服务,自动化也就仅仅局限于这个产品的系统回归测试. 随着自动化程度的不断提高和管理层的重视,自动化测试也逐步发展壮大,服务的部门也从仅仅是系统测试部门的回归测试拓展到集成测试,单元测试等等. 服务的产品也从单一的产品扩大到整个公司的产品. 这是一个必然的过程. 专门的自动化测试部门有利于从整个公司的角度协调各种资源,所以是必然的.

在自动化测试独立成单独的部门,角色一般是这样:有一个经验丰富的自动化经理,负责全局的统筹和管理. 对于不同的产品或者不同的系统有资深的自动化测试专家/自动化测试主管, 下面会有专门的自动化测试工程师,对自动化测试工程师甚至资深自动化测试专家要求首先有过开发经验,并且有一定的测试经验,做过手工测试,这个必须的,另外,对相关的产品要比较熟悉. 另外对资深自动化测试专家要求对被测系统的架构有全面和深刻的理解. 另外可能还有一些自动化测试工程师或者测试工程师, 来执行相关的自动化测试用例. 这些测试工程师要求对系统要相当了解,可以从手工测试部门抽调过来,也可以本身就属于系统测试部门, 这样就是一个虚拟的泛自动化测试部门.

有了组织结构,就可以进行自动化测试了吗,当然不, 首先自动化测试需要以来很多的因素,自动化测试平台就是其中一个,下节重点介绍自动化测试的平台建设.

--to be continued

自动化测试的思考和总结之天时地利篇

昨天谈到自动化适合的产品,今天简单聊聊何时开始引入自动化最有效.

自动化测试的建设不是一蹴而就的,首先自动化测试的发展依赖于手工测试.
一般来说,手工测试进展到比较成熟的阶段,公司有完整的手工测试流程,相应的手工测试工程师具有一定的编程经验或者脚本开发经验,这个时候引入自动化测试才会比较有效.

相反,如果一个公司或者一个产品基本的手工测试都很不完善和规范,测试的质量也得不到保证,更谈不到测试的覆盖率,这个时候贸然的想通过实行自动化来提高测试的质量或者测试的效率.失败的机会就会非常大了.

完善的自动化测试流程和规范不是简单的几个文档就能解决问题的,而是要把这种流程或者规范彻底贯彻到每个测试工程师身上. 测试用例如何写? 产品规格说明书更新及时不及时?有没有符合本公司的测试管理系统? 测试报告能不能按时提交?等等一系列问题,不是简单停留在是否存在几篇文档或者开几次会议就能解决的问题.

现在国内我知道好多朋友所在的公司,看到自动化测试不错,可以提高效率,节省人力,老板就拍脑袋也要搞自动化,好像搞了自动化测试,公司的测试水平就能提高一个台阶,产品的质量就能得到保证. 其实他完全没有看到自动化测试的另外一面. 另外,居然还有人理解我引入了几个自动化测试工具WinRunner, QTP, LoadRunner, 我就是自动化测试了. 大错特错了.
关于测试工具和自动化测试的话题,后面会有讨论.

一个公司或者一个产品在引入自动化测试之前,一定要进行详细和客观的评估.

--to be continued

自动化测试的思考和总结之有的放矢篇

对于自动化测试适合的产品,或者更精确到哪些测试测试适合做自动化,已经被广泛的讨论过.总体来说, 有如下一些:

1. 首先是回归测试,这是勿庸置疑的.
利用自动化来进行回归测试,不仅可以把测试工程师从枯燥无味的繁琐测试中解脱出来,而且可以腾出更多的时间设计更多更好的测试用例,提供测试的覆盖率和测试的质量.
2. 其次是部分性能测试
对于一些性能测试,比如系统容量或者系统并发用户的测试,因为资源的限制,利用手工测试有很大的困难,有时候条件也不允许,充分利用一些自动化性能测试工具,就可以很好的完成测试目的.
3. 还有就是利用手工很困难或者根本无法完成的.
有的时候,需要进行一些压力测试,离开工具可能比较困难,这个时候就可以发挥自动化的长处.
4. 还有就是产品趋于稳定,变化小,这样的产品更适合与自动化,我们就曾经在一个产品很不完善的时候进入到自动化,结果耗费了巨大的人力,最后产品变化了,自动化测试脚本和测试用例重用性不好,基本全废了. 其实这也需要产品和软件本身应该满足一些可测性要求. 并在前后的版本之间保持接口的统一. 细节来说,就是配置哪怕是基本的日志都必须满足一定的规范. 否则自动化测试进展起来就比较困难.

另外,无论针对任何产品的自动化测试,都会存在一些普遍的问题:
1. 自动化测试不会比系统测试发现更多的bug,或者说自动化测试更重要的是帮助快速验证产品经过更新或者修改之后的质量.如果要发现更多的潜在问题,必须进行手工测试.
2.对于频繁变化的产品,自动化测试的维护成本很高,这点反复强调,就是因为我们在这方面走过很多弯路,往事不堪回首啊~~
3.通过自动化测试没有发现缺陷并不能代表说一定没有缺陷存在,没有权限的系统或者产品是不存在的.
4.自动化测试对环境的依赖远远大于手工测试对环境的依赖,针对自动化测试的环境问题,因为牵涉到的问题比较多,后面打算专门讨论这个问题.

自动化测试的思考和总结之开篇

自己从事自动化测试三年了,经历了很多的波折和教训,当然也积累了些许的经验,很久以来一直有想法把这些内容系统的记录下来,对自己来说,轻装上阵,更好的探索以后的自动化怎么走;对别人来说,也算提个醒,哪些错误最容易犯, 需要避免什么样的误区.
最近看了很多的论坛文章,感觉大家都很茫然,测试怎么做, 刚入行的, 在这个行业打拼了几年的,大家对前途都没有太多的目标,也许只能好好反省自己的过去,总结一下自己过去犯过的错误,回过头去,才能更好的认识前面的路.
罗嗦了这么多,现在开篇,本文打算以系列的形式连载,主要都是自己的经验和教训的回顾,所以有时候想到哪儿就说到哪里,不会刻意去组织很美的文字,不过我会尽量使文章能表达我的意思. 这个系列目前大致想分为几个大的部分:

• 自动化测试的适合产品
• 何时引入自动化
• 自动化测试的组织结构
• 自动化测试的平台建设
• 自动化测试的支持和维护
• 自动化测试和自动化测试工具
• 自动化测试的管理保证
• 自动化测试和回归测试

下次着重讲讲自动化测试的适合产品.


--to be continue