小夕瑶-优快云博客

原创 CAPL脚本获取电脑时间

time now的最大值:2^32*10微秒=11小时55分钟49秒672毫秒96微秒;如果是长时间压力测试的时候使用该函数需要注意处理最大值以免测试结果的误判。如果是长时间压力测试的时候建议使用timeNowInt64。没有本质区别，只不过返回值一个是整形，一个是浮点型。纳秒级的CANoe工程启动到执行到该函数的时间;没有本质区别，只不过返回值一个是整形，一个是浮点型。返回值的单位都是10ms。1.timeNow():CANoe四工程启动到执行到该函数的时间。

2024-12-19 17:59:46 221

原创 SOMEIP_ETS_164: SD_SubscribeEventgroup_with_unallowed_option_ip_2

验证DUT能够拒绝一个在请求中包含错误参数（端点选项中包含无效IPv4地址，即111.111.111.111）的SubscribeEventgroup消息，并以SubscribeEventgroupNAck作为响应。本测试用例旨在确保DUT遵循SOME/IP协议，当接收到一个在端点选项中包含无效IPv4地址（111.111.111.111）的SubscribeEventgroup消息时，能够正确地拒绝该订阅请求。2、DUT：发送SubscribeEventgroupNAck以拒绝订阅请求。

2024-12-06 15:23:01 152

原创 SOMEIP_ETS_166: SD_TestFieldUINT8

本测试用例旨在确保DUT的ETS能够响应Tester的请求，正确地使用Getter方法获取TestFieldUINT8的值，以及使用Setter方法设置新的值。验证DUT能够通过Getter和Setter方法正确地发送和接收TestFieldUINT8字段的值。1、TESTER: 触发DUT通过Getter方法发送TestFieldUINT8字段。4、DUT: 返回TestFieldUINT8字段，值为测试者在步骤3中设置的值。DUT: 返回TestFieldUINT8字段，值为测试者在步骤3中设置的值。

2024-12-06 15:21:22 144

原创 SOMEIP_ETS_167: SD_TestFieldUINT8Array

本测试用例旨在确保DUT的ETS能够响应Tester的请求，正确地使用Getter方法获取TestFieldUINT8Array的值，以及使用Setter方法设置新的值。验证DUT能够通过Getter和Setter方法正确地发送和接收TestFieldUINT8Array字段的值。DUT: 返回TestFieldUINT8Array字段，值为测试者在步骤3中设置的值。DUT: 返回TestFieldUINT8Array字段，值为测试者在步骤3中设置的值。

2024-12-06 15:20:01 199

原创 SOMEIP_ETS_168: SD_TestFieldUINT8Reliable

本测试用例旨在确保DUT的ETS能够响应Tester的请求，正确地使用Getter方法获取TestFieldUINT8Reliable的值，以及使用Setter方法设置新的值。这些操作需要是可靠的，意味着设置和获取的值应该是一致的，并且能够被DUT正确地处理和返回。验证DUT能够通过Getter和Setter方法正确地发送和接收TestFieldUINT8Reliable字段的值，并且这些操作是可靠的。4、DUT: 返回TestFieldUINT8Reliable字段，值为测试者在步骤3中设置的值。

2024-12-06 15:18:15 262

原创 SOMEIP_ETS_171: SD_Unicast_FindService

本测试用例旨在确保DUT能够正确处理单播FindService消息请求，并为请求的服务提供至少一个单播OfferService消息作为响应。验证DUT能够响应Tester发送的多个单播FindService消息，并至少回复一个单播OfferService消息。1、TESTER: 发送多个单播FindService消息以请求DUT提供的服务。2、DUT: 发送至少一个单播OfferService消息。DUT: 发送至少一个单播OfferService消息。

2024-12-06 15:16:28 123

原创 SOMEIP_ETS_172: SOMEIP_ETS_173: SD_Unicast_SubscribeEventgroup

本测试用例旨在确保DUT能够正确处理单播订阅请求，并对两种不同的端点选项配置发送单播订阅确认。验证DUT能够对Tester发送的单播订阅请求做出响应，发送单播订阅确认消息。2、DUT: 发送单播subscribeEventgroupAck。4、DUT: 发送单播subscribeEventgroupAck。DUT: 发送单播subscribeEventgroupAck。DUT: 发送单播subscribeEventgroupAck。

