内容来源：本文为腾讯移动分析与人人都是产品经理联合举办产品测评大赛的参赛作品。

参赛者：郑几块，人人都是产品经理的专栏作家，前新浪微博产品经理。

编辑：Fiona

本文针对腾讯移动分析(MTA)平台的用户——包括开发、产品、测试、运营、市场等人员，对平台进行可用性测试，通过整理测试过程中的发现，总结 MTA 存在的部分问题，并提出解决方案。

一、基本情况

关于 MTA

目前的 MTA，结合众多同类产品，已经是相当的完善了，这其实给可用性测试的组织，带来了不小的麻。特别是对外部人员来说，就作者自身在实施可用性测试的过程中，发现了一些问题，对测试的组织实施影响不小。

比如：

1.角色问题：我的角色以及 MTA 产品经理等人的角色不同，我很难完全站在他们的角度思考产品功能、结构和框架的问题，也很难完全理解目标市场以及用户的范畴，从而会影响测试任务的设置；

2. 范围问题：开篇提到过，目前 MTA 已经是相当完善了，如何选择测试范围，确定主功能和主任务，这就决定了测试的范围。当然，还有个前提是如何确定哪些功能是主要的。也是因为当前产品处在较成熟的阶段，不是特别好确定。

3.目标市场和用户问题：这个问题我将其排到了第三位，并不是它不重要，而是不好确定。无论是 MTA，还是同类产品，都没有一个针对开发者的分析——虽然大家都或多或少的从事和互联网相关的工作，毕竟有太多不同了。当然，你会说，即便是企业设计的领域不同，但都不可能没有开发、产品、测试、运营、市场，这我无法辩驳。不过，也有其他的思考需要重视起来，这些领域的人员，使用移动分析工具或者平台，他们的动机、行为就真的是一致的么？

关于作者

首先，接触活动的时间比较靠后了，大致是在 5 月 18 日，结合自身的情况，给用户分析整个活动和 MTA 平台，以及制定可用性测试的时间并不是太多。

即便如此，我用了大致一周的工作之余的时间，在咖啡厅、办公地点以及以一些其他场所，就 MTA 的可用性问题，做了一轮简单的测试，并对测试过程中的发现做了整理，分析出了一些问题，并且尝试提出一些解决方案，在此抛砖引玉，以飨读者。

在此，如果整篇文章，所描述的问题，有不当之处，还请批评指正。大家一起讨论，共同进步。

二、基本思路

对于整个可用性测试的实施，我大致的思路是：

1. 尝试从 MTA 相关人员的角度思考其目标市场以及用户群体，最终确定了以纯粹的互联网企业的开发、产品、测试、运营、市场等人员为主要的目标测试者；

2. 从目标测试者的角度，思考 MTA 可用性测试的主要任务，并形成一个主要任务的列表；

3.给主要任务排优先级，并从中确定部分可用来测试的任务；

4.结合场景描述任务，需要注意的是：不要在场景中提供重要的任务线索、不要让场景容易遵循、不要展示过多不必要的细节；

5.有可能的话，组合场景；这点在做的过程中，实现起来并不是特别好，因为这和我我找到的测试人员有一定关系，他们自身的指责限定了一些测试任务和具体实施过程中的细节，这个后续补充；

6. 测试、观察、总结问题、提出解决方案，最后整理部分结论形成这篇文章。

这么做，一方面能够保证针对主要功能的任务进行测试；另外一方面是，希望能够从这个过程中，了解基本的用户群体和他们对产品的理解，包括动机、目标等等；最后，如果这个思路可以的话，能够为当前产品的可用性测试，提供一个不错的思路，从而给未来的工作（给 MTA 做参考、给自己做实验案例、给大家吐槽的内容，哈哈～）打下一个不错的基础。

三、可用性测试

1. 确定目标测试者

文章前面的几个部分中都有提及，针对 MTA 做可用性测试的目标测试者包括开发、产品、测试、运营、市场等人员。但在总结过程中发现还缺少 UI&UE 等人员的参与，后续工作以及实际测试中，希望能够适当考虑这部分人员。

