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