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