上面提到的這種情況也不是不可能發生，接需求前記得保持自己的底線：
不能在當前版本落地的緩一緩（下個版本還是未知數，也許整個特性都會被干掉，那么這次的測試就是白費功夫）
沒有明顯變化或改進的等一等（如果這個版本只是修復了上個版本的一些細節內容，而大的交互流程和圖標體系沒有變化，并且和上個版本測試出來的可用性問題無關，那么建議不要接，或者利用其他平臺測試的資源順便測試。）
對界面完全沒有影響的就算了（有時會和其他產品甚至是硬件合作，如果我們無法影響到其中的界面那么就算有問題也沒法改，這種情況不如不做）
保證一個主平臺的基本特性不測漏，其他合理補充
雖說這奧義是哪里做完測哪里，但是也不能胡來對吧。
通常來說會放到可用性測試里去測試的特性有這么4種：
在多平臺的可用性測試中，首先要選定一個主平臺，保證該平臺所有的基本特性不測漏，對于其他平臺，有全新特性做完的平臺優先測，其次是有改進后特性的，但一次測試不要超過3個平臺。這樣是為了讓新特性有更多的試錯驗證機會。
重場景、輕任務，同平臺放一起，跨平臺看場景
場景，是對角色如何使用基于軟件的產品達到自己目標的簡明描述。任務，在我看來更像是對特性的包裝，而這些都需要在“場景”這個大劇本下才可執行。
實際測試時我通常會讓用戶明白TA是誰（通常就是TA本人）現在在哪里（比如家里）要干什么（把手機里的照片存到電腦上），然后看TA如何操作就好。至于TA是不是按照理想的任務順序來操作其實并不重要，重點是TA的目的（或者說是我們設定的目標）是否達到。如果沒有達到目標，觀察TA是在哪些環節出了問題導致失敗即可。
至于用戶通過捷徑跳過設定的任務直接達成目標（或者說沒有測到需要測試的特性）的情況，可以在用戶達到目標后再邀請TA通過其他方式嘗試。
另外值得注意的是，雖然讓用戶自然地操作很好，但是當平臺較多的時候很可能出現手忙腳亂的情況，所以為了用戶方便還是盡量要把同平臺的任務編排到一起，需要跨平臺的話（比如在電腦上下載了電子書傳到手機上看）那就把它放在使用電腦的任務和使用手機的任務之間作為過渡，如下圖示意。
瘋狂鞭笞小伙伴修改問題，反復驗證解決方案
測出了好多可用性問題怎么辦？催著改啊！改完才能在下一輪驗證解決方案對不對啊！iOS的特性A這輪出錯了，下輪Android就能測改過以后的特性A啦！還有問題？那繼續改啊！之后還有iPad那輪吶！（見下圖）
這里需要重申一下最前面提到的一個大前提——特性在不同平臺同質性高。也就是說當特性A在iOS和Android的界面基本類似的情況下為了節約時間可以用另一個平臺來驗證這個平臺的問題，當然最好還是能在原平臺進行驗證啦。
把報告寫給要看的人，及時跟蹤落地結果
報告出來以后要讓同事能看懂并且立即消化對吧，所以給不同角色看報告大概是這樣的：
給老板看核心問題和主要結論；
給產品經理看問題的嚴重性，提供需求優先級的參考；
給設計師看具體問題發生的原因，這樣設計師就可以去思考更好的解決方案，而不是粗暴地通過增加功能特性的方式來解決；
給開發看哪些問題是屬于bug，可以立即修復；
另外，不同平臺的負責人可能是不同的，所以最好把同一個平臺的內容聚合到一起呈現。
最后來說說自己維護一個可用性問題追蹤表（如下圖示意）的好：
從跟蹤情況看哪些問題是歷史遺留并且還沒有解決的，再發生類似問題就多跟相關同事聊一聊；
從特性名稱看哪些任務總是完成得很差，哪些是改了以后越來越差，嗯，還是要找同事聊一聊；
從其中一個平臺的問題也可以預估其他平臺在做類似任務的時候可能出錯的地方；
方便統計自己的落地率，總結一下經驗教訓；
最最好用的一點是——別人問起某平臺某版本的問題時你可以瞬間把同版本不同平臺/不同版本該平臺的所有問題全截給TA看，如果順便能把其他平臺的同樣問題或者該平臺的歷史遺留問題一并解決就太棒了。
唔 說了這么多不知道對大家有用么~