有赞测试文章读后感

有赞的发布系统为公交车发布系统,我们的发布系统为极品飞车发布系统将来肯定会比他们的牛逼。目前我们的极品飞车系统还在起步阶段,分支发布还在开发过程当中,但整个发布系统功能跟有赞类似,我们的平台将来还要与docker平台,监控系统对接,这是有赞公交车系统所没有的;感觉他们的分支发布好像不是自动编译的,现在我们运维平台实现了自动编译功能,发布项目挺快的;他们的发布流程很长,也不知道他们发布一个项目需要多长时间。

值得借鉴的是他们的整个发布过程已经跟测试打通,整个发布流程相当于是一条龙服务,全程自动化,平台界面展示效果较好。我们的平台现在还没有达到这种地步,但是肯定会的,很看好我们的平台!

有高度,有深度——有赞测试团队介绍读后感

附链接:有赞测试团队介绍

一、有高度:有赞的测试团队基于“提高产品质量”的立场,参与到产品研发流程各个环节:技术评审后的测试方案制定和评审、测试用例编写驱动开发、codeReview、集成测试、多环境测试,并且积累了一系列高效的工具:QA平台、mock服务、安全扫描工具、性能测试平台、持续集成平台、基于测试历史数据分析的工作台。

二、有深度:深入到跟质量相关的各个层面:RPC接口、http接口、线上服务监控等。

他们的测试团队打破了我对测试团队固有的看法:界面点一点、顶多用工具做一下接口测试和压测,他们能基于自己的使命主动出击,做了很多严格意义上讲并不属于测试职能的工作:codeReview、服务监控等,但这些也确实与产品质量和服务质量息息相关。

还有一点,他们的自研能力很强,能基于测试需求开发自己的工具,达到了可持续测试,并且基于测试数据做产品的宏观质量分析。

最大的感触,测试团队也大有可为!

有赞.测试团队介绍读后感

有赞测试团队的一个亮点是,他们对平台上的开发和使用。他们的有赞QA平台提供了「构造测试数据」「项目质量报告」「项目日报」「环境健康检查」能力。性能测试平台简化了性能测试的步骤,提高了测试的效率,使得普通测试工程师也能方便地进行性能测试。以及他们正在建设的carmen该平台可以实现测试用例管理,又能够将用例自动化与用例绑定在一起;还有他们的集成测试平台,测试工作台等等,这些平台规范了他们的工作流程,提高了他们的工作效率。

再者从自动化来说越底层的自动化,收益越高,有赞的自动化分布图正是这样的金字塔结构,从而创造最大的效益。一个人的工作量是有一定范围的,自动化测试可以有效的减少单一重复的手工测试,去做更多更有意义的手工测试。

最后,质量不是测试人员一个人的事情,而是所有参与人员的事。

有赞测试团队介绍 读后有感

读了“有赞测试团队介绍”的这篇知乎分享,确实能感受到有赞测试流程的规范和成熟,有些我们可以借鉴起来;接下来我主要从如下几个方面同时结合公司现状(我刚来公司一周,可能会有些现状了解的不是很透彻,如果有片面或是不全面的欢迎大家指正),发表一下读后感言。
一、流程方面
项目协作
如上图,通过有赞的项目协作流程,个人总结有如下优点:
1、测试人员参与的时间比较早,从需求评审就介入,而且跟踪项目较完整,从需求评审一直到项目上线
2、测试流程很规范,从前期的需求分析,测试方案设计,设计评审,再到测试用例及提测用例的编写;有比较合理的时间去消化需求,落实用例,为后期的测试场景覆盖打下良好基础,避免后期时间紧张,场景考虑不全;
3、对于需求分析比较重视:需求分析后,需要输出对象生命周期图、业务时序图、用例图、待确认的问题、风险点清单。并就相关问题、风险与产品、开发进行多次沟通,直到问题得到明确答复。
这样前期重视需求分析,可以将一些需求不合理或是遗漏问题在前期暴露,在开发阶段就会解决一些问题,避免到后期测试阶段才暴露一些需求或是流程问题;同时能够更合理的评估测试范围,避免一些其他的业务功能兼容遗漏;
4、对于开发质量比较重视,开发阶段增加了单元测试,这样能够进一步保证开发功能的提测质量,把一些问题截止在前面,而不是到后期测试才发现,才去修改;
5、测试用例管理:在测试产出用例的时候会有两份用例,一份是测试用例,一份是提测用例;顾名思义,提测用例,就是开发在提测之前需要保证的流程功能用例,而且在开发流程中也有冒烟测试(个人认为冒烟测试直接执行提测用例即可,实际可能不太清楚是不是一套)和提测报告。这样,就保证了提测之后测试程序的质量,避免测试前期还因为主流程不通等严重影响测试进度的问题出现;
6、对于测试效率提升的重视,引入了测试自动化以及白盒测试,这里可能包括接口、UI等自动化