2. 测试主要任务

确定测试主要任务的思路是从 MTA 移动应用相关用户的角度出发，梳理主流程，确定主流程相支线任务的角度出发的。在测试准备阶段，对主要任务进行了大致如下的分类：

• 注册登录流程

• 新建应用流程

• 查找和选择（切换）应用流程

• 统计分析流程

其中，统计分析流程是重点，又分为以下几部分：

• 数据看板部分：包括新建和编辑（在应用分析中也有交叉）

• 应用分析部分：这部分是测试的重点，包括数据概览、事件、版本/渠道、用户生命周期、用户行为、用户挖掘、安装来源、借贷业务、反作弊等分析子模块

• 广告监测部分：包括概览、推广效果、推广管理等分析子模块

• 开发组件部分：包括 Crash 分析、运营工具、运维监控等子模块

• 配置管理部分：包括应用管理、接入调试、数据订阅、指标波动提醒、上报策略、用户属性配置以及到处配置等子模块

3. 主要任务优先级

当有了上面一个大致的任务列表后，通过给 1-3 的分值来给所有的任务项排优先级，这些分值表示的是任务被使用的频率。

例如：

3分表示用户经常使用该任务（高频）；

2分表示偶尔使用；

1分表示仅一次。

接下来，主要任务优先级就出来了：

• 注册登录流程 1

• 新建应用流程 1

• 查找和选择（切换）应用流程 2

• 统计分析流程 3

其中，统计分析流程部分的优先级为：

• 数据看板部分 2：包括新建和编辑（在应用分析中也有交叉）；

• 应用分析部分 3：这部分是测试的重点，包括数据概览、事件、版本/渠道、用户生命周期、用户行为、用户挖掘、安装来源、借贷业务（此部分不能体验，暂不做测试）、反作弊等分析子模块；

• 广告监测部分 3：包括概览、推广效果、推广管理等分析子模块；

• 开发组件部分 2：包括 Crash 分析、运营工具、运维监控等子模块；

• 配置管理部分 1：包括应用管理、接入调试、数据订阅、指标波动提醒、上报策略、用户属性配置以及到处配置等子模块。

在针对主要任务的优先级排序中，发现统计分析是最重要的任务，而统计分析中应用分析和广告监测部分的使用频率，不管是对哪一类用户群来说，频率都是很高的。

于是就有了针对统计分析流程的任务列表：

数据概览事件版本渠道用户生命周期用户行为用户挖掘安装来源借贷业务（此部分不能体验，暂不做测试）反作弊广告概览广告推广效果推广管理按照 1-3 的分值继续进行优先级排序，就得到了如下的优先级：

数据概览2

事件1

版本渠道3

用户生命周期3

用户行为3

用户挖掘2

安装来源2

借贷业务 3（此部分不能体验，暂不做测试）反作弊1

广告概览2

广告推广效果1

推广管理 3

于是，得到了一个高优先级的任务列表，包括：版本渠道用户生命周期用户行为借贷业务（此部分不能体验，暂不做测试）推广管理。

4. 描述任务（场景化）

现在，让我们将测试任务放到用户能够阅读、理解、遵循的场景中。记住：只要场景合适，测试才能起作用。好的场景能够帮助你测试，那就和目标受众参与测试一样。

这里有几个设计场景的规则：

• 不要在场景中提供过多的线索。必须对场景进行说明，以便清楚易懂，但必须使用通俗易懂，而不是艰深晦涩。

• 让场景容易遵循。写下你的说话方式，尽可能避免科学或学术语言。提前与朋友和同事预先测试场景，确保易于理解，人们可以毫不犹豫地遵循。（这点，在我找三五个人测试的时候，就已经有了感受，还需要不断的调整提升～）

• 去掉任何不起作用或者不必要的细节。场景为用户提供必要的上下文，并为他们提供必要的信息就够了。其他一切都是不必要的，你应该尽可能缩短你的场景。

