[譯]36 Days of Web Testing(六)

Day 30 Test in situ  真實場景下的測試

爲何？

我十分推崇現場測試，簡單講就是要在你的站點或應用真實使用的場景下進行測試。但隨着人口增加，對於「真實場景」的定義變得愈發困難，由於人們可能在各類場景下使用產品。

若是你正在測試一個公共報亭軟件，在擁擠，嘈雜，光線刺眼的公共環境，是否能夠如預期的工做？在測試環境可能正常工做，但在戶外街道上測試，和在測試環境的結果同樣嗎？你的移動APP在公交站點，深夜，下雨的時候均可以正常工做嗎？

怎麼作？

試着定義一些常見的「真實場景」，並在這些場景下測試。設計一系列場景是一個好主意。在這些場景中用戶會發現本身真實使用的情景，例如「忙碌的辦公室」，「吵鬧繁忙的火車站」，「安靜的房間」等。這些場景會幫助你理解在什麼樣的狀況下，以及爲何使用你的產品。

我測試呼叫中心軟件，沒有比拜訪一些最終用戶（呼叫中心代理），看看他們是如何使用這些應用的更來得直接了。這可能會改變你對產品一些元素的見解。

我有一個朋友，他從事很酷的航海導航工具測試。若是可能，他會在海中的船上進行測試，沒有什麼能夠替代這樣的真實場景。

另外一個朋友測試醫療設備，在模擬操做階段發現設備致使噪聲很大，血花飛濺。這樣的體現，讓他回到辦公室後對整個產品有個全新的認識。

建議：

這樣的角色扮演不僅僅設計專家，功能專家來作。這一樣是一個很棒的主意，能夠有助於產生一些測試點子。

連接：

In Situ on Wikipedia - http://en.wikipedia.org/wiki/In_situ
Blatant self-promotion link to Social Tester site - http://thesocialtester.co.uk/theres-method-in-the-madness/

 

Day 31  Print it out 打印出來

爲何？

若是你的站點有表單，應用提供其餘使用者一些數據，例如收據，可訪問的代碼，確認碼等，那麼最好將打印這些數據做爲你測試的一部分。

終端用戶是會打印收據這些數據的，若是你發現你優雅的功能站點打印出來是如此槽糕，這將搞壞用戶體驗。

舉個例子，當我收到了一個會議邀請的電子邀請函，我通常都會打印出來做爲報銷憑證的，若是驚訝的發現打印出來的格式很糟糕

怎麼作？

點擊打印，而後檢查打印出來的。

建議：

大多數瀏覽器都提供了打印預覽功能，經過打印預覽就能夠看出效果了，沒必要浪費紙了。

連接：

Insights in to how to make a print ready CSS - http://answers.oreilly.com/topic/1018-how-to-make-a-web-formprint- ready-with-css/

 

Day 32 Too many extensions  太多的擴展

爲何？

不少現代瀏覽器容許你添加附件組件、擴展，或插件，這些均可以增長瀏覽器的功能，容許你在瀏覽器中執行一些操做。

對一個測試而言，Firefox的主要擴展可能就是Firebug,經過Firebug能夠查看客戶端和服務器的網絡交互，能夠作一些很酷的頁面檢查，以及其餘一些事情。

對於主瀏覽器，有成千上萬中不一樣的擴展，我以前已經討論過不少相似的擴展應用了。

然而，在測試的過程當中，你所安裝的這些應用也會和產品進行交互，擴展自己的問題可能致使你花費大量時間來調查一個對用戶並非十分重要的bug

怎麼作？

我最近就遇到過一個問題，個人一個擴展將一段Javascript腳本給禁用掉了，雖然並無配置禁用JavaScript腳本。

這個bug在其餘瀏覽器上都沒法重現。經過分析全部執行過的代碼咱們得出的結論是，這多是Firefox的擴展引發的問題。我在另外一個虛擬機上安裝了一樣版本的Firefox，可是沒有安裝擴展，結果是正常的，因此緣由找到了。

由於我安裝有20+的擴展來協助我測試，因此我每次移除兩個擴展，以此來定位致使問題的擴展到底是哪一個。

當我移除掉最後兩個擴展時，問題解決了。接着，我又以相反的順序將那些移除的擴展安裝起來，結果當安裝完前兩個擴展時，問題又出現了。我定位到了致使問題的擴展，並作了一番探究。這是這個擴展的已知問題，由於擴展自己也是JavaScript實現的。

擴展很強大，但也有可能會妨礙正常功能。

建議：

準備一個測試機（虛擬機，或實體機均可以），安裝絕對乾淨的（沒有擴展，或沒必要要的插件）的瀏覽器，若是你發現了很詭異的問題，這時候能夠在兩套環境下比較一下，看是否是瀏覽器擴展引發的問題。

連接：

How to manage add-ons across multiple machines - http://lifehacker.com/272113/sync-your-firefoxextensions-and-profiles-across-computers

 

Day 33 Refresh during page loads  在頁面載入的過程當中刷新

爲何？

