App的测试,和传统软件测试有哪些区别?应该增加哪些方面的测试用...
随手机对人们生活中的影响越来越大,App测试工作逐渐被众人所知。
从一开始的众包到现在的自动化探索,手机测试上的技术发展也是日新月异。
App测试相比以往传统的软甲测试相关要复杂的多且困难的多。
基于工作经验,我将如何做好app的测试归结为如下内容。
(1) 非功能测试 app测试的一个重要方面是app的非功能需求。
移动app在推出市场或进行进一步开发前,测试人员有一定的职责做该类需求的跟踪工作。
早期开发阶段要进行的第一个测试应该是实用性测试。
通常是由alpha用户或同事进行的。
走进一家咖啡馆或餐厅,问问里面的人他们的app使用情况。
让他们看看现阶段开发的第一个版本并收集反馈,看看用户是否能很好地使用新功能,以便得出第一印象。
(2) 功能测试 每项开发的新功能都需要进行测试。
app测试中功能测试是一个重要方面。
测试人员应该要进行手动测试和后期的自动化测试维护。
刚开始测试时,测试员必须把app当做"黑盒"一样进行手动测试,看看提供的功能是否正确并如设计的一样正常运作。
除了经典软件测试,像点击按钮、提交订单看看会发生什么,测试员还必须执行更多功能的app测试。
除了整个手动测试过程,测试自动化对移动app也很重要。
每个代码变化或新功能都可能影响现存功能及它们的状态。
通常手动回归测试时间不够,所以测试员不得不找一个工具去进行自动化回归测试。
现在市面上有很多自动化测试工具,有商业的也有开源的,面向各个不同平台,如Android,iPhone,WindowsPhone7,BlackBerry以及移动Webapp。
根据开发策略和结构,品质管理测试专家需找出最适合他们环境的自动化工具。
(3) 客户端性能测试 一个App做的好不好,不仅仅只反应在功能上。
被测的app在中低端机上的性能表现也很重要。
比如:一个很好玩的游戏或应用,只能在高端机上流畅运行,在中低端机上卡的不行,也不会取得好的口碑。
关于App的性能测试,我们比较关注的参数有:CPU,内存,耗电量,流量,FPS。
同时也需关注一下App的安装耗时和启动耗时。
目前大家可能比较困惑的一个问题,多高的CPU,内存,耗电量,流量,FPS才算是符合发布的值呢?这里可以告诉大家,可以参考精品游戏的一些数值,将自己研发的app与业内精品的app数据做对比。
(4) 适配兼容测试 App在经过功能测试后,也需对其进行适配兼容测试需要检查的项主要有以下几点:(a) 在不同平牌的机型上的安装、拉起、点击和卸载是否正常;(b) 在不同的操作系统上的安装、拉起、点击和卸载是否正常;我们在实际测试中,常常会遇到下列问题:(a) 在某个平牌某个系统上,app安装不上;(b) 在某个平牌某个系统上,app无法拉起;(c) 在某个平牌某个系统上,app拉起后无响应或拉起后黑屏、花屏;(d) 在某个平牌某个系统上,app无法顺利卸载;(WeTest腾讯质量开放平台)这个产品可以实现多款热门机型的适配兼容测试。
(5) 弱网络测试 App在使用的过程中,难免会遇到弱网络环境,例如在公车上、在地铁里。
在这种情况下,常常会出现网络抖动、上行或下行超时,导致应用中出现丢包。
作为一个测试人员,我们要对app在上线前做一定场景的弱网络环境模型,并查看app在弱网络环境下是否存在某些未知的问题。
下面是我们常用的弱网络环境场景:(a) 3G弱网络信号场景模拟;(b) 市区低速移动场景模拟;(c) 郊区高速移动场景模拟;(d) 请求回应超时_上行超时场景模拟;(e) 请求回应超时_下行超时场景模拟;(f) 网络抖动场景模拟;(6) 耗电量测试 App在手机上的表现,除了功能外,app是否耗电,也是测试过程中重点要关注的一项。
手机设备在满电的时候,这个App能玩多久;App每小时的耗电是多少;App在某个场景挂机10分钟耗电量是多少;这些都是我们平时在耗电量测试中比较关注的点。
(7) 协议测试 模拟客户端直接发送协议包给服务器,看看服务器是否有一定的校验,认不认客户端发过来的数据。
协议测试,主要是为了处理用户发送恶意协议到服务器,骗过服务器的校验。
(8) 安全测试 App在上线前,都需要做详细的安全测试。
安全测试主要为了检测应用是否容易被外界破解;是否存在被恶意代码注入的风险;上线后外挂的风险高不高等。
(9) 服务器性能测试 服务器性能测试,主要包含单机容量测试和24小时稳定性测试。
单机容量测试,可以检测到单机服务器在90%的响应时间和成功率都达标的前提下,能够承载多少用户量。
使用特定游戏模型压测24小时,服务无重启,内存无泄漏,并且各事务成功率达标。
这个可以在WeTest入口预约。
(10) 服务器容灾测试 服务器容灾测试,主要指某个服务进程奔溃掉后,是否具有自行恢复能力。
比如游戏逻辑进程消失后,是否会自动拉起;memcached崩溃时,是否会重新启动,是否会对所有玩家有影响。
这些都是app测试过程中需要考虑的因素。
(11) 中断测试 针对智能终端应用的服务等级划分方式及实时特性所提出的测试方法,如:App在前台和后台运行状态时与来电、文件下载、音乐收听等关键运用的交互情况测试等。
测试电话,短信,彩信,微博或其他通...
怎么做好软件测试?一个合格得软件测试师要具备哪些能力?
自动化测试方面接触不多,就黑盒测试方面,我说下我的理解。
基础的:1、做测试时要绝对专心,要有很强的判断能力,bug出现在你面前你不能疏忽漏掉并且要能准确判断它是哪类哪个区域的bug以及严重程度。
2、要能准确描述bug发生的各种情况和实际结果、复现bug的各种步骤和各种方法,期望结果写的全面些而非一句“它应该正常工作”这么简略,有能力的话再给点建议辅助开发人员快速修复bug。
3、对bug负责,做好bug跟踪和回归测试工作,直到bug修复。
进阶的:1、可以根据文档设计测试计划、测试用例。
在没文档的情况下,快速理解软件工作逻辑,创建些简易文档辅助测试,进行测试工作时规范的写下所用测试用例和结果。
2、掌握一些测试方法,比如说探索式测试。
3、掌握些软件设计、产品设计方面的知识,便于理解软件,从而辅助测试工作。
目前我能想到的大概就这些,希望对你有帮助:)
full phone test 安卓手机里的这个是什么意思
full phone tes:全电话测试。
1、前期功能测试和健全测试一天一轮,频度太快且测试费时,效果不好。
2、初期的测试用例设计全面,但未精确定义编写粒度,描述过程过细,后期因需求变更导致维护成本较高。
3、因项目流程和过程控制影响,无法明确划分测试阶段,且初期没有找到最佳敏捷测试方法,测试流程冗余僵化,导致大量重复性的工作,灵活性偏低。
在测试进程中我们已发现测试策略的问题,并及时调整,在阶段二开始使用新策略——使用两阶段测试模型: 1、阶段一:按照探索性测试(Exploratory Testing )模式,布置有针对性有重点的自由测试,以“把软件使用坏掉”为目的,尽可能多发现bug 。
2、阶段二:执行各项测试用例,以“全面测试”为目的 具体的时间安排如下: 1、先期产品开发阶段,即Alpha release 之前,做功能测试、健全测试、缺陷验证+自由测试。
2、项目中期,Alpha ~ Beta 之间,执行全面的系统测试、兼容性测试、性能测试,并开展自动化脚本开发、环境搭建等工作。
3、Beta release 之后,在产品发布前的2~3周,就开始确定稳定版本Release Candidate ,在此版本基础上做最后一轮全面测试、重点子模块的健全测试、缺陷主导的ET 等,完成最终报告并交由项目组领导、QA 审核发布。
...
软件测试方法?都有哪几种?
第一类测试方法是试图验证软件是“工作的”,所谓“工作的”就是指软件的功能是按照预先的设计执行的;而第二类测试方法则是设法证明软件是“不工作的”。
还有两大类:白盒法和黑盒法。
白盒法:你清楚程序的流程时,用不同的数据测试你程序的代码,验证程序的正确性,有:条件测试,路径测试,条件组合。
。
。
。
白盒法用在程序开发阶段的前期。
黑盒法:主要用于程序开发阶段的后期,即程序的流程测试正确后,测试程序的结果。
有什么因果法,边缘值法等。
具体你可以买本软件工程方面的书看看。
还有一下方法:功能测试:可接受性测试:用户界面测试:探索或开放'型的测试:性能测试:回归测试:强力测试:集成与兼容性测试:装配/安装/配置测试:国际化支持测试:本地化语言测试:这些都是测试的方法....
学习软件测试如何入门?
软件测试入门的话,首先需要掌握测试一些基础概念:比如白盒测试,黑盒测试,回归测试,探索测试等。
其次需要了解测试用例设计方法,测试用例要素,及如何编写好的测试用例。
最后要了解测试流程,如何开展测试工作。
在这基础上,可以在黑马程序员再针对性的学习一些自动化测试相关的技术和方法。
想自学软件测试,有推荐的书籍、资料或者视频吗?
推荐一些软件测试书籍(这些都是黑马程序员内部教学课本):基础阶段:《软件测试》,《软件测试的艺术》,《计算机软件测试》《软件测试经验与教训》,《软件测试用例设计》进阶阶段:《Web安全测试》,《Google的测试之道》,《软件质量保障原理与实践》,《探索性测试》自动化:《软件测试最佳实践》,《selenium自动化测试指南》,《软件性能测试过程详解与案例剖析》,《接口测试实践》,《测试驱动开发》...
软件发展方向测评
其实我觉得软件测试工程师是个非常有前途的职业.现在软件测试工程师的缺口非常的大. 程序员跟测试员是相互对应的.以前国内认为只要有好的程序员就行了,其实还要有好的测试员.现在国内的软件厂商越来越注重测试员. 软件测试工程师 一提到软件测试工程师,很多人就会想到那些反复使用软件,试图在频繁操作中寻找到错误发生的低层次人员或者软件用户。
其实这是一种错误的概念,软件测试早已超越了用户使用来发现Bug的基本测试阶段。
陈宏刚介绍说,微软的软件测试工程师分为三种:测试执行者(Basic Software Tester)、测试工具软件开发工程师(Software Development Engineer in Test)和高级软件测试工程师(Ad_hoc Tester) 测试执行者负责理解产品的功能要求,然后根据测试规范和测试案例对其进行测试,检查软件有没有错误,决定软件是否具有稳定性,属于最低级的执行角色。
测试工具软件开发工程师负责写测试工具代码,并利用测试工具对软件进行测试;或者开发测试工具为软件测试工程师服务。
产品开发后的性能测试、提交测试等过程,都有可能要用到开发的测试工具。
对技术要求最强的是这些人,因为它们要具备写程序的技术。
“因为不同产品的特性不一样,对测试工具要求也是不同的,就像Windows的测试工具不能用于Office,office的也不能用于SQLserver,微软很多测试工程师就是负责专门为某个产品写测试程序的。
” 而Ad_hoc Testet属于比较有经验,自己会找方向并做的很好的测试工程师,这要求具有很强的创造性。
刚进入微软时,老板也是只给陈宏刚一个操作流程,每天就按照这个规程去做,几天下来,一个Bug都没有发现。
陈宏刚也很沮丧,觉得这样挺对不起公司,后来自己问自己:为什么非要这样做!于是换了其他的方法试试,令他吃惊的是,一下就找到很多严重的Bug,当时也不敢声张。
有一天,他找到10多个非常严重的Bug,开发经理一下就惊呆了,怒冲冲的跑到陈宏刚面前问:“你是不是改变了测试方式和测试步骤?”陈宏刚有些吓住,说道:“可能改变了一点。
”对方说:“我非常生气,但我不是生你的气,而是因为以前测试人员水平太差,或者以前的测试方面有问题,软件中有些Bug存在了半年甚至一年,但直到现在才发现,现在修补这些错误要困难很多!”后来陈宏刚得到了老板的赞许,可以按照自己的想法去做测试。
对此,陈宏刚感受颇深:“一方面我体会到了微软非常鼓励创造的文化,同时也感到只遵守教条不是好的测试人员,就和用户一样了。
做软件测试工程师同样需要开拓和创造性。
” 在开发管理上,测试不应该归属于项目管理,也不应该归属开发人员。
这三个部门应该是并驾齐驱,相互协作,测试工程师最终决定产品是否能够发布。
软件测试工程师的素质 因为软件测试仍然处在发展阶段,还没有上升到理论层次。
对人员的评测,包括微软在内,都还没有一个统一标准,因此评定软件测试工程师只能根据工作实践进行自然淘汰。
软件测试对逻辑思维、学习能力、反应要求很高,是否有严密的思维和逆向思维也非常重要。
陈宏刚介绍说,在五六个人的测试小组时,一半以上的Bug都是他找到的。
他认为这同自己数学专业的背景关系密切,数学中有逻辑思维的培训,要善于找出来各方面的因素。
比如要证明一个定理,各个方面都考虑到,一个条件不满足就无法证明;但如果证明其不成立,最常用的就是找到一个反例,只要有一点证明不成立就可以了,软件测试也是找这一点。
做测试还要考虑到所有出错的可能性,还要做一些不是按常规做的、非常奇怪的事。
除了漏洞检测,测试还应该考虑性能问题,也就是要保证软件运行得很好,没有内存泄漏,不会出现运行越来越慢的情况;在不同的使用环境下,考虑软件的兼容性同样重要。
软件测试同产品的规模也有很大的关系,因为软件的bug往往出在大型软件的连接处。
做软件测试工程师需要对软件抱有怀疑态度。
这是因为开发人员喜欢想当然,总是找一些有利于自己程序执行的数据,有些开发人员甚至认为不利于程序执行的数据是对代码的玷污和亵渎。
而软件测试却要策略性的准备各种数据,从每个细节上设计不同的应用场景,不去想当然的假定任何一个数据是可行的。
在职业素质和交际方面方面,并不是测试工程师爱挑别人毛病才好,反而这个工作要求很强的沟通能力。
经常的和开发人员进行沟通,说话办事要很得当,不能指责别人,否则会事倍功半。
性格随和才能和开发人员顺畅的沟通,对人和对事是完全不同的两个问题。
如何培养优秀的软件测试工程师 朗川软件测试工程师张建阳从北大力学系毕业之后,曾开发流体力学分析软件,软件缺少测试而产生的问题给她留下了很深的印象。
后来去大唐电信做UIM(统一消息管理系统),她发现尽管公司为了鼓励员工找bug采取了很多奖励方法,但还是很少人愿意去做系统测试。
而张建阳却从那时查阅翻译了很多国内外的资料,对软件测试产生了浓厚的兴趣。
像张建阳这样在工作中自己定位在软件测试领域的开发人员并不多见,因为程序员更愿意去做开发而不是测试,从大环境上,测试人员收入水...
互联网公司的软件测试工程师们都在干什么?
互联网和传统行业的不一样,变更多,迭代快,测试工程师们能大噶说一下吗?还有,怎么样才能提高自己的价值呢? 精彩答案: 会员jijiting: 抛砖引玉,了解皮毛而已。
测试要做的是,检测和监控产品的质量,提高测试效率,优化测试流程,改善评测办法,为产品的改进和上线提供保障。
测试工程师大概在做: 1、功能测试:包括和开发、产品确认产品需求,做测试计划,设计测试用例,做测试用例评审,做冒烟测试或者准入测试,执行测试用例,多轮迭代测试,一直跟踪到上线之后的回测,以及看下用户的反馈,确认测试过程中有没有遗漏(算作是KPI的一部分)。
在这个过程中,可以反思自己的疏漏,完善测试的流程,完善测试的检查点,增加各种类似的测试,思考可以自动化的部分并实现。
2、自动化测试:对界面、接口或者后台进行自动化的测试,在测试的前期可以保障基本功能的正常,在测试中期可以保障开发的修改没有对产品质量引起严重问题,在测试的后期可以做上线前的回归测试,上线之后可以作为日常的监控。
自动化的测试在不同平台、不同操作系统、不同浏览器下使用不同的工具,采用不同的框架,所以在没有这些的时候需要调研目前行业内比较流行的解决方案,寻找到适合自己产品的方法来解决问题。
之后开始设计测试用例,并进行实现。
产品的改进过程中需要进行维护,保证随时都可以通过。
3、性能测试:测试产品的性能,在多大的压力下可以满足当前预期的用户请求。
需要使用各种压力工具,做压力文件,安排与线上一致的测试机器或者精简后的环境进行测试,对测试出来的数据进行分析,确认现有的系统是否存在问题。
貌似环境部署可能是个问题,所以公司里面会有大牛做一些自动部署的工具,甚至会开发出一些独立的平台来完成多台机器的部署工作,可以节省很多的时间。
测试出来的数据跟产品以及开发人员确认,也可能会找到一些方案来解决。
4、测试开发:相对来说开发的工作比一般测试工作要多一些。
开发一些自动化的测试的平台,比如一些评测系统,供人工评测试用;设计一些测试框架,来满足日常自动化以及性能测试的需要。
制定持续集成测试的平台和方案并且实现,结合自动化的测试实现人工测试之前的自动化测试实现,对开发的代码进行监控,跟踪并尽量帮开发改进产品质量等等。
这块我比较白,还在仰视阶段。
接受其他测试人员的需求,开发合适的工具来提升整体测试效率,改进测试方法。
5、测试工具以及测试理念的推进。
测试在大多数人看来还是比开发要差一些的,测试工具还可以,能够直接快速的反映出测试人员的价值,但是更多的功能测试、性能测试还需要跟开发去沟通,让他们意识到测试的重要性,但是最重要的还是要提升测试自己的工作能力,尝试影响开发人员并且和开发人员一起,最终提升产品的质量。
6、测试人员还是要多学习吧。
要是觉得测试是个人都可以做的就别来趟这个浑水了。
会员 姜雷: 我当时是做实习生,实习生的时间比较自由,也没有具体的产品、KPI捆绑,所以我做的主要是没有具体产品关联的长线项目。
比如说自动测试平台的搭建,测试自动化辅助工具的开发,原有测试脚本的集成、改写、自动化等工作(比较杂,有些随性,我甚至写过单元测试——这个应该是dev做的)。
还有就是一些具体的模块覆盖率的提高、测试自动化的探索。
具体到身边的入职同事们,工作就比较杂了。
忙起来的时候,是黑盒、白盒;自动化、手动的都要做。
项目上线之前的功能、性能、压力测试等都是必要做的,由于目前国内互联网发展较快,项目改进迭代的压力很大,所以有的时候感觉身边的同事都被项目纠缠得忙——这就是为什么上下一心都觉得自动化很重要。
当然,还有些人专门做测试工具的开发和测试流程改进的探索,我当时所在的部门也开发了很不错的自动化测试工具——这应该是我接触过的最接近开发的测试开发人员了。
我实习的组测试人员比较主动,去做了一些项目敏捷化的探索,还主导了项目的敏捷化,但是开发人员那边跟进得并不是很积极——我个人认为这个应是开发人员主导的,而且整个团队都参与进来,各个人员的角色需要有交叉——可惜我在实习期间没有体验到这些,这个在形成了一定的规模的国内公司估计很难改变。
我实习结束的时候,有些组在流程上已经非常敏捷、自动化了,但是毕竟是上线的产品,自动化的初期肯定有一定的阵痛,估计现在应该好多了。
另外,谈谈我个人的一些感受,如果专门做测试的话,我觉得最大的问题就是成就感的问题。
你做的似乎永远只能是内部使用的东东,永远不会成为呈现在用户面前的产品(gtest等测试框架产品除外)。
当一个项目上线以后,你得到的relief多一些,但是成就感相对少一些。
我只是从实习生的角度谈的。