总结概括:流程比较完善,测试全程介入,提测之前的流程是比较多的,比如需求分析确认问题,设计测试方案,测试用例,单元测试,提测冒烟测试等等,前期介入比较多,可以将部分问题控制在前面解决,毕竟问题越是遗留到后边,修改的成本越高;

接下来通过这段时间与同事沟通以及自己总结,与公司现有情况做一下对比以及一些自己的建议想法:
1、测试人员介入和项目跟踪时间,以及测试流程:
需求评审会有人员参与,但是可能存在项目忙,参与项目需求的人员和实际执行测试的人员不是同一个人;
测试有的时候在项目提测的时候才开始介入项目测试,之前没有时间或是很少时间去充分的分析需求,以及评估测试范围,制定测试方案,有时候都没有时间编写测试用例。
当然以上问题也是测试资源和项目周期紧张,这就需要以后平衡,要想流程规范且质量有一定保证,多少是需要投入一定的时间和前期合理规划的;
2、对于开发质量,及提测质量的重视
缺少开发单元测试和自测的阶段
建议先把提测之前的自测做起来,在提测之前至少保证主流程,提测用例是通过的,后期可以再将单元测试推广;
3、测试效率提升
就如之前的计划,正好把接口测试和UI自动化引入,在提测之前保证接口质量,同时自动化用例也可以同步上线,对线上环境做相应的监控,以及后期其他项目兼容的一种辅助,避免大范围回归;后期大家能力提升之后可以考虑是否引入白盒测试等。
4、项目总结
对于一些优先级比较高或是项目周期比较长的项目,可以考虑要不要加入项目站立会的流程,这样每天或是几天同步一下进度,以及项目问题解决;
项目上线之后可以做定期的总结及复盘,对线上反馈问题进行总结,确认是用例场景考虑不全,还是测试范围评估不准确,还是环境需要完善等等,总结才能有进步。
二、工具建设
QA平台、有赞mock服务、安全扫描工具,性能测试平台,Carmen测试平台,持续集成平台,测试工作台等等;
这里对于工具和平台的构建其实还是需要时间和人力去搭建和维护的,如果前期达不到构建如此规范的平台,可以先重点关注这些平台中主要涉及到的一些内容,或者通过其他方式或是其他已有平台等来进行一些相关内容反馈。。
比如:
  • 有赞QA平台提供了「构造测试数据」「项目质量报告」「项目日报」「环境健康检查」能力;测试报告,包含项目质量报告及项目日报。用于跟踪项目过程质量、进展、风险及最终项目上线的质量。
  • 测试工作台:该工作台的目标是把测试小伙伴平时奋斗的成果展示出来,测试同学参与了哪些项目,项目的提测质量、测试质量、相关报告及风险点
我们可以考虑要不要先发起这些平台中的项目质量报告,项目日报,项目提测质量,测试质量等内容的补充;
三、线上监控
现在开发有线上的监控服务,加上后期的接口及ui自动化测试上线,后期如果通过定期执行,个人认为监控力度还是比较完善的。
四、发布管理
在发布管理上可能需要运维多费心,尽量梳理统一的环境部署规范,使环境部署不会占用太长时间;暂时发现以下一些情况,可能阻碍测试进度:
  • 前期测试环境搭建有时候比较费时间,有的时候提测之后好几天部署不成功;
  • 在有项目并行的时候,有的项目分支代码不完整,导致在分支下测试时候其他功能报错等不能使用,可以讨论是否可以优化;

有赞.测试团队介绍 读后感

有赞的测试和开发的边界比较模糊的,甚至延伸到了运维,已经有了一套交叉的套路,开发可以做测试工作,测试有开发能力,只是分工不同
同样我们研发人员也应该向外延伸,去多了解测试工作,也必须做好测试工作,简单的单元测试还不够,要做到具体流程测试,测试人员提供测试用例,及进一步验证
各个环节测试是非常耗时耗力的,要让开发人员尽量在提测前发现bug,就需要一个好的套路,这个套路需要各种测试工具和平台做支撑,如有赞的UI自动化、测试工作台、性能测试平台、全链路性能压测等。开发人员在开发的过程中能方便的进行测试,不当减轻了测试人员的工作压力,还可以及时让开发人员对代码进行调整,避免排查bug时耗费大量的精力。
我们曾经上线事故发生概率较高,除了上线规范没有做到位,还有一个就是缺乏一个线上业务级可用性监控。
然而我们目前这块还处于较为初级阶段,开发和测试套路交叉还比较少,还是偏向于测试找bug,开发改bug。要达到开发与测试的边界逐渐模糊,互相默契加深,只是在分工上做事的侧重点不同。我们还需要不断的努力,共同进步。

