移动应用的功能性测试和可用性测试,孰轻孰重?

(How To Decide The Strategy For Mobile App’s Functionality Testing And Usability Testing)

发表于十一月 14, 2014

 

我以前对功能性测试与可用性测试的认识

 我记得10年以前还在华为做测试的时候,功能测试是我工作的主体,也是绝大多数测试人员工作的重心。毕竟,功能都有问题的软件,怎么能算得上质量好的软件呢?我们不仅关注功能的正确性、还关注功能的完整性;不仅关注基本功能的测试、还关注各种复杂的功能交互场景的测试。一旦发现严重或致命类的功能性bug,比如导致系统死机或重启,测试人员如获至宝,开发人员、测试人员等所有角色都高度重视,一起复现bug、解决bug。

 

相比而言,Usability Testing,易用性测试或可用性测试(本文对易用性测试和可用性测试,不作严格的区分),上上下下关注的都比较少了。比如,我们虽然知道影响用户满意度的一个很重要的方面是用户手册的质量,可是没有人愿意在用户手册或其他资料的测试上浪费时间。毕竟,在测试人手紧张的情况下,还有太多严重的功能性bug等待我们去发现,哪有时间做资料测试呢?

 

于是,无论从测试顺序的安排上、还是从测试资源的投入上,功能性测试在先、可用性测试在后,似乎成了我们默认的测试策略。


移动应用的质量属性

移动互联网大潮来袭,我成了名副其实的移动App的用户,鉴于“所有用户都默认也是测试人员”这个事实,我也一直在测试着Mobile App,我发现功能性测试和可用性测试二者的地位有些变化了。不仅思考,作为移动应用的测试人员,该如何平衡功能性测试和可用性测试,制定合适的测试策略呢?

 

在讨论这个问题之前,先要说明,移动应用的质量属性当然不仅仅包括功能性和可用性,只不过本文更着重讨论功能性和可用性之间的关系以及相应的测试策略问题而已。

 

James BachHeuristic Testing Strategy Model里提到的各种质量属性,对每一个软件来说都可能要涉及到:CRUSSPIC STMPL,我们这里谈的功能性和可用性对应到HTSM里的CCapability)和 UUsability),其他的还包括RReliability)、SSecurity)、SScalability)、PPerformance)、IInstallability)和CCompatibility)等。对于每个软件而言,都要根据自身的特点以及软件项目上下文,选择和关注特定的质量属性、确定合适的质量属性测试策略。

 

那么,对于移动App而言,哪些质量属性是非常重要的呢?

 

现在不妨拿出您的手机,解锁屏幕,看看屏幕上这些五彩缤纷的Mobile App的图标,您对这些App的期望或要求是什么?您是为了某一目的才安装了这App,功能性是默认要关注的质量属性,可是,除此以外呢,想一想您最关注什么?

 

对我而言,我把最关注的质量属性简称为SUP(Security、Usability、Performance)。我希望我所选择的App安全、易用、够快。如果您去App Store里的用户评论区查一查,就会发现SUP也是用户经常抱怨的内容。

 

安全性是非常重要的,因为这些App所赖以存在的环境-我的智能手机,已经是我的必不可少的非常重要的私人物品了,它承载了我的工作、生活、娱乐等方方面面,安全可靠是第一位的。有一次我去某家咖啡厅,边工作边品尝咖啡,过了一段时间,突然发现手机不见了,心理陡然紧张起来,后果简直不敢想象啊,我翻遍了所有的口袋,最后把希望寄托给“忘在家里了”。于是,再也没有心思继续品尝咖啡和看书,立即驶回家里。可见现在的智能手机已经不仅仅是一部手机那么简单了,如若哪个App敢冒天下之大不韪,在安全性方面让用户好看,一定是下下之策。

 

