本文章轉載于搜狗測試
選擇題
下列哪些產品的測試屬于web測試？
A. 12306網站B. 搜狗輸入法C. 搜狗瀏覽器D. 搜狗壁紙E. ie1.0
我的觀點
要回答這道問題，首先要明確什么是web測試？
兩年前的我會這樣回答：網站的測試就是web測試；
而現(xiàn)在的我會這樣回答：互聯(lián)網產品的測試是web測試。
那什么是互聯(lián)網產品呢？
互聯(lián)網產品經理？肯定不是 :-D
我把互聯(lián)網產品定義為有網絡請求的軟件（ps：這個理解可能不準確），按照我的理解，那開篇的這道題就有答案了，A一定是，B、C、D也是。
當代的互聯(lián)網產品，在優(yōu)化用戶體驗的路上越走越遠，這些產品會通過發(fā)送網絡請求的方式，在降低程序自身大小的同時提高用戶體驗。
ie1.0：為什么沒有我？
我：個人認為，作為ie的第一個版本，應該只是個本地的腳本解釋器吧（可能是對ie有偏見導致我這么想的。。。希望有了解的同學可以為ie正名）。
回到正題：web測試的關注點有哪些呢？
我們做為一名測試工程師，對功能、性能、兼容性、UI、安全、接口，這些名詞應該都不陌生，而每個人對這些名詞都有各自的理解。
下面先來說說我總結的功能測試關注點：
什么是功能測試？
問：這個產品要實現(xiàn)的功能是哪來的？
答：產品經理在需求文檔中定義的。
問：那我們怎么進行功能測試呢？
答：根據需求文檔寫用例，然后執(zhí)行用例。
說起來功能測試就這么簡單，那為什么還會有犯迷糊的同學呢？因為功能測試難就難在設計用例的方法和執(zhí)行用例的方法上。關于設計用例和執(zhí)行用例的方法，大家可以翻閱之前關于黑盒測試的文章，會有詳細的介紹，而今天我們說說頁面功能測試的關注點：
鏈接
表單
頁面寫法
鏈接
一個網站是由千萬個頁面組成的，那么連接他們的就是“鏈接”，所以鏈接就是功能測試中的一個關注點。鏈接有很多種寫法來實現(xiàn)：直接寫個連接、js跳轉、服務器跳轉等等。一般的門戶網站，例如搜狐主頁，不用想就知道，一個頁面上有成千上萬個鏈接。如果一個一個點擊去驗證，那效率就太低了。所以測試這些鏈接，我們一定要用工具。這里介紹一個掃死鏈的工具，名叫“xenu”，他能快速的查出一個頁面中的死鏈，而且可以檢查多級鏈接（但是一定要記得設置掃描級別，不然它會像爬蟲一樣掃上百層的鏈接，這樣會導致網絡癱瘓的）。
表單
表單是web頁面里最容易出問題的地方之一，因為他有很多危險的地方：post表單數據的時候、操作數據庫的時候、接收返回值的時候；表單數據的格式是我們每次執(zhí)行測試時都會驗證的地方。對一個文本框設計用例，相信大家都有一籮筐的方法，邊界值、等價類劃分、多文本框時正交實驗法等等，這里就不贅述了。我想說的是一些容易疏忽的地方，例如：注入js腳本、注入sql腳本、輸入單獨的特殊符號（例如：一個雙引號，一個點）、輸入一個空格，一個大括號等等，這些都是要特別注意的；我們的前端開發(fā)一般會通過正則來過濾這些特殊符號，但是可能會有一些遺漏，而一旦這些異常字符或者字符串順利通過前端的過濾，進入后臺，而后臺同樣沒有做類似的處理，那后果是很嚴重的。12306官網曾經爆出的用戶數據泄露，就是sql注入導致的，chrome瀏覽器的第一個bug，地址欄輸入一個“.”，導致崩潰，這些都是活生生的例子，所以作為測試，一定不能放過每一個小符號。
頁面寫法
怎樣才能說一個前端開發(fā)是個高手？
頁面代碼寫的易讀、注釋清晰、代碼復用度高，這是首先能想到的。再深入一點：頁面符合w3c標準，靜態(tài)文件引用合理，頁面加載速度快，再高手一點呢？嚴格遵守雅虎34條軍規(guī)---這個應該很少有開發(fā)能做到吧 。
那對于我們測試要關注哪些地方呢？
與開發(fā)確認頁面里每一個引用的文件都是有用的，因為一個沒用的引用會影響頁面的加載速度；
header的第一行一定要是聲明字符集的標簽，如果不是可能會導致在聲明字符集之前加載的頁面元素亂碼（當代瀏覽器會優(yōu)化頁面的加載順序，優(yōu)先加載字符集聲明，但是優(yōu)良的傳統(tǒng)還是要保持下去）；
JS最好放到頁面的最后，一些需要先加載的js最好要抽離出來放到header里，這樣能保證頁面更快的展現(xiàn)出來；
js和css在上線前要做加密。查看一下搜狗主頁的源碼，你會發(fā)現(xiàn)一堆密密麻麻的代碼，這就是加密過的，好處是減小頁面的體積更利于網絡傳輸、并且可以提高我們代碼的閱讀成本；
頁面的js和css盡量外部調用。好處是頁面的靜態(tài)文件理論上都是可緩存的，外部調用提高頁面的相應速度的同時還能減小服務器的壓力，而且比起那些都寫在一起的代碼更易維護；
可能有人會說，這些都是開發(fā)要考慮的事兒??？但是作為一名優(yōu)秀的測試工程師，要做的不僅僅是發(fā)現(xiàn)Bug，而是要給產品提出合理化的改進建議；給開發(fā)提出效率更高、成本更低的實現(xiàn)方案；共同持續(xù)優(yōu)化我們的產品；