有赞测试团队介绍读后感

       看了有赞测试团队的分享,让我对优秀的测试团队有了更清晰的认识,一个优秀的测试团队需要具备以下几点:人员分工明确,团队目标一致,相互学习资源互补,有条不紊的测试流程等方面。有赞测试团队的强大不是一朝一夕能够实现的,我们可以吸收他们的长处补充自己的不足,设计出一套适合本公司的一个测试平台,让我们的测试团队更加强大。
       1.对于测试平台的搭建。我们需要探索出适合本公司发展的测试平台,让自动化测试不断的融入我们的测试过程中。对于功能测试,UI测试,安全性测试,性能测试,自动化测试要有一个合适的平台去合理的分工协作。
       2.对于自动化测试,每个测试人员都应有意识的去学习,去探索更好更快更精准的测试方法。自动化是必修课,我们也要学着从接口层、端对端的数据层、端对端的UI层来做自动化建设,尽可能的去朝着自动化 的方向去发展,不能一味的停滞不前,要不断的学习,不断的向自动化测试靠拢,尽可能的减少不必要的人工测试。
       3.对于不同的项目有不同的解决方案。对于标准需求项目或者跨多个业务的项目,一定会有测试投入,并且会有一位PTM来协调测试工作。即哪些业务的功能测试PTM可顺带执行掉,哪些确实需要对应业务线测试同学来完成,以避免一个项目投入过多测试同学。 对于重构改造项目,测试同学要做的就是对新系统进行自动化覆盖。对于小型项目,如果开发的自测场景与测试同学的测试场景基本一致,那开发自行搞定即可;或者测试同学把需要特别关注的或者风险点给开发同学简单介绍。对于有差异的,测试同学把差异点向开发同学描述清楚即可。
        以上几点是我读完有赞测试团队后的感想,一个强大的团队必有它的强大之处,我们要正确的认识自己,去努力追赶超越他们。加油!!!

有赞测试分享读后感

       看完有赞的测试团队建设与测试日常工作,让我对测试有了一个新的认识。
       之前也经历过几家公司,相对来说,对测试的重视程度都不高,都只是开发完成之后,将代码提到测试环境,然后测试人员根据需求文档,主要对功能进行测试。如果有必要会做简单的性能测试与自动化测试。
但是有赞对测试团队却很重视,他们的测试团队负责相关项目具体测试工作、自动化建设、合并发布流程管控、设计开发线上业务级别可用性监控、同时在研发提升测试效率的工具。 相对的,他们对测试技能要求也很严格,需要具备白盒测试能力、CodeReview能力、业务功能测试。另外,测试的规范性也很重要,有赞的根据项目来划分测试资源很有借鉴意义。我们也可以效仿他们,对每个项目进行评估,需要投入几个测试,测试负责的业务线,哪些项目测试只负责写完测试用例,后续执行由开发自己执行即可。测试只需要在上线前走一下checklist即可。对于一些小型项目,开发自行搞定即可。再次,有赞的测试方案很规范。可以让大部分公司直接拿来使用。 除此之外,有赞在性能测试平台,接口测试平台,QA测试平台等方面都很成熟。
        相对于有赞,首先,我们在白盒测试能力、CodeReview能力这两方面都比较欠缺。其次,我们测试的规范性也不健全,每次提测代码质量不高,这个其实可以通过项目规范解决问题。比如,开发先自己执行测试用例,没有问题了再提测,测试只需要走一下checklist即可。我们测试现在花费了过多的时间在跟开发一起走主流程,往往主流程需要走2天,然后正式再开始测试。这样导致接口测试,性能测试,复杂业务流程测试都没有时间进行。再次,有赞的测试方案我们可以直接使用。如下:
33
       面对如此大的差距,我们只有一步步慢慢来。现在我们的自动化测试平台robotframework已经成功使用起来,同时doclever接口平台也正在渐渐使用起来。其实再大的骨头我们只要有了目标都可以慢慢啃下来。后续如性能测试,接口测试,兼容性测试等方面的建设,也需要找准方向,慢慢开始进行。我相信我们QA部门可以顶住压力,创造一个不一样的明天。

有赞测试团队介绍读后感

感觉有赞的业务和我们有相似之处,他们的自动化建设、测试工作、监控等对于我们来说有很多可以借鉴的地方。各种效率工具覆盖到了开发测试监控的各个阶段,节省了很多重复性的劳动。能让六百多人的团队有条不紊地工作,确实很了不起。希望我们将来也能做到他们那样。

