SOA服务测试内容及环境搭建
SOME/IP协议底层通过以太网实现，基于service的控制器之间对服务的调用流程，以及基于service的控制器和基于信号(signal)的控制器之间对信息的传输，都需要在软件开发过程中进行验证，一般分5个方面测试SOA的性能。
- SD测试：服务的订阅/发布测试
- 接口测试：测试服务的每一个Interface，以及Interface对应的参数
- 功能测试：测试特定输入场景下的SOA功能输出
- 压力测试：多个客户端同时调用某个服务的测试
- 系统测试：服务的嵌套调用
进行SOA测试首先要能与DUT建立通讯（CAN(FD)/LIN/以太网），能控制DUT上下电和唤醒，可以参考以下的测试拓扑来监控DUT的通讯，同时模拟传统的CAN(FD)/LIN网络节点，以及服务的client/server与DUT建立连接，测试DUT实现SOME/IP服务的状态。
SOA服务接口测试
前置：需要提供服务接口的需求规范、服务矩阵(Ethernet Matrix)、服务数据库(Arxml)，如果涉及到S2S（service to signal）的接口，也要提供相关的CAN(FD)/LIN数据库文件。
测试需求：
以BodyDoorLock服务的RR method接口LockReq为例，DUT作为server，Tester模拟client。接口包含两个请求参数（Source，Req），和一个响应参数（Result）。
测试规范：
根据需求规范的描述设计测试用例，需要覆盖接口的通讯机制，接口参数值以及S2S。可以参考思维导图的方式解析需求，并设计测试用例。
测试工程：
首先，要在CANoe工程中添加SOME/IP数据库文件，在CANoe界面点击“Simulation > System and Communication Setup > Import Data Source > 选择对应的Arxml文件 > Finish”。然后在“System Explorer”中，绑定BodyDoorLock为SOME/IP服务。
CANoe工程导入对应的数据库之后，可以跟DUT自动建立服务的发布和订阅，也可以自动的解析服务接口的参数。测试工程师不需要考虑底层逻辑的实现，即服务发现（Service Discovery）和序列化等过程，只需要考虑接口层的使用即可。
其次，在CAPL脚本中实现接口的调用和响应参数的检查，开发测试脚本如下：
作者： 千里和他的软件测试
