本節書摘來自華章計算機《web測試囧事》一書中的第3章，第3.2節，作者 黃勇 雷輝 徐潇 楊雪敏，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。
設計師做好的ui設計稿為什麼還要做測試呢？因為測試可以讓我們最直接、最有效地洞察産品在使用者行為、界面可能性、使用者期望與功能契合度等方面的綜合表現。那作為一名測試工程師，在拿到卡中的設計稿後，需要進行哪些方面的測試呢？正好，小蔡剛剛接手一項關于ui設計稿的測試工作，我們一起來看看她會怎麼做。
小蔡所在項目組使用的是靈活開發流程，測試人員參與研發各個環節的讨論，同時提供測試思路，以便項目組其他成員打開思路。一般流程是，當開發人員根據優先級在backlog挑了一張使用者故事卡正式編碼前，會和項目相關成員，如需求分析（ba）、開發、測試，甚至産品經理和使用者體驗設計（ux）等一起進行kick off來确認所有需求細節。這時候就需要測試人員從測試角度提出一些建議來幫助開發人員在後期的編碼中進行自測，這些建議包括是否有未覆寫到的異常路徑/場景、如何測試這張卡、研發的實作方案可測性如何等。經過讨論，還可以幫助小夥伴們打開腦洞，引出更多更新的想法。
下面就是小蔡關于測試ui設計稿的思路。
思路1 ：頁面效果（見圖3-2）。
首先，小蔡要檢查ux設計師是否給出了字型、字号、行高、圖檔透明度、邊緣空白等具體内容或數值。這是因為在網頁開發過程中這些内容或數值對最終顯示效果均有一定的影響，是以測試時必須考慮設計稿中是否提供出具體内容和資料，以保證最終的顯示效果與設計稿一緻。而小蔡目前所在的項目組設計師在使用zeplin工具進行設計時都能給出一些具體資料，以便測試人員和開發人員進行測試開發。
那除了這些關系到頁面效果的細節，還應該關注/測試哪些呢？小蔡左思右想還是沒有頭緒。于是跑來找老牛讨思路，老牛給她的建議是多關注變化點，例如背景動态變化的資料如何顯示在界面中，以及頁面是否是responsive（響應式）頁面，如果是的話，還需要看頁面元素在不同尺寸的螢幕顯示是否正确。
思路2：ui設計圖是否适用于具體螢幕尺寸。
小蔡在kick off卡時還需要觀察設計人員是否提供了針對不同裝置螢幕的設計圖，并且每種設計是否合理，是否友善使用者使用。這與小蔡平時工作中勤于使用各種軟體是離不開的。通過橫向對比各軟體的使用體驗，小蔡能夠針對不同螢幕迅速而準确地提出建議。
小蔡目前所在的項目使用了responsive頁面技術，此技術的一個顯著特性是頁面會根據客戶的浏覽器尺寸定制顯示頁面元素，給使用者提供最佳的使用體驗。例如平闆電腦的螢幕較大，可顯示比較多的内容，但會要求功能按鈕或者連結友善使用者用手去點中。而手機屏較小，同樣要求按鈕的大小要友善使用者用手指可以很容易地去點中，同時可能需要改變一些界面元件的顯示位置或大小，删除或增加一些更适宜的元件。是以如果設計師的設計稿隻對應寬度600～800px的螢幕，小蔡就需要考慮當螢幕變小或者變大後，界面元素的排列是否友善使用者使用。
又如，界面上有100個字元的文本，在浏覽器最大化時顯示完全正常，但是當浏覽器縮小為iphone 4的寬度後，是否需要進行折行顯示？可是折行顯示會破壞界面上各元件之間顯示的相對位置。那麼這100個字元是否需要自動截斷或者省略部分内容，如顯示為“今天……”嗎？ 這些問題都是一些很好的思路，需要小蔡和設計人員讨論如何進行是最優的。
思路3：重點關注背景資料變化動态影響界面顯示。
圖3-3界面中的文本都是從背景資料庫中動态讀取的，如果資料庫中的字元串非常長，該如何顯示呢？例如“cbd商圈”變成長字元串後，是折行還是加省略号？有時在字元串變長後，會和其他文本顯示區域重疊，頁面也是以會變得不美觀。又如“視野寬廣”是從資料庫讀取字元串的，如果這個字元串是空字元串該怎麼處理，是留着空白的一列還是這一行從四列變為三列呢？
再比如，圖3-4的兩個按鈕是根據資料庫中的資料動态生成的，可能是一個按鈕，也可能是多個。如果是多個并且超出螢幕的寬度，需要做折行處理，還是讓每行顯示多個按鈕，這都不可能在初版設計稿中全部展現，是以就需要小蔡根據自己的測試常識與業務人員和設計人員商量了。
事實證明，小蔡擁有的這些針對界面設計稿的測試思路，讓她在做kick off卡時能及時提出很多有效建議，極大地幫助團隊澄清需求，減少了開發返工，也大大提高了團隊工作效率。