2024-12-06 14:53:29 232

原创 SOMEIP_ETS_174: SD_Unknown_Option_type

本测试用例旨在确保DUT遵循SOME/IP协议，当接收到一个引用了未知选项类型的SubscribeEventgroup消息时，能够正确地拒绝该订阅请求。验证DUT能够拒绝一个引用了未知选项类型的SubscribeEventgroup消息，并以SubscribeEventgroupNAck作为响应。测试者：发送带有未知选项类型的subscribeEventgroup。DUT：发送subscribeEventgroupNAck。DUT：发送subscribeEventgroupNAck。

2024-12-06 14:49:15 187

原创 SOMEIP_ETS_175: SD_Unreferenced_option

验证DUT能够处理包含所有必需端点选项以及一个不必要的配置端点选项的SubscribeEventgroup消息，并以SubscribeEventgroupAck作为响应。本测试用例旨在确保DUT遵循SOME/IP协议，当接收到一个包含不必要配置端点选项的SubscribeEventgroup消息时，能够正确地处理该消息并确认订阅。1、测试者：发送包含所有所需端点选项的subscribeEventgroup，包括一个不需要的配置端点选项。2、DUT：发送subscribeEventgroupAck。

2024-12-06 14:47:41 148

原创 SOMEIP_ETS_176: SD_Unused_data_after_Options_Array

验证DUT能够正确处理包含在选项数组之后未使用的有效载荷数据的单播SubscribeEventgroup请求，并针对每个请求发送SubscribeEventgroupAck消息。1、测试者：发送带有未使用的负载数据的subscribeEventgroup，紧随选项数组之后（并包含在SOME/IP长度字段中）3、测试者：发送带有未使用的负载数据的subscribeEventgroup，紧随选项数组之后，但未计入消息的总长度。2、DUT：发送subscribeEventgroupAck。

2024-12-06 14:46:10 151

原创 SOMEIP_ETS_177: SD_Unused_data_after_Options_Array_wrong_length

验证DUT能够正确处理单播SubscribeEventgroup请求，该请求在末尾包含未使用的有效载荷数据，且这些数据的长度不包括在SOME/IP长度字段中，并对此发送SubscribeEventgroupAck消息。本测试用例旨在确保DUT遵循SOME/IP协议，当接收到一个在末尾包含未使用数据（且这些数据长度未计入SOME/IP总长度）的SubscribeEventgroup请求时，能够正确地处理这些数据并确认订阅。DUT：发送subscribeEventgroupAck。

2024-12-06 14:42:53 163

原创 SOMEIP_ETS_178: Subscribe_using_wrong_SOMEIP_MessageID

验证DUT能够拒绝一个SOME/IP头部使用错误消息ID进行服务发现的SubscribeEventgroup消息，并以SubscribeEventgroupNAck作为响应。本测试用例旨在确保DUT遵循SOME/IP协议，当接收到一个使用错误消息ID的服务发现SubscribeEventgroup消息时，能够正确地拒绝该消息。1、测试者：发送其SOME/IP头部使用错误Message-ID进行服务发现的subscribeEventgroup消息。DUT：发送subscribeEventgroupNAck。

2024-12-06 14:40:29 101

原创 CAPL脚本数组问题：在数组中查找某一个值或者查找子数组

函数原型： int CompareTwoArrary(byte target[] ,byte source[])为方便阅读，上面已经贴出来的代码，就不再下面贴出来，全部源码到博客开头的git 链接去下载。两数组形同返回值为 0，否则返回值为 -1。

2024-11-21 17:49:45 267

原创 UDP_Padding_02: 验证IUT生成的UDP数据报具有偶数大小的有效载荷，并且在末尾没有填充

本测试旨在确保当DUT被请求生成一个具有偶数大小有效载荷的UDP数据包时，DUT能够生成一个不包含任何填充字节的UDP数据包，且数据包中的数据正确反映了接收到的偶数大小有效载荷值。验证IUT（被测设备）能够生成具有偶数大小有效载荷的UDP数据报，并且在数据报的末尾没有填充字节。RFC 768, “User Datagram Protocol”, “Fields” 部分。1、测试仪：向DUT发送请求，要求生成一个具有偶数的UDP数据包。2、DUT：生成一个没有填充的UDP数据包。

