在工作中，測試人員經常接觸的是功能測試（手工測試），俗稱點點點，大有一種我會點點點，便能走遍天下的硬氣。
無可厚非，如果會點點點，也能說明這個人會做事。
往往有一種現象，某天，領導心血彭拜走過來，xx啊，甲方客戶讓我們提供乙份效能測試報告，你趕緊做一下測試，寫乙份報告。。。
此時，相信很多只做功能測試的人，就懵逼了~
不做？那不可能，甲方爸爸要，必須得給！！！
此時，要想一下，從哪些方面入手去做，還能做好！
我這邊大概提供幾種方法，供大家擇優而取。
方法一效能測試（響應時間）——秒錶計時
這是乙個很笨的方法了，但是起碼能幫助你初步解決問題，操作步驟也很簡單了，基本需求也能達到了。
1、準備乙個秒錶（手機）；
2、羅列一下系統的所有典型頁面；
3、點選乙個頁面，目測全部載入出來，秒錶計時結束；
4、記錄時間。
方法二效能測試（響應時間）——控制台（f12）
這個也是乙個很基本的方法了，怎麼說呢，測試人員要提高自己只會發現問題的本領，就勢必要學會定位問題，定位問題最基本乙個技能，就是要會看控制台。
廢話不多說，上圖。
方法三效能測試（負載、壓力、響應時間）——借助效能測試工具
效能工具loadrunner（沒圖）、jmeter（圖示）
方法四效能測試——寫**
比如「post」方法，登入、提交等，針對這些功能，編寫**進行效能測試~
例項沒有~
（反正，最後一種，我還在修煉中~）
效能測試之 響應時間
響應時間 網路傳輸時間 請求 伺服器處理時間 一層或是多層 網路傳輸時間 響應 頁面前段解析時間 響應時間 呈現時間 網路傳輸時間 伺服器端響應時間 應用延時時間 呈現時間 其實主要說的瀏覽器對接收到資料的乙個處理展示的過程。幾年前大家都在用ie，如果頁面顯示比較慢，我們肯定不會怪罪ie，只會怪罪電...
效能測試基礎（五）響應時間
站在使用者角度來說，你可以將軟體效能看作是軟體對使用者操作的響應時間。說得更明直白點，對使用者來說，當單擊乙個按鈕或鏈結，從使用者單擊開始到應用系統把本次操作的結果以使用者識別的方式展示出來，這個過程所消耗的時間就是使用者對軟體效能的直觀印象。我們需要對這個過程進行分解，才能得到你真正想要的響應時間...
效能測試 99線響應時間
隨著吞吐量的增大，響應時間會逐漸變長，當達到最大吞吐量之後，響應時間會開始急劇飆公升，尤其是後面堆積佇列中等待的請求 如果僅僅是關注平均值，由於大部分請求的響應時間還是相對較短，有一部分介面可能是10ms級別，慢請求往往只佔乙個很小的比例，所以從平均值中分析資料時，慢響應的介面響應時間被平均了。但實...