• 减少对测试用户的引导。这一点，在之前多次测试过程中，也深有体会。减少引导，并且能够让测试用户放松，能够让你有意想不到的收获。（也是需要提升的一个方面！）

我选了优先级较高的四个任务作为主要的测试任务，但其实每个任务又可以拆分出很多细小的任务，这个在后面我会随任务说明下。

另外，在任务场景描述过程中，我没有拆分开，而是讲其他任务流程的描述一起带进来了，这样能够在用户执行并完成某一任务的同时，测试观察用户使用 MTA 的全流程。感兴趣的可以试试通过分解主任务为多个支线任务，并对支线任务进行描述后，再将支线任务组合，这样你会有一些意想不到的发现哦～（至于是什么发现，真的是仁者见仁了）

（1）版本渠道分析

想象一下，这是你第一次使用 MTA，，而且 MTA 账户是个老账户，登录成功后，你试图了解某一应用的当前版本，在应用宝一周的，针对某一用户群的数据情况，包括新增、活跃等数据的变化，并将数据导出来以供后续分析。

（2）用户生命周期分析

想象一下，这是你第一次使用 MTA，而且 MTA 账户是个老账户，登录成功后，你试图了解某一应用的当前版本，在应用宝一周的，针对某一用户群的用户活流失统计分析。

（3）用户行为分析

想象一下，这是你第一次使用 MTA，而且 MTA 账户是个老账户，登录成功后，你试图了解某一应用的当前版本，在应用宝一周的，针对某一用户群的页面访问者流的统计情况。

（4）广告监测推广管理

想象一下，这是你第一次使用 MTA，而且 MTA 账户是个老账户，你是一个 App 运营人员，你需要新建针对当前系列活动的推广计划和单元，并且在新的渠道B中进行推广，推广过程中统计记录针对这次推广统计注册数据并持续观察。

你可以按照这个思路去描述各个主要任务对应功能下的其他子模块。当然，这会是一个十分精细的过程，需要你真对目标测试者提出复核场景的问题，让他们带着一定的动机和目标去执行，不管是失败还是成功。而不是告诉他们或者问他们，你觉得这个怎么样啊，那个怎么样啊？

补充其他任务描述（部分），针对并没有针对全部任务做测试，所以也只针对有测试的部分做了任务描述，并有针对性的做了简单的测试，其他任务描述，补充如下：

（5）其他任务以及描述

5.1 注册登录流程

想象一下，你是一个 MTA 的新用户，通过朋友介绍 MTA 的优势，你打算使用 MTA 作为公司 App 的统计工具，你需要注册一个账户，才能了解 MTA。

5.2 新建应用流程

你已经注册 MTA 账户，使用账号和密码（提供账号和密码给测试者）登录成功后，你需要新建一个应用，之后把应用的 App ID 和 App Key 提供给开发。

5.3 查找和选择（切换）应用流程

你刚刚入职公司，并且使用 MTA 作为公司 20 款 App 的统计分析工具已经有 5 年以上，你负责 A 应用以及对应的业务，你想要在 MTA 中找到 A 应用，并了解应用当前的基本数据情况。（针对多业务和多产品负责人，在多个应用中的查找和切换就先的尤为重要了）

切换应用部分相关的任务，在查看应用相关的分析中需要进行测试。

5.4 数据看板

包括新建、编辑以及切换数据看板（在应用分析中也有交叉，就是添加对应的数据统计到数据看板），此部分的任务描述大致如下：在 MTA 中，通过数据看板，能够了解到 A 应用的的基本数据统计情况，不过当前的数据统计项还不能满足你的需要，你想在数据看板中看到其他相关的数据统计项。

5.5 开发组件

在 MTA 中，开发组件包括 Crash 分析、运营工具、运维监控等子模块。根据频率分值，Crash 分析的优先级最高，其次是运营工具（用户反馈），这部分的可用性测试，我只安排了针对 Crash 的测试。针对 Crash 分析任务的可用性描述大致如下：

