[譯]36 Days of Web Testing(一)

【前言】最近負責的一次迭代發佈中，一個小需求涉及前端JS改動，在測試這個需求的過程當中忽略了瀏覽器兼容性測試，致使了一個線上bug。惡補下web測試，《36Days of web testing》是以前看到有人推薦的，翻了翻，以爲挺不錯的，決定利用業餘時間把它翻譯完，但願本身能堅持住，保證每週更新。

Day1: Cross Browser - 跨瀏覽器兼容性測試

爲何要作有瀏覽器兼容性測試？

現在，市面上的瀏覽器種類愈來愈多（尤爲是在平板和移動設備上），這就意味着你所測試的站點須要在這些你聲稱支持瀏覽器上都能很好的工做。

同時，主流瀏覽器（IE,Firefox,Chrome,Opera,Safari）版本更新更加頻繁，終端用戶甚至不會感知這些瀏覽器版本的升級。

這兩點就致使了對於日益增多的瀏覽器作兼容性測試顯示十分必要，但也使得這種兼容性測試變得十分耗時。

經過全覆蓋的測試，你就能夠明確的知道你的站點支持哪些瀏覽器，哪些有兼容性問題。一個最簡單的減小瀏覽器兼容性測試的辦法，就是中止對老版本瀏覽器的支持。這個策略對一些公司是適用的，但並不適用所用的公司。

中止對老版本瀏覽器的支持，並不意味這你的產品在這些老版本上就沒有bug, 這僅僅是你能夠忽略那些老版本上的潛在問題，把精力放在那些當前支持的瀏覽器版本上。

瀏覽器兼容性測試應該如何來作？

分散風險

一個途徑就是在多瀏覽器環境中執行平常的測試工做。

舉個例子來說，你要測試這樣一個web應用：用戶登入，生成報表，發送報表，退出系統。這個應用還包含一個管理功能，管理員或經理登入後可查看哪些人作了哪些改動。

爲了覆蓋更多的瀏覽器，你能夠用一種瀏覽器來測試登入功能，在另外一個瀏覽器中測試「發送報表」的功能，用第三種瀏覽器測試「審計變更」的功能。

這是一個有效的方法，在平常的功能測試的過程當中，同時覆蓋多瀏覽器兼容性測試。上面這個例子仍是存在一些問題的，好比講，若是「審計變更」這個功能在第一種，或第二種瀏覽器裏是有問題，那麼就會發現不了。這種方法節省下來的時間，可讓你在作兼容性測試策略時，更有側重。

讓其餘人來幫你作測試

對於一些明顯的頁面兼容性問題，有一些在線工具能夠幫着你檢查，例如Browser Shots,它能夠將你的頁面載入到它所支持的瀏覽器中(它支持瀏覽器種類和版本很豐富),而後截屏,你能夠查看在這些瀏覽器下的載入狀況了.

這是一個很棒的工具,但那些須要登入驗證的應用,或則你的應用中包含的頁面太多 ,這個工具就顯得有點力不從心了.

和標準進行比對

你能夠對你的站點進行HTML語法標準檢查，若是經過了，在多瀏覽器兼容性上，你能夠更有自信一點了，但即便經過了，仍是總有一些瀏覽器（好比萬惡的360）渲染你的頁面是會有兼容性問題。

W3.org提供一個很好的標準檢平臺。

自動化

Web UI的測試能夠經過webdriver這個工具來實現自動化，可使用selenium Grid來說自動化腳本在多瀏覽器上運行。

前提是你得有Web UI自動化的投入。Web UI自動化能夠發現一些功能上的問題，但對於多瀏覽器頁面佈局方面的差別，經過它是很難發現的。

Fight Layout Bugs

你能夠寫一些自動化腳原本檢查頁面在不一樣瀏覽器下渲染效果。Fighting Layout bugs是一個開源的工具，能夠用來檢查頁面佈局方面的bug

手工測試

你能夠手工測試全部的瀏覽器版本，爲了不混淆，你能夠將不一樣的瀏覽器安裝在不一樣的虛擬機上（uedde的確這這樣作的），當有其餘人須要用是，能夠直接克隆這些虛擬機，或則直接訪問這些虛擬機。但這太耗時，費力了，但仍是有必要作一次這樣的多瀏覽器手工測試的。

分類

你能夠依據內核來劃分瀏覽器。

chrome & safari使用的是webkit內核，Firefox則是Gecko, IE系列的是Trident內核，Opera使用Presto內核。最新的Opera好像也開始使用webkit內核了。

這樣你就能夠認爲，若是在chrome上沒有問題，那麼「理應」在safari也應該沒問題。

模擬

市面上有一些工具能夠模擬不一樣的瀏覽器，有一些瀏覽器也附帶了工具來兼容老版本。但使用這些工具是要謹慎，這樣的模擬並不必定準確。慎重。

outsource selenium

若是你沒有條件搭建selenium grid測試環境，你能夠嘗試着使用Sauce Labs 和 testingbot 這樣的服務。

多瀏覽器的支持咱們心中永遠的痛，特別是現在瀏覽器更新如此頻繁的情況下。哎~ 你能夠選擇上面的適合你的方法。

PS：有些瀏覽器有兼容模式，能夠經過兼容模式來模擬老版本。有些瀏覽器，如chrome,提供了開發者工具能夠幫着定位問題。

有用的連接：

Compatibility Mode page on Wikipedia - http://en.wikipedia.org/wiki/Compatibility_mode_%28software%29

Sauce Labs - http://saucelabs.com/

Testing Bot - http://testingbot.com/

Browsers and Rendering Engines - http://en.wikipedia.org/wiki/Web_browser_engine

Selenium Grid - http://selenium-grid.seleniumhq.org/

Day2: Web Accessibility - 頁面可訪問性測試

【題外話】對於web accessibility testing以前都沒聽過，但曾據說過「淘寶無障礙」。wikipedia上對於web accessibility的定義是：站點要具有包容性，正常人能使用，殘障人士也能無障礙的訪問。當網頁合理的設計，編輯，就能夠保證全部的人均可以平等的訪問你的站點，獲取信息，進行操做。如，盲人能夠經過讀屏軟件訪問你的站點，紅綠色盲也能夠辨別出頁面上的超連接等。

Why ? 爲何要作

不多有公司會十分重視他們的網頁對於特殊人羣可訪問性問題，但現在互聯網早已滲入咱們的平常生活，讓殘障人羣能融入到這個虛擬的世界，而不是將他們排斥在外，就顯得十分重要。

一方面講，可訪問測試十分簡單，另外一方面看，又很難。

一個站點的可訪問性能夠經過W3C制定出來的國際合規標準來進行斷定，這個指南給出了A，AA，AAA三個等級。

How? 怎麼來作

市面上有不少工具能夠幫着你檢查你的站點是否符合合規標準，這些自動化工具能夠很快的給出結果來。這是最簡單的方法，分分鐘就能夠給你結果，但這些結果每每又不是很全面。

讓咱們來看一個簡單的例子：你的頁面包含有一張圖片。圖片的 alt 屬性可能爲空。

當用戶由於網速太慢沒法查看圖片，或則使用屏幕閱讀器時，alt屬性就顯得十分重要了，它能夠爲圖像提供替代的文本信息，使用屏幕閱讀器的殘障人士能夠聽到關於這個圖像的文本信息。

若是alt屬性爲空，自動化檢查工具就會報錯，這是很容易修復的。填上alt屬性值，從新跑一遍，就能夠經過了。

然而，當你的圖像是一個紅蘋果，而你輸入的文本信息是「可愛的泰迪熊」，就可訪問性而言，圖像的alt屬性告訴使用屏幕閱讀器的用戶，這個圖像真實的是什麼。因此「可愛的泰迪熊」這樣的文本信息對他們是沒有幫組的，實際上起到的做用偏偏相反，誤導了用戶。這種狀況，自動化的檢查工具是檢查不出來的。

頁面流，頁面的邏輯對於盲人用戶，或沒有背景知識的用戶，是否是很明瞭，這一點，自動化檢查工具也是沒法幫着檢查出來的。

就個人經驗而言，讓真正使用可訪問站點的人來測試站點的可訪問性比正常人更有效。所以，能夠考慮將站點的可訪問性測試外包給那些專業的可訪問性測試公司或慈善組織。我曾經過自動化工具來檢查一個站點，檢查的結果是符合AA規範標準的，但當我將它交給可訪問性測試專家測試時，我驚呆了，就可訪問而言，基本等於不可用。它是符合規範的，但用起來很不方便，也很不爽。

優秀的可訪問性測試須要人的判斷和思考，而不是簡單的自動化。須要不斷的嘗試，須要來自目標用戶的反饋。

毋庸置疑，在線工具擅於發現那些明顯的錯誤和規範性問題，並且這些工具也在不斷優化，變得更強大。

若是你的站點在開發時，根本沒考慮可訪性，那麼當用這些工具掃描你的站點，你會驚訝的發現，你的站點在可訪問性方面是多麼的差。

不管你是否在乎你的站點是否符合可訪問性規範，作一下可訪問性檢查每每會發現Html中一些明顯的問題，並能給你下一步的測試工做提供一個方向。

若是你的公司絕不在意本身的站點來個A標準都達不到，這時候，做爲一個優秀的測試工程師，你就要問一個爲何不了。

小建議：

最簡單的方法來檢查你的站點是否符合W3C標準的方法就是，安裝一個firefor插件，而後打開網頁，進行一個快速的掃描。

有用的連接：

Firefox accessibility extension - https://addons.mozilla.org/en-US/firefox/addon/accessibility-evaluation-toolb/

Tips on how best to describe the alt attribute - http://webdesign.about.com/od/beginningtutorials/a/aa122004.htm

The W3 standards on accessibility - http://www.w3.org/standards/webdesign/accessibility

Test Partners accessibility testing  - http://www.testpartners.co.uk/accessibility_testing.htm

再補充兩個淘寶的規範：

淘寶信息無障礙設計標準  http://www.taobaotest.com/acc/66

淘寶屋無障礙-網站開發編碼規範  http://www.taobaotest.com/acc/68

 

Day3: Is the HTML valid? 你的HTML符合規範嗎

爲何

HTML是一種主要用來描述網頁的標記語言。

不合規的HTML可能會致使bug, 頁面渲染問題，瀏覽器兼容性性問題，可訪問性也差，因此在作web測試時，能夠關注一下HTML是否符合規範。

嚴格遵照HTML規範能夠確保你的站點能經受將來的考驗。

有不少站點沒有遵循HTML規範，其中不乏一些人氣很高的網站。談到爲何不遵照規範，拿出來的說辭老是：爲了頁面響應更迅速一點，跨瀏覽器兼容性的考慮（諷刺的是，HTML5是可以保證跨瀏覽器一致性），這裏就不深究了。

一言以蔽之，利用現有的工具來作一次基本HTML規範性檢測，是明智之舉。作檢查只是個開始，究竟要不要修這個能夠討論。

怎麼作

測試時，你可使用Firefox的FireWeasel插件來驗證你的站點是否合規。也有一些在線驗證工具能夠迅速的給出反饋。這些驗證工具能夠指出哪一部分HTML違反了規範，應該如何修復。

小建議

鼓勵團隊中的開發同窗裝個IDE插件來檢查他們寫的HTML是否符合規範，這樣就能夠儘早的發現HTML規範性問題了。

有用的連接

Good post on why you should validate - http://www.stevefenton.co.uk/Content/Blog/Date/201108/Blog/Do-I-Need-To-Validate-My-HTML/?Page=Blog&Date=201108&Blog=Do-I-Need-To-Validate-My-HTML

The W3C validator - http://validator.w3.org/

FireWeasel - https://addons.mozilla.org/en-US/firefox/addon/fireweasel/

 

Day4: Check for Dead-links  壞連接檢查

爲何

幾乎全部的站點都存在連接無效的現象，連接沒法訪問，或則一個內容過時，再也不更新，沒人維護的頁面。緣由很簡單，要麼是你連接指向的頁面已經被移除，要麼就是沒指向正確的地方。也有多是你指向的頁面沒法工做了。

爲了不後續花費大量時間來維護這些連接，應該要保持這些連接能獲得及時更新，但提及來容易作起來難，特別是在開發那些商業站點時。

壞連接可能會致使其餘問題，這一塊也是Web測試工程師應該關注的。

怎麼來作？

有不少工具能夠掃描你的站點，列出一個壞連接的列表，並建議你如何來修復。大多數狀況下，簡單的移除那些壞連接就能夠了，但這麼作也有點很差。

下載一個連接檢查工具，如 Xenu , 輸入你的URL，而後就能夠等着看報告了

小建議

將壞連接的檢查做爲持續集成（CI）的一部分，當自動化測試執行時，你就能夠順帶着作壞連接的檢查 了。

有用的連接

Xenu Link Checker - http://home.snafu.de/tilman/xenulink.html
W3C Checker - http://validator.w3.org/checklink
Broken Link Checker Tool - http://www.brokenlinkcheck.com/

Day5：One,Two,Many  一個，兩個，以及更多

爲何？

除了一些定位很小衆的網站，不然你老是但願有多的人來訪問你的站點。所以，最好測試一下你的站點在N個用戶訪問的狀況下是否也是能正常工做的。

系統的多用戶測試，或壓力測試中最讓人頭疼的是用戶使用模型和預期負載的定義。

舉個例子，有一些站點平日的訪問量不多，只有幾十，但週末的時候訪問量會增長到好幾千。這就增長了使用模型的複雜度。所用的用戶每次訪問你的站點所作的操做都是同樣的嗎？

最簡單的開始多用戶測試/壓力測試/性能測試的方法就是使用「一個，兩個，或則更多」概念。

我我的比較偏好「一個，兩個，或則更多」是由於，這個觀念很容易解釋，同時，在使用的過程當中它也提供了額外的價值。我一直使用這個理論作測試，並將它運用到自動化腳本中。

這個理論是這樣的：

首先，在一個用戶場景下的測試，主要要確保基本功能能正常工做。

其次，經過兩個併發用戶訪問來檢查是否存在死鎖問題，以及一些其餘的多用戶訪問問題。你會驚訝的發現竟然存在如此多的問題，這種測試很簡單，沒必要花費幾個月時間來搭建一套專門的自動化框架來驗證這些基本問題。

接着，在多用戶場景下測試。多用戶，這個根據你的實際須要來調整，能夠是十個，二十個，甚至百萬級的。

爲何，一開始從一個低量級下測試，而後纔開始在一個大數量下測試呢？我遇到過一些例子：一些耗費昂貴設備，測試腳本的壓力測試，結果發現僅僅是產品不支持兩個用戶同時登入。

怎麼來作呢？

爲了獲得快速的反饋，通常「一個」、「兩個」的場景我都是經過手工測試來驗證的，也會藉助一些自動化工具，如selenium來輔助測試，甚至會忽略UI，直接驗證web service層的功能。

大負載的測試有許多選擇，這裏我就很少講了。我我的比較偏好使用jmeter, 這是一個免費的工具，上手也快，容易擴展。你也能夠採用其餘一些工具，免費的，收費的，本地安裝的，或則服務方式的。

不管採用何種方式來測試，但別忘了你的目標是什麼。若是不能專一於你的目標，不斷嘗試各類不一樣的工具，你會發現性能測試和壓力測試會變得十分複雜，笨重，成本也很大。

小建議：

先了解一下那些免費的工具，或則下載個試用版玩玩，而後再決定是否須要購買。工具的質量和適用性很重要。

有用的連接：

A list of testing tools - https://en.wikipedia.org/wiki/Load_testing/
jMeter -  http://jmeter.apache.org/

Day6: 多分頁和多窗口

Why?

在多個分頁或多個窗口打開你的網頁，會發現一些有趣的安全性bugs, 數據刷新問題，或則多個cookie的混亂。

一個常常忽略的測試點就是：在同一Session下，在多個分頁，多個瀏覽器窗口打開頁面。這是爲了檢查應用對於同一用戶（或不一樣用戶）在一樣session token場景下，在不一樣分頁/窗口的處理。

不少站點是使用cookie來存儲Session IDs和其餘一些數據的，所以頗有可能會發現一些錯亂數據，seesions或安全訪問的問題。這些錯誤信息顯示，安全漏洞，或功能沒有人預期地那樣，這些都會很明顯的。

How?

這裏有個簡單的發現安全缺陷的例子。

打開Firefox, 在一個分頁裏登入你的系統。在一個新分頁中打開一樣的頁面，這兩個分頁被認爲在同一個Session中。在第二個分頁中，點擊「退出」，而後第一個分頁中，作一些其餘操做。看看，是直接退出了，仍是讓你作這些操做。大多數狀況下，會讓你退出的。

在不少狀況下，可能會存在同一瀏覽器下登入兩個不一樣帳戶，致使不一樣分頁下數據交叉。

看一個真實的案例。

我在分頁1下以Rob的身份登入網上銀行，在分頁2下以Dave的身份再次登入。接着，回到分頁1，點擊頁面上的連接，我看到了Dave的信息，而Dave看到了個人信息。這是由於混亂的session數據存儲在同一個cookie文件中，這兩個分頁共享的同一cookie文件。

不僅僅是身份驗證的問題。

在不一樣的分頁中，分別往購物車中添加商品，檢查一下購物車裏的商品是否和你已添加的一致。

在不一樣的瀏覽器中，是否是以不一樣的Seesion登入的？

是否是經過在不一樣分頁中操做，來繞過前端驗證和限制？

多個分頁測試最好的方法就是：在多個分頁中打開你的應用，檢查在一個分頁中改動，是否會影響另個。在這個過程當中，要關注：數據，狀態，操做由於糟糕的cookie管理，seeson管理而出現問題。

有一些工具能夠幫着檢查請求、響應的內容。Burpsuite安全工具特別有用，若是你想作session劫持的話。Firecookie是一個FireFox插件，能夠顯示有哪些cookies和cooke的內容。

小建議

有些支持多分頁的瀏覽器，能夠打開多個分頁，而後將一個分頁拖拽出當前窗口，成爲一個新的窗口，這兩個窗口是在同一session下的。在測試的過程當中，能夠經過」Ctrl」+」tab」鍵來切換檢查這兩個分頁的內容。

但須要注意的是，並非全部的瀏覽器都認爲這個新出來的窗口，在同一個Session下的。

其餘有用的連接

A list of testing tools - https://en.wikipedia.org/wiki/Load_testing/
jMeter - http://jmeter.apache.org/
Good site about cookies and sessions - http://www.allaboutcookies.org/cookies/session-cookies-used-for.html/
Session Hijacking - http://en.wikipedia.org/wiki/Session_hijacking
Security implications of cookies - http://it.toolbox.com/blogs/securitymonkey/successful-hacking-with-xsscookies-session-ids-11098
Burpsuite - http://portswigger.net/burp/
Firecookie - https://addons.mozilla.org/en-us/firefox/addon/firecookie/