第一節 測試的一般步驟 

性能測試的工作是基于系統功能已經完備或者已經趨于完備之上的，在功能還不夠完備的情況下沒有多大的意義（后期功能完善上會對系統的性能有影響，過早進入性能測試會出現測試結果不準確、浪費測試資源）；因此，性能測試首先是基于功能測試的，你必須了解其功能實現才能開展性能測試。

我們還是來逐步分解說明：

一個被測系統來了，需要分三塊來分析

○ 入口：需要怎么發送請求，施壓方應該施加多大的壓力，用什么方法施壓；

○ 被測系統：系統怎么應對單個請求，系統業務流程是怎么樣的，系統網元節點、數據流向等，整體性能需求有沒有，需要考察哪些指標，怎么監控；

○ 出口：接收數據有哪些，怎么獲取和比對；

是不是感覺就像功能測試差不了多少？是的，就是先分析單個用戶的功能流程以及系統的數據流向（包括后臺的數據流向）結構圖，然后再考慮大量的用戶操作。

那么一般系統的性能測試步驟大體如下：

1） 確認測試目標

2） 分析被測系統業務需求

3） 分析被測系統的系統結構

4） 分析被測系統的性能測試點

5） 設計測試方案、檢測方案和測試案例

6） 選擇測試工具

7） 測試腳本開發

8） 測試執行

9） 測試結果分析

10） 測試調優、測試驗證、測試分析

11） 測試報告

 第二節 測試準備 

測試準備工作越充分后期的測試執行越順利，一般測試準備工作如下：

1） 確認測試目標

2） 分析被測系統的業務

3） 分析被測系統的結構

4） 分析被測系統可能產生性能瓶頸的節點

5） 設計測試方案、檢測方案和測試方案

我們分步來研究一下：

1、確認測試目標

拿到一個任何任務首先都要確認任務的目標是什么。如果不知道目標，你所做的任何努力得到的結果有可能都不是最終所需要的結果。

性能測試也一樣，它首先是有一個目標的。無論是你是隨機測試想看看系統的當前性能情況，還是奔著對系統進行優化而去的，還是檢驗一下系統的性能是否滿足需求，等等，這些都是你再做事情之前的一個目標。

你后面所做的一切事情，從分析到方案和案例設計，到測試執行監控，再到最后的測試分析和報告，都是要圍繞這個目標展開的。

所以，首要的任務就是確認測試的目標要求，需要達到怎樣的一個測試目的和目標。

有一些測試任務沒有明確的目標或者要求，并不說明它沒有目的和目標，這就需要我們進行溝通和分析了。

溝通就是要和項目組達成一致的目的要求；分析，分析需求，分析系統，最后也是要明確項目或者系統測試任務的目的要求。

2、分析被測系統的業務

曾經在一次面試中，有一位面試官給了我這樣一個題目：“有一個網站，只知道它的總訪問量一天是300萬，怎么測試它的性能？”，大家想一想要怎么設計方案？

------猜想面試官是想面試者回答，正態分布、二八原理等基本的測試原則應用。

我當時沒有回答任何與正態分布、二八原理相關的東西；記得當時面試官對我的回答好像是“蔑視”的笑了笑；可能是覺著“連基本的正態分布、二八原理都不知道，還搞性能測試？”。

其實，性能測試并不是想象的那樣簡單，并不是一個簡單的原理的應用就行的，如果這么容易，那豈不是誰都能搞。

性能測試的基礎是基于系統的業務功能基本趨于穩定，首要的任務就是性能在系統滿足業務功能需求上展開，因此我們必須要分析系統的業務。

不管是普通的網站也好還是比較專業的系統也好，它都是有業務功能需求的，所有的性能測試都要基于這些功能才能進行，脫離了業務功能的性能測試沒有意義。

性能測試所以首要的任務就是分析系統的業務功能，分析系統業務上的性能限制，也就是業務需求。

那么怎么分析系統的業務需求呢？

○ 如果有用戶需求規格說明，首要的任務就是閱讀和理解分析用戶需求規格說明；

○ 如果沒有用戶需求規格說明，那么就需要分析系統功能，提煉出系統的業務需求。如果可能，項目組比較熟悉的人講述一遍是最好的了。

○ 最后無論哪一種，最好的方法就是按照自己的理解畫出系統的業務流程或者系統的功能結構圖，拿到項目組進行確認。一定要進行確認，和整個項目組達成一致的認同。

有人會說，我們自由測試沒有項目組可確認的時候怎么辦？

還是一樣，需要從分析入手。如果不分析，你就不會知道系統的功能數據流向，請求的數據構成，系統的網元結構，以及系統可能出現的瓶頸在哪一個節點，你又怎么進行優化呢？

當然面對一種全新的知識領域的時候，可能需要我們多積累經驗，更多的進行分析；我們可能需要結合實踐，多次實際運行系統或者執行測試，在測試中不斷的進行優化和完善我們的分析過程、分析結果、測試方案、測試開發甚至是測試執行等等。