2024-11-14 11:47:46 236

原创 UDP_DatagramLength_01 : 验证IUT是否丢弃了一个截断的UDP数据报

确保当被测设备接收到一个长度字段小于以太网帧实际数据大小的UDP数据包时，该设备将丢弃该UDP数据包。验证被测设备（IUT）是否会丢弃一个截断的UDP数据报。RFC768，格式部分以及关于帧完整性的汽车特定要求。2.DUT：丢弃UDP数据包并且不发送任何指示。1.测试仪：发送一个截断的UDP数据包。DUT丢弃了UDP数据包。

2024-11-14 11:24:35 145

原创 UDP_MessageFormat_02：验证IUT接受包含格式正确的UDP头部的UDP数据包

本测试用例旨在确保当DUT接收到一个包含格式正确UDP头部的UDP数据包时，它能够正确处理该数据包。UDP头部应包含源端口字段、目的端口字段（其值等于DUT的UDP端口）、长度字段（其值等于发送数据报的大小）以及校验和字段（其值等于由DUT计算出的）。验证IUT（被测设备）是否接受包含格式正确的UDP头部的UDP数据包。2、DUT：发送<指示>，包含接收到的UDP数据包的相同内容。1、测试者：发送一个包含格式正确的UDP头部的UDP数据包。RFC768，第4节“格式”。DUT接受UDP数据包。

2024-11-14 09:29:32 107

原创 OMEIP_ETS_175: SD_Unreferenced_option

验证DUT能够处理包含所有必需端点选项以及一个不必要的配置端点选项的SubscribeEventgroup消息，并以SubscribeEventgroupAck作为响应。本测试用例旨在确保DUT遵循SOME/IP协议，当接收到一个包含不必要配置端点选项的SubscribeEventgroup消息时，能够正确地处理该消息并确认订阅。1、测试者：发送包含所有所需端点选项的subscribeEventgroup，包括一个不需要的配置端点选项。2、DUT：发送subscribeEventgroupAck。

2024-10-25 00:00:00 117

原创 TCP_RETRANSMISSION_TO_05：指数退避RTO SYN

如果在预定的RTO时间内未收到对方的SYN,ACK响应，发送方会重传SYN段。根据TCP协议，每次重传后的RTO值应该按照指数退避算法增加，以指数速率增长，而不是线性增长。本测试用例旨在验证DUT（被测试设备）在TCP连接建立过程中，对于发送SYN（同步）段的重传行为是否遵循指数退避算法。这确保了DUT能够在没有收到SYN,ACK响应时，适当地增加重传定时器（RTO）的值，从而适应网络条件的变化并避免过度重传。5、TESTER: 不发送SYN,ACK并验证RTO重传间隔以快速（至少超过线性）速率增加。

2024-10-24 22:55:04 308

原创 TCP_RETRANSMISSION_TO_04：指数退避RTO数据

指数退避算法是TCP协议中用于处理数据段重传的一种机制。当一个数据段发送后，如果在预定的RTO时间内没有收到对应的ACK，发送方会重传该数据段，并将RTO的值加倍。本测试用例的目的是验证DUT（被测试设备）是否正确实现了TCP的指数退避算法。在TCP连接中，当发送的数据段未被确认时，发送方需要根据指数退避算法来增加重传定时器（RTO）的值，以便在保证传输效率的同时减少网络拥塞。6、TESTER: 不发送ACK并验证RTO重传间隔以快速（至少超过线性）速率增加。5、DUT: 超时后重传数据段。

2024-10-24 21:34:20 246

原创 TCP_RETRANSMISSION_TO_03：Karn算法

如果在定时器到期之前没有收到对应的ACK，发送方会重传该数据段，并且将重传定时器的值加倍（指数退避）。本测试用例将验证DUT是否按照Karn’s算法进行重传，并正确调整重传定时器的值。本测试用例的目的是验证DUT（被测试设备）是否正确实现了Karn’s算法，这是一种TCP协议中用于处理数据段重传的算法。12. TESTER: 验证重传计时器的值是之前记录的RTO值的两倍（仅指数退避）12、TESTER: 验证重传计时器的值是之前记录的RTO值的两倍（仅指数退避）11、DUT: 重传数据段。

