任何急功近利的事情都是扯蛋的，要想做好某個專項測試也是一樣的道理，不明白協議本身的工作原理，不深入學習一下就急於上手測試，反而會一路碰壁，測試思路和方法錯了，就算用對工具也是白乾一場，本文就我自己對onvif測試的理解拋一些看法和拙見，歡迎舉手拍磚！一個真實情況是，在沒深刻理解之前，我自己對onvif的測試思路陷入到了較多的誤區，這裡正好也記錄一下。

如何更好地理解onvif？

首先：要想上手Onvif的測試，簡單瞭解onvif是什麼東西是必須的，這裡就不再贅述了，隨便Google一下就能瞭解，但是在做onvif測試之前，作為測試人員，應該有必要知道webservice，這將幫助你更好地理解Onvif。

在onvif的協議介紹中，有這麼一段：

ONVIF規範中裝置管理和控制部分所定義的介面均以Web Services的形式提供。

ONVIF規範涵蓋了完全的XML及WSDL的定義。每一個支援ONVIF規範的終端裝置均須提供與功能相應的Web Service。服務端與客戶端的資料互動採用SOAP協議。

WebService是何物？

Web Services 可以將應用程式轉換為網路應用程式。
通過使用 Web Services，應用程式可以向全世界釋出資訊，或提供某項功能。
Web Services 可以被其他應用程式使用。
通過 Web Services，會計部門的 Win 伺服器可以與 IT 供應商的 UNIX 伺服器相連線。

其實Web Service本身是很古老的東西了，但是onvif的此舉確實給監控安防領域的對通開發帶來了極大的便利，知道了webservice，我們就來看看onvif在監控安防產品中的應用，下面這張圖大致說了這麼一件事情：

onvif在視訊監控中的應用

ONVIF規範向視訊監控引入了Web Service的概念。裝置的實際功能均被抽象為了Web Service的服務，視訊監控系統的控制單元以客戶端的身份出現，通過Web請求的形式完成控制操作。

好，OK，以上這張圖告訴我們一些有用的資訊和事情，可能會為我們的測試帶來思路：

我們通常說的“onvif裝置”“支援onvif裝置接入”指的是什麼？

根據上面這張圖，我們已經知道這裡的onvif裝置類似於Server的角色，它的內部功能全部被抽象成了webservice的服務，也就是說，在真正的開發過程中，有兩種情況：

要開發一款【支援onvif裝置接入】的裝置，程式碼實現的是client

要開一款【onvif裝置】，程式碼實現的是Server

我們拿NVR裝置來講，極有可能的情況是，NVR在onvif協議框架中既作為onvif客戶端，又作為onvif服務端，兩個端框架都應用了，下圖可以說明這一切：

這就告訴我們一條測試線索：

測試線索一：onvif客戶端/onvif服務端，他們扮演的角色是有差異的，隨之而變的是：我們測試工作也應該在搞清楚這點之前再去下手。

我們需要知道的一種場景是，還是拿NVR舉例，我們的NVR需要實現onvif裝置的接入和非onvif裝置的接入，這個時候那些非onvif裝置的廠商會提供一些SDK，供我們獲取一些資訊以便我們將其相容在onvif協議框架中，可以簡單理解為，比如說一個非標準的資訊格式，我們需要給他再次封裝一下，這個時候，我們的NVR裝置同時啟用的是onvif服務端和onvif客戶端兩種模式（這麼描述其實不是很嚴謹，但是我只是想為了說明這個事情），真實的應用中，NVR裝置中的onvif服務端和onvif客戶端極有可能是這樣的一些場景：

NVR客戶端發出一個Set（設定相關的請求，有可能是設定時間什麼的），NVR裝置中的onvif服務端就要負責解析，根據外廠商提供的SDK中的API對前端裝置完成設定；同樣的，這個時候如果我需要Get一個相同的東西，那麼，我需要從外廠商SDK中對應的API獲取一些資訊轉化成標準的onvif，然後傳回我們的客戶端。

-----------------分割線--------------------

NVR裝置作為onvif客戶端的可能場景：這個時候前端裝置往往是onvif服務端，我們的NVR裝置需要開啟【支援onvif裝置接入】，好讓我們去讀取IPC裝置的一些資訊，包括請求碼流等之類的東西。

-----------------分割線--------------------