分析被測系統的業務，有時候不是一蹴而就，需要我們進行多次反復的分析、確認和再分析、再確認，直到把系統弄明白，甚至有可能在測試執行的最后階段你還需要再次進行分析和確認，然后重新規劃測試。

3、分析被測系統的結構

系統的結構和系統的業務一樣重要，不知道系統的網元結構可能就沒有辦法進行監控，就沒有辦法知道瓶頸在哪個節點，就不能進行優化。

分析系統的結構，最好的方法就是項目組提供系統的部署和構成圖；如果項目組不能提供或者沒有項目組，那就需要用TCPDUMP等抓包工具，分析數據流向。

TCPDUMP的使用：

tcpdump tcp -i eth1 -t -s 0 -c 100 and dst port ! 22 and src net 192.168.1.0/24 -w ./target.cap

● tcp: ip icmp arp rarp 和 tcp、udp、icmp這些選項等都要放到第一個參數的位置，用來過濾數據報的類型

● -i eth1 : 只抓經過接口eth1的包

● -t : 不顯示時間戳

● -s 0 : 抓取數據包時默認抓取長度為68字節。加上-S 0 后可以抓到完整的數據包

● -c 100 : 只抓取100個數據包

● dst port ! 22 : 不抓取目標端口是22的數據包

● src net 192.168.1.0/24 : 數據包的源網絡地址為192.168.1.0/24

● -w ./target.cap : 保存成cap文件，方便用ethereal(即wireshark)分析

從第一個節點分析流向到哪，確定第二層的節點；

然后從第二層每個節點分析第三層節點，逐層分析，完善系統的數據流向的所有機構層次和節點；

然后再弄明白每個節點部署的應用程序或者進程隊列；

對每一個節點的應用程序或者進程隊列進行測試監控；

最后才能得出哪些應用或者進程隊列需要進行優化。

弄明白系統的節點構成之外，還需要弄明白各個節點之間的通訊協議和數據格式，后面的測試工具選擇和測試數據準備以及測試腳本開發就需要你明白這些。

這一切的基礎就是要分析和弄明白系統的所有節點，也就是要分析清楚系統的結構。

4、分析系統可能的性能瓶頸

分析系統的業務需求和系統的結構組成，同時預判系統可能存在的性能瓶頸，這是分析中的一個目標；得到預判的性能瓶頸后我們后面需要在監控的時候多注意一下這些節點。

當然有一些常見的可能會是系統瓶頸的節點我們需要注意:

● 登錄，一般系統登錄要進行多種校驗，可能數據交互比較頻繁；

● 下單，搶單、搶紅包這個時候會有一定量的并發需求；

● 大數據的查詢、統計和報表分析，會對系統產生壓力；

● 視頻、動畫等會對網絡產生壓力；

● 消息比較集中的系統功能節點，會對系統產生壓力；

● 一些特殊的業務需求會對系統產生壓力；

常見的瓶頸：

● 數據庫的瓶頸一般在磁盤IOPS過高造成進程阻塞

● 系統進程數過多一般會消耗系統的內存空間

● 消息隊列和緩存服務，開啟持久化后會需要考察磁盤IOPS，不開啟持久化則需要考察內存占用

● 頻繁的管道開辟和銷毀會導致CPU占用較高

● 有部分程序結構上不能利用多個CPU

在分析業務和系統結構的過程中，我們就需要考慮這個業務點或者結構點會不會有大量的數據訪問，會不會產生壓力，我們的設計會不會產生性能瓶頸。

5、確方案和案例設計

測試方案的以及最后測試方案文檔的形成，實際就是上面所有分析工作的總結。

你寫測試方案的過程就是明確測試目的目標、分析業務需求、系統結構以及評估測試方法、測試安排、測試風險等等的過程總結。而這些全部來源于你在測試執行之前的分析，有時候可能你在測試過程中還需要做出一些分析和調整。

測試方案包含了這些你分析和整理的各個方面。

一個好的測試方案包含的內容：

測試目的目標、內容（可能包含業務性能、可靠性、穩定性等等），業務需求目標，系統業務構成，系統節點構成，測試方法流程，需要監控的指標要求和節點等等。

測試案例，實際上一般需要包含在測試方案中；測試案例，實際上就是普通的業務操作流程，用測試工具或者其他測試手段來模擬大的數據量業務操作，并對系統的各個節點進行監控，獲取監控數據。

預期的監控數據和實際監控數據的對比，滿足要求就是預期要求，實際對比結果就是測試結果。

更多軟件測試相關推薦：

軟件測試更多干貨文章

軟件測試就業培訓

文章來源：網絡  版權歸原作者所有

上文內容不用于商業目的，如涉及知識產權問題，請權利人聯系博為峰小編(021-64471599-8103)，我們將立即處理