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