NVR裝置作為onvif服務端的可能場景：這個時候往往需要實現的是NVR本身的onvif，用於我們NVR客戶端去呼叫資訊使用，比如我們呼叫NVR裝置的名稱等之類的東西。

-----------------分割線--------------------

NVR裝置作為onvif客戶端和服務端的可能場景：我們需要做一些set操作，包括往下相容一些非onvif的前端裝置，需要做一些資訊格式化的轉換。(上面提及到了)

說到這裡，我們聊一些題外話

通常在開發過程中，藉助強大的組合：c++/gsoap可以快速完成上述框架的搭建。

一般會根據onvif的wsdl生成一個onvif原始碼框架，原始碼框架包括存根Stub->對應客戶端和提供soap服務的Skeleton->對應框架，然後需要在裡面實現各種方法。

這就隱含地告訴我們，雖然介面是標準的，但是各個廠商對協議的理解和實現方式不同會導致一些差異。

當然了，這個過程本身十分的複雜，我們沒必要深究下去，那麼，我們該做什麼？

明確測試目標 ->摸清onvif角色(服務端,客戶端)->選擇工具和場景->進行測試

步驟一：

還是拿NVR裝置舉例，這個等於是我們首先明確了測試目標。

------------步驟一 Done----------------

步驟二：

NVR裝置通常擔任了onvif的兩種角色，這裡我們等於是需要明確角色

當NVR裝置作為onvif服務端時，我們關注：

1.其實現的介面是否能夠返回正確的資料。

針對資料正確性這一點，有一種快速的類Mock方法就是：要麼利用現成的工具，要麼自己寫相關的請求介面，然後堆砌這塊的自動化測試用例，這樣來講會高效很多，不過Gsoap的WSDL比較隱蔽，第二種方法成本消耗稍大。推薦現成工具：Onvif Test Tool，利用這款官方工具，我們能夠快速保證我們的介面質量，他提供了一套自動化執行的Case，你甚至可以單獨除錯某一個介面，包括請求視訊瀏覽等，一些常規的測試項都能在這款官方工具中找到，對於測試onvif PU 裝置而言，無疑是最速度，上手最容易的onvif測試工具

---------------- 第三方的ODM( Onvif Device Manager)------------

這是一個第三方的onvif測試工具，專案託管在SF上，是免費使用的，在測試實時視訊瀏覽，解析度設定等內容時，個人認為比官方的工具要來的方便的多，有一點不好的是，ODM目前好像不怎麼支援Discovery（不會主動發現onvif裝置），但是好在他有手動新增的方式，我目前是這麼做的：用官方工具去發現裝置，然後在ODM中手動新增onvif裝置並進行測試。

親測結果：對於核心功能的測試（視訊瀏覽）來講，ODM絕對可以勝任了。

2.介面的穩定性（大量客戶端接入的同時是否大量呼叫了一些NVR裝置本身實現的onvif？介面頻繁呼叫是否穩定？）。

根據我們之前分析的一些場景，不排除這兩種場景（甚至更多）存在的可能性，那麼這個時候，藉助單獨的工具可能就無法勝任了，好在我們上層也有一些可以呼叫webservice的辦法，實在不行，自寫一個對應的工具，理論上應該也是可行的。

當NVR裝置作為onvif客戶端時，我們關注：

這個時候，首先明確，我們的角色是請求發起者，所以我們需要驗證：

我們的請求格式是否正確，通過這個請求，我們能不能得到自己想要的資訊，這個時候往往需要對裝置本身的業務介面呼叫非常熟悉，可以跟開發多多溝通，比如，我們需要測試NVR處理非onvif前端裝置接入的時候，我們通過廠家SDK包實現的轉換能否得到正確資料，從功能測試角度而言，這一點往往會遇到一個高成本的問題：

這麼多不標準的外廠商裝置，我們都要一一測試嗎？從理論上來講，最好是這樣的，但是工作量可想而知，(但是，目前看來，從系統測試角度而言，沒有更好的辦法)可見，監控安防領域快速推進標準化工作是一舉多得的事情。

-----------步驟二 Done------------

當然，其實還有一些其他我們熟悉的場景，歡迎大家補充。

碼了這麼多字，我自己都已經很混亂了（文中肯定有很多錯誤的地方），感謝讀到這一行的同事，希望能夠得到你們的批評和指導！