移动APP测试方法

超赞！移动APP测试实用指南译者注：本文从测试人员的角度出发，提出了 100多个在测试移动App过程中需要考虑的问题。不管你是测试人员、开发、产品经理或 是交互设计师，在进行移动App开发时，这些问题都很有参考价值。我和Queen合力译出此文，分享给大家，希望有所帮助和启发。测试人员常被看作Bug寻找者，但你曾想过他们实际是如何开展测 试的吗？你是否好奇他们究竟都做些什么，以及他们如何在一个典型 的技术项目中体现价值？作者将带你经历测试人员的思维过程，探讨他们测试移动App时的 各种考虑。本文的目的在于揭示测试人员的这一思维过程，并展示他 们通常所考虑内容的广度和深度。1.测试人员需要询问问题测试人员的核心能力在于提出有挑战性的相关问题。如果你能将调查、 询问技巧和技术、产品的知识结合起来，渐渐地，你也会成为一个好 的测试人员。比如，测试人员可能会问：这个App应该在什么平台上使用？ o这个App到底是干什么的？ o如果我这样做，会发生什 么情况？ o诸如此类。测试人员能从各种场景中发现问题，它们可能来自对话、设计、文档、用户反馈或者是产品本身。这些可能性太多了因此，让我们一探究竟吧！2.从哪里开始测试理想情况下，测试人员应该掌握所测产品的所有最新细节资料。但事实上这很少见，因此，像其他人一样，测试人员只能将就使用手上有限的资料。但这不是不能测试的借口！测试人员其实是可以从内部和外部多种不同的来源处收集信息的。这个阶段，测试人员可以问这些问题：有哪些信息：规格？项目会议？用户文档？知识渊博的团队成员？有支持论坛或者o是公司在线论坛提供帮助？有现存Bug的记录吗？该应用是在什么系统、平台和设备上进行运作和测试？ o该应用是处理什么类型的数据（比如 个人信息、信用卡等等）？ o该应用有整合外部应用（比如API和数据来源）吗？ o该应用 需要用到特定的移动端网页吗？ o现有消费者如何评价这个产品？ o有多少时间可用于测试？ o测试的优先级和风险是什么？ o哪些用户使用起来不愉快，为什么？ o如何发布和更新？ o基于以上收集的信息，测试人员可以制定测试计划了。通o常预算决定测试方法，一天测完，一个星期或一个月测完的方法肯定不同。当你逐渐熟悉团队、工作流程以及这类问题的解决方式时，你就更容易预测结果了。案例：FacebookApp的社会评论o当作为一名测试人员收集信息时，我喜欢选用o作为案例，因为用户的抱怨到处都是。以下FacebookApp中发表仅仅展示了部分遇到难题的用户在iTunesAppStore的评论，网络上还 有很多。FacebookApp有很多负面的评论iPhone上的，我肯定会考虑这些 App这个如果我接受挑战去测试Facebook反馈，否则就是傻子。测 试人员的创造力3.原本想做的事，但是它究竟可以做什么事呢？ 你可能知道这个App用户实际上是如何使用它的？测试人员擅长作 为旁观者来思考，为什和” “如果。会怎么样尝试不同的事物，以 及不断地询问“”么的问题。比如，移动端的测试人员常常以不同的用户角色进行测试一一当然有 点夸张，但是，这种把自己当成不同用户进行思考、分析和设想的能 力对测试是备受启发的。测试人员可能会设想自己是以下用户：毫无经验；o很有经验；o爱好者；o黑客；o竞争对手；o当然还有更多可选 的角色，这主要取决于你们所开发的产品是什么。其实除了角色特点 外，其操作行为和工作流程也很重要。人们使用产品方式常常很奇怪， 比如：在不应该返回的时候返回了； o不耐心而且多次敲按键；o输入错误的数据；o不理解该 怎么做；o可能没有按要求进行设置；o可能会自以为是地认为自己知道该做什么（比如通 常不阅读说明）。o测试人员遇到这些问题时，也常常发现意料之外的Bug。有时候，这些Bug微不足道，但是更深入的调查就会发现更严重的 问题。很多问题是可以被预先确定和测试的。测试移动端App时，以下的 问题并不都有关，但是也可以尝试问问：是否按照所说的来做呢？ o是按设计完成任务的吗？ o不是按设计完成任务的吗？ o.如果处于一直被使用或者负荷情况下，状况会怎么样？会反应迟钝吗？会崩溃吗？ o会更新吗? 有反馈吗？崩溃报告会反馈到App吗？ o用户可能有哪些创造性的、逻辑性的或是消极的导航方式？用户 相信你的品牌吗？ o用户的数据安全如何？ o有可能被中断或是被破解吗？ o运行到极限 时会发生什么状况？ o会要求打开相关服务吗（如GPS、Wi-Fi）？如果用户打开会怎样？没打 开又会怎样？ o将用户重新引向哪儿？去网页？还是从网页到App？这会导致问题出现吗？ o沟通过程和市场反馈是否符合该App的功能、设计和内容？ o登录流程是怎样的？能在App 上直接登录还是要去网页端？ o登录是否整合了其他服务，比如用Facebook和Twitter帐号 登录？ o 案例：RunKeepersgyUpdateRunKeeper，是一款能跟踪你健身活动的App，最新发布的版本里有个“目标设置”的功能，对此我很感兴趣去体验一下，一部分从测试人员的角度来看，更多的是作为一个真心喜欢产品的用户来体验。但我发现了一些问题：1. 默认单位是英镑，我却想要把公斤作为重量单位；2. 英镑和公斤间的切换根本不好用；3. 当设定目标后，会导致展示错误的数据和图表，这让我很迷惑；4. 由于第3条，我想删除目标，但却根本找不到删除的地方；5. 为了解决这一问题，我不得不改变的个人体重的值，直到“目标设置“范围之内，这样目标达到了，就能重新设定目标了；6. 我会再次尝试添加目标；正因为以上疑惑，我花了更长的时间把玩它，看能不能找到其他的 问题；以下是一些发现问题的屏幕截图:Go衬I Details f-j Welgm Loss &S0遍 rt bateCHWDrtH部分。设置日期的时候，我发现开始和结束的”的最新版本包含了一个新的目标该App年开 始，另外，为什么有两个1年可选（译者注：年份那列从上往日期都可以从公元1下应该显示为 “1、2、3” )?曜DQ-UK甘 枚弟T心二|mW喝初I Detorh Vfp Weight Loas GoalI St&rtEW姗网11 End Dufe奶网1I Cunerrt WeightElnerht 11 takg 画 W# 母 hlMnunl H you vuric m !:? ObiSet Goal!另一个Bug，是“当前体重”部分的一个拼写错误，当清空数据时会 出现拼写错误的“Enter（应用中用的是Etner），这只是一个小Bug， 但是看上去非常不专业。发现问题没有捷径，你只能反复的慢慢的试用。每个App及其团队 都会面临很多不同的挑战。但是，测试人员的典型的特点就是：超越 极限，做一些非常规的、可以改变周围事物的事情，保持长时间的测 试（测试几天、几个星期甚至几月，而不是几分钟就测完），即使明 明知道这些事情是不可能发生的。这些也正是可以找到和引出的场景 所在。4.哪儿有所有的数据？测试人员喜欢从数据上找问题，这让开发人员有时候很郁闷。事实上， 用户或者是软件开发人员在信息流中确实太容易迷惑了，因为可能会出现很多错误，所以基于数据和云的服务更为重要。也许你可以尝试在以下场景中检查出问题：移动设备数据已满；o测试人员移除了所有的数据；o测试人员删除了 App，那数据怎么办？ o测试人员删除并重装了 App，数据怎么办？ o过多或者过少的内容导致设计和布局的改变； o在不同的时间段和时区使用；o数据不同步；o同步被中断；o数据更新影响其他的服务（比如网页和云端服务）；o快速处理数据或是处理大量的数据；o使用无效的数据；o案例：Soup.me的错误o.我试用过的Soup.me，是一个可以通过地图和颜色将个人oInstagram中的照片进行分类的网页服务，但是我却没用多久。当注 册时，它提示我Instagram上的照片不够多，然而我的账号中明明有 500多张照片。我并不清楚问题出在哪儿，也许是数据问题，也许是表现层的问题，也有可能是该App出错提示的问题。Quicklytics另一个案例：上的网页分析应用。在使用过程中，尽管iPadQuickytics 是一个中删除了网站配置，但它仍然存在。Google Analytics我已经 从 这里有一些问题：我已经删除了网站配置，为什么还是有这些信 息？，那么是不是可以改该操作无法完成“”左边模块没有解释为什 么 进以避免迷惑用户呢？测试人员也很喜欢测试极限数据下的情况。他们常常是作为典型用户来了解这个App,所以极限 下的测试并不会花很长的时间。数据是混乱的，所以测试人员要考虑到软件的用户类型，以及在 不同的数据场景下如何进行测试。比如，他们可能尝试以下场景：测试用户可输入的极限值；o用重复的数据进行测试；o在全新无数据的手机里测试；o 在老手机上测试；o预先安装不同类型的数据；o考虑聚集大家的资源来进行测试；o让 一些测试自动化；o用一些超出预期的数据去测试，看它是怎么处理的；o分析信息和数据 是怎么影响用户体验的；o不管用户看到的是否正确，都要一直问问题。o5.创建出错提醒和消息这里，我不是从设计师的角度来要谈论好的错误消息的设计，而是想从用户或是测试者的角度来看这个问题。出错提醒和消息是测试人员很容易发现问题的地方。关于错误信息要问的问题：请考虑以下问题：o出错提醒的UI设计可以接受吗？ o错误信息内容可以理解吗？ o错误 信息是否保持一致？ o这些错误信息有帮助吗？ o错误信息内容是否合适？ o这些错误是 否符合惯例和标准？ o.这些错误信息本身是否安全？ o运行记录和崩溃是否能被用户和开发者获得？ o是否所有的 错误都被测试过？ o用户处理完错误信息后，将处于什么状态o是否在用户应该接受错误信息时，却没有错误信息弹出？不好或无用的出错提!错误信息会影响用户体验。然而，。虽最理想的状态是避免用户遭遇错误信息，但无处不在。这几乎不可能。出错情况的设计、实现和确认可能与预期，并能仔相反，但是，测试者往往善于发现意料外的Bug细考究是否改进它们。错误信息的案例：o这个例子。这些冗FacebookAppiPhone我非常喜欢举上o长又晦涩的文字不仅仅试图涵盖了许多不同的场景，而且 还可能无端地丢失。Tila Ei-ErHrni广ka vnts-心iu i屯s a oi onsLa-mg”“可能如下的消息提示框可以列入反例名人堂了？.W FilmMhAu M lrf*AnMErnf app frSeverui 1 .U.b is d*Hmw wilh mjxUwH.胴献向 teCbJflT H liphDlKiBmSl Mg WyM 2Mnit xju： krfdJih 3. fSXJQB AF -19,- whtch Wrts.The aW JV5! wa ikimed ati n JLdy 引 WL Rytoi?h M 网Iai 2ul-SW 2WfxliAd yH# *!命 Isig I gi-M liu! jiJiiiLly hluppvij ift* f：. NO U咬 1聘 W50 dflTil5l Nat s good naw |5 .日时卜 R by DI-id J LM； u -i T-Jj 201-2 U ;ad I上y app far 卫 yog 占cd ggt - & 二母. WNOW WI；MI I Wim Ill rril. e-igiKi (心W bjuhcd end nc rn3qc ar up derlc- rnam ttie nc-pflny 脂 vin- niwrlSo wn-vpalhBfWical a*era(ie = 2 E1ar.配(1 ,B|Lp Miniljv侦& DIE: LfakKT使口 12后，我瞬间看到了如下这个Twitter。更新并启动这个AppiPhone另外一个案例是上的你的时间线数据显示为空，你至今没有关注任何人”（但我是拥有提示语：“5年经验的活跃用户）。我担 心了一会儿，庆幸的是，这个消息很快就消失，然后加载出历史数据。VoMriimciiHJC ia ump 时I oaw*# XIlWa8.测试不是对错判断我们讨论了移动测试的一些方面，但这些前提是：带着问题，才能发 现问题。通常，测试被认为是完全合乎逻辑的、可计划的和可预测的，过程包 括：测试脚本和测试计划、通过和失败、正确和错误的反馈。走完这 些测试流程就离真相不远了。当然，如果必要，我们可以用上述方法进行测试，但这并不是测试的 目的。我们不仅是为了创建测试用例、发现Bug，更重要的是找到关 键的问题，为项目组决定什么时候发布App提供有价值的信息。而 找到那些关键问题的最好方法就是：提问！