若是你測試的應用或站點存在特定的狀態，或則事務更新，舉例來說，當你點擊一個按鈕，而後嘗試刷新頁面時，這時候會進入不一樣的狀態。

你會驚訝的發如今這個地方存在不少潛在的問題。當一個頁面在載入，或發送、接收新數據時，刷新操做也會可能會獲取老的狀態數據。這時候經過刷新獲取到的數據可能不是最新的數據。

怎麼作？

在執行一些操做（如提交表單）的同時，點擊「刷新」按鈕。依據這個模塊的響應速度有多快，你可能會發現一些關於狀態、數據、或則用戶活動的問題。

Ps: 曾發現過，在提現時，輸入短信校驗碼後，在提現成功頁面，按F5刷新，會出現重複提現的問題。

建議：

找出你所使用的操做系統的快捷鍵，這樣即可以更迅速的刷新

連接：

Windows shortcut keys - http://support.microsoft.com/kb/126449
MAC shortcut keys - http://support.apple.com/kb/HT1343
Linux shortcut keys - http://linux.about.com/od/linux101/l/blnewbie5_1.htm

 

Day 34  Check for SEO 搜索引擎優化

爲何 ？

在現在這個社交意識愈發強烈的社會，咱們須要經過點擊來進行銷售和獲取市場份額。獲取點擊並非單單提供正確的內容，還得市場要知曉你的運營活動。這固然也包括，建立一個搜索引擎優化的網站，或設計。

「搜索引擎優化(SEO)是指經過一些‘天然的’，‘非付費的’，或算法的方式來提升網站在搜索引擎結果中的可見度」

基於上述考慮，咱們就要作一些研究，看看究竟改作些什麼，哪些不能作才能是有利於SEO(搜索引擎優化)。

市面上存在一些有用的指導，有一些好不幫助，還有一些幫助甚微。對於最佳方式提高SEO的，也有一些不一樣意見，甚至認爲SEO到底是否重要都有不一樣的意見。

站點的SEO另外一個常常被忽視的做用就是，SEO的同時有利於站點的可訪問性。看看下面一個有意思的對比：

http://www.slideshare.net/ConeTrees/seo-through-accessibility

怎麼作？

我已經在下面列出了一些有用的連接，可是仍是最好訂閱一個內容靠譜的網站，保持與這個快速變化的領域時刻同步。

小建議

有不少瀏覽器插件提供SEO檢測功能。

有用的連接

Marketing and Sales look at SEO -
http://www.promotionworld.com/articles/se/articles/Internet_Marketing_Strategy/SEO/071007EssentialGuide.html
SEO through accessibility - http://www.slideshare.net/ConeTrees/seo-through-accessibility
SEO at Wikipedia - http://en.wikipedia.org/wiki/SEO

 

Day 35 Five second test  五秒測試

爲何？

當人們訪問你的站點時，一般會很快對這個站點作出一個判斷，也就是第一印象，接下來去哪，他們是否喜歡這個設計（或內容）。

有個很棒的服務叫作「五秒測試」（http://fivesecondtest.com/），提供這個服務的網站上有一些用戶和測試人員，他們會訪問你的站點，回答一些關於你的網站的問題，並給你一些反饋。

這能夠幫助你發現當用戶訪問你的站點時，他們的注意力會更關注那些內容。

「在僅僅5秒的訪問時間後，看看一我的對於你的設計究竟能回憶起什麼，這能夠確認你的信息是否有效的傳遞給用戶。」 – From Five Second Test Website

怎麼作？

只需註冊一下，上傳你網站的線框圖，或則mocks，接着等待反饋

建議：

儘早得到用戶的反饋能夠第一時間確保你專一在作正確的應用。常常看到，像這種有用的測試作的太晚，一直於最後代碼的變動已經很難了，或則說太多時間投入到一個很爛的設計中。

連接：

Five Second Test - http://fivesecondtest.com/
24 Usability Tools - http://www.usefulusability.com/24-usability-testing-tools/

 

Day36  Throttle It 限流

爲何？

在測試應用時，測試環境的網絡連接是很快的，這就意味着咱們的產品是在很好的網絡鏈接和網速的狀況下測試的。

但終端用戶並非都能經過很快的網絡鏈接來訪問咱們的站點的。

不要設想你的用戶的網絡環境是很流暢的，這一點很重要。要面對冷酷的現實。過分的設想會致使設計和實現不能知足用戶，或則現場的場景。

怎麼辦？

市場上有不少工具，但我發現Charles Proxy是最有效的限流工具。

在Charles Proxy的界面上，有個很明顯的「節流閥」按鈕。容許你限制鏈接的網絡速度，就像用戶的網速同樣。

介紹怎樣限制網站的網速：

http://www.charlesproxy.com/documentation/proxying/throttling/

經過使用Charles Proxy能夠測試不一樣網絡鏈接速度下，和網站交互或鏈接時的反應。

Useful Hint

在產品說明書中一般會有須要的最小配置，能夠從最小配置開始測試。

Useful Links

Charles Proxy - http://www.charlesproxy.com/