想从事测试行业，现在移动互联网比较发达，什么app啊、游戏啊，感觉测试的话比较缺，想做自动化测试？_百度知道
想从事测试行业，现在移动互联网比较发达，什么app啊、游戏啊，感觉测试的话比较缺，想做自动化测试？
之前做过一段时间测试，不太了解自动化测试，求教需要学习什么，需要什么能力
我有更好的答案
首先是高质量的自动化测试脚本所必备的能力,并不是掌握了一门语言就是代码能力完事了，自动化测试脚本也是需要有代码健壮性、代码扩展性、代码稳定性要求的，而良好的代码功底、数据结构和算法，可以开发出高质量的自动化脚本，这会极大地减少后期自动化脚本的维护成本。随着自动化脚本所解决的问题逐步增多，范围逐步扩大，对自动化脚本的架构设计也会提出更好的要求。当然也不仅仅只有这些，一个有实力的测试人员，需要长时间的积累TestBird - 手游和App自动化测试平台
采纳率：87%
为您推荐：
其他类似问题
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。(一起学数据分析)
([已注销])
(哼我们棒着呢)
(无聊人士)
第三方登录：从产品的角度来说说功能测试环节中最容易被忽视的测试细节点
在经历了策划、设计、开发等一系列的劳作辛苦之后，只要再进行细致地测试网站便可以上线了。笔者参与过很多大大小小的网站项目，今天从产品的角度来说说功能测试环节中最容易被忽视的测试细节点。
一：搜索死角
这里所说的搜索是指站内搜索，站内搜索可以让用户非常方便的找到目的内容，另外可以通过记录用户站内搜索关键词来进行用户分析。可是随着网站内容的增多以及条件的繁琐，站内搜索往往是以多重条件搜索的方式来展示给用户使用的。这就给测试人员造成了一定的压力，毕竟测试人员光从需求文档上是无法对每项搜索条件和结果进行深入分析的，因此搜索功能的测试可称之为“测试死角的老大”。
解决方法：建议测试人员邀请产品经理共同测试该功能，做到万无一失。
二：列表排序死角
无论是门户网站还是电子商务网站或者是NNS社区，他们都少不了列表排序，今天笔者用某网站的口碑榜排序列表来叙述一下该死角到底有多深。如果我们来做一个公正的第三方评论平台的话我们只需要根据时间、口碑值来进行排列即可，这样一来死角不会太深。越来越多的网站把口碑榜，销售榜，关注榜作为提高PV和降低退出率的手段，这样一来列表排序会有网站的运营人员参与，在此我做一个比方大家就会明白列表排序会出现死角的原因了。假设我们现在来进行一个电脑关注度的排序，假设从网站后台的表单中我们查询是这样排列的：
这时运营接到市场部的通知，要求把神舟电脑加入到关注度排行榜的第三位，从网站后台我们查出神舟电脑的关注度为1200，这里就存在一个问题了如果强制将方正替换为神舟的话那么展现在网页上的列表排序就像下面这样：
用户不是傻子一眼就看出来这样的商业行为，因此测试人员在测试排序列表时，如果包含了强制置顶功能的列表不光是要把值插入进去，更要做到前后统一的效果，这样才不会穿帮。
解决方法：没有绝对的解决方法，因为本文是做死角探讨不是技术文章，因此具体的方式不做赘述，笔者以前的做法就是采用“补偿法”把少的补上，出现相同值得话就要视情况而去操作了。
三：SQL注入攻击死角
SQL注入攻击是黑客对数据库进行攻击的常用手段之一。随着B/S模式应用开发的发展，使用这种模式编写应用程序的程序员也越来越多。但是由于程序员的水平及经验也参差不齐，相当大一部分程序员在编写代码的时候，没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据，这就是所谓的SQL Injection，即SQL注入（摘取百度百科）。前段时间密码泄露门事件闹的沸沸扬扬，所以在测试环节对待这样一个普通用户涉及不到的操作还是需要倍加留心。
解决方法：笔者不是安全专家，所以没有非常好的解决方法，如果大家对此有兴趣的话可以在网上查阅相关资料。
四：图片缩放死角
图片是网站的灵魂，一张恰到好处的配图能够吸引用户的目光，从而为用户提供优良的用户体验。UI设计师在设计页面时选取照片的尺寸会根据版面的需要来进行搭配，而往往这样的配图在网站上线后是需要运营人员根部不同的内容进行更换的，甚至有新闻采集系统会自动转发外站的新闻，由于配图的图片位置大小是固定的，所以一不小心的工作失误就会出现图片变形的情况从而影响用户使用的心情。
解决方法：根据版面的样式确定图片的最大长宽尺寸，并配以淡色的外框，如果程序检测到上传的尺寸与之不符，那么根据等于缩放的比例缩放最大宽度或者高度。即便左右留白或者上线留白总比一张变形的图片看得舒服。
五：文字截取死角
该死角和第四个颇有相似之处，最大字符长度如果设置不准确的话一来会影响用户的阅读，二来会影响页面的美观，好在这样的一个死角修正起来很简单，笔者就不做赘述希望测试人员在测试的时候多加小心便好。
解决方式：试验及调整到最佳的字符显示数量，如果标题真的过长的话建议用…放在标题的末尾，从程序的角度来说增加标题的“title” 显示。
今天就说这么多，我相信肯定会有很多看官也有会有自己总结的死角，不妨说出来分享一下。
Copyright (C) , All Rights Reserved.
版权所有 闽ICP备号
processed in 0.064 (s). 13 q(s)收藏的论坛
手游与App测试如何快速转型 分析手游与App测试四大区别
　　随着智能设备的普及和移动互联网的兴起，各家互联网巨头纷纷在往移动端布局和转型，同时初创的移动互联网公司也都盯着这个市场希望分一杯羹。在这个大环境下，互联网的重心已经慢慢从Web端转向了移动端，而移动端的软件测试也变得越来越重要了。　　在移动端的软件里，手游又是其中非常大的一块。从下面的图可以看出，智能手机的普及和手游玩家的增长是密切相关的： 　　笔者曾经从事过手机App的测试开发工作。1年前加入鹅厂后转行做了手游测试工作，通过摸索实践，发现两者在相同的测试理论基础之上，其实有着非常不同的测试场景和测试需求。下面就为大家整理一下其中的基础部分，涵盖了两者在手工和自动化测试方面的不同，希望能帮到想从App测试转到手游测试的朋友们。　　1.APP自动化测试完全不同于手游自动化测试　　手机App和手游的开发技术不同，这导致了两者的自动化测试技术是截然不同的。　　以安卓开发举例，手机App一般使用Android SDK开发，使用Java编写。通过Android提供的服务，我们可以获取App当前窗口的视图信息，进而查找和操作按钮等控件，以完成自动化测试，如Uiautomator。这个过程是标准化的，从技术上来说没有任何难度，因此各个公司各个App自动化测试的方法都大同小异。　　但手游的开发却不是这样。手游一般使用引擎开发，现在著名的有cocos2d和unity3d。两者都是使用引擎自带的语言进行开发，主流的分别是c++和c#，虽然在开发过程中也有按钮等控件的概念，但当运行时由引擎渲染后就变成了一副简单的图片：　　游戏中看到的只是一副简单的图片，按钮已经不是控件了　　因此，我们就无法通过Android自带的服务来找出游戏中的按钮了，也就没法进行常规的自动化测试。　　如果有人说自己的技术是基于Android原生控件识别的，那就一定做不了手游自动化测试。这个问题大家都在探索解决方案，我们现在通过注入引擎SDK到安装包反射出引擎层控件的方法进行自动化测试，实践下来具有很好的效果。　　2.玩法不同导致功能测试更复杂　　2.1 随机性　　游戏的场景和过程是动态并且伴有随机要素的，这体现在两点。　　1.你重复玩一个游戏关卡，很可能两次出现敌人以及游戏过程是不同的。　　2.你玩一个手游的时候不进行操作，敌人和周围的场景也在时刻发生改变。　　这两点对自动化测试带来了极大的挑战，如果测试脚本写的不够灵活，很容易导致上一次运行成功的脚本这一次就无法运行了。我们需要在测试脚本里适当的加入探索和自适应的功能。　　App测试就没有这个问题，大部分App的使用方式都是静态且可以重复的。因此自动化测试可以完全按照测试脚本进行编写并执行。　　2.2 探索性　　手游和App的第二个玩法不同在于探索性。App一般都是功能性的，好的App需要把它的功能简单明了地告诉用户。而游戏重在娱乐性，需要给玩家一定的探索要素。因此在做手游测试的时候，我们需要测试游戏的用户帮助说明是否清晰，同时后续的游玩和探索过程和前面给出的说明之间是否有合理联系，规则的指示是否有足够的提示性。　　2.3 难度测试　　App希望做的越简单，用户的使用成本越低越好。而手游是有难度设置的。我们在做手游功能测试的时候，会把资源和等级调到最大以方便后期功能的执行，但当所有的功能测试都做完后，我们需要把自己的资源初始化，以&回归&一个普通玩家的水平，通过普通玩家的视角来查看游戏的难度提升是否合理，资源分配是否均匀。　　2.4 关卡测试　　App的使用是功能性的，一个功能的重复使用总是一样的。而手游具有关卡的概念，即便是同一种玩法，关卡和关卡之间也有细微的差别，前面的关卡测试正确了，并不表示后面的关卡一定是正确的。作者曾经碰到过一个手游的Bug，当游戏进行到某个后期关卡时，游戏一定会崩溃。而导致这个Bug的原因也很简单：这个关卡的图片资源在打包客户端的时候没有加入。因此当我们玩前面的关卡时并不会触发这个Bug，但一到后面的关卡就出错了。　　这类Bug虽然原因简单，但确实非常难测试到。因为各个关卡的玩法虽然都一致，但一个游戏的关卡数却是非常多。如果我们要遍历所有的关卡走一遍，那耗费的人力成本将是非常大的。对于这类重复性的关卡测试，建议使用自动化脚本进行遍历。　　2.5 PvP测试　　App的使用普遍是单人的，而手游往往有玩家对战的PvP模式，好的手游更是具有实时的PvP模式。由于两个玩家实时进行游戏合作或者对战，因此网络延迟的测试就变得非常关键了。我们在测试中需要模拟不同的网络对游戏延迟的影响，观察两个玩家的状态和数据是否一致，同时体验网络延迟对游戏手感的影响，这在传统的App测试中是完全不需要的。　　3.手游测试更看重商业类测试　　3.1 支付测试　　现在的手机App基本上以广告收入为主，并不会直接向用户收取费用。而手游的直接消费群体就是玩家，在游戏过程中伴随着玩家大量的支付操作。由于这类操作和玩家的金钱密切相关，因此支付类的测试在任何游戏中都要做最高优先级的保证。　　我们需要在各种严格的环境下保证玩家的支付操作被正确执行或者得到了正确的失败提醒。例如当网络状况很差的时候，用户在支付界面的多次确认操作必须只能被执行一次。当用户在支付过程中断网，未收到货物时，游戏需要在玩家的网络恢复后第一时间补发货物，并作出明显的提示。另外支付操作需要在大量不同系统、不同型号的手机上进行适配操作，以降低出错的可能性。　　3.2 安全测试　　对于大多数非支付类App来说，安全并不是一个特别大的问题，只需要保证登录鉴权的安全性即可。App是一个方便用户的工具，没有人会在用自己的计算器App时候锁定内存，或者把加法操作变为乘法操作。　　手游在这点上很不一样，手游与玩家在某种程度上具有&对抗&要素，玩家要战胜游戏关卡获得奖励，而游戏关卡要设置一定的难度阻止玩家。如果游戏的外挂横行，玩家不需要任何对抗就能获得胜利，一方面会对游戏的平衡性造成影响，使得某些玩家的资源大大超过别的玩家;另一方面从长远看会使得这个游戏变得无趣，从而造成玩家的离开。　　对游戏进行安全测试的普遍方法为通过锁定/修改内存来锁定和修改游戏资源、通过修改游戏内存来改变游戏逻辑简化游戏流程等。　　3.3 收益测试　　一般的手游App没有付费用户的概念，所有的用户都是使用同一个功能。即便有付费用户，他们和普通用户的区别也非常明显：付费用户可以使用一些额外功能。手游的付费用户和非付费用户的界线并没有这么明显。手游里根据用户付费的多少分为非R用户，小R用户，大R用户等。我们需要在策划的时候就计算好这些付费用户的投入和回报，并在测试的过程中验证这些。举两个例子，如果一个大R用户获得的回报，非R用户只用很少的时间就能获得，那大R用户一定不满意，这个收费项目的设置就是不合理的;如果两个购买项的金额相同，而收益明显不同，那也会造成玩家的不满。　　4.后台性能不同　　虽然我们这里讨论App和手游主要是前端客户端，但其实两者的后台性能也有区别。相比一般的App，手游的在线人数明显更有规律性且更集中，一般在中午12点和晚上8点是两个明显的高峰。因此手游的性能测试就要贴合这种用户模型，能够处理极值情况下的服务器性能负载。当然，两者都会受到节假日较大的影响，这个对于App和手游来说是一致的。　　也来谈下相似之处　　除了上面提到的这么多手游测试和App测试的不同点，其实两者也有很多相似之处，在测试的时候都不能遗忘，例如手机来电、短信的中断测试，碎片化的兼容性测试(尤其是安卓)，客户端运行在手机上的性能测试，网络较差或者网络频繁切换的弱网络测试，已经用户体验和UI测试等。
近期游戏热闻
类型:3V3 MOBA
厂商:Supercell
类型：MOBA
类型：动作射击
类型：角色扮演
类型：音乐舞蹈
类型：换装养成
类型：休闲益智
类型：ARPG《51测试天地》―顾翔与你一起漫谈测试
《51测试天地》―腾讯WeTest教你玩转手游测试
手游与App测试如何快速转型
　　随着智能设备的普及和的兴起，各家互联网巨头纷纷在往移动端布局和转型，同时初创的移动互联网公司也都盯着这个市场希望分一杯羹。在这个大环境下，互联网的重心已经慢慢从Web端转向了移动端，而移动端的也变得越来越重要了。　　在移动端的软件里，手游又是其中非常大的一块。从下面的图可以看出，的普及和手游玩家的增长是密切相关的：　　加入鹅厂前，笔者曾经从事过手机App的测试开发。1年前加入鹅厂后转行做了工作，通过摸索实践，发现两者在相同的测试理论基础之上，其实有着非常不同的测试场景和测试需求。下面就为大家整理一下其中的基础部分，涵盖了两者在手工和方面的不同，希望能帮到想从App测试转到手游测试的朋友们。　　1、APP自动化测试完全不同于手游自动化测试　　手机App和手游的开发不同，这导致了两者的自动化测试技术是截然不同的。　　以安卓开发举例，手机App一般使用 SDK开发，使用Java编写。通过Android提供的服务，我们可以获取App当前窗口的视图信息，进而查找和操作按钮等控件，以完成自动化测试，如Uiautomator。这个过程是标准化的，从技术上来说没有任何难度，因此各个公司各个App自动化测试的方法都大同小异。　　但手游的开发却不是这样。手游一般使用引擎开发，现在著名的有cocos2d和unity3d。两者都是使用引擎自带的语言进行开发，主流的分别是c++和c#，虽然在开发过程中也有按钮等控件的概念，但当运行时由引擎渲染后就变成了一副简单的图片：　　图：游戏中看到的只是一副简单的图片，按钮已经不是控件了　　因此，我们就无法通过Android自带的服务来找出游戏中的按钮了，也就没法进行常规的自动化测试。　　如果有人说自己的技术是基于Android原生控件识别的，那就一定做不了手游自动化测试。这个问题大家都在探索解决方案，我们现在通过注入引擎SDK到安装包反射出引擎层控件的方法进行自动化测试，实践下来具有很好的效果。　　2、玩法不同导致更复杂　　2.1、随机性　　游戏的场景和过程是动态并且伴有随机要素的，这体现在两点。　　1、你重复玩一个游戏关卡，很可能两次出现敌人以及游戏过程是不同的。　　2、你玩一个手游的时候不进行操作，敌人和周围的场景也在时刻发生改变。　　这两点对自动化测试带来了极大的挑战，如果测试脚本写的不够灵活，很容易导致上一次运行成功的脚本这一次就无法运行了。我们需要在测试脚本里适当的加入探索和自适应的功能。　　App测试就没有这个问题，大部分App的使用方式都是静态且可以重复的。因此自动化测试可以完全按照测试脚本进行编写并执行。　　2.2、探索性　　手游和App的第二个玩法不同在于探索性。App一般都是功能性的，好的App需要把它的功能简单明了地告诉用户。而游戏重在娱乐性，需要给玩家一定的探索要素。因此在做手游测试的时候，我们需要测试游戏的用户帮助说明是否清晰，同时后续的游玩和探索过程和前面给出的说明之间是否有合理联系，规则的指示是否有足够的提示性。　　2.3、难度测试　　App希望做的越简单，用户的使用成本越低越好。而手游是有难度设置的。我们在做手游功能测试的时候，会把资源和等级调到最大以方便后期功能的执行，但当所有的功能测试都做完后，我们需要把自己的资源初始化，以"回归"一个普通玩家的水平，通过普通玩家的视角来查看游戏的难度提升是否合理，资源分配是否均匀。　　2.4、关卡测试　　App的使用是功能性的，一个功能的重复使用总是一样的。而手游具有关卡的概念，即便是同一种玩法，关卡和关卡之间也有细微的差别，前面的关卡测试正确了，并不表示后面的关卡一定是正确的。作者曾经碰到过一个手游的，当游戏进行到某个后期关卡时，游戏一定会崩溃。而导致这个Bug的原因也很简单：这个关卡的图片资源在打包客户端的时候没有加入。因此当我们玩前面的关卡时并不会触发这个Bug，但一到后面的关卡就出错了。　　这类Bug虽然原因简单，但确实非常难测试到。因为各个关卡的玩法虽然都一致，但一个游戏的关卡数却是非常多。如果我们要遍历所有的关卡走一遍，那耗费的人力成本将是非常大的。对于这类重复性的关卡测试，建议使用自动化脚本进行遍历。　　2.5、PvP测试　　App的使用普遍是单人的，而手游往往有玩家对战的PvP模式，好的手游更是具有实时的PvP模式。由于两个玩家实时进行游戏合作或者对战，因此网络延迟的测试就变得非常关键了。我们在测试中需要模拟不同的网络对游戏延迟的影响，观察两个玩家的状态和数据是否一致，同时体验网络延迟对游戏手感的影响，这在传统的App测试中是完全不需要的。　　直接下载本专刊：　　本文收录于《测试专刊-腾讯WeTest教你玩转》。　　版权声明：本文出自《测试专刊-腾讯WeTest教你玩转手游测试》。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
建议使用IE 5.0以上浏览器，800×600以上分辨率,法律顾问：上海瀛东律师事务所 张楠律师
, 沪ICP备号
投诉及意见反馈：  
业务联系：  021-7