任何急功近利的事情都是扯蛋的，要想做好某个专项测试也是一样的道理，不明白协议本身的工作原理，不深入学习一下就急于上手测试，反而会一路碰壁，测试思路和方法错了，就算用对工具也是白干一场，本文就我自己对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 Services 平台是 XML+HTTP。
Web services 使用 XML 来编解码数据，并使用 SOAP 来传输数据。
其实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绝对可以胜任了。
补一下ODM的SF下载地址:http://sourceforge.net/projects/onvifdm/?source=directory
2.接口的稳定性（大量客户端接入的同时是否大量调用了一些NVR设备本身实现的onvif？接口频繁调用是否稳定？）。
根据我们之前分析的一些场景，不排除这两种场景（甚至更多）存在的可能性，那么这个时候，借助单独的工具可能就无法胜任了，好在我们上层也有一些可以调用webservice的办法，实在不行，自写一个对应的工具，理论上应该也是可行的。
当NVR设备作为onvif客户端时，我们关注：
这个时候，首先明确，我们的角色是请求发起者，所以我们需要验证：
我们的请求格式是否正确，通过这个请求，我们能不能得到自己想要的信息，这个时候往往需要对设备本身的业务接口调用非常熟悉，可以跟开发多多沟通，比如，我们需要测试NVR处理非onvif前端设备接入的时候，我们通过厂家SDK包实现的转换能否得到正确数据，从功能测试角度而言，这一点往往会遇到一个高成本的问题：
这么多不标准的外厂商设备，我们都要一一测试吗？从理论上来讲，最好是这样的，但是工作量可想而知，(但是，目前看来，从系统测试角度而言，没有更好的办法)可见，监控安防领域快速推进标准化工作是一举多得的事情。
-----------步骤二 Done------------
当然，其实还有一些其他我们熟悉的场景，欢迎大家补充。
码了这么多字，我自己都已经很混乱了（文中肯定有很多错误的地方），感谢读到这一行的同事，希望能够得到你们的批评和指导！
8183
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