再说性能方面。现在的人都非常忙,这意味着很少能够对一件事情或一个东西有过长时间的等待,我下载了一款游戏App,点开它以后,加载非常慢,界面上只有一个进度条,接近结尾的时候就长时间停在那里,漫长的等待后终于进到游戏界面,倒是很炫,又是声音又是动画。下一次再想玩的时候,点击App图标,再一次陷入了等待,于是毫不犹豫,立马删除之。最近玩的一款“1+2=3”的小游戏也存在性能问题,当玩家得了比较高的分数,这通常意味着已经玩至少1个小时以上了,此时划屏操作变得很慢很笨拙,玩家好不容易到达这么高分的状态,却发现游戏已经变得“岌岌可危”,仿佛随时有可能葬送掉这次难得的高分经历,这使我决定立即找寻另外一款类似的游戏对比一下(用户已经有逃离的想法了)。

 

可见,安全性和性能已经是移动App的“刚需”属性,这是bottom line,必须满足,网上有很多讨论与此内容相关的文章,读者不妨搜索一下,接下来我们重点看看移动应用的功能性测试和可用性测试。


移动应用的功能性测试和可用性测试

如果您的移动App给用户提供的价值(满足用户的需求)是独一无二的,那么恭喜您,您没有竞争对手,也没有太大的压力来反复斟酌“到底功能性测试和可用性测试做到什么程度算合适的?”

 

可遗憾的是,这是一个用户选择过剩的时代,产品的竞争日益剧烈,用户的选择极大丰富,测试的时间更是短暂而紧促,所以选择一个适当的功能性和可用性测试策略就显得很重要了。

 

尽管关于功能性测试和可用性测试都有很多种定义,我更喜欢用简单一点的方式来讨论它们。移动App所要满足的用户需求,是其核心的价值 – Core Value,这是个what的问题,也就是功能性测试要关注的重点(也许FunctionalityCapability有细微的差别,但在本文中将忽略这些差别,不作区分);除此以外,如何去实现这些需求,这其实是个how的问题,在每一个细微环节,我们都期望用最能吸引用户的方式去实现,这是可用性测试要关注的。

 

相对于传统的WEB或桌面应用而言,移动App的功能性的地位发生了一些变化。功能的正确性和完整性依然是最基础而重要的,毕竟这是用户购买App的目的,帮助用户完成想要完成的事情,如果这一点都做不到,那用户绝对是“删你没商量”。但是对于复杂的功能交互的场景出现的问题,用户却表现了极高的容忍度,甚至对于那种比较严重的重启或者闪退问题,只要不是频繁出现,用户也表现得比较大度。我想主要原因有二:一是如果用户同时做了很多复杂的操作,一边玩着游戏、一边听着音乐、一边回复消息、一边处理一些弹出事件。。。,即使出现了异常,用户也是可以理解的,大不了在重新来过;二是由移动App整体的质量水平决定的,在使用很多App的时候都出现过程序莫名其妙地就退出了、或者iPad突然黑屏自动重启了,这都成了司空见惯的现象。只不过与PC时代表现不同的是,移动App这些严重的bug会第一时间从用户眼前消失,会尽快让用户继续完成想要做的事情,让用户尽快地忘记这些bug,好像他们从来就不曾来过一样!(想一想PC的软件,您遭遇过多少回错误提示框,它们通常在醒目的位置告诉您:“嗨,我有bug了!!!想了解详细信息,请点击。。。,您需要。。。的步骤来处理。。。。”)

 

所以,从功能上很难将多款相似的App区分开层次来,这时可用性就得登场了。比如在App Store里能找到很多款“以2的幂次方拼成2048”这样的小游戏,它们的功能相差无几,但是实现的方式包括用户可能的设置、界面的展示形式、游戏的进入与退出等等都不尽相同,当每一种设计有不止一种方案可供选择的时候,就要考虑下可用性的问题了。现在为了提升用户体验,有专门的用户体验设计师,并且从业务人员到产品经理到开发人员等各角色都在关注用户的体验,有时会先选择一种方案(或者两套A/B方案)先提供给部分用户使用,收集用户的反馈,再不断修正,以达到用户体验最佳。在这个过程中,测试人员可以扮演很积极的角色,在设计阶段提供很多有价值的意见和建议,在事后分析性的活动中也可以发现很多可用性相关的缺陷,从而为提升产品的质量做出贡献。

 