2024-10-24 21:26:40 305

原创 TCP_OUT_OF_ORDER_05: Stream of full-sized segments

在高效率的数据传输中，尤其是在接收窗口完全打开的情况下，发送方可能会连续发送多个满大小的数据段。根据TCP协议的行为，接收方应该至少对每个第二个数据段发送一个ACK，即使采用了延迟ACK的优化机制。特别是在接收到每个第二个数据段后，DUT应该发送一个ACK，以确保数据传输的可靠性和效率。4. TESTER: 验证对于每个偶数个数据段发送，接收到的ACK数量至少是该数的一半。4、TESTER: 验证对于每个偶数个数据段发送，接收到的ACK数量至少是该数的一半。3、DUT: 为所有数据段发送ACK。

2024-10-24 21:22:24 192

原创 TCP_OUT_OF_ORDER_03：排队乱序段

接收方需要能够识别这些乱序的数据段，并将它们存储在缓冲区中，直到所有先前的数据段都已接收完毕。一旦缺失的数据被接收，接收方应该发送一个确认，确认所有排队的数据段。TCP协议要求接收方能够对乱序的数据段进行排队，直到所有缺失的数据被接收，然后一并发送确认。4、TESTER: 发送个数据段，在SEQ号码的开头留有间隙（好像跳过了一个段）7. DUT: 发送所有排队数据段的ACK，包括最新的一个。7、DUT: 发送所有排队数据段的ACK，包括最新的一个。3、DUT: 发送该数据段的ACK。

2024-10-24 21:19:11 233

原创 TCP_OUT_OF_ORDER_02：计时延迟ACK

延迟ACK是TCP协议中的一种优化机制，它允许接收方延迟发送ACK段，以便能够合并对多个接收到的数据段的确认。然而，延迟ACK必须在一定的时间内发送，以避免发送方超时并重传数据。本测试用例将验证DUT是否实现了延迟ACK机制，并且延迟时间是否符合TCP规范的要求。本测试用例旨在验证DUT（被测试设备）是否实现了延迟确认（delayed ACK）机制，并确保该机制的延迟时间不超过0.5秒。这有助于提高网络的效率，因为它允许接收方合并多个确认，减少网络上的ACK段数量。

2024-10-24 21:16:04 255

原创 TCP_OUT_OF_ORDER_01：Timing full-sized segment

在TCP连接中，接收方收到数据段后，必须及时发送ACK段以确认接收。这是为了告知发送方数据已成功接收，并且可以继续发送后续的数据段。如果ACK段没有在预定时间内到达，发送方可能会认为数据段丢失，并进行重传。本测试用例将验证DUT在接收到满大小的数据段后，是否能够在0.5秒内发送ACK段。本测试用例的目的是验证DUT（被测试设备）在接收到一个满大小的数据段后，是否能够在规定的时间内发送ACK（确认）段。4、TESTER: 验证接收ACK的延迟（减去平均往返时间）小于0.5秒。

2024-10-24 21:11:26 156

原创 TCP_PROBING_WINDOWS_04：开放连接探测ACK

然而，根据TCP协议，即使在这种情况下，发送方也应该保持连接打开，并定期发送探测包（即包含ACK的段，但不含数据），以检测连接状态。特别是当接收窗口长时间为零时，发送方TCP必须能够保持连接打开状态，并且能够继续发送探测包，只要这些探测包得到确认。8. DUT: 只要测试器在每次接收时都确认每一个探测，就继续发送零窗口探测，保持在ESTABLISHED状态。8、DUT: 只要测试器在每次接收时都确认每一个探测，就继续发送零窗口探测，保持在ESTABLISHED状态。6、DUT: 发送零窗口探测。

2024-10-24 10:39:59 139

原创 TCP_PROBING_WINDOWS_03：窗口收缩

如果接收方的缓冲区已满，它可能会发送一个窗口大小为零的ACK段，以通知发送方暂停发送数据。一个健壮的TCP发送方应该能够正确处理这种情况，并在“可用窗口”为负值时停止发送新的数据段。特别是当接收方的窗口大小更新为零时，发送方TCP必须能够健壮地处理这种情况，避免发送数据，以免造成“可用窗口”变为负值。8、TESTER: 导致DUT端的一个应用程序发出一个数据段的SEND请求。7、TESTER: 为第一个段发送带有更新后的窗口值（为零）的ACK。9、DUT: 不发送该段，因为“可用窗口”是负数。

