你花了很多心血、汗水和眼泪来构建一个App，然后才发现你的产品根本不是你幻想的那样。 这个很耳熟吧？
如果你的App无法留住用户，那你App的可用性和长期吸引性就有问题。但是互联网是个很容易通过跟踪发现App问题的地方。下面我们就介绍一些方法和工具，能让你的App在正式面市前看起来不那么恶心。
做一个职业的评估：可用性测试工具uTest
新手设计师常犯的错误就是违反基本的设计和可用性原则，有经验的设计师在审计可用性的时候就可以把这些问题标记出来。所以在真正面向用户前，使用。
检查用户是否认可你的价值主张：登陆页面测试工具Clue
也许你认为你的登陆页面完全阐述清楚了你的App是多么强悍，但是你的说明语言可能很不清楚或者扯得不相关，使用测试，你可以快速创建一个内存测试来看看用户对你的实际页面有什么反馈。
跟踪正确的分析数据：App数据分析工具
Flurry 和Google都提供免费的App分析报告，比如用户会话长度和用户使用频率。另外一些先进的移动分析平台包括Kontagent, Localytics, 以及Apsalar。它们会提供更复杂的用户分类、使用故障、留存率和转换率分析功能。
远程用户行为记录工具
找到你的目标用户进行测试，建立面对面的可用性研究非常耗时。如果想节省时间，可以使用远程移动可用性测试服务和，它们可以提供目标用户第一次使用你程序的时候的赞赏或者困惑的表情视频。
热点地图工具跟踪用户操作和路径
用户经常会在你意想不到的方式和手势使用App，所以移动平台上你可以使用触摸跟踪工具，来可视化用户来源和手势。该工具也会构建用户路径向你展示用户如何使用App、用户使用时在哪里反弹了。这样你就知道用户是否在关注你认为正确的事情，是否在你认为重要的地方采取了必要步骤。
分割测试工具
分割测试也叫A/B测试，一般通过运行多个设计版本来决定哪一个是最棒的的，可用的工具包括, , 和 ，这对帮助非技术人员设计测试多个代替品是非常有用的，比如测试App内购买的界面和文字教程。
而且这些分割测试的结果很直观，比如Swrve一个著名案例曾发现App内购买价格提高竟然没有导致销量下降。
团队协作工具Notable：与你的设计团队随时讨论和反馈
做完了上面所有的用户测试后，你会在哪里记录你的这些测试反馈？就是专门的一个协作工具，可以让你批量上传和注释你的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 & 随机性
游戏的场景和过程是动态并且伴有随机要素的，这体现在两点。
你重复玩一个游戏关卡，很可能两次出现敌人以及游戏过程是不同的。
你玩一个手游的时候不进行操作，敌人和周围的场景也在时刻发生改变。
这两点对自动化测试带来了极大的挑战，如果测试脚本写的不够灵活，很容易导致上一次运行成功的脚本这一次就无法运行了。我们需要在测试脚本里适当的加入探索和自适应的功能。
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测试等。
阅读(...) 评论()常用入口：| | |
常用攻略：| | |
dnf手游四测副本和端游有什么区别？dnf手游副本有几种难度？
地下城与勇士（news）新闻导语
本文详细介绍了dnf手游四测副本和端游有什么区别和dnf手游副本有几种难度
dnf手游四测副本和端游有什么区别?dnf手游副本有几种难度?dnf手游正在进行四测中，哪些拿到资格的玩家可以去尽情的玩耍吧，因为此次测试进行到11.11就会结束了，那么游戏中的副本玩法是否和端游差不多呢?下面我们来一起dnf手游四测副本和端游有什么区别和dnf手游副本有几种难度。
本次测试副本有剧情地下城、普通地下城。公会副本则合并到了公会系统中。新增副本难度选择，分别为：普通级、冒险级、勇士级。其中普通级顶多爆紫装，其他的则有爆粉的几率。而二测中的深渊地下城并没有出现在本次测试中，不知道是否删除了这一玩法。
由上面两张图可以看出：手游四测中的一些副本系统玩法和端游差异不大，那些端游党的玩家可以放心了。
轻触这里关闭目录
手机看攻略，电脑玩游戏两不误！
加点再也不需要切来切去啦~
【地下城与勇士（news）】最新消息第一时间推送给您
友情链接：             |          |          |          |          |          |          |          |          |          |          |          |          |  
本类热点图文资讯
手游与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测试等。
Powered by DOGAME游戏兵工厂}