手机、PC、网页、平板……一个产品拥有多个终端/平台的情况已经非常普遍，面临大版本时更是所有平台要同期发布，并且各个平台之间的连贯体验也越来越重要，单平台的可用性测试已经渐渐不能满足当前的需求，这里就跟大家探讨下面对多平台的可用性测试需要注意的内容。
（以下故事纯属为了奠定全文喜剧色彩和夸张手法，和真实产品没有半毛钱关系。）
用户研究员老王最近遇到了一件烦心事，TA 负责的某产品过俩月要发个大版本，瞅了眼项目经理发的周报，六个平台还要同步发！（领导再也不担心老王的工作不饱和了）看来各平台的可用性测试跑不掉了，老王掐指一算：
我们这个狂霸酷拽的产品共有 6 个平台；
这个新版本共有 3 个新特性和 5 个基本特性需要测试；
各平台是分开研发的，所以每个特性完成的时间点不一样；
那么项目进度表有可能是以下这样丧尽天良的：（以下表格纯属虚构）
所以：
等单一平台的所有特性开发完成后按平台测试是来不及的！
等单一特性在所有平台开发完成后按特性测试也是不可能的！
这可把老王愁坏了，硕果仅存的几缕头发也要被薅（hao 一声）光了。
老王不用怕！小天使偷偷告诉你一个秘诀——
已经翻了白眼的稍安勿躁，这样放荡不羁的前提条件是：
1. 平台多；
2. 发布时间集中；
3. 特性在不同平台同质性高。
至于好处则是：
1. 减少可用性测试的次数；
2. 增加验证解决方案的轮数；
3. 预测并避免同类问题在不同平台重复出现。
那么具体执行与常规的可用性测试有什么不同呢：
首先给大家讲个小故事：
其实只是多问一句的事儿：
上面提到的这种情况也不是不可能发生，接需求前记得保持自己的底线：
虽说这奥义是哪里做完测哪里，但是也不能胡来对吧。
通常来说会放到可用性测试里去测试的特性有这么 4 种：
在多平台的可用性测试中，首先要选定一个主平台，保证该平台所有的基本特性不测漏，对于其他平台，有全新特性做完的平台优先测，其次是有改进后特性的，但一次测试不要超过 3 个平台。这样是为了让新特性有更多的试错验证机会。
场景，是对角色如何使用基于软件的产品达到自己目标的简明描述。任务，在我看来更像是对特性的包装，而这些都需要在“场景”这个大剧本下才可执行。
实际测试时我通常会让用户明白 TA 是谁（通常就是 TA 本人）现在在哪里（比如家里）要干什么（把手机里的照片存到电脑上），然后看 TA 如何操作就好。至于 TA 是不是按照理想的任务顺序来操作其实并不重要，重点是 TA 的目的（或者说是我们设定的目标）是否达到。如果没有达到目标，观察 TA 是在哪些环节出了问题导致失败即可。
至于用户通过捷径跳过设定的任务直接达成目标（或者说没有测到需要测试的特性）的情况，可以在用户达到目标后再邀请 TA 通过其他方式尝试。
另外值得注意的是，虽然让用户自然地操作很好，但是当平台较多的时候很可能出现手忙脚乱的情况，所以为了用户方便还是尽量要把同平台的任务编排到一起，需要跨平台的话（比如在电脑上下载了电子书传到手机上看）那就把它放在使用电脑的任务和使用手机的任务之间作为过渡，如下图示意。
测出了好多可用性问题怎么办？催着改啊！改完才能在下一轮验证解决方案对不对啊！iOS 的特性A这轮出错了，下轮 Android 就能测改过以后的特性A啦！还有问题？那继续改啊！之后还有 iPad 那轮呐！（见下图）
这里需要重申一下最前面提到的一个大前提——特性在不同平台同质性高。也就是说当特性A在 iOS 和 Android 的界面基本类似的情况下为了节约时间可以用另一个平台来验证这个平台的问题，当然最好还是能在原平台进行验证啦。
报告出来以后要让同事能看懂并且立即消化对吧，所以给不同角色看报告大概是这样的：
给老板看核心问题和主要结论；
给产品经理看问题的严重性，提供需求优先级的参考；
给设计师看具体问题发生的原因，这样设计师就可以去思考更好的解决方案，而不是粗暴地通过增加功能特性的方式来解决；
给开发看哪些问题是属于 bug，可以立即修复；
另外，不同平台的负责人可能是不同的，所以最好把同一个平台的内容聚合到一起呈现。
最后来说说自己维护一个可用性问题追踪表（如下图示意）的好：
从跟踪情况看哪些问题是历史遗留并且还没有解决的，再发生类似问题就多跟相关同事聊一聊；
从特性名称看哪些任务总是完成得很差，哪些是改了以后越来越差，嗯，还是要找同事聊一聊；
从其中一个平台的问题也可以预估其他平台在做类似任务的时候可能出错的地方；
方便统计自己的落地率，总结一下经验教训；
最最好用的一点是——别人问起某平台某版本的问题时你可以瞬间把同版本不同平台/不同版本该平台的所有问题全截给 TA 看，如果顺便能把其他平台的同样问题或者该平台的历史遗留问题一并解决就太棒了。
唔说了这么多不知道对大家有用么~
相关文章