2024-10-24 09:32:28 276

原创 TCP_OUT_OF_ORDER_02：计时延迟ACK

延迟ACK是TCP协议中的一种优化机制，它允许接收方延迟发送ACK段，以便能够合并对多个接收到的数据段的确认。然而，延迟ACK必须在一定的时间内发送，以避免发送方超时并重传数据。本测试用例将验证DUT是否实现了延迟ACK机制，并且延迟时间是否符合TCP规范的要求。本测试用例旨在验证DUT（被测试设备）是否实现了延迟确认（delayed ACK）机制，并确保该机制的延迟时间不超过0.5秒。这有助于提高网络的效率，因为它允许接收方合并多个确认，减少网络上的ACK段数量。

2024-10-23 21:48:36 517

原创 TCP_OUT_OF_ORDER_03：排队乱序段

接收方需要能够识别这些乱序的数据段，并将它们存储在缓冲区中，直到所有先前的数据段都已接收完毕。一旦缺失的数据被接收，接收方应该发送一个确认，确认所有排队的数据段。TCP协议要求接收方能够对乱序的数据段进行排队，直到所有缺失的数据被接收，然后一并发送确认。4、TESTER: 发送个数据段，在SEQ号码的开头留有间隙（好像跳过了一个段）7. DUT: 发送所有排队数据段的ACK，包括最新的一个。7、DUT: 发送所有排队数据段的ACK，包括最新的一个。3、DUT: 发送该数据段的ACK。

2024-10-23 21:46:03 574

原创 TCP_OUT_OF_ORDER_05: Stream of full-sized segments

在高效率的数据传输中，尤其是在接收窗口完全打开的情况下，发送方可能会连续发送多个满大小的数据段。根据TCP协议的行为，接收方应该至少对每个第二个数据段发送一个ACK，即使采用了延迟ACK的优化机制。特别是在接收到每个第二个数据段后，DUT应该发送一个ACK，以确保数据传输的可靠性和效率。4. TESTER: 验证对于每个偶数个数据段发送，接收到的ACK数量至少是该数的一半。4、TESTER: 验证对于每个偶数个数据段发送，接收到的ACK数量至少是该数的一半。3、DUT: 为所有数据段发送ACK。

2024-10-23 21:42:52 299

原创 TCP_RETRANSMISSION_TO_03：Karn算法

如果在定时器到期之前没有收到对应的ACK，发送方会重传该数据段，并且将重传定时器的值加倍（指数退避）。本测试用例将验证DUT是否按照Karn’s算法进行重传，并正确调整重传定时器的值。本测试用例的目的是验证DUT（被测试设备）是否正确实现了Karn’s算法，这是一种TCP协议中用于处理数据段重传的算法。12. TESTER: 验证重传计时器的值是之前记录的RTO值的两倍（仅指数退避）12、TESTER: 验证重传计时器的值是之前记录的RTO值的两倍（仅指数退避）11、DUT: 重传数据段。

2024-10-23 21:36:04 178

原创 TCP_RETRANSMISSION_TO_04：指数退避RTO数据

当一个数据段发送后，如果在预定的RTO时间内没有收到对应的ACK，发送方会重传该数据段，并将RTO的值加倍。本测试用例的目的是验证DUT（被测试设备）是否正确实现了TCP的指数退避算法。在TCP连接中，当发送的数据段未被确认时，发送方需要根据指数退避算法来增加重传定时器（RTO）的值，以便在保证传输效率的同时减少网络拥塞。TESTER: 不发送ACK并验证RTO重传间隔以快速（至少超过线性）速率增加。5. TESTER: 验证RTO重传间隔以快速（至少超过线性）速率增加。DUT: 超时后重传数据段。

2024-10-23 21:33:08 208

原创 TCP_RETRANSMISSION_TO_05：指数退避RTO SYN

