摘要: 手机、PC、网页、平板……一个产品拥有多个终端/平台的情况已经非常普遍，面临大版本时更是所有平台要同期发布，并且各个平台之间的连贯体验也越来越重要，单平台的可用性测试已经渐渐不能满足当前的需求，这里 ...
上面提到的这种情况也不是不可能发生，接需求前记得保持自己的底线： 不能在当前版本落地的缓一缓（下个版本还是未知数，也许整个特性都会被干掉，那么这次的测试就是白费功夫） 没有明显变化或改进的等一等（如果这个版本只是修复了上个版本的一些细节内容，而大的交互流程和图标体系没有变化，并且和上个版本测试出来的可用性问题无关，那么建议不要接，或者利用其他平台测试的资源顺便测试。） 对界面完全没有影响的就算了（有时会和其他产品甚至是硬件合作，如果我们无法影响到其中的界面那么就算有问题也没法改，这种情况不如不做） 保证一个主平台的基本特性不测漏，其他合理补充 虽说这奥义是哪里做完测哪里，但是也不能胡来对吧。 通常来说会放到可用性测试里去测试的特性有这么4种：  在多平台的可用性测试中，首先要选定一个主平台，保证该平台所有的基本特性不测漏，对于其他平台，有全新特性做完的平台优先测，其次是有改进后特性的，但一次测试不要超过3个平台。这样是为了让新特性有更多的试错验证机会。 重场景、轻任务，同平台放一起，跨平台看场景 场景，是对角色如何使用基于软件的产品达到自己目标的简明描述。任务，在我看来更像是对特性的包装，而这些都需要在“场景”这个大剧本下才可执行。 实际测试时我通常会让用户明白TA是谁（通常就是TA本人）现在在哪里（比如家里）要干什么（把手机里的照片存到电脑上），然后看TA如何操作就好。至于TA是不是按照理想的任务顺序来操作其实并不重要，重点是TA的目的（或者说是我们设定的目标）是否达到。如果没有达到目标，观察TA是在哪些环节出了问题导致失败即可。 至于用户通过捷径跳过设定的任务直接达成目标（或者说没有测到需要测试的特性）的情况，可以在用户达到目标后再邀请TA通过其他方式尝试。 另外值得注意的是，虽然让用户自然地操作很好，但是当平台较多的时候很可能出现手忙脚乱的情况，所以为了用户方便还是尽量要把同平台的任务编排到一起，需要跨平台的话（比如在电脑上下载了电子书传到手机上看）那就把它放在使用电脑的任务和使用手机的任务之间作为过渡，如下图示意。  疯狂鞭笞小伙伴修改问题，反复验证解决方案 测出了好多可用性问题怎么办？催着改啊！改完才能在下一轮验证解决方案对不对啊！iOS的特性A这轮出错了，下轮Android就能测改过以后的特性A啦！还有问题？那继续改啊！之后还有iPad那轮呐！（见下图）  这里需要重申一下最前面提到的一个大前提——特性在不同平台同质性高。也就是说当特性A在iOS和Android的界面基本类似的情况下为了节约时间可以用另一个平台来验证这个平台的问题，当然最好还是能在原平台进行验证啦。 把报告写给要看的人，及时跟踪落地结果 报告出来以后要让同事能看懂并且立即消化对吧，所以给不同角色看报告大概是这样的： 给老板看核心问题和主要结论； 给产品经理看问题的严重性，提供需求优先级的参考； 给设计师看具体问题发生的原因，这样设计师就可以去思考更好的解决方案，而不是粗暴地通过增加功能特性的方式来解决； 给开发看哪些问题是属于bug，可以立即修复； 另外，不同平台的负责人可能是不同的，所以最好把同一个平台的内容聚合到一起呈现。 最后来说说自己维护一个可用性问题追踪表（如下图示意）的好：  从跟踪情况看哪些问题是历史遗留并且还没有解决的，再发生类似问题就多跟相关同事聊一聊； 从特性名称看哪些任务总是完成得很差，哪些是改了以后越来越差，嗯，还是要找同事聊一聊； 从其中一个平台的问题也可以预估其他平台在做类似任务的时候可能出错的地方； 方便统计自己的落地率，总结一下经验教训； 最最好用的一点是——别人问起某平台某版本的问题时你可以瞬间把同版本不同平台/不同版本该平台的所有问题全截给TA看，如果顺便能把其他平台的同样问题或者该平台的历史遗留问题一并解决就太棒了。 唔 说了这么多不知道对大家有用么~ |
