[譯]36 Days of Web Testing(五)

Day 23 禁用CSS  Disable CSS

爲何 ?

CSS，層疊樣式表，是用來定義web頁面佈局和顯示的機制。經過修改CSS樣式，能夠改變整個頁面的外觀。

可是有一些人，由於以前的選擇或者其餘緣由，或選擇禁用瀏覽器的CSS。這樣可使得站點看起來更加簡單，最終也有利於屏幕閱讀功能訪問這些頁面。

所以，在css禁用場景下的測試仍是很重要的。若是禁用了CSS，你會驚訝的發現站點的流程和順序都會有改變。

怎麼作 ?

我發現的最簡單的測試方法就是，用裝有web開發工具插件的Firefox來打開你的站點。在擴展插件的菜單中能夠選擇禁用CSS。站點就會無樣式下從新渲染。你也可使用Firebug或其餘功能來作。

建議：

Firebug有個CSS的分頁，能夠顯示站點中使用的CSS樣式。若是修改了其中的一些CSS標籤，會怎樣呢？

連接：

W3C standards and advice for CSS - http://www.w3.org/Style/CSS/
Firebug Firefox Extension - http://getfirebug.com/
Web Developer Add-One - https://addons.mozilla.org/en-us/firefox/addon/web-developer/

 

Day 24 Text Only

爲何 ?

若是能確保站點在純文本模式下也能正常工做，那就再好不過了。從可訪問性角度來看，純文本模式下的測試是很重要的。從最求簡單的角度來看，能在純文本模式下正常工做，也是一個很好的目標。

可是，很難發現有站點能夠在純文本模式下也能正常工做。

對於提供站點文本訪問模式的好處，見解仍是不一致的。

怎麼作 ?

最簡單的來得到網站文本模式的方法就是，啓用瀏覽器的開發者工具。我選擇了Firefor的開發者工具欄。

安裝上開發者工具之後，你只須要找到選項來開啓文本模式。

在開發者工具欄裏面：

images > Disable All Images

而後，選擇 Disable > Disable JavaScript

接着，選擇 CSS > Disable Styles > All Styles

這樣訪問的站點就是文本模式了。你會發現有一些你須要的功能不可用了，或則一血頁面流出現了異常，或則你會發現你真的須要一些視覺圖片來使得網頁更易於讓人理解。

建議：

Firefox的開發者工具欄提供了不少選項按鈕，這些會幫着你測試你的站點在一些不支持特定功能的設備上打開會怎樣，或須要可訪問頁面的用戶打開會怎樣。

連接：

Information on Text Only - http://www.webcredible.co.uk/user-friendly-resources/web-accessibility/textonly.shtml
The Developer Tool Bar extension for Firefox - http://chrispederick.com/work/web-developer/

 

Day 25  禁用 javaScript    Disable JavaScript

Why ?

有不少很好的緣由會促使你使用JavaScript  , 但有時候過分使用JavaScript也會致使一些有意思的bugs.

舉例來講，在訪問你的站點時，並非全部的瀏覽器都會啓用Javascript的，這會致使你站點的部分功能不可用，或則一些邏輯沒有如預想的那樣執行。

JavaScript常被用於收集數據，展現信息，執行頁面邏輯，以及提交表單或用戶數據。若是用戶禁用了JavaScript ,這些功能就會丟失。

How ?

最簡單的測試方法就是使用開發則工具擴展來禁用瀏覽器JavaScript, 禁用後訪問你的站點，看看會發生什麼

Useful Hint

有不少JS的單元測試框架

Useful Links

JSLint - http://www.jslint.com/lint.html
JavaScript information - http://coding.smashingmagazine.com/2011/10/27/lessons-from-a-review-of-javascriptcode

 

Day 26 Flash Free

Why ?

並非全部的瀏覽器支持，或則容許Flash功能，所以提供給一個不包含Flash的站點被認爲是一個必須的。特別是現在Adobe本身都宣佈了將在不少移動平臺上中止對Flash的支持。

有新聞價值的就是Ipad就不支持Flash 。也有一些插件和設置能夠在瀏覽器中禁用Flash 。若是你的站點是依賴Flash的，這的確是個壞消息。

HTML5已經在路上，它能提供Flash所擅長的那些功能。

How ?

測試 無Flash的最簡單的方法就是下載一個Firfox插件，例如 「Flash Block」,而後啓用這個插件，訪問你的站點。

下面這個圖片就是禁用了Flash的汽車站點。在這個例子中，瀏覽器禁用了汽車的交互視圖，這個站點的核心功能。實際上，人們不多會有理由會徘徊在這個站點。若是你是終端用戶，這是你所想要的嗎？

我始終簡單的認爲，即使禁用了Flash , 也不該該影響站點的主要功能。

若是由於一些緣由，站點必須使用Flash ,而不是簡單的炫耀你的Flash技能，這時候作一名測試同窗，你就應該問一問，「咱們有沒有選錯技術」

若是選擇了Flash ,那麼就有可能失去一部分潛在的市場。

Useful Hint

若是此時你使用Firefox的插件來禁用Flash , 這時候若是要訪問你喜歡的站點，記得修改一下設置。由於這個插件同時會禁用掉 Silverlight , 微軟的多媒體框架。

Useful Links

Flash Block - https://addons.mozilla.org/en-US/firefox/addon/flashblock/
Flash and why you shouldn’t use it - http://dynamicwebs.com.au/weblog/?p=33
Flash 99% Bad - http://www.useit.com/alertbox/20001029.html
When and where to use Flash - http://www.businessknowhow.com/internet/flash.htm

 

Day 27 用戶接受測試（UAT，User Acceptance Testing)

Why ?

依據個人我的經驗，大多數人（包括，開發、測試、產品經理）在作產品時，總會設想使用者是很Power的。我之因此這麼認爲，是由於在我以往接觸的這些人中，他們每每都很擅長電腦技術，擁有這領域的專業知識，他們和項目息息相關，對項目和產品有本身的看法。

他們是電腦專家，對本身的產品有着很深的看法。這就意味着他們不是「Greenfield「用戶。他們可能對本身的產品應該作成什麼樣，爲何這樣作，有着本身執拗的見解。畢竟，是他們編寫了這個產品，測試這個產品，推廣這個產品，支持維護這個產品的人。

「Greenfield」用戶是指那些第一次訪問你站點的用戶，他們不懂技術，也不瞭解設計方面的知識，來訪問你的站點僅僅是爲了完成一些目標（好比，解決一些問題）

有些時候，做爲一名測試工程師，咱們忽略了產品的最終使用者，自覺得是的認爲用戶在訪問站點時，擁有和咱們差很少的技能。這是很危險的。

How ?

獲取用戶反饋最簡單的辦法就是找一個開發團隊以外的人來執行一些用戶驗收程序。驗收可大可小，小到這個頁面看起來不舒服，均可以提，但這樣的驗證頻次在開發的過程當中越頻繁越好。敏捷開發部分採用了用戶驗收測試的方式，意識到用戶的存在，頻繁的更新發布。

但像瀑布模型，V模型或其餘一些生命週期較長的軟件開發模式，應該更頻繁的用戶驗收測試來收益。

用戶驗收，ISTQB是這樣定義的：

驗收測試是對用戶，或最終系統使用者負責的一種測試。其餘利益相關者也可參與。驗收測試的目的就是創建對系統，系統的某一部分，或特定的非功能特定的自信。發現bug並非驗收測試的主要關注點。

對於這樣的定義存在很大爭議，此次就先不在這裏討論了。我認爲咱們應該從這裏面看到一些不一樣點，我認爲用戶驗收測試能夠在項目任一階段來執行。

我認爲這應該是開發團隊的責任（有助於你交付正確的產品），我認爲應該鼓勵發現bug（要看對bug的分類了，是enhancement,defect,fault,missing copliance ,suability ,performance）。這些反饋能夠反映產品是否是用戶想要的，如用戶預期的。爲何要等到產品要發佈了才作驗收測試呢？

傾聽來自用戶的聲音對你的成功相當重要，獲得用戶的反饋越早越好。

Useful Hint

每隔幾周，或幾個月作一次用戶驗收測試是一個正確的策略。儘快的把產品放到用戶面前，頻繁傾聽用戶的聲音。儘快聽到用戶反饋，並將反饋後的改動包含在下一次的發佈中

Useful Links

ISTQB online - http://istqb.org/display/ISTQB/Home

 

Day 28 移動設備友好網站   Mobile Friendly ?

Why ?

現在有不少關於移動設備使用狀況的統計數據。

不管你相信哪一種統計信息（試着搜索一下「移動設備使用數據」），都很清晰的代表對於不少企業來講，移動是一直值得擁抱的將來。

做爲一名測試同窗，應該嘗試着在各類移動設備上訪問你的站點，看是否能正常工做。也許你的公司認爲mobile並非一個須要支持的平臺，但長遠開來mobile愈來愈流行，這是不爭的事實。

How ?

若是你本身就有移動設備，能夠訪問下你的站點，看是否正常工做。也有不少移動模擬器能夠用來測試你的站點。

在不一樣的操做系統上（mobile 和平板）上測試，把在各個系統的測試結果分別記錄下來。

試試右擊，頁面更新，多個分頁和數據選擇（下拉，單選按鈕）。這些地方我曾發現過問題，但各個產品在不一樣的場景下操做，須要根據本身的狀況決定測試哪些。

Useful Hint

若是你在移動設備上測試須要一些數據，不要老是傻不拉幾的每次都手動輸入。能夠把須要的數據以SMS或Email的形式發送到你的手機上，下面就能夠在手機上Copy, 粘貼了。

若是你使用的是智能機，可使用Evernote 或Dropbox進行數據同步。

Useful Links

A monster list of emulators - http://www.mobilexweb.com/emulators
Micro emulator - http://www.microemu.org/
Android Emulator - http://developer.android.com/guide/developing/tools/emulator.html
Nokia Toolkit - http://www.developer.nokia.com/info/sw.nokia.com/id/d57da811-c7cf-48c8-995ffeb3bea36d11/
Nokia_Mobile_Internet_Toolkit_4.1.html
Opera Mobile Emulator - http://www.opera.com/developer/tools/mobile/
Windows Mobile Emulators - http://msdn.microsoft.com/en-us/windowsmobile/bb250560.aspx
iPhone Emulator - http://www.marketcircle.com/iphoney/
Evernote - www.evernote.com

 

Day 29  Race conditions with selenium

爲何？

Selenium是UI自動化的利器，但它還有一些其餘的，被你們忽視的用處。條件競爭就是其中之一的用處。

例如，Selenium IDE容許你以超過正常人爲速度，來輸入數據，點擊按鈕，以及訪問一個站點。有時候，以很快的速度來走一個流程，訪問一個站點可能會改變事件的順序，改變消息，或則是其處在一個不應觸發的狀態上。這就是條件競爭。

使用Selenium UI測試，很容易就能發現競爭危害。我曾經過Selenium重現過以前正常UI測試沒法每次都發現的問題。

怎麼作？

使用Selenium腳本以較快速度回放以前錄製的一系列頁面操做。

舉例來講，你正在填寫一個表單，對於問題三選擇了「Yes」，這時候在表單末尾出現了另外兩個必填的問題。在這種場景下，就存在一種潛在的競爭危害。這兩個問題多是等一個很快的頁面重載後出現的（或則其餘實現方式）。

若是你以正常的速度填寫表單，選擇了「Yes」,接着看到了兩個問題的展現，若是不填寫這兩個問題，你就會收到提示信息，告訴你這兩個問題是必填的。

可是，若是你錄製了表單填寫過程，並經過Selenium以很快的速度回放，你就可能選擇了「Yes」,並在頁面重載前，按下一步。

這就意味着你能夠提交一個在技術上不合法的表單（由於另外兩個問題是必填項目）。

過去幾年我在真實系統中發現過這樣的Bug.這樣的問題經過本身手動點擊是不能重現的，但經過Selenium每次都能重現。

關於這個問題存在必定爭議，由於終端用戶並不會看到這種類型的bug,由於他們不會以這樣的速度來操做，但競爭條件能夠暴露出一些代碼底層的問題，或則處理流程的錯誤。這樣的討論仍是有必要的。

每一個團隊對待這樣的bug都是不同的。有一些自動化框架使用「思考時間」來模擬真實用戶的響應時間。這對於常規的自動化是有效的，但若是你專門爲了尋找這種競爭條件的話，那麼快速UI自動化能夠幫助你。

有一些用戶的操做速度比其餘人快，在操做速度的判斷上須要作一些本身的判斷，但競爭條件是會在任何速度下發生的，只是使用Selenium能夠幫助更容易的，更多的發現這種現象。

建議：

掌握了Selenium IDE意味着你能夠更快速地編輯，和執行它。

連接：

Race Conditions (Wikipedia) - http://en.wikipedia.org/wiki/Race_condition
Selenium - http://seleniumhq.org/

 

Day 30 Blink testing

爲何？

關於「閃爍測試」，我本想寫下和James Bach不同的介紹，但實際上他的描述已經很到位了。所以，這裏直接引述他的定義：

所謂的閃爍測試，就是把你置身於數據的海洋裏 - 有太多數據，以致於一時沒法理解消化。接着你理解了這些數據時，但你都不知道本身是怎麼就想通了的。可是你真的理解了，但你本身並無意識到該怎麼理解

- James Batch   http://www.satisfice.com/blog/archives/33

怎麼作？

舉個例子，你能夠很從容的填寫一個表單（用Selenium或屏幕抓取軟件記錄下來），完成上面的每個字段，而後回放腳本，或視頻。你可能會發現一些佈局問題，標籤的不一致，頁面的錯誤，或則其餘一些以前沒注意到的問題。

你能夠把點擊按鈕產生值的過程錄製下來（就像JB博客中的那段視頻同樣http://www.satisfice.com/blog/archives/33，或則將一個探索式測試的測程錄製下來），而後以很快的速度回放，你可能會發現一些第一次漏掉的問題。

當你看到頁面，或則數據閃爍的時候，你會開始觀察到一些不一樣之處，而這些在以前的常規測試中並非很明顯。Selenium 是一個很棒的工具，其餘一些屏幕記錄工具，或則自動化工具能夠提供幫助。

建議：

在測試音頻時，以兩倍速度播放音頻，能夠有效的發現一有意思的元素，在正常速度下是不會注意到的。

連接：

James Bach’s article on Blink Testing - http://www.satisfice.com/blog/archives/33
Screen recording for your browser - http://www.screenr.com/
Desktop screen reading software - http://camstudio.org/