如果在预定的RTO时间内未收到对方的SYN,ACK响应，发送方会重传SYN段。根据TCP协议，每次重传后的RTO值应该按照指数退避算法增加，以指数速率增长，而不是线性增长。本测试用例旨在验证DUT（被测试设备）在TCP连接建立过程中，对于发送SYN（同步）段的重传行为是否遵循指数退避算法。这确保了DUT能够在没有收到SYN,ACK响应时，适当地增加重传定时器（RTO）的值，从而适应网络条件的变化并避免过度重传。5、TESTER: 不发送SYN,ACK并验证RTO重传间隔以快速（至少超过线性）速率增加。

2024-10-23 21:30:15 321

原创 TCP_RETRANSMISSION_TO_06：初始RTO

根据RFC 6298，TCP连接建立时，发送方在发送初始的SYN段后，如果在预定的时间内未收到响应，将会重传SYN段。本测试用例将验证DUT在发送SYN段未收到响应时，是否按照RFC 6298的规定使用1秒作为初始RTO值。本测试用例的目的是验证DUT（被测试设备）在TCP连接建立过程中，初始重传定时器（RTO）的值是否符合RFC 6298的规定，即初始RTO应设置为1秒。5. TESTER: 验证DUT是否根据参考RFC使用了超时。TESTER: 验证DUT是否根据参考RFC使用了超时。

2024-10-23 21:28:33 156

原创 TCP_RETRANSMISSION_TO_08：数据段的2*MSL RTO上限

根据TCP协议规范，TCP连接在数据传输过程中，如果发送方在预定的RTO时间内未收到数据段的确认（ACK），将会重传该数据段。当RTO值增加到2倍最大段生命周期（2*MSL）时，发送方应该将RTO的值固定在这个水平，不再增加。本测试用例的目的是验证DUT（被测试设备）在TCP连接中对于数据段的重传行为是否符合TCP协议的规范，特别是在达到最大重传定时器（RTO）值后，是否能够将RTO固定在2倍最大段生命周期（2*MSL）的值。6. TESTER: 验证DUT是否以递增的延迟重复重传，直到重传超时达到2。

2024-10-23 21:22:14 179

原创 TCP_RETRANSMISSION_TO_09：SYN段的2*MSL RTO上限

如果在预定的RTO时间内未收到对方的SYN,ACK响应，DUT将会重传SYN段。当RTO值增加到2倍最大段生命周期（2*MSL）时，发送方应该将RTO的值固定在这个水平，不再增加。本测试用例旨在验证DUT（被测试设备）在TCP连接建立过程中，对于SYN（同步）段的重传行为是否符合TCP协议的规范，特别是在达到最大重传定时器（RTO）值后，是否能够将RTO固定在2倍最大段生命周期（2*MSL）的值。5、TESTER: 不发送任何SYN,ACK并验证DUT是否以递增的延迟重复重传，直到重传超时达到2。

2024-10-23 21:19:59 338

原创 TCP_PROBING_WINDOWS_06：增加间隔的零窗口探测

在TCP连接中，如果接收方的窗口大小持续为零，发送方TCP会定期发送零窗口探测包以检测连接状态。根据TCP协议，发送方应该指数级地增加这些探测包之间的间隔，以减少网络拥塞并避免对接收方造成不必要的压力。本测试用例旨在验证DUT（被测试设备）在TCP连接中对于零窗口探测包的发送间隔是否按照指数退避算法进行增加。当接收方的窗口大小持续为零时，发送方TCP应该能够逐渐增加发送零窗口探测包的间隔。6. DUT: 在一定延迟后持续发送零窗口探测。6、DUT: 在一定延迟后持续发送零窗口探测。

2024-10-23 21:14:25 500

原创 TCP_PROBING_WINDOWS_05：首次零窗口探测

在TCP连接中，如果接收方的窗口大小持续为零，发送方可能会认为连接已经断开或接收方无法接收更多数据。然而，根据TCP协议，发送方应在窗口大小保持为零的情况下，经过一个RTO周期后发送一个零窗口探测包，以检测连接的状态。本测试用例将验证DUT是否能够在接收窗口保持为零的情况下，经过RTO周期后发送零窗口探测包。特别是当接收方的窗口大小持续为零超过重传定时器（RTO）的周期时，发送方TCP是否能够发送第一个零窗口探测包。6. DUT: 在一定延迟后发送零窗口探测。6、DUT: 在一定延迟后发送零窗口探测。

2024-10-23 20:15:24 305

空空如也

空空如也