移动应用的功能性和可用性测试策略

应该设定什么样的移动App功能性和可用性测试策略?简单点回答就是没有统一的、标准的答案,您需要考虑产品当前所在的上下文。

 

Geoffrey MooreCrossing the Chasm书中曾描述过一个好的产品或思想传播的模型,或者用户增长的模型(Moore’s Idea Diffusion Curve),见下图。若该App当前处于Early Adopters时期,仅有少量早期的用户在使用,什么样的测试策略比较合适呢?也许你们处于团队初创时期,还你们没有专门的用户体验工程师,也许只有您一名测试人员,你们已经经过了几轮的测试并且产品已经推向了市场赢得了一些用户。。。(是的,我在假设所有可能的测试上下文,这些因素加在一起才能确定一个测试策略,您可用借鉴James BachHTSM模型中的Project Environment部分CIDTESTD的启发式方法进一步探究您所在项目的上下文),那我建议您花少部分精力验证核心的基本功能(这些功能一直处于不断变化中),重点关注可用性测试,挖掘那些能让用户眼前一亮的点,通过与其他App的对比测试发现自身产品的不足,通过收集用户的反馈发现可用性方面的问题,通过角色扮演和测试人员的耐心细心发现那些影响用户使用感受的问题。因为,如果希望产品成功的从Early Adopters走向Early Majority阶段,您很有可能需要借助社交媒体中用户的口碑传播或者是App Store中来自用户的好评,而只有让用户眼前一亮的产品才能得到用户的好评和口口相传。

 

PeppersRogersThe One to One Future中将用户分为四类,潜在用户(Prospects)、一般用户(Customers)、忠实用户(Loyal Customers)和曾经的用户(Former Customers)。忠实用户即铁杆粉丝,是愿意付费进行购买的用户,像前面提到的“1+2=3”(也叫“奇妙的3”)的小游戏在玩家玩到1个小时以上出现的性能问题就是在伤害其忠实用户的心(普通用户谁会玩那么久呢),也是在减弱自身的营收啊!

 

我们不妨结合用户类型在四象限中分析下移动App的功能性和易用性所产生的影响。

 

在“所满足的用户的需求”即“待实现的功能”是一定的情况下,横轴表示产品功能性的质量属性达成情况,纵轴表示产品可用性的质量属性达成情况,在进一步讨论之前,首先要注意到两点:

  1. 质量属性的达成情况更多的是基于主观的评估进行,并不存在一个神奇的checklist,基于此逐项检查就能得出准确的评估结果了;
  2. 达成情况的起点为“一般”,在“一般”以下的是糟糕的产品、或者还未上市的产品,大体上应该还未能进入App Store,尚未拥有实际的用户,比如处于开发阶段的产品,基本功能还没有实现正确呢,就赶紧进行功能性测试吧,在这个时候如果更多的追求可用性测试,就像一个小孩还未学会走路呢,就先学如何跳舞了是一样的道理。但这并不表示可用性测试的关注度就是0,我们知道,有些可用性的问题有可能涉及到整体架构的变动,越早发现越有利。

 

先来看第一和第三象限:

第一象限,功能性和可用性均为好,这是优秀的产品,它的忠实用户数会不断增长,这个象限也是所有App追逐的目标;

第三象限,功能性和可用性均一般,这不是一般的产品,当周围的App质量都比你好的时候,这就属于差的产品了,如果仍然不改进的话,会不断有用户放弃使用您的产品,成为曾经的用户。至于是在可用性测试方面加强,还是在功能性测试方面加强,还是二者同时发力,就得看测试所在的上下文了。

 

再来看第二和第四象限:

第二象限,功能性表现平平,使用过程中偶尔某些功能存在缺陷,但是可用性表现突出,这已经初步赢得了用户的芳心,可以归为好的产品,但是拥有的更多的是一般的用户,要想将一般用户转化为付费的忠实用户,还得努力改善其瑕疵,向第一象限努力。 最近在iPad上使用的PDF Reader被我归到了这个象限,其核心功能就是阅读PDF文件,但是用户可以像阅读纸质书一样边阅读边做标记,可用性大大提高(您也可以认为这属于功能性需求):希望将某一段文字标记为波浪线、高亮显示或者底部标横线的话,只要选中图标后,用手指清扫相应的文字即可。用户还可以在页面任意地方做笔记,输入想说的话。可是使用过程中发现一些缺陷,比如添加笔记时,竟然不支持复制、粘贴、鼠标移动等功能,因为只要手指在笔记处一点,就退出编辑状态,变为选中整个笔记的状态,这种设计很显然没有考虑到移动设备这种特有的输入方式。再比如,当连续翻过数页时,该App会有闪退现象。另外一个比较懊恼的功能是广告功能,每当使用一段时间,出现广告的页面,这对于HD版本的App来说很正常,但是设计人员好像有意在关闭广告的叉叉符号上做了点文章,起初我点击多次,界面没有任何反映,我甚至怀疑iPad已死机或者手势不能识别了,结果点击多次以后,叉叉符号突然亮了一下,然后广告页面终于成功关闭了。这种设计站在广告商这种客户的角度讲确实很好,但是站在使用者的角度讲,却是败笔了。作为用户,再没有找到更好的App之前,我还会继续使用它,也就是说我有可能从一般用户变为它的曾经用户;但另一方面,如果它能改进这些瑕疵,变得更好用一些,再增加些亮点功能,我也很有可能从一般用户变为忠实的用户。

第四象限,可用性表现平平,功能性表现突出,使用过程中基本没有什么问题,用户能够完成他想要完成的事情(也许不那么顺利),这属于一般的产品,拥有的也更多是一般的用户。一款叫做iExplainApp被我归为了此类,这是一款付费产品,通过阅读软件介绍,发现其功能强大,正好满足我的需要,于是购买了下来,可是使用过程中发现可用性不是很好,使用了数次有些功能仍然不是很清楚如何操作,文档目录的设置也显得有些乱,总之离“易学习、易理解、易操作”还有不小的距离。可见,此时的当务之急是改进其可用性,否则现有的“一般的用户”会不断转变为“曾经的用户”。

 

从以上的分析中不难看出,

功能性质量属性达成度高,能让您的App不至于太差;

可用性质量属性达成度高,能让您的App更有吸引力、更具创新性、比竞争者更具优势;

功能性和可用性质量属性达成度都很高的产品(加上之前提到的SUP),造就优秀App

 

结论

很遗憾,我仍然无法给您提供一套准确的标准来制定准确的移动应用功能性测试和可用性测试策略,事实上,我从来不认为存在这样的标准,毕竟,这和具体的测试上下文有很大关系。

  • 对于移动应用,除功能性外,重点关注SUPSecurityUsabilityPerformance)这些刚需属性;
  • 移动应用的核心价值Core Value,“基本功能的正确性和完整性”测试属于必选项,而复杂的功能交互场景测试属于可选项;
  • 确保严重的功能性缺陷比如重启或闪退不要出现得过于频繁,并且让这样的缺陷尽快消失在用户的视野中,注重软件的自愈设计;
  • 当每一种设计有不止一种方案可供选择的时候,就涉及到可用性测试的问题;
  • 应该设定什么样的移动App功能性和可用性测试策略,没有统一的、标准的答案,需要考虑产品当前所在的上下文;
  • 功能性质量属性达成度高,能让您的App不至于太差;
  • 可用性质量属性达成度高,能让您的App更有吸引力、更具创新性、比竞争者更具优势;
  • 功能性和可用性质量属性达成度都很高的产品(加上之前提到的SUP),造就优秀App
  • 在考虑测试上下文时,不妨参考下本文提到的移动应用功能性可用性四象限图。
Comment Box is loading comments...