你负责的 A 产品已经上线一周了，你想了解下该产品的 Crash 相关统计，用来协助开发定位一些问题，根据问题出现的频率，找出当前前十的问题，在下一个版本中解决并修复这些问题。

5. 测试、观察、总结、提出问题并旋球解决方案

首先说一下，针对 MTA 的测试，都是由我一个人完成的，所以消耗了比较多的时间和精力，当然，还有请客吃饭以及喝咖啡(╥╯╰╥)（不过没有那么夸张啦）。所以，我建议还是希望团队做可用性测试，而不是个人，通俗点说，人多力量大；更细一点，人多（当然不是单纯的人多）——多部门的人联合起来，对可用性测试来说是有很多帮助的，他们会从自身的角度，提出测试任务和对应的描述，也会有自己的测试方法、观察、洞见，等等。

其次，对于观察方式，我基本上采用的都是一对一座谈的方式。在描述大致的目的后，我会给测试者一到两个符合他工作职责和职能的任务。之后，就是在旁边静静地观察和记录，特别是在测试者长时间停顿，以及表情产生变化的时候。你翻看下任务描述，你会了解到，这些任务并不是一上来就直接询问他们，比如这样：

• 你登录成功后，点击“进入管理”就能够进入移动应用界面了，你觉得这个界面有什么好或者不好的地方么？

• 你在找自己负责的应用的时候有什么觉得不好的体验么？

• 你觉得新建数据看板、编辑数据看板有什么不好的体验么？

• ……

诸如此类的问题，在设置任务描述的时候，是需要极力杜绝的，那样不但给测试者极强的引导，也给了用户最初的印象，让他们没有带着通过使用 MTA 完成自己的目标去使用和体验 MTA，也会让你的测试大打折扣。

在测试者执行任务过程中有比较大的停顿的时候，我知道这会是一个比较大的可用性问题。当然，在这个时候，我就停下了测试，开始和测试者针对观察时候发现的一些问题聊一聊。

在测试过程中，发现的问题包括：

（1）找到某一应用的问题

体验活动有大量的人参与，在参与过程中，会创建相当多的应用，测试者试图找到我指定的应用，会在移动应用界面用掉一些时间。随着创建应用的数量越多，找到指定应用的时间成本会增加。如果公司的业务以及产品线较多，也会面临同样的问题——如何在较多的应用中，快速找到自己负责的产品。

思考解决的方式：

• 在移动应用界面增加应用搜索；

• MTA设置用户组，主账号可以邀请子账户，并设置子账户负责的产品。

（2）数据看板

这部分，测试过程中在新建和编辑数据看板流程上的没有发现问题。不过，在切换看板过程中，设置默认看板的能力，确是在测试了几个人之后才发现的。随后的思考，如果多人负责同一个产品的不同功能，多人查看的数据会有些许的不同，针对同一应用设置同一个看板，是不是真的可行？

针对这一点，我还没有找到一个较好的解决方式，总不能和 5.1 一样继续分账号和权限吧，那样会把整个系统搞得更加复杂。

（3）应用分析

应用分析的体验过程中，切换不同的应用分析项目以及子项目的时候，发现是整个页面刷新的。

考虑到这会带来几个问题：

• 整个页面刷新的逻辑如果是 MTA 整个网站，那会带来相当频繁的请求，会给 MTA 的后端带来不小的压力

• 由于刷新过程中会有一定的时间消耗，我发现在测试过程中，会有测试者担心由于网络不好，导致失败。

如果上面的问题假设是成立的，对应的解决方式：只刷新当前选择的项目以及项目对应的数据

（4）安装来源分析

针对这部分——需要结合广告监测-推广管理部分一起思考，问题最多的并不是可用性方面，而是 App 运营和产品提出的实际应用过程中，如何将 MTA 的统计数据与自家产品后台的统计数据结合对比的问题。这会涉及到投入产出相关的问题，也就是相关应用的推广计划、费用等等问题。

我们知道，一直以来，App 推广和实际的数据之间会有或多或少的干扰数据，App 第三方统计没有能够特别好的解决这个问题；当然，企业和产品开发团队也一直试图找到更好的解决方案。