monkeyrunner之环境搭建及实例

一、Monkeyrunner简介
1.MOnkeyrunner相对Monkey区别
1)Monkeyrunner工具在工作站上通过API定义的特定命令和事件控制设备或模拟器(可控)
2)精确控制事件之间的事件
3)可以进行:点触屏、拖拽、长按、键盘事件
4)可以智能截图对比和判断
5)回溯出详细具体的BUG路径
2.Monkeyrunner优缺点
1) 能完全模拟人工所有操作
2) 有详细的API文档参考
3) 可以写出智能图像对比脚本
4) 支持java和Python两种语言脚本
5) 脚本移植性差
3.Monkeyrunner脚本编写
1) 终端USB调成开发者模式
2)电脑安装手机驱动
二、Monkeyrunner环境搭建
    Monkeyrunner的环境搭建,需要安装以下工具:jdk、android sdk、python编译器。
1.jdk的安装与配置
1)jdk下载地址
    下载完成后,默认安装即可。
2)jdk环境配置
    jdk安装成功后,计算机→属性→高级系统设置→高级→环境变量,在系统变量中,新建JAVA_HOME变量,变量值填写jdk的安装目录。

100

    在系统变量中,编辑Path变量,在变量值最后输入%JAVA_HOME%\bin;%JAVA_HOME%\jre\bin;(注意原来Path的变量值末尾有没有;号,如果没有,先输入;号再输入上面的代码)
101
在系统变量中,新建CLASSPATH变量,变量值填写为:
  .;%JAVA_HOME%\lib;%JAVA_HOME%\lib\tools.jar(注意最前面有一点)
102
    到此,系统变量配置完毕。
3)jdk环境检查
    检验jdk环境是否配置成功,则运行cmd,在cmd窗口中,输入 java -version (java 和 -version 之间有空格)。若如图所示,显示版本信息,则说明安装和配置成功。
103
2.android sdk安装与配置
android sdk就是指Android专属的软件开发工具包。android sdk中我们最常用的就是tools和platform-tools文件夹中的工具。
1)sdk下载地址
下载地址1:http://developer.android.com/sdk/index.html
下载地址2:http://rj.baidu.com/soft/detail/23485.html?ald
Sdk下载完成后,解压缩到自己的目录,不需要安装。
2)sdk环境配置
    sdk安装成功后,计算机→属性→高级系统设置→高级→环境变量,在系统变量中,新建ANDROID_HOME变量,变量值填写sdk中tools和platform-tools的安装目录。
104
    在系统变量中,编辑Path变量,在变量值最后输入%ANDROID_HOME%;
(注意原来Path的变量值末尾有没有;号,如果没有,先输入;号再输入上面的代码)
105
3)sdk环境检查
    检验sdk环境是否配置成功,则运行cmd,在cmd窗口中,输入adb。若如图所示,则说明安装和配置成功。
106
3.Python编辑器安装与配置
    python用于支持Monkeyrunner运行,使用python脚本编写用例会大大简化Monkeyrunner用例的编写,且会帮助扩展monkeyrunner的自动化功能。
1)Python下载地址
下载后,按照提示信息,下一步安装即可。
2)Python环境配置
    Python安装成功后,计算机→属性→高级系统设置→高级→环境变量,在系统变量中,编辑Path变量,在变量值最后输入Python的安装路径;
(注意原来Path的变量值末尾有没有;号,如果没有,先输入;号再输入上面的代码)
107
3)Python环境检查
    检验Python环境是否配置成功,则运行cmd,在cmd窗口中,输入python。若如图所示,显示版本信息,则说明安装和配置成功。
108
4.Monkeyrunner环境检查
    若以上步骤均完成,且各环境变量也配置正确,至此,Monkeyrunner环境已经搭建完成。检验Monkeyrunner环境是否搭建成功,则同样运行cmd,在cmd窗口中,输入monkeyrunner。如下图所示,则说明Monkeyrunner环境搭建成功。
109
    下面就可以用Monkeyrunner连接模拟器来进行自动化的测试了。
三、Monkeyrunner使用方法
    Moneyrunner在使用前,必须先打开模拟器或连接上手机设备。下面是Monkeyrunner的实例操作。
1.模拟器启动
    我们这里选择命令打开模拟器。运行cmd,在cmd窗口,输入命令:emulator -avd AVD_test,其中AVD_test是模拟器的名称,填写自己创建的模拟器名称。
110
    模拟器启动成功后,我们仍在cmd环境中操作。现在进入Monkeyrunner的shell命令交互模式。
