天貓設計師為什么說不真實的產(chǎn)品測試是無效的？

王鎮(zhèn)雷：之前我寫過一篇文章《喂，你設計稿的文案和圖片都真實嗎？》，講述的是設計師在能力所及時，應該盡可能將設計稿中的所有內(nèi)容都換成真實的數(shù)據(jù)。

所謂真實的數(shù)據(jù)，包含但不限于文案、圖片、價格、品牌等。對于更復雜的需求，數(shù)據(jù)可能還會包含不同時間段時的產(chǎn)品狀況，甚至還有多個產(chǎn)品需求疊加/互斥等復合邏輯。

所以，我們在做設計方案時，除了重要場景的界面設計（正常主流程），也有相稱多時間花費在特別場景的處理（非常和分支流）。

而隨著工作涉及的產(chǎn)品越來越復雜，我越來越覺得除了真實的設計稿之外，真實的產(chǎn)品測試也是同樣緊張。

以下幾個場景，是設計師在走查開發(fā)還原度、測試產(chǎn)品流程時經(jīng)常碰到的：

一. 假的文案，假的圖片素材

一樣平常來說，文案會隨著產(chǎn)品需求一路寫在 PRD 文檔里，告訴大家在什么時候出現(xiàn)什么內(nèi)容。然后設計師會從 PRD 文檔里原封不動地把這些文案 Copy 到設計稿中（當然不負責的設計師會本身隨便編，負責的設計師還會反過來和產(chǎn)品經(jīng)理一路優(yōu)化文案）。而這些文案，其實最終還會進入到體系中，精確地展示到用戶面前。

在測試過程中，經(jīng)常由于時間關系來不及去校對所有的文案?；蛘呤怯捎谖陌笀鼍疤?，或者是由于覺得文案后面還會改，所以總是不能看到精確的文案。而當設計師提出題目時，開發(fā)也總會說「這個隨時可以改的，先不要在意這個點」。

真實線上產(chǎn)品，文案也是經(jīng)常出題目的一點——表意不清、有歧義、時間錯亂等等。圖片素材也是類似，都必要我們在前期測試中真正去跑一遍。

二. 復合產(chǎn)品分開測試，未薈萃總測

一個網(wǎng)頁里有三個新功能必要上線，最常見的測試方法是把三個功能分開自力測試。假如這三個功能不是完全隔離的，如許分開測風險就特別很是高。由于我們單獨看一個功能彷佛沒題目，但是連動查看其他功能時，可能就不是正常的場景了。

此外，即便三個功能是隔離的，我也經(jīng)常在測試中看到不應該一路出現(xiàn)的功能展示在統(tǒng)一個網(wǎng)頁里。而我們可能會給本身找托言：「先別管那個功能，正常情況下它不會出現(xiàn)」。但可能就由于你的一個疏忽，上線時用戶也會看到這些不該同時出現(xiàn)的內(nèi)容。

三. 全鏈路完備測試

和前一種情況很像，由于公司重大，所以在測試時經(jīng)常每個產(chǎn)品線單獨測試。比如首頁是一個團隊、搜索是一個團隊、用戶中間又是一個團隊，測試時大家常常只按著本身范圍內(nèi)的產(chǎn)品體現(xiàn)。

而許多產(chǎn)品功能都不會只作用于一個鏈路，每每都是由多個鏈路配合實現(xiàn)的。就拿用戶買東西來說，勢必都要經(jīng)過首頁、搜索、商品詳情、下單、購物車等等界面。而在測試時，我點擊下單之后沒有正常反饋，大家卻說是由于購物車那邊數(shù)據(jù)返回還沒做好。

所以很容易理解：產(chǎn)品的全鏈路、全場景聯(lián)合測試是多么緊張。

四. 極端非常場景未測試

正常主流程是所有人都會關注、測試的。通俗非常流也是大家會留意的。但對于一些特別很是極端、特別很是特別的場景，一來制造如許的情景比較難（技術上，特別場景的觸發(fā)條件也同樣苛刻），二來覺得這些場景出現(xiàn)概率不高，也就不是那么緊張。

舉個例子，我經(jīng)常碰到的一個非常情況是「技術接口返回非常」。常見的處理方法是做一個通用的非常彈窗，告訴用戶諸如「網(wǎng)絡被擠爆了，請稍后再試」。但現(xiàn)實上新功能測試時，照舊要驗證一下是否所有網(wǎng)絡相干的非常情況都配置了這個界面。我就見過按鈕點擊后毫無反應，或者點擊多次出現(xiàn)多次效果的情況發(fā)生。

再比如，許多產(chǎn)品狀況與數(shù)值相干：用戶的積分、等級，產(chǎn)品自己稀有量限定等等。那積分不足、等級不夠，產(chǎn)品售罄的狀況該如何處理？都是必要設計且測試的。當真實上線真正碰到題目時，要靠這些場景來救命。

五. 與時間相干的產(chǎn)品場景錯亂

以電商產(chǎn)品的大促為例，很多場景都是和時間強相干的，比如一個大促活動會在5月5日到5月15日之間進行，那么測試時，界面上所有和時間相干的數(shù)據(jù)都應該在這個時間內(nèi)。

舉個很典型的例子，倒計時類的組件就經(jīng)常在測試時發(fā)現(xiàn)錯誤，并沒有指向目標時間點，甚至展示了過期的時間「距開始」，變成「距結束」。而多個產(chǎn)品各自有本身的生命周期時，測試就會變得更加復雜，錯誤情況也會更多。

六. 多設備測試

Android 設備在整個移動端的占比高得超乎你的想象（70%+），而我們身邊絕大多數(shù)設計師和產(chǎn)品經(jīng)理都在使用 iOS 體系。我已經(jīng)見過太多次 iOS 上還原度極高的界面放在 Android 中無法直視的場景，還有許多基礎功能兩邊不同等等等。

因此，一次負責任的測試，都必須要把多個可能涉及的設備都拿出來檢查一次，盡可能使得多端體驗同等。

小結：

但越是難以檢查和測試的場景，越容易出現(xiàn)題目，也就越有需要在上線之前查看結果。當復雜時間線互相穿梭，也常出現(xiàn)不該有的內(nèi)容出如今界面上、該生效的組件沒有生效的情況。

榮幸的是，基本我碰到的開發(fā)和測試同窗都是極其負責的。假如時間充裕、大家精力足夠，測試同窗一樣平常都會根據(jù)真實情況造好測試場景，然后嚴酷對照用例一個一個去展示。

但當項目時間緊、營業(yè)復雜度高、組織內(nèi)部流程長的時候，就難以做得十全十美了。這也側面證實，需求管理和人力資源的分配，同樣極其緊張。

迎接關注作者的微信公眾號：「王鎮(zhèn)雷」