此部分的另外一个问题，安装来源和广告监测是不是有合并的可能性？在测试讨论中发现，这两部分的性质很类似。

（5）其他发现

新建和编辑数据看板时候，添加数据报表时候的问题：1）已经添加的不能取消，2）需要添加的项目无法取消。针对 2），解决的方式：1）退出编辑，重新进来，2）选择另一个项目后取消要删除的项目。

新建和编辑数据看板时候，添加数据报表之后，如果所选的数据报表很多，“保存”和“取消”按钮需要拖动页面到顶部才能获得。这会有一定概率造成误操作，比如不小心关掉浏览器、关掉标签等等。

在某一应用切换应用时候的疑惑。“注册应用”和“我的应用”的出现，增加了切换应用操作的难度，特别是当应用的数量增加的时候，提高了误操作的概览；并且“我的应用”在 MTA 界面的右上角已经有了露出，不是特别理解，为什么还需要在当前流程中，新增“注册应用”和“我的应用”，这无疑是对当前主要操作的干扰。

属性导航折叠以及数据筛选项。当属性导航折叠起来后，数据筛选项是否可以考虑放到一行展示，那样可以增加适当的空间，展示对应的数据细节。

涉及到时间对比的数据项。是否考虑把对比项作为首要的展示数据，而不是非对比的数据。考虑这么做的主要原因是对比项数据的意义要比非对比项的要高一些。这在几次测试过程中，和测试者沟通的时候有针对这一细节进行讨论，大多数认为对比项的重要程度和意义要高。

四、测试的不足

由于可用性测试过程中存在一些制约因素，也暴露出来仓促之下的测试有一定的不足之处：

1. 测试者范围方面。在整理过程中，我发现竟然没有找到——偶遇设计mm也行啊，可惜都没有—— UI&UE 等相关人员，从他们的角度一定能够给可用性测试带来不错的反馈，从中获得更好的洞见，从而发现问题并提高 MTA。

2. 测试者人数方面。特别少，碍于工作和时间的原因，并不能找到太多的典型用户进行较好的、充分的测试。

3. 测试地点方面。大多数测试者都是在公司内部以及公司附近的互联网公司的工作人员，测试地点选在咖啡厅以及工位，并不是太严谨。

4. 测试任务的精细度方面。当前的可用性测试可是相当的粗糙，不过倒是能够获得较粗钱的反馈，也对产品有了一定的认识。时间允许的话，我希望能够更好的提高测试的精细度，包括任务、任务描述等等。

5. 问题解决方案方面。这部分也会是一个重点。因为解决方案也需要验证，但是通过测试也只能是提出解决方案，而不能重返验证方案的可行性，所以后续可能的话，在 MTA 或者其他产品上可寻找以及验证对应的解决方案，不断优化。

当然，测试过程中还暴露了一些其他问题，比如测试过程中话术、测试环境以及测试人员干扰等方面，或多或少都影响了测试的顺利进行。

五、测试优化

测试优化方面，主要是针对第四部分中的问题进行的调整和优化。在此，不做过多的描述和讲解。

六、结语

在最后，我说一下这次可用性测试的感受，主要有以下几方面：

1. 一定要在产品没有面世或者上线前充分地实施可用性测试。这次，由于一些自身因素和 MTA 产品的阶段原因，不可能从像开始一样对产品进行可用性测试，自认为做的还是相当的不充分。

2. 一定要靠团队的力量真对产品做可用性测试。单人的力量和能力是不足的，而且自己给自己的产品做测试，毕竟带有很多先入为主的观念——偏爱自己的孩子。

3. 多了解和实施可用性测试，做定性分析。不管是产品、UI&UE，还是开发、市场、测试等人员，了解和实施可用性测试，对产品以及团队能力的提升来说，都是有益处的——前提是可用性测试的方向准确。

4. 在这个过程中，我也有一定的提升，算是对可用性测试有了进一步的了解吧。

最后的最后，共勉！

获奖作品｜腾讯移动分析(MTA)可用性测试初探