输入命令:monkeyrunner
进入shell命令交互模式后,首要一件事就是导入monkeyrunner所要使用的模块。直接在shell命令下输入命令:
from com.android.monkeyrunner import MonkeyRunner,MonkeyDevice
再回车,这步完成我们就可以利用monkeyrunner进行测试工作了。
111
2.模拟器连接
    下面我们就要Monkeyrunner连接上模拟器,进行一系列操作了。输入命令:
device=MonkeyRunner.waitForConnection()
其中,device=MonkeyRunner.waitForConnection(6,’emulator-5554′)
参数1:超时时间,单位秒,浮点数,默认是无限期地等待。
参数2:指定的设备名称device_id,默认为当前设备(手机优先,其次为模拟器)
112
    输入命令后,页面上没有错误信息返回,即成功连接设备。
3.app安装并启动
1)app安装
    模拟器启动成功后,我们安装自己想要的apk,这里我们选择qq音乐安装。
输入命令:device.installPackage(‘F:\\QQyinle_439.apk’),其中,参数是APK的相对路径。
    安装成功返回true,此时查看模拟器我们可以在IDLE界面上看到安装的APK的图标了。
113
2)app启动
    app安装成功后,现在启动该app,命令为:
device.startActivity(component=”package名/.activity”)
首先,我们有必要说一下,如何获取一个app的package名和activity。这里,我们只描述一种获取方式。
使用aapt,其中aapt是sdk自带的一个工具,在sdk\builds-tools\目录下:
114
    以存储在F盘的qq音乐为例,运行cmd,命令行中切换到aapt.exe目录,
方法一:
执行命令:aapt dump badging F:\QQyinle_439.apk ,注意,apk路径中一定不能有空格。
120
120
121
由上图可知:package name:com.tencent.qqmusic
activity:.activity.AppStarterActivity
方法一由于日志较多,寻找起来比较费劲,所以我们引出方法二。
方法二(推荐):
把日志存储在特定的文件中,在文件中通过搜索关键字,得到包名及活动名,这里我把结果输出到F盘的log.txt中:
aapt dump badging F:\QQyinle_439.apk > F:\log.txt
    到此,已经获取了app的package名和activity。下面,我们真正的启动app。在原有cmd运行窗口,输入命令:
device.startActivity(component=” com.tencent.qqmusic/.activity.AppStarterActivity “)
    命令执行后,模拟器上的app被启动。这表示命令启动app成功。这里的关键是app的package name和activity对应获取正确,否则启动不了特定app。
115
    此时可以向模拟器发送如按键、滚动、截图、存储等操作了。
四、Monkeyrunner运行python脚本
    同样,Monkeyrunner可以直接调用指定python脚本,将命令写到python文件里,命名例如***.py,然后我们再从命令行直接通过monkeyrunner运行它即可。比如,我们还是用上面的例子,语法如下:monkeyrunner ***.py。接下来monkeyrunner会自动调用***.py,并执行其中的语句,相当方便。
    我们这里将上述例子,所有命令放在python文件里,并命名test.py,然后存储到本地F盘,即路径为:F:\test.py。
复制代码
#coding:utf-8 from com.android.monkeyrunner import MonkeyRunner,MonkeyDevice device=MonkeyRunner.waitForConnection() device.installPackage(‘F:\\QQ_374.apk’) MonkeyRunner.sleep(3.0) runComponent = “com.tencent.qqmusic/.activity.AppStarterActivity” device.startActivity(component=runComponent)
复制代码
    在cmd中运行monkeyrunner F:\test.py,这里的python脚本路径为相对路径。结果报错:SyntaxError:mismatched input ‘test’ expecting NEWLINE,如下:
116
    这是因为python脚本应在dos模式下执行,不要进入monkeyrunner的shell命令交互模式。正确的方式如下,输入命令monkeyrunner F:\test.py:
117
    运行成功后,则可以在模拟器上看到启动的qq音乐app。

在做自动化测试之前你需要知道的

什么是自动化测?

       做测试好几年了,真正学习和实践自动化测试一年,自我感觉这一个年中收获许多。一直想动笔写一篇文章分享自动化测试实践中的一些经验。终于决定花点时间来做这件事儿。

  首先理清自动化测试的概念,广义上来讲,自动化包括一切通过工具(程序)的方式来代替或辅助手工测试的行为都可以看做自动化,包括性能测试工具(loadrunner、jmeter),或自己所写的一段程序,用于生成1到100个测试数据。狭义上来讲,通工具记录或编写脚本的方式模拟手工测试的过程,通过回放或运行脚本来执行测试用例,从而代替人工对系统的功能进行验证。

