第一篇:关于手机自动化测试的研究与总结报告
自动化测试是由测试脚本组成,它的核心仍然是代码,说的简单点,自动化测试就是程序测试程序。我们知道,是程序就一定会有缺陷,所以,不能保证测试工程师开发的脚本就完全100%没有缺陷,如果代码中出现一个小小逻辑错误,哪怕一个条件判断的误写也会导致测试结果完全出错。当然,对于一个有经验和优秀的自动化测试开发工程师来说,大多数的错误还是会在脚本调试中避免的。
经过我上网搜索,知道了测试中有85%的缺陷是归功于手工测试,而只有15%的缺陷归功于自动化测试(注意:这个标准并不是随便说的,而是由自动化测试专家共同总结得出的一组数据结论)。而且在这15%中,大约只有0.1%不到的缺陷属于新缺陷。的确,自动化测试几乎是无法发现新缺陷的,自动化测试大多是用来发现曾经发现过的缺陷在每个版本下有没有重新出现。自动化测试更适合缺陷预防而不是发现更多缺陷。自动化测试最大的用途就是回归……再回归。而对于我们手机软件测试,用自动化测试更是少的可怜。
自动化测试对测试工程师来说必须有一定的开发技术背景,开发技术越高则写出来的脚本质量也就越高、越有技术性和想象力。所以对于我们现在必须要把程序语言(脚本代码)学习好,有个良好语言的基础,是自动化测试必不可少的条件之一;
其实每一个测试工具能真正地被使用在真实的项目中并驾驭项目的,也没有听说过有一个自动化测试工具能做到适合每一个项目。就拿最近我研究的三大免费自动化测试软件:winrunner,QTP,Loadrunner;我发现其实他们并不是很适合测试我们现在所开发的软件(飘信),飘信是一款基于手机平台的软件,在这样的要求下,我们最好而且我觉得最基本的自动化测试就是工程师第一轮的自测,这样是最节约成本的;我尝试使用winrunner进行测试,这是一款自动化黑盒测试工具,其实在一些很简单的window平台下的软件是可以进行测试的,但是它们对自行开发组件、非Windows标准组件和特有组件的支持很差,容易导致整个测试过程的失败。而且提供的这种基于GUI对象和位图的测试方式,对于具有复杂交互功能的软件而言,他的测试所花的时间和精力不如人工在机器上进行测试的精确并且周到。对于GUI和位图,在这方面我们的这款软件更不需要也不值得花费这么长的精力纠结于在这方面的测试。WinRunner提供了GUI Map的自动学习功能,但这种学习过程在某些情形下与测试过程不能取得一致,达不到理想的效果。因此,仅依赖GUI对象和位图并不能提供足够强大的功能,也不能满足飘信测试的需求;
继续说QTP和loadrunner这两款现今最流行的自动化测试软件,我在研究过程中发现,这两款软件在使用方面确实是异曲同工,他们都需要编写测试脚本,这一项要求对于我们这边的测试团队是有很大的要求的,因为我们这款飘信软件是在各个平台开发的,所以需要研究的语言就要很多种,我的想法是这两款软件是作为测试人员必须要学习的测试工具,就拿测试这个行业来说他们是你必备的,但是在我们这边作为测试工具估计要很长时间的学习,而且自学会要更长的时间,我建议大家有时间的时候学习或者互相研究比较好,但现在按照我们团队的状况使用这两款软件作为自动化测试工具可能有点问题;
再说一个大家都知道的Android SDK这款软件吧,我在eclipse的基础上,进行测试,我觉得还不如就是用手机连接电脑用eclipse直接测试来的方便,在这上面你先要搭配android使用环境,用logcat记录使用情况,与人工测试并无很大的差异,人工可能更方便快捷; android在eclipse中使用Android Test Project是可以进行白盒测试,可是其中仍需要输入android一些测试代码,但是这个我个人觉得这个白盒测试是可以学习的,所以要加强学习,最好让开发人员教导,因为这个应该是他们进行自测的一种测试方法。
我现在在等待一款android自动化测试软件,叫做:AndroidRobot,它正处于试用期,我建议大家也可以看看这款软件的介绍,很适合飘信这款软件的使用!
以上就是我这些天对手机测试自动化的研究与总结,我会继续学习和研究,从而找出更优秀的测试软件符合我们现在的飘信团队测试需要!报告人:xxxx
报告时间:2012/3/8
第二篇:自动化测试经验分享
一、测试的困惑
以前我时常反思,测试组的工作多吗?我的回答是多。测试小组的工作成果的好坏和工作任务的多少成正比吗?最终的回答却并非成正比。我们的测试工作成果往往并不理想,甚至是差。那么为什么事倍功半?这问题很难找到清晰的答案。
参与了外部培训之后,发现了自己在对测试的工作有了新层次的理解。对之前工作成果差的问题思考也有了新的方向。“测试的最高境界是找出所有BUG吗?不是,测试的最高境界是不需要进行测试。为什么不需要进行测试?是因为所有的问题都已经在软件各阶段中介入的测试工作中给预防解决了。由此引申,测试的定位并不是找出BUG,而是预防BUG。” 这是我培训报告中的一部分。如果测试的出发点只为是发现BUG,那么测试工作将会如何?辛苦的发现了一个BUG,之后开发针对性的修正了这个BUG,再回重新测试的过程,又会有多少人会重新被卷入,又会有多少BUG因此而产生,又需要花费多少时间,答案可想而知。这就是我们忙又不见成果的主要原因。所以改善这个问题的出发点就是改变对测试工作的认识——测试的目标并不是为了找出BUG,而是预防BUG的出现。
如何理解正确的测试目标是预防BUG的出现。首先可以从软件测试的阶段划分来看。软件测试的阶段划分为需求、设计、编码、测试、验收。但按此划分来定位测试是错误的。假如在编码阶段完成后测试出的BUG属于设计问题(这也是我们测试工作中经常遇到的情况),那么我们已经编码完成的产品就要面临着伤筋动骨的修改,这样的修改会带出多少个新的BUG出现?为这个修改我们又要重复的测试我们的新提交版本多少次?想必都有很深刻及惨痛的答案了。由此可以说明需求设计阶段的测试比编码阶段测试重要的多。在需求上出现的BUG就很有可能足以推翻整个产品。那么如果在需求设计阶段测试人员就能发现产品设计的BUG,那么就可以避免了因此而衍生的产品BUG,达到预防BUG这种测试理念的目标。
那么又如何能做好以预防BUG为目标的测试工作。“测试工作不只是一种技术,也不仅是一种活动。测试工作的成功也不能取决于测试成果,测试的BUG越多并不能证明测试工作做的好,所以由此引申,测试工作要站在团队的高度来开展,在团队中做好测试,而不是在测试小组中做好测试。”这是我培训报告中的另一部分。要做好以预防BUG为目标的测试工作,首先要尽早的参与到项目中,其次就是需要各部门及小组的大力支持,与业务、项目、代码人员共同形成团队,在团队中影响其他小组提高产品质量,更好的完成以预防产品出现BUG为目标的测试活动。
总结来看,我个人觉得拥有这样的测试理念可以解开我们的疑惑,带领我们走出目前的困境。
二、自动化测试迷失
随着工作、发展、提高等等多方面的需要,我接到了开展自动化测试的研究工作。概念上来说自动化测试是一种测试度量体系。现实点来说,自动化测试可以为我们自动、无误的运作完成大量且需要重复执行的测试用例。这是多么让人振奋的概念。甚至可以解开我上文所提到的有关测试工作的困惑。我很兴奋的去展开研究目前最流行的自动化测试工具之一QTP。甚至设计出了管理中心的三个重要功能的自动化测试脚本,并且运行无误在自动化测试讨论会上兴奋的向大家演示。之后还用工具按键精灵设计出了前端的A类测试用于实际的测试。但很让人沮丧的是最终这些脚本全被遗弃在电脑硬盘的角落,再也没派上用场。为什么?因为他们维护起来很困难,因为他们编写它们的时间与实现的价值并没有超过手工测试。这就是自动化测试吗?怎么不可行啊,我有点不太相信这种结局,所以我再一次困惑了。
外部培训的老师这样告诉我们:“我们并没有理性的看待自动化测试,自动化测试并不是我们看上去的那样美。首先自动化测试能直接的节约成本、让测试人员变轻松的想法是一个误区。因为原本用于手工测试的时间用来编写及维护测试脚本了,而完善的自动化测试脚本编写或维护的时间很可能会超过手工测试的时间。再者自动化测试脚本用例是测试人员所编写,自动化测试只能是沿着该测试人员的“足迹”前进。所以用自动代测试来发现更多软件产品问题的想法也是一个误区。其次并不是所有的测试都能自动化,测试的自动化也不一定是解决问题的最佳手段。”
听完这些,原本困惑的我又多了份惊讶,一方面惊叹产述的这些状况与我之前的自动化测试的试行失败是相近的。另一方面又猜疑这自动化测试该不会像共产主义社会那般吧!随着培训内容的展开,我终于解开了困惑,何为理性的看待自动化测试。
“如同不能指望原始社会拥有了汽车就能进入现代社会一样,自动化测试工具永远都不能主导测试实现自动化”(出自国信培训文档)。我们错误的把自动化测试看成了一种测试工具或测试手段。自动化测试是一种理念,它要发挥它真正的作用就需要这种理念转变为一种体系——自动化测试体系。
“引入自动化测试的前提是已经建立了合适的自动化测试体系,如果没有这些,而片面的追求自动化,无异于缘木求鱼。自动化测试体系是指能够适用某种环境的测试工具、过程、人员结构、方法的综合,运用于整个项目团队”。回到我之前的对QTP研究失败的原因,首先我开始就觉得因为研发的设计、编码实现并没有考虑到自动化,而导致自动化脚本的编写非常吃力。比如产品页面项目的命名不规范,导致自动化测试工具很难捕捉这些页面对像。其次就是测试脚本的方向迷失,我在研究QTP的时候就发现了这个问题。随着我一点点的在编写着脚本,我不断的发现自己在的测试脚本的编写方向上出现了迷失。这段脚本我编写的目标本来是功能测试,但随着我的补充却接近于开发级的单元测试。而另一段本属于功能性测试的脚本,因为功能的重点需要,我又补充了部分脚本导致整个测试脚本测试目标变成了完整关联性测试。而做为单元测试的脚本却并没有在开发的角度上来设计,根本做不到函数、类等代码级的测试,根本不能达到要求。做为完整性测试的脚本也无法模拟接口功能中几何倍数级的各种条件输入对应的输出测试。而功能测试脚本算是硕果仅存,但随着开发对产品的代码大规模调整(这些调整当然不会考虑对已经实现的脚本的影响)而直接“报废”。如果需要脚本继续工作,那么就要花时间来修改调整它。这些脚本的结局又再一次可想而知了。
所以首先我们要理性的看待自动化测试,不要片面的去追求它。对不同的项目要开展不同自动化策略。参考如下
(1)评审项目中特定的部分作为应用自动化的候选对像。
(2)从项目中高度冗余的任务或场景重点考虑自动化。
(3)将乏味且人工容易出错的工作重点考虑自动化。
(4)将回归测试经常需要“照顾”到的部分重点考虑自动化。
(5)自动化开始时要首先关注开发成熟、理解透彻、相对稳定的且不易变的部分优先考虑自动化
其次,自动化所实现的最大价值目标是可不间断的、可重复的自动执行对需求、设计、代码全面覆盖的大量测试用例从而预防bug的产生的一套质量保障机制。所以自动化测试的重点在于测试自动化作为一个体系,要运用于整个项目团队。项目组要讨论它(策略、时间、成本等)、研发需要参与它(编码方向、自动化支撑、以及代码单元测试自动化的计划和执行等)、测试要引导及推进它(策略、方法、执行、跟进、维护等),各团队共同形成体系,才能让自动化测试工具真正的成为一种质量保证的有力武器。
第三篇:手机测试经验总结
手机测试经验总结
VPM主要是激励团队成员测试和学习,而不是自己去执行用例。当被委派为一个项目的测试经理时,VPM应该清楚项目计划和转折点、软件发布时间表、产品定义特征列表。
1、作为VPM应具备以下几方面能力:
(1)、用不同的方式看待问题
(2)、制定计划,满足项目上市时间
(3)、依据质量、时间、成本对PR进行判断和决定
(4)、增进沟通,总结不同项目的经验
(5)、和团队的密切合作
2、测试工作点:
(1)、测试软件机制
(2)、分析问题
(3)、对产品进行认证并得到相应证书
(4)、评估对于返修率、最终用户和运营商抱怨的影响
若做欧洲市场的产品,一定要做CE认证。FCC认证在Latam市场是必须的,CTA认证在中国是必须的。
一、相关测试知识学习
1、软件测试包括测试计划、测试设计、测试执行、测试评估这几个阶段;
测试计划:
了解软件当前状态及客户对软件的需求;
了解产品规格书:按键定义及菜单树;
管控和跟催软件方案商的版本发布时间;
测试设计:根据客户需求和产品规格说明书来编写测试用例;
测试执行:测试策略包括基本功能测试、UI测试、冲突测试、压力测试、兼容性测试、验收测试
测试评估:进行三次全面测试,由方案商发出软件和报告,TMC和SZ Team
同时测试并反馈给方案商,如此反复数次,方案商改善结果并商讨最终结论。
2、场测
在硬件成熟、软件基本成熟的情况下做场地测试,主要测试这几项:寻网时间、呼通率数据、通话质量、Wap测试、FM测试、信息、紧急呼叫、基本功能测试。
3、说明书测试
验证说明书基本功能是否正确,是否清晰易懂、排版规范、无错别字等。
4、认证分类
按照销售地区分为国内认证和国外认证,国内认证是CTA认证,国外认证是CE认证和FCC认证。CTA认证需要拿到国家无委颁发的入网证书、受理中心颁发的许可证书、3C认证颁发的3C证书。
第四篇:手机测试简历
个人简历
个人信息
姓名:性别:男
出生日期:1990籍贯:河南省
毕业院校:郑州科技学院专业:计算机应用技术 学历:大专手机:xx
邮箱:xxx@qq.com
求职意向
手机测试和相关专业
职业技能
1.软件测试:学习过测试流程,文档的编写,测试用例,软件测试周期、软件工作流程及掌握黑盒测试技术,能够运用黑盒、白盒的测试方法,及自动化测试工具,完成测试用例的编写和执行,并提交缺陷报告等。
2.测试工具:自动化测试工具(Quick Test Professional),性能测试工具(LoadRunner),能够使用loadrunner自动化测试工具进行功能和性能自动化测试。
3.编程技术:学习过C++、HTML。
4.数据库:Access、SQL server 2000/2005。
5.办公软件:使用软件会用Ppt、Word、Excl、及其它Office系列办公软件。
6.操作系统:Windows和Linux下各类开发及测试环境的搭建。
项目经验
项目一:中国石油管道公司移动应用系统测试
测试环境:CPU 双核 + 2.0GHz + 内存2.0 + 硬盘60G + Windows7 +IE 7.0以上 项目描述:该系统是北京万岩通有限公司为中国石油西南管道公司、西北管道公司及 宁夏石化公司开发的移动应用系统,主要包含:移动站点、移动新闻、文档库、代办管理,各集团移动信息门户等功能;在此期间本人负责对西北销售信息门户的新闻、栏目、行业动态、子站点等内容进行Web测试及兼容性测试。
职责描述:担任测试工程师,负责搭建测试环境,完成所负责功能模块的PC机和移动终端的页面 Web测试、兼容性以及安全性测试,设计测试用例并执行,提交缺陷报告。
项目二:北京万岩通HRM系统
测试环境:客户端操作系统Windows XP + SQL Server 2008
项目描述:万岩通HRM系统是北京万岩通科技有限公司为适合企业自身发展,而推
出的企业人力资源管理系统。本项目主要针对局部功能模块进行测试,包括:人事管理、行政管理、薪资管理以及考勤管理等功能进行测试,本人负责对人事管理模块进行测试。
职责描述:担任测试工程师,负责搭建测试环境、完成人事管理模块测试任务,参
与整个HRM系统测试计划的拟定,负责设计测试用例并执行,提交缺陷报告,最终经该项目测试小组分析与总结,完成项目的测试报告。
工作经历
2011-9至2013-12郑州科技学院
2014-12至今北测教育科技发展有限公司,学习软件测试
自我评价
1.热爱测试行业,对软件测试有浓厚的兴趣,具有很好沟通能力和团队精神
2.喜欢学习新技术,敢于面对和克服困难
3.较强的动手能力,很好的分析问题与解决问题的能力
4.工作认真负责,积极上进、有耐心、细心,有良好的职业素质
5.生活中乐观向上,待人友善
第五篇:手机测试心得
手机测试小总结
时间过得真快,一晃自己已经工作八个月了。通过这段时间的用心学习,对手机测试工作有了一定的认识和理解,自己也从一个尝试学习的软件测试员升任为test leader,总结了一下半年多自己的心得体会,希望对那些渴望学习并做好软件测试的同仁有所帮助。
软件测试是一个提高产品质量的必要条件,也是提高产品质量的最直接最有效的手段。软件测试会成为软件行业中最关键及重视的一个环节,所以做软件测试还是很有前途的。
要想成为一名出色的测试人员,首要条件是测试人员要非常喜欢测试工作,才能在工作中找到乐趣,才能使自己的潜能在工作中发挥出来。其次,在测试过程中,测试人员需要勤奋并富有耐心,善于学习、思考和发现问题,细心能够有条理地总结问题,这样自己才有机会成为最出色的员工。下面是我自己总结的一些在测试工作中需要注意的问题:
1.认真细致的依据 test case 进行测试。不要总以为 test case 比较简单,不能找出问题,test case 是手机最基本功能的测试点,只有掌握了手机最基本的功能,从而认真思考各功能点的衔接性,拓展测试思路,才能更全面的找到bug。
2.发现bug 后要找出最简单的重现bug的步骤,这样有助于你掌握出现问题的原因所在。
3.测试人员要及时关注开发的过程,每出新版本要着重测试开发修改和增加的模块,因为开发的调整可能会引发许多新问题.。
4.多看看公司CQ里的bug,有助于你了解手机哪些地方出现问题比较多,软件系统哪里存在问题比较严重。另外,注意一下别人寻找bug的思路,从而取长补短,提高自己的测试能力。
5.拓展测试思路,尝试各种不同操作。软件测试需要模拟各种真实用户(包括专业用户、无聊用户、黑客、甚至变态用户)对软件进行操作和使用,从中查找出软件的缺陷。只有通过各种方式对软件全面测试,才能避免漏测。
6.学习与测试软件相关的知识。学习操作系统的知识有助于你发现缺陷,定位问题更加准确,如可以根据PC机的Word 来对比手机的Word 文档。
7.进行free test 时要有明确的测试范围和测试目的,不能漫无目的,看见模块就测试,容易产生浮躁不稳定情绪,就很难发现问题了。
8.压力测试一般会有很多问题,需要有耐心并详细严谨的进行,不要因为难度大又繁琐而偷工减料,导致漏测问题很多。
9.测试过程中需要学会控制情绪。测试工作是一件很细致繁琐的工作,不能因为工作的繁琐或找不到bug而产生浮躁情绪,否则乱上加乱。
10.要学会与开发人员很好的沟通。沟通时需要注意:(1)自己要站在用户的角度看问题,不能因为问题对开发有难度而妥协(2)找出最简单的重现bug步骤来减轻开发寻找问题所在的难度(3)关注开发对软件的改动,随时与开发沟通(4)与开发交流沟通时注意方式与态度,不能与开发产生冲突
11.对于提交bug时应该注意的问题:(1)注意描述语言,要简洁明确,避免错别字;(2)在提交和网络相关的Bug时请注意认真填写当前网络信号情况;(3)在提交死机黑屏等严重问题时要注意当前电池电量,以及是否插入数据线,充电器,并要描述能否呼入电话,以及呼入时的网络提示(关机,无法接通,忙音…)
想了半天也只写了上面几点,希望能对大家有所帮助。就我个人觉得软件测试最主要的是测试工程师的态度与理想问题。测试工程师要看到测试行业前途的光明,要使自己热爱测试的工作,在工作中做一个善于总结的有心人。软件测试并不单纯是为了找bug,而是为了保证软件的质量问题。不能把bug数作为衡量一个工程师能力的尺度,提交bug得以修复最多的测试工程师才是最棒的。