手機、PC、網頁、平板……一個產品擁有多個終端/平臺的情況已經非常普遍，面臨大版本時更是所有平臺要同期發布，并且各個平臺之間的連貫體驗也越來越重要，單平臺的可用性測試已經漸漸不能滿足當前的需求，這里就跟大家探討下面對多平臺的可用性測試需要注意的內容。

（以下故事純屬為了奠定全文喜劇色彩和夸張手法，和真實產品沒有半毛錢關系。）

用戶研究員老王最近遇到了一件煩心事，TA負責的某產品過倆月要發個大版本，瞅了眼項目經理發的周報，六個平臺還要同步發?。I導再也不擔心老王的工作不飽和了）看來各平臺的可用性測試跑不掉了，老王掐指一算：

我們這個狂霸酷拽的產品共有6個平臺；這個新版本共有3個新特性和5個基本特性需要測試；各平臺是分開研發的，所以每個特性完成的時間點不一樣；

那么項目進度表有可能是以下這樣喪盡天良的：（以下表格純屬虛構）

?

所以：
等單一平臺的所有特性開發完成后按平臺測試是來不及的！
等單一特性在所有平臺開發完成后按特性測試也是不可能的！

這可把老王愁壞了，碩果僅存的幾縷頭發也要被薅（hao一聲）光了。
老王不用怕！小天使偷偷告訴你一個秘訣——

?

已經翻了白眼的稍安勿躁，這樣放蕩不羈的前提條件是：
1. 平臺多；
2. 發布時間集中；
3. 特性在不同平臺同質性高。

至于好處則是：
1. 減少可用性測試的次數；
2. 增加驗證解決方案的輪數；
3. 預測并避免同類問題在不同平臺重復出現。

那么具體執行與常規的可用性測試有什么不同呢：

接需求前切記保持底線

首先給大家講個小故事：

其實只是多問一句的事兒：

上面提到的這種情況也不是不可能發生，接需求前記得保持自己的底線：

• 不能在當前版本落地的緩一緩（下個版本還是未知數，也許整個特性都會被干掉，那么這次的測試就是白費功夫）
• 沒有明顯變化或改進的等一等（如果這個版本只是修復了上個版本的一些細節內容，而大的交互流程和圖標體系沒有變化，并且和上個版本測試出來的可用性問題無關，那么建議不要接，或者利用其他平臺測試的資源順便測試。）
• 對界面完全沒有影響的就算了（有時會和其他產品甚至是硬件合作，如果我們無法影響到其中的界面那么就算有問題也沒法改，這種情況不如不做）

保證一個主平臺的基本特性不測漏，其他合理補充

雖說這奧義是哪里做完測哪里，但是也不能胡來對吧。
通常來說會放到可用性測試里去測試的特性有這么4種：

?

在多平臺的可用性測試中，首先要選定一個主平臺，保證該平臺所有的基本特性不測漏，對于其他平臺，有全新特性做完的平臺優先測，其次是有改進后特性的，但一次測試不要超過3個平臺。這樣是為了讓新特性有更多的試錯驗證機會。

重場景、輕任務，同平臺放一起，跨平臺看場景

場景，是對角色如何使用基于軟件的產品達到自己目標的簡明描述。任務，在我看來更像是對特性的包裝，而這些都需要在“場景”這個大劇本下才可執行。

實際測試時我通常會讓用戶明白TA是誰（通常就是TA本人）現在在哪里（比如家里）要干什么（把手機里的照片存到電腦上），然后看TA如何操作就好。至于TA是不是按照理想的任務順序來操作其實并不重要，重點是TA的目的（或者說是我們設定的目標）是否達到。如果沒有達到目標，觀察TA是在哪些環節出了問題導致失敗即可。

至于用戶通過捷徑跳過設定的任務直接達成目標（或者說沒有測到需要測試的特性）的情況，可以在用戶達到目標后再邀請TA通過其他方式嘗試。

另外值得注意的是，雖然讓用戶自然地操作很好，但是當平臺較多的時候很可能出現手忙腳亂的情況，所以為了用戶方便還是盡量要把同平臺的任務編排到一起，需要跨平臺的話（比如在電腦上下載了電子書傳到手機上看）那就把它放在使用電腦的任務和使用手機的任務之間作為過渡，如下圖示意。

?

瘋狂鞭笞小伙伴修改問題，反復驗證解決方案

測出了好多可用性問題怎么辦？催著改?。「耐瓴拍茉谙乱惠嗱炞C解決方案對不對??！iOS的特性A這輪出錯了，下輪Android就能測改過以后的特性A啦！還有問題？那繼續改??！之后還有iPad那輪吶！（見下圖）

?

這里需要重申一下最前面提到的一個大前提——特性在不同平臺同質性高。也就是說當特性A在iOS和Android的界面基本類似的情況下為了節約時間可以用另一個平臺來驗證這個平臺的問題，當然最好還是能在原平臺進行驗證啦。

把報告寫給要看的人，及時跟蹤落地結果

報告出來以后要讓同事能看懂并且立即消化對吧，所以給不同角色看報告大概是這樣的：
給老板看核心問題和主要結論；
給產品經理看問題的嚴重性，提供需求優先級的參考；
給設計師看具體問題發生的原因，這樣設計師就可以去思考更好的解決方案，而不是粗暴地通過增加功能特性的方式來解決；
給開發看哪些問題是屬于bug，可以立即修復；
另外，不同平臺的負責人可能是不同的，所以最好把同一個平臺的內容聚合到一起呈現。

最后來說說自己維護一個可用性問題追蹤表（如下圖示意）的好：

從跟蹤情況看哪些問題是歷史遺留并且還沒有解決的，再發生類似問題就多跟相關同事聊一聊；
從特性名稱看哪些任務總是完成得很差，哪些是改了以后越來越差，嗯，還是要找同事聊一聊；
從其中一個平臺的問題也可以預估其他平臺在做類似任務的時候可能出錯的地方；
方便統計自己的落地率，總結一下經驗教訓；
最最好用的一點是——別人問起某平臺某版本的問題時你可以瞬間把同版本不同平臺/不同版本該平臺的所有問題全截給TA看，如果順便能把其他平臺的同樣問題或者該平臺的歷史遺留問題一并解決就太棒了。

唔 說了這么多不知道對大家有用么~