当然,我们更普遍的认识把“自动化测试”看做“ 基于产品或项目UI层的自动化测试”。

分层的自动化测试

       这个概念最近曝光度比较高,传统的自动化测试更关注的产品UI层的自动化测试,而分层的自动化测试倡导产品的不同阶段(层次)都需要自动化测试。1

  相信测试同学对上面的金字塔并不陌生,这不就是对产品开发不同阶段所对应的测试么!我们需要规范的来做单元测试同样需要相应的单元测试框架,如java的Junit、testNG,C#的NUnit ,python 的unittest、pytest 等,几乎所有的主流语言,都会有其对应的单元测试框架。

  集成、接口测试对于不少测试新手来说不太容易理解,单元测试关注代码的实现逻辑,例如一个if 分支或一个for循环的实现;那么集成、接口测试关注的一是个函数、类(方法)所提供的接口是否可靠。例如,我定义一个add()函数用于计算两个参数的结果并返回,那么我需要调用add()并传参,并比较返回值是否两个参数相加。当然,接口测试也可以是url的形式进行传递。例如,我们通过get方式向服务器发送请求,那么我们发送的内容做为URL的一部分传递到服务器端。但比如 Web service 技术对外提供的一个公共接口,需要通过soapUI 等工具对其进行测试。

  UI层的自动化测试,这个大家应该再熟悉不过了,大部分测试人员的大部分工作都是对UI层的功能进行测试。例如,我们不断重复的对一个表单提交,结果查询等功能进行测试,我们可以通过相应的自动化测试工具来模拟这些操作,从而解放重复的劳动。UI层的自动化测试工具非常多,比较主流的是QTP,Robot Framework、watir、selenium 等。

 为什么要画成一个金字塔形,则不是长方形 或倒三角形呢? 这是为了表示不同阶段所投入自动化测试的比例。如果一个产品从没有做单元测试与接口测试,只做UI层的自动化测试是不科学的,从而很难从本质上保证产品的质量。如果你妄图实现全面的UI层的自动化测试,那更是一个劳民伤财的举动,投入了大量人力时间,最终获得的收益可能会远远低于所支付的成本。因为越往上层,其维护成本越高。尤其是UI层的元素会时常的发生改变。所以,我们应该把更多的自动化测试放在单元测试与接口测试阶段进行。

  既然UI层的自动化测试这么劳民伤财,那我们只做单元测试与接口测试好了。NO! 因为不管什么样的产品,最终呈现给用户的是UI层。所以,测试人员应该更多的精力放在UI层。那么也正是因为测试人员在UI层投入大量的精力,所以,我们有必要通过自动化的方式帮助我们“部分解放”重复的劳动。

  在自动化测试中最怕的是变化,因为变化的直接结果就是导致测试用例的运行失败,那么就需要对自动化脚本进行维护;如何控制失败,降低维护成本对自化的成败至关重要。反过来讲,一份永远都运行成功的自动化测试用例是没有价值。

  至于在金字塔中三种测试的比例要根据实际的项目需求来划分。在《google 测试之道》一书,对于google产品,70%的投入为单元测试,20%为集成、接口测试,10% 为UI层的自动化测试。

我为什么要做自动化测试?

   根据51testing的《中国软件测试从业人员调查报告》,手工测试占到的89% ,相对开发来说,测试的门槛底,薪资普遍较底,所要求的知识面虽然有一定广度,但缺乏深度。这是测试的普遍现状。

  正因为手功测试人门槛不高,使大量的毕业生,甚至是非专业人员涌入这个行业。从而增加了这个行业的激烈竞争。对于工作几年扔处于手工测试的人员来说都会有强列的危机感。由于工作的技术含量不高,薪资的涨幅遇到瓶颈,另一方面受到新进入者的威胁,同样的工作公司花5K招来的人就可以做,那么就不会花8K 的招。

  好吧,这个问题不应该出现讨论技术的话题中,但他的确是大多测试人员不得不面对的一个问题。所以,从测试人员自身的发展来说,我其实非常需要通过自动化技术来增加自己有竞争力。当然,做到一定年限测试人员会选择转管理或其它岗位,这又是另一个话题了。

  从测试行业的发展来说,国内产品由于产品特点,世界级的产品不多,技术含量相对不高,质量要求相对要求不高,外包国外项目,测试人力成本低廉,所以需要大量的手工测试人员。

  所以,在不远的未来,我认为纯的工手测试人员的需求是递减,公司更需要更高技术能力的测试。质量需要测试,测试行为永远不会消失,但纯的手工测试人员是否消失是有可能的。

  好吧,你可以说测试多朝阳的行业,我纯属在危言耸听。不管未来如何,我们都需要提升自身的技能对吧!

什么项目适合做自动化测试?

  假如你已经决定要学习自动化测试了,如何学习是要面临的下一个问题?这个问题以被测试产品为出发点进行分析,假如你所学的技术不能得到应用(验证),将会使你的学习过程寸步难行。

  首先考考虑产品是否适合做自动化测试。这方法比较普遍的共识是从三个方面进行权衡。

  软件需求变动不频繁

  测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁,测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本,而脚本的维护本身就是一个代码开发的过程,需要修改、调试,必要的时候还要修改自动化测试的框架,如果所花费的成本不低于利用其节省的测试成本,那么自动化测试便是失败的。

  项目中的某些模块相对稳定,而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试,而变动较大的仍是用手工测试。

  项目周期较长

由于自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成。这样的过程本身就是一个测试软件的开发过程,需要较长的时间来完成。如果项目的周期比较短,没有足够的时间去支持这样一个过程,那么自动化测试便成为笑谈。

  自动化测试脚本可重复使用

  自动化测试脚本的重复使用要从三个方面来考量,一方面所测试的项目之间是否很大的差异性(如C/S系统和B/S系统的差异);所选择的测试工具是否适应这种差异;最后,测试人员是否有能力开发出适应这种差异的自动化测试框架。

选择什么工具进行自动化测试

  假如你已经确认了XX 项目适合做自动化测试,那么接下来你要做的就是选测试工具了。

  首先要先确认你所测试的产品是桌面程序(C/S)还是web应用(B/S)。

  桌面程序的工具有:QTP、 AutoRunner

  web应用的工具有:QTP、AutoRunner、Robot Framework、watir、selenium

  由于B/S架构的诸多优势,早几年前大量C/S架构的应用转为B/S结构。从而也推动了web开发与测试技术的发展。假如,被测试有产品是C/S架构的,那么推荐QTP ,QTP在UI自动化测试领域占到了一半的试用率。所以,足以说明QTP在自动化领域强大,易用性等。学习主流的工具也可以使你获得更多的机会。市面上关于QTP的书籍也非常丰富。当然,要想学好QTP ,你必须要掌握VBS脚本语言。

  如果,被测产品是B/S 结构,那么推荐selenium ,为什么不是QTP 或其它工具?因为selenium 对B/S应用支持很好,更重要的一点,它支持多语言的开发,真正的试用selenium ,你所要掌握的不仅仅是一个工具而已,你还需要学习一门语言。我为什么要选择selenium?还要学一门语言,这无疑增加了我的学习成本。增加成本的同时,也增加的你的竞争力,而且,在这个过程中你不单单只是学会了一个自动化工具而已,你完全可以使用所学的语言去做更多的事情。

  好吧!假如你决定试用selenium 了之后,你又面临了一个新的问题,选择一门语言。selenium 是支持java、python、ruby、php、C#、JavaScript 。

  从语言易学性来讲,首选ruby ,python

  从语言应用广度来讲,首选java、C#、php、

  从语言相关测试技术成度(及 资料)来讲:ruby ,python ,java

  或者你可以考虑整个技术团队主流用什么语言,然后选择相应的语言。

selenium 用前须知

  OK!经过上的过程,我相信你一定做出的相应的选择,如果你选择的是selenium 工具,那么接着往下阅读。

首选你在开始selenium之前,需要花一到两个月时间去学一门语言,这里是根据没有语言基础的同学而定的。我推荐ruby ,python ,java 任意一门语言来进行学习。

  当然,已经如果有很好的语言基础略过这个环节,或者你的丰富的java编程能力,那么学习python 可能只需要几天时间或更短。

  假如,你已经搞定了一门语言的基础,接下来你需要先了解selenium ,selenium 并不是单纯的一个工具,他是一组工具的集合,而且,他还有1.0与2.0之分,当然3.0也已经到来。

  selenium 也不是简单一个工具,而是由几个工具组成,每个工具都有其特点和应用场景。

2

selenium IDE

  selenium IDE 是嵌入到Firefox浏览器中的一个插件,实现简单的浏览器操作的录制与回放功能。那么什么情况下用到它呢?

  快速的创建bug重现脚本,在测试人员的测试过程中,发现了bug之后可以通过IDE将重现的步骤录制下来,以帮助开发人员更容易的重现bug。

  IDE录制的脚本可以可以转换成多种语言,从而帮助我们快速的开发脚本,关于这个功能后而用到时再详细介绍。

selenium Grid

  Selenium Grid是一种自动化的测试辅助工具,Grid通过利用现有的计算机基础设施,能加快Web-app的功能测试。利用Grid,可以很方便地同时在多台机器上和异构环境中并行运行多个测试事例。其特点为:

· 并行执行

· 通过一个主机统一控制用例在不同环境、不同浏览器下运行。

· 灵活添加变动测试机

selenium RC

  selenium RC 是selenium 家族的核心工具,selenium RC 支持多种不同的语言编写自动化测试脚本,通过selenium RC 的服务器作为代理服务器去访问应用从而达到测试的目的。

  selenium RC 使用分Client Libraries和selenium Server,Client Libraries库主要主要用于编写测试脚本,用来控制selenium Server的库。

  Selenium Server负责控制浏览器行为,总的来说,Selenium Server主要包括3个部分:Launcher、Http Proxy、Core。其中Selenium Core是被Selenium Server嵌入到浏览器页面中的。其实Selenium Core就是一堆JS函数的集合,就是通过这些JS函数,我们才可以实现用程序对浏览器进行操作。Launcher用于启动浏览器,把selnium Core加载到浏览器页面当中,并把浏览器的代理设置为Selenium Server 的Http Proxy。

selenium 2.0

  搞清了selenium 1.0 的家族关系,selenium 2.0 是把WebDriver 加入到了这个家族中;简单用公式表示为:

  selenium 2.0 = selenium 1.0 + WebDriver

  需要强调的是,在selenium 2.0 中主推的是WebDriver ,WebDriver 是selenium RC 的替代品,因为 selenium 为了向下兼容性,所以selenium RC 并没有彻底抛弃,如果你使用selenium开发一个新自动化测试项目,强列推荐使用WebDriver 。那么selenium RC 与webdriver 主要有什么区别呢?

  selenium RC 在浏览器中运行JavaScript应用,使用浏览器内置的JavaScript 翻译器来翻译和执行selenese命令(selenese 是selenium命令集合)。

  WebDriver通过原生浏览器支持或者浏览器扩展直接控制浏览器。WebDriver针对各个浏览器而开发,取代了嵌入到被测Web应用中的JavaScript。与浏览器的紧密集成支持创建更高级的测试,避免了JavaScript安全模型导致的限制。除了来自浏览器厂商的支持,WebDriver还利用操作系统级的调用模拟用户输入。

  如果是新项目直接学习webdriver 就OK了,RC是过时技术。

selenium学习路线

  配置你的测试环境,真对你所学习语言,来配置你相应的selenium 测试环境。selenium 好比定义的语义—“问好”,假如你使用的是中文,为了表术问好,你的写法是“你好”,假如你使用的是英语,你的写法是“hello”。 所以,同样有语义在不同的语言下会有不同的写法(语法)。

   接着你需要熟悉webdriver API ,API就是selenium 所定义一方法,用于定位,操作页面上的各种元素。

  先学习元素的定位,selenium 提供了id、name、class name、 tag name、link text、partial link text、 xpath、css、等定位方法。xpath和css 功能强大语法稍微复杂,在这其间你可能还需要了解更多的前端知识。xml ,javascript 等。

  定位元素的目的是为了操作元素,接就要学习各种元素有操作,输入框,下拉框,按钮点击,文件上传、下载,分页,对话框,警告框…等等。

  经过一段时间的学习,你可以游刃有余的模拟手工测试来操作页面上的各种元素了。接着你需要做的就是把这些“用例”组织起来,统一来跑。

  那么你需要做的就是学习并使用单元测试框架,单元测试框架本身就解决了用例的组织与运行。

  当你写了一些“测试用例” 之后,你会发现用例中有大量重复的操作,能不能写到一个单独的文件中,需要的时候调用这些操作?当然可以,运用你的编程能力来实现这一点将非常简单。然后,你又发现每个用例中都有一些数据,这些数据也是一样的,但如果变化了修改起来非常麻烦,你也可以把他写到一个单独的文件中进行读取。

  接着你又遇到了新的疑问,我写的脚本(用例)都是流水式的,我怎么知道用例运行失败还是成功。那么就需要在脚本中加一些验证与断言。

  接着你又有了更多的想法,单元测试框架的log太简陋了,能不能生成一张漂亮的测试报告出来。我能不能定时的来跑这个脚本。能不能把每一次跑脚本的测试结果直接发到我的邮箱。能不能……

  为解决这些问题,你不得不学习更多的编程技术,然后你的“测试结构”会功能越来越强大,越来越灵活。产生了一定的通用性和移植性。一个有模有样的自动化测试框架诞生了。

   假如,有一天你不再做UI的自动化测试了,你会发现你去做单元测试 或接口测试基本没什么难度。开发个测试工具之类的也不在话下,感谢selenium 吧!顺便也感谢一下我吧!

总结:每天学习一点点!