[譯]36 Days of Web Testing(三)

時間 2019-11-15

標籤 days web testing 欄目 HTML 简体版

原文原文鏈接

Day 14: Automate the tedious

Why ?

有些時候，web測試仍是蠻單調乏味的，在開始測試前，你可能要必須跳轉到一個特定的表單頁面，或則爲了獲得一個特定的頁面（或配置），你必須準備不少數據。php

這種場景下，我發現經過selenium IDE進行UI測試的錄製、回放，經過一些簡單的SQL腳原本造數據，可使測試準備工做特別有高效。html

經過這些工具，能夠很簡單、快速的，來到你想測試的點（test point）web

PS：這個感同身受啊，舉個實際工做中的例子，好比我要測試退款業務（test point爲退款），但在申請退款前，這筆訂單必須已經支付、清算完成sql

How?

Selenium IDE是Firefox的一個插件，如何使用這個插件錄製UI自動化腳本，能夠查看官方的在線文檔。數據庫

能夠錄製你在訪問站點時所作的操做，頁面跳轉，後續若是須要，就能夠回放這些步驟了。瀏覽器

舉個例子，我須要測試多用戶場景下的Cookies管理，這時候就須要以不一樣的用戶不斷的作「退出」和「登入」操做。安全

這種狀況下，我寫了個自動化腳原本實現，一個用戶的「登出」和另外一個用戶的「登入」。服務器

若是手動作的話，就須要重複的機械點鼠標。須要注意的是，我並無用Selenium來測試，只是用selenium來作測試準備工做的自動化，和幫我點鼠標，Cookie管理的校驗，我來test的。網絡

建議

若是學會了如何在Selenium IDE裏Debug自動化腳本，就能夠更快的錄製和回放腳本了。ide

有一點須要注意，若是你但願經過錄制UI自動化腳本，並依靠這些來作迴歸測試，你要想清楚。大多數狀況下，這是不靠譜的。

另一點，你能夠經過SQL腳原本作測試前的數據準備工做。

連接：

SQLYog Tool - http://www.webyog.com/en/downloads.php
SQL Learning at W3 Schools - http://www.w3schools.com/sql/default.asp
Selenium Debugging - http://seleniumhq.org/docs/02_selenium_ide.html#debugging
Selenium - http://seleniumhq.org/

Day 15: Soap Testing

Why ?

若是你的應用使用了Web services,那麼它就可能正在使用SOAP協議

下面是維基百科對SOAP的定義：

簡單對象訪問協議（SOAP，全寫爲Simple Object Access Protocol）是交換數據的一種協議規範，使用在計算機網絡Web服務（web service）中，交換帶結構信息。SOAP爲了簡化網頁服務器（Web Server）從XML數據庫中提取數據時，節省去格式化頁面時間，以及不一樣應用程序之間按照HTTP通訊協議，聽從XML格式執行資料互換，使其抽象於語言實現、平臺和硬件

網上有不少關於SOPA封裝,編碼規則,但最基本的它如何傳遞消息的.

你能夠只關注UI層面的測試,而忽略底層的SOAP交互, 但在UI下面,有更多值得你探究的東西.甚至, 測試時均可以不須要UI, 直接測試web services。

你能夠直接和web servcice交互，測試全部的點。傳遞一個髒數據、損壞的數據（corrupt date），無效數據，傳遞不少數據，較少數據。你甚至能夠寫一個自動化腳本以你指望的方式整夜的綁定web services

How ?

測試SOAP服務最簡單的方法就是使用一個SOAP UI工具，它的UI界面很整潔，有不少在線文檔提供直觀的幫助。

SOAP UI的具體指令能夠查看它的官方文檔，但最基本的包括，鏈接一個web service,查看這個web service提供的元素，接着你就能夠想一些測試點了。

建議：

和Http services同樣，SOAP UI也是RESTful的。

連接：

SOAP UI - http://www.soapui.org

Day 16: See the source 查看頁面源代碼

Why ?

頁面源代碼是發現bugs的好地方，能夠對感興趣的代碼塊進行深刻探究，看有沒有潛在的安全漏洞，或則信息泄露。

我所說的源碼是指你所測試的頁面的源代碼。源碼能夠看出你的應用是如何和頁面組合在一塊兒的。

頁面源碼可能會包含註釋、用戶名和密碼，經過蛛絲馬跡能夠看出所引用的方法，後臺實現，從安全角度來看這些信息可能會有幫助。頁面源碼裏還可能包含對公司、用戶各類讚美、挖苦、諷刺的註釋，設置有些註釋裏還會有一些笑話，或則提到一些部分實現的功能。

頁面源碼裏還可能有安全URLs和證書等。

How ?

在瀏覽器裏打開你的頁面，點擊工具欄的「查看」按鈕，選擇「查看頁面源碼」。

頁面源碼就會在瀏覽器窗口打開，簡單瀏覽下，而後對你感興趣的代碼塊進行深刻閱讀。

建議：

也能夠在瀏覽器窗口，右擊，選擇「查看頁面源碼」。

連接：

Andréas Prins article on Hidden Treasures - http://www.thetestingplanet.com/2010/12/hidden-treasures-foreveryone/
Firefox Extension to visualise page source - https://addons.mozilla.org/en-US/firefox/addon/view-source-chart/

Day 17: Explore the competition 競爭對手研究

Why ?

看看規範手冊、聲明文檔，研究下用戶在使用你的系統前還用過那些系統，作下競爭對手研究，這些均可以幫着想出更多的測試點。

研究下競爭對手的產品和服務，這樣的學習將有助於你的測試

在測試行業，有個話題一直討論的很激烈：一個測試工程師對於所測試的站點，有沒有必要提出改進性的意見或建議。

個人答案是，Yes ，絕對應該。

我認爲，若是一個測試工程師依據本身的知識、看法能夠提出使得產品變得更好的方案，若是他不提的話，這將會使他錯失增加本身看法的機會。

測試並非快樂的道路檢查，貼着標記的盒子，不是預先肯定好的路。在測試過程當中，須要應用到你的判斷、看法、經驗和掌握的知識。

這些觀點，看法，若是有助於提高產品，那麼就應該提出來，相互溝通，交流。

若是有機會改進這個軟件，使它更好用，在市場上更具競爭力，最終成爲一個成功的產品，難道不就是增長了產品的價值嗎

不要想着，已經有其餘人在研究競爭對手了，也不要以爲以前的人已經考慮到了用戶習慣。

經過比較產品獲得的信息，將有助你想出新的測試點，想出改善產品功能的辦法，想出使你的產品脫穎而出的辦法。這是一個很好的，可以幫助你提高的測試技能。

若是單純是模仿競爭對手，這並非一個很好的商業策略。

你能夠經過從他們產品信息中收集使用案例開始，並以新的思路來考慮本身的產品。

同時，這也能加深你對所從事領域的理解。

How ?

在網上能夠很快地搜索到競爭對手的網站，你能夠讀讀他們的marketing材料，註冊下載試用版，對他們的產品和領域有更深刻了解。

建議：

可能你會發現你的產品或站點在「二選一」站點的列表中，好比http://alternativeto.net/。這些站點會列出可供對比選擇的產品，這是一個很好的途徑來看你的競爭對手在作些什麼？人們是怎麼評價他們的產品的。 PS，在這網站尚未alipay的信息。輸入paypal，能夠看到國外第三方支付的公司列表。