diff --git a/testcases/new/CSM_Unittest_README/CSM_Unittest_README(en-us).html b/testcases/new/CSM_Unittest_README/CSM_Unittest_README(en-us).html new file mode 100644 index 000000000..7136909ff --- /dev/null +++ b/testcases/new/CSM_Unittest_README/CSM_Unittest_README(en-us).html @@ -0,0 +1,1317 @@ + + + + + Communicable State Machine (CSM) Unit Test + + + + + + + + + + + + + +

Communicable State Machine (CSM) Unit Test

+

📖 1 Project Introduction

+

1.1 Project Background

+

This project utilizes the JKI VI Tester toolkit to develop a suite of unit tests for verifying the functional correctness of the Communicable State Machine (CSM) programming framework. This unit test suite provides reliable functional verification support for the long-term maintenance of CSM. +The unit tests are integrated into the Git CI/CD platform, running tests and generating reports through an automated process, helping CSM framework developers quickly locate issues, maintain, and debug.

+

1.2 Installation Environment

+ +
+

⚙️ 2 Function Description

+

The following two images show the LabVIEW project structure and the JKI VI Tester interface respectively:

+
+LabVIEW Project +JKI VI Tester
+

The unit tests are categorized according to CSM framework functionalities and mainly include the following test classes:

+
    +
  1. Message +Test messages between different CSM modes (Normal Mode, SubModule Mode, System Level Mode, Worker Mode, Chain Mode, lvlibp Mode). Synchronous messages, asynchronous messages with reply, and asynchronous messages without reply. Verify if messages are correctly passed, if arguments, response, and error information are also correctly carried. +Specific test case description is explained in the table below and test code is in testcase-CSMMessage.lvclass.
    2. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode Submodule Mode System-Level Mode Worker Mode Chain Mode lvlibp
1CSM1 sends a synchronous message to CSM2, CSM2 returns the correct reply, CSM1 enters Response Case to process the reply infotest1-SyncMessage.vi✔✔✔✔✔✔
2CSM1 sends a synchronous message to CSM2, CSM2 encounters an error, CSM1 enters Response Case carrying the Response and error informationtest2-SycnMessageWithError.vi✔✔✔✔✔✔
3CSM1 uses API to send a synchronous message to CSM2, CSM2 returns the correct Response, CSM1 obtains the return via APItest3-SyncMessage_API.vi✔✔✔✔✔✔
4CSM1 uses API to send a synchronous message to CSM2, CSM2 encounters an error, CSM1 obtains the Response and error information via APItest4-SyncMessageWithError_API.vi✔✔✔✔✔✔
5CSM1 sends an asynchronous message with reply to CSM2, CSM2 returns the correct Response, CSM1 enters Async Response to process the replytest5-AsyncMessageWithReply.vi✔✔✔✔✔✔
6CSM1 sends an asynchronous message with reply to CSM2, CSM2 encounters an error, CSM1 enters Async Response carrying the Response and error informationtest6-AsyncMessageWithReplyWithError.vi✔✔✔✔✔✔
7CSM1 sends an asynchronous message without reply to CSM2, verifies that CSM2 executes, CSM1 does not process the replytest7-AsyncMessageWithoutReply.vi✔✔✔✔✔✔
8CSM1 uses API to send an asynchronous message without reply to CSM, verifies that the caller executes asynchronously, does not process the replytest8-AsyncMessageWithoutReply_API.vi✔✔✔✔✔✔
+ Note: CSM modes include Normal Mode, Submodule Mode, System-Level Mode, Worker Mode, Chain Mode, and lvlibp. All possible CSM mode relationships between CSM1 and CSM2 are covered. +
+
    +
  1. Argument +Based on message test class, further verify whether arguments/parameters carried by messages can be transmitted normally between different CSM modes (Normal Mode, SubModule Mode, System Level Mode, Worker Mode, Chain Mode, lilvbp Mode). +Specific test case description is explained in the table below and test code is in testcase-CSMArgument.lvclass.
    2. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode
1Create preset information and verify HexString conversion works correctly: 1. Check a nested complex Cluster; 2. Check empty string parsing behavior.test1-HexStr conversion.vi✔
2Create preset information and verify ErrorString conversion works correctly: 1. Conversion of Error; 2. Conversion of No Error; 3. Empty string behavior.test2-ErrorStr conversion.vi✔
3Create preset information and verify SafeString conversion works correctly: 1. Empty string behavior (no conversion for empty string); 2. Behavior with special characters; 3. Behavior with carriage return.test3-SafeStr conversion.vi✔
4CSM - Argument Type.vi can correctly identify HexString/ErrorString/SafeString types.Integrated in test1,2,3✔
5Parameters sent from CSM1 to CSM2 are correctly carried into the TargetCSM, i.e., into the CSM.test4-ArgumentCanBeTakenToTargetModule.vi✔
+ Note: Only normal mode is tested between CSM1 and CSM2, other modes have been tested in the message test class. +
+
    +
  1. Response +Verify the correctness of message response/return values between different modes (Normal Mode, SubModule Mode, System Level Mode, Worker Mode, Chain Mode, lilvbp Mode), including the transmission of error information, and aslo test the behavior of response/return values during macro message execution meets expectations under different circumstances. +Specific test case description is explained in the table below and test code is in testcase-CSMResponse.lvclass.
    2. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode Submodule Mode System-Level Mode Worker Mode Chain Mode lvlibp
1Basic message response function, already tested in message test class, including Sync/Async/AsyncNoRepTested✔✔✔✔✔✔
2CSM1 sends a message to CSM2, single message response. When an error occurs, it first enters the Error Handler, but still returns the Response of the message execution case.test1-ResponseWithError.vi✔✔✔✔✔✔
3Macro message execution returns the response of the last SubMessagetest2-MacroWithSubMessages.vi✔✔✔✔✔✔
4Macro message execution with PostStep messages returns the response of the last SubMessagetest3-MacroWithSubAndPostMessages.vi✔✔✔✔✔✔
5¹Macro message execution: if the last SubMessage sends a message to another module (sync/async with response/async no response), the final return value is emptytest4-MacroWithNonLocalSubMessages.vi✔✔✔✔✔✔
6Message response: Sync message API carries the name of the executing module, already tested in test3-SyncMessage_API.vi of the message test classTested✔✔✔✔✔✔
7In Response/Async Response, the source module name, message name, and message parameters can be obtained, already tested in Sync/Async/AsyncNoRep message test cases.Tested✔✔✔✔✔✔
8Message response with Error, already tested in Sync/Async/AsyncNoRep message test casesTested✔✔✔✔✔✔
+ ¹ Related issue tracking: + + https://github.com/NEVSTOP-LAB/Communicable-State-Machine/issues/547 + +

+ Note: CSM modes include Normal Mode, Submodule Mode, System-Level Mode, Worker Mode, Chain Mode, and lvlibp. All possible CSM mode relationships between CSM1 and CSM2 are included. +
+
    +
  1. Broadcast +Test status, interrupt (high priority), and state change broadcast (state change is a unique broadcast mechanism provided by CSM) across different modes (Normal Mode, SubModule Mode, System Level Mode, Worker Mode, Chain Mode, Packed Project Library Mode), including registration, unregistration, and selective registration (both senders and receivers can flexibly decide priority). Additionally test scenarios where broadcast functionality is called outside the CSM framework, extending cross-framework compatibility. +Specific test case description is explained in the table below and test code is in testcase-CSMBroadcast.lvclass.
    2. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode Submodule Mode System-Level Mode Worker Mode Chain Mode lvlibp
1CSM1 throws Status, can use Register/Unregister internally or externally to control Status triggering the State bound to CSM2test1-LocalExternalStatusRegistration.vi✔✔✔✔✔✔
2CSM1 throws Status, can use API internally or externally to control Status triggering the State bound to CSM2test2-LocalExternalStatusRegistrationViaAPI.vi✔✔✔✔✔✔
3CSM1 throws Status, can use API internally or externally to control Status triggering the State bound to CSM2test24-MappingRelationshipByExternalRegistration_API.vi✔✔✔✔✔✔
4CSM1 throws Status, when subscribing externally with string syntax, the subscription does not disappear after CSM exitstest25-MappingRelationshipByExternalRegistration.vi✔✔✔✔✔✔
5CSM1 throws Status, when subscribing internally to its own State: if the subscriber name is explicitly written as CSM1, the subscription does not disappear after exit; if the subscriber name is omitted, the subscription is automatically removed after exit.test26-MappingRelationshipByLocalRegistration_WithSubcriberName.vi +

+test27-MappingRelationshipByLocalRegistration_WithoutSubcriberName.vi		✔✔✔✔✔✔
6CSM1 throws Status, can be subscribed to multiple States in multiple modules, all will be triggered automatically after throwingtest3-1ToNBroadcastStatus.vi✔✔✔✔✔✔
7CSM1 throws Status, can be subscribed in non-CSM using UserEventtest4-RegisterStatusFromNonCSM.vi✔✔✔✔✔✔
8CSM1/CSM3 throw different Statuses, can be subscribed to CSM2's State, both can trigger CSM2 to execute Statetest5-RegisterMultipleStatusesToOneState.vi✔✔✔✔✔✔
9When subscribing, Source Module Name can use * as a wildcard to subscribe to the same Status from multiple modules at once; unsubscribing from one module's Status does not affect otherstest6-AsteriskWildcardStatusRegistration.vi✔✔✔✔✔✔
10After successful subscription, CSM1 throws Status multiple times, the subscriber receives all State triggers without losstest15-LosslessRegisterStatusMultipleTimes.vi✔✔✔✔✔✔
11After successful subscription, CSM1 throws Status multiple times, the subscriber receives all State triggers without loss (subscribed in non-CSM using UserEvent)test16-LosslessRegisterStatusMultipleTimesNonCSM.vi✔✔✔✔✔✔
12The Argument of Status is the Argument of the triggered StateTested, see test1-LocalExternalStatusRegistration.vi✔✔✔✔✔✔
13The triggered Status can obtain Source State Name/Source module from Argument Infotest7-TestArgumentInfoOfTriggeredState_Status.vi✔✔✔✔✔✔
14CSM1 throws Interrupt, can be subscribed to multiple States in multiple modules, all will be triggered automatically after throwingtest19-1ToNInterruptStatus.vi✔✔✔✔✔✔
15CSM1 throws Interrupt, can be subscribed in non-CSM using Interrupt User Event; Status User Event will not triggertest21-RegisterInterruptFromNonCSM.vi✔✔✔✔✔✔
16CSM1 throws Status, subscribed as interrupt, can be subscribed in non-CSM using Interrupt User Event; Status User Event will not triggertest20-RegisterStatusAsInterruptFromNonCSM.vi + ✔✔✔✔✔✔
17CSM1 throws Interrupt, subscribed as Status, can be subscribed in non-CSM using Status User Event; Interrupt User Event will not triggertest22-RegisterInterruptAsStatusFromNonCSM.vi✔✔✔✔✔✔
18CSM1 does not throw Status, its State can use Register/Unregister internally or externally to control Status triggering the State bound to CSM2test8-LocalExternalStateRegistration.vi✔✔✔✔✔✔
19CSM1 does not throw Status, its State can use API internally or externally to control Status triggering the State bound to CSM2test9-LocalExternalStateRegistrationViaAPI.vi✔✔✔✔✔✔
20CSM1 does not throw Status, when subscribing externally to its State with string syntax, the subscription does not disappear after exittest29-MappingRelationshipByExternalRegistration_State.vi✔✔✔✔✔✔
21CSM1 does not throw Status, when subscribing externally to its State via API, the subscription does not disappear after exittest28-MappingRelationshipByExternalRegistration_API_State.vi✔✔✔✔✔✔
22CSM1 does not throw Status, when subscribing internally to its own State: if the subscriber name is explicitly written as CSM1, the subscription does not disappear after exit; if the subscriber name is omitted, the subscription is automatically removed after exit.test30-MappingRelationshipByLocalRegistration_WIthSubscriberName_State.vi +

+test31-MappingRelationshipByLocalRegistration_WIthoutSubscriberName_State.vi		✔✔✔✔✔✔
23CSM1 does not throw Status, its State can be subscribed to multiple States in multiple modules, all will be triggered automatically after throwingtest10-1ToNBroadcastState.vi✔✔✔✔✔✔
24CSM1 does not throw Status, its State can be subscribed in non-CSM using UserEventtest11-RegisterStatesFromNonCSM_State.vi✔✔✔✔✔✔
25CSM1/CSM3 have different States, can be subscribed to CSM2's State, both can trigger CSM2 to execute Statetest12-RegisterMultipleStatesToOneState.vi/td> + ✔✔✔✔✔✔
26When subscribing, Source Module Name can use * as a wildcard to subscribe to the same State from multiple modules at once; unsubscribing from one module's State does not affect otherstest13-AsteriskWildcardStateRegistration.vi✔✔✔✔✔✔
27After successful subscription, CSM1 throws State multiple times, the subscriber receives all State triggers without losstest17-LosslessRegisterStateMultipleTimes.vi✔✔✔✔✔✔
28After successful subscription, CSM1 throws State multiple times, the subscriber receives all State triggers without loss (subscribed in non-CSM using UserEvent)test16-LosslessRegisterStateMultipleTimesNonCSM.vi✔✔✔✔✔✔
29The Response of State is the Argument of the triggered StateTested, see test8-LocalExternalStateRegistration.vi✔✔✔✔✔✔
30The triggered State can obtain Source State Name/Source module from Argument Infotest14-TestArgumentInfoOfTriggeredState_State.vi✔✔✔✔✔✔
31Subscribe State as interrupt, in Non-CSM mode, events can only be obtained in interrupt User Event, not in Status User Eventtest23-RegisterStatusAsInterruptFromNonCSM_State.vi✔✔✔✔✔✔
+¹: The unit test VIs of this class are not sorted from top to bottom according to this table, but are sorted according to the actual test machine, especially the performance of the actual running machine for Git CI/CD. +

+ Note: CSM modes include Normal Mode, Submodule Mode, System-Level Mode, Worker Mode, Chain Mode, and lvlibp. All possible CSM mode relationships between CSM1 and CSM2 are included. +
+
    +
  1. Global Log +Test global logging functionality across different modes (Normal Mode, SubModule Mode, System Level Mode, Worker Mode, Chain Mode, lilvbp), including module creation and destruction, state change, registration and unregistration, syn messages, async messages with reply, async messages without reply, broadcast, and user-defined log. +The CSM programming framework provides two implementation methods: Global Log Queue and Global Log User Event. This unit test class covers all possible scenarios for both implementations. +Specific test case description is explained in the table below and test code is in testcase-CSMGlobalLog.lvclass.
    2. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ +
Test Case No. Test Case Description Test Case VI Normal Mode Submodule Mode System-Level Mode Worker Mode Chain Mode lvlibp
1Module creation and destruction logs (module created/module destroyed) can be obtained through the global log queue, and the number of logs can be checked for correctnesstest1-ModuleCreatedDestroyed_Queue.vi✔✔✔✔✔✔
2Module state change logs (state change) can be obtained through the global log queue: sending a message via external API triggers an internal state change in the CSM module. Both the triggering message and the resulting state change can be seen in the global log.test2-StateChange_Queue.vi✔✔✔✔✔✔
3Subscription and unsubscription logs can be obtained through the global log queue. CSM module names in Worker and Chain modes must not have suffixes.test3-RegisterUnregister_Queue.vi✔✔✔✔✔✔
4Module message communication logs (message) can be obtained through the global log queue: sending a synchronous message via external API triggers an internal state in CSM1, which then sends a synchronous message to CSM2. Both messages should be strictly logged in the correct format.test4-Message_Queue.vi✔✔✔✔✔✔
5Module broadcast logs (broadcast) can be obtained through the global log queuetest5-Broadcast_Queue.vi✔✔✔✔✔✔
6Module high-priority broadcast logs (interrupt) can be obtained through the global log queuetest6-Interrupt_Queue.vi✔✔✔✔✔✔
7Module state broadcast logs (state) can be obtained through the global log queuetest7-StateBroadcast_Queue.vi✔✔✔✔✔✔
8Module custom user message logs can be obtained through the global log queuetest8-UserLog_Queue.vi✔✔✔✔✔✔
9Module Sync/Async/NoRep-Async message logs can be obtained through the global log queueTested, see test4-Message_Queue.vi✔✔✔✔✔✔
10Module creation and destruction logs (module created/module destroyed) can be obtained through global log custom events, and the number of logs can be checked for correctnesstest9-ModuleCreatedDestroyed_Event.vi✔✔✔✔✔✔
11Module state change logs (state change) can be obtained through global log custom events: sending a message via external API triggers an internal state change in the CSM module. Both the triggering message and the resulting state change can be seen in the global log.test10-StateChange_Event.vi✔✔✔✔✔✔
12Subscription and unsubscription logs can be obtained through global log custom events. CSM module names in Worker and Chain modes must not have suffixes.test11-RegisterUnregister_Event.vi✔✔✔✔✔✔
13Module message communication logs (message) can be obtained through global log custom eventstest12-Message_Event.vi✔✔✔✔✔✔
14Module broadcast logs (broadcast) can be obtained through global log custom eventstest13-Broadcast_Event.vi✔✔✔✔✔✔
15Module high-priority broadcast logs (interrupt) can be obtained through global log custom eventstest14-Interrupt_Event.vi✔✔✔✔✔✔
16Module state broadcast logs (state) can be obtained through global log custom eventstest15-StateBroadcast_Event.vi✔✔✔✔✔✔
17Module custom user message logs can be obtained through global log custom eventstest16-UserLog_Event.vi✔✔✔✔✔✔
18Module Sync/Async/NoRep-Async message logs can be obtained through global log custom eventsTested, see test12-Message_Event.vi✔✔✔✔✔✔
+

Note: CSM modes include Normal Mode, Submodule Mode, System-Level Mode, Worker Mode, Chain Mode, and lvlibp. All possible CSM mode relationships between CSM1 and CSM2 are included. +

+
    +
  1. System Level Module +Test the CSM List Module.vi API functionality by modifying the input Scope parameter to identify scenarios that include or exclude system-level modules. Other related system-level module functionalities have been covered in the Message class tests. +Specific test case description is explained in the table below and test code is in testcase-CSMSystemLevelModule.lvclass.
    2. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode Submodule Mode System-Level Mode Worker Mode Chain Mode lvlibp
1CSM List Module.vi by default cannot list system-level modules, but after changing the scope to 'all', they can be recognizedtest1-SystemLevelModuleInListModuleAPI.vi✔✔✔✔✔✔
2The message function of System-Level has already been tested in the Sync/Async/AsyncNoRep message test casesTested, see message class tests✔✔✔✔✔✔
+
    +
  1. SubModule +Test the CSM List SubModules.vi API functionality to correctly find corresponding first-level or multi-level submodules(resursive) based on the input module/submodule names. +Specific test case description is explained in the table below and test code is in testcase-CSMSubModule.lvclass.
    2. +
+ + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Submodule Mode
1CSM List SubModules.vi: When UI, UI.a1 (not existing), UI.a2, UI.a1.b1, and UI.a2.b2 exist, it can correctly list the required submodules according to the input parameterstest1-ListSubModulesInDifferentSenarios.vi✔
+
    +
  1. Worker Mode +Test data sharing among multiple worker nodes, ensuring data written externally can be read by all nodes via CSM Attribute. Other related functionalities have been covered in the Message class tests. +Specific test case description is explained in the table below and test code is in testcase-CSMWorkerMode.lvclass.
    2. +
+ + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Worker Mode
1All nodes share the same CSM Attribute data space; data written externally is read identically by all internal modulestest1-AllWorkerNodesShareTheSameData.vi✔
+
    +
  1. Chain Mode +Test data sharing and message processing among multiple nodes, verify whether Allowed Messages defined by different nodes can be processed and report errors correctly, and test the sequence of node exit. Other related functionalities have been covered in the Message class tests. +Specific test case description is explained in the table below and test code is in testcase-CSMChainMode.lvclass.
    2. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Chain Mode
1All nodes share the same CSM Attribute data space. Data written externally is read identically by all internal modules.test1-AllChainNodesShareTheSameData.vi✔
2Three nodes (A->B->C), each with different Allowed Messages. Messages are sent to the corresponding allowed module; using the API to send synchronous messages returns the correct parameters.test2-DifferentChainNodesProcessDifferentAllowedMessages.vi✔
3Three nodes (A->B->C), with Allowed Messages combinations of AB, BC, AC, and ABC. Messages should be executed by the first node in the chain. Using the API to send synchronous messages returns the correct parameters.test3-FirstChainNodeProcessesAllowedMessages.vi✔
4Three nodes (A->B->C), with Allowed Messages defined. If no module can execute the message, the sender reports an error.test4-EndNodeHandlesErrorForNotAllowedMessages.vi✔
5Three nodes (A->B->C), each node broadcasts a message. After subscribing, the corresponding module's API is triggered; after unsubscribing, none can be triggered.test5-ChainNodeBroadcast.vi✔
6Three nodes (A->B->C). If the "Macro: Exit" command does not specify a node (i.e., uses the core name without the $ suffix), nodes should exit in order from the end to the head of the chain. If the command specifies a node, only that node exits and others are unaffected.test6-ChainNodeExitSequenceCheck.vi✔
+
    +
  1. Management API +Test CSM built-in management APIs, such as Module Status.vi, verifying if they can correctly read module information (name, node count, etc.), and test the polymorphic VI with various filtering functions. Other related functionalities have been covered in the Message class tests. +Specific test case description is explained in the table below and test code is in testcase-CSMManagementAPI.lvclass.
    2. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode Submodule Mode System-Level Mode Worker Mode Chain Mode lvlibp
1After module instantiation, this interface can be used to read module information. Test whether all different Modes can be read and whether the number of nodes is correct. The number of items in the message queue does not need to be tested.test1-TestModuleStatusVI.vi✔✔✔✔✔✔
2Create a complex message list and test that the filter function only filters the corresponding messages. Test the filter function of each VI in the polymorphic VI. Actual sending is not required.test2-TestFilterJKISMStringQueueVI.vi✔✔✔✔✔✔
+
    +
  1. Non-CSM Caller Support API +Test APIs that take effect when a module exits, such as Module Exit Event.vi and Module Turns Invalid.vi. Other related functionalities have been covered in the Message class tests. +Specific test case description is explained in the table below and test code is in testcase-CSMNonCSMCallerSupportAPI.lvclass.
    2. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode Submodule Mode System-Level Mode Worker Mode Chain Mode lvlibp
1Module exit can trigger the Exit Module event. In Worker and Chain modes, this event is triggered only when all modules have exited.test1-testModuleExitEventAPI.vi✔✔✔✔✔✔
2Module exit can trigger this status change. In Worker and Chain modes, this event is triggered only when all modules have exited.test2-testModuleTurnsInvalidAPI.vi✔✔✔✔✔✔
+
    +
  1. CSM Loop Support +Test the loop mode supported by the CSM framework, verifying that a module can both receive and process external messages while running in a loop, and send messages to other modules without blocking the running loop. +Specific test case description is explained in the table below and test code is in testcase-CSMAddonLoopSupport.lvclass.
    2. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode Submodule Mode System-Level Mode lvlibp
1While running in Loop mode: 1. Can receive and process synchronous messages sent from outside; 2. Can also send synchronous messages to other modules.test1-ProcessSyncMessageInCSMLoop(SendAndReceive).vi✔✔✔✔
2While running in Loop mode: 1. Can receive and process asynchronous messages with reply sent from outside; 2. Can also send asynchronous messages with reply to other modules.test2-ProcessAsyncMessageWithReplyInCSMLoop(SendAndReceive).vi + ✔✔✔✔
3While running in Loop mode: 1. Can receive and process asynchronous messages without reply sent from outside; 2. Can also send asynchronous messages without reply to other modules.test3-ProcessAsyncMessageWithoutReplyInCSMLoop(SendAndReceive).vi + ✔✔✔✔
+ Note: The CSM (=worker and chain modes are special module patterns composed of multiple running nodes. Messages sent in these modes cannot reliably target a specific node to execute. When a node operates in worker or chain modes, it cannot be clearly instructed by messages to stop a loop. Therefore, it is not recommended to use the CSM Loop Support addon in worker and chain modes. Therefore, this testclass does not cover worker and chain modes. +
+
+

🛡️ 3 Maintenance Notes

+

To ensure the long-term maintenance and stable operation of this unit test suite, please read the following:

+
    +
  1. +

    Broadcast Test Order +It is recommended to place the Broadcast test class as the last class of the test suite to execute because it consumes many hardware resources. Improper testing may affect subsequent tests.

    +
    2. +
  2. +

    Add New Test Case +If you need to add new test case, please first check the tail code of the current last test case in the corresponding test class. If restarting the CSM modules has been disabled, please enable it first. Then add the new test case as the last case and decide whether to restart the CSM modules or not in the tail code of this newly added test case.

    +
    3. +
  3. +

    Recommended Debugging Tool +It is recommended to use the CSM's built-in debugging tool Debug Console – DebugTool.vi. We can use this tool to manually send messages between different modules, view return values, and perform advanced debugging by monitoring log performance parameters (such as logging handling speed, logging queue count).

    +
    4. +
+
+

📜 4 License

+

This project follows the MIT License.

+
+

🔗 5 Related Resources

+ + + + + + \ No newline at end of file diff --git a/testcases/new/CSM_Unittest_README/CSM_Unittest_README(en-us).md b/testcases/new/CSM_Unittest_README/CSM_Unittest_README(en-us).md new file mode 100644 index 000000000..8639db86c --- /dev/null +++ b/testcases/new/CSM_Unittest_README/CSM_Unittest_README(en-us).md @@ -0,0 +1,1168 @@ +# Communicable State Machine (CSM) Unit Test + +## 📖 1 Project Introduction + +### 1.1 Project Background +This project utilizes the **JKI VI Tester** toolkit to develop a suite of unit tests for verifying the functional correctness of the **Communicable State Machine (CSM) programming framework**. This unit test suite provides reliable functional verification support for the long-term maintenance of CSM. +The unit tests are integrated into the **Git CI/CD platform**, running tests and generating reports through an automated process, helping CSM framework developers quickly locate issues, maintain, and debug. + +### 1.2 Installation Environment +- Windows 10 OS +- NI LabVIEW 2017 (32-bit) +- JKI VI Tester ([JKI VI Tester Toolkit for LabVIEW - VIPM Download](https://www.ni.com/zh-cn/support/downloads/tools-network/download.vi-tester-unit-test-framework.html#378053)) + +--- + +## ⚙️ 2 Function Description + +The following two images show the LabVIEW project structure and the JKI VI Tester interface respectively: +
+LabVIEW Project +JKI VI Tester
+ +The unit tests are categorized according to CSM framework functionalities and mainly include the following test classes: + +1. **Message** + Test messages between different CSM modes (Normal Mode, SubModule Mode, System Level Mode, Worker Mode, Chain Mode, lvlibp Mode). Synchronous messages, asynchronous messages with reply, and asynchronous messages without reply. Verify if messages are correctly passed, if arguments, response, and error information are also correctly carried. + Specific test case description is explained in the table below and test code is in `testcase-CSMMessage.lvclass`. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode Submodule Mode System-Level Mode Worker Mode Chain Mode lvlibp
1CSM1 sends a synchronous message to CSM2, CSM2 returns the correct reply, CSM1 enters Response Case to process the reply infotest1-SyncMessage.vi✔✔✔✔✔✔
2CSM1 sends a synchronous message to CSM2, CSM2 encounters an error, CSM1 enters Response Case carrying the Response and error informationtest2-SycnMessageWithError.vi✔✔✔✔✔✔
3CSM1 uses API to send a synchronous message to CSM2, CSM2 returns the correct Response, CSM1 obtains the return via APItest3-SyncMessage_API.vi✔✔✔✔✔✔
4CSM1 uses API to send a synchronous message to CSM2, CSM2 encounters an error, CSM1 obtains the Response and error information via APItest4-SyncMessageWithError_API.vi✔✔✔✔✔✔
5CSM1 sends an asynchronous message with reply to CSM2, CSM2 returns the correct Response, CSM1 enters Async Response to process the replytest5-AsyncMessageWithReply.vi✔✔✔✔✔✔
6CSM1 sends an asynchronous message with reply to CSM2, CSM2 encounters an error, CSM1 enters Async Response carrying the Response and error informationtest6-AsyncMessageWithReplyWithError.vi✔✔✔✔✔✔
7CSM1 sends an asynchronous message without reply to CSM2, verifies that CSM2 executes, CSM1 does not process the replytest7-AsyncMessageWithoutReply.vi✔✔✔✔✔✔
8CSM1 uses API to send an asynchronous message without reply to CSM, verifies that the caller executes asynchronously, does not process the replytest8-AsyncMessageWithoutReply_API.vi✔✔✔✔✔✔
+ Note: CSM modes include Normal Mode, Submodule Mode, System-Level Mode, Worker Mode, Chain Mode, and lvlibp. All possible CSM mode relationships between CSM1 and CSM2 are covered. +
+ + + +2. **Argument** + Based on message test class, further verify whether arguments/parameters carried by messages can be transmitted normally between different CSM modes (Normal Mode, SubModule Mode, System Level Mode, Worker Mode, Chain Mode, lilvbp Mode). + Specific test case description is explained in the table below and test code is in `testcase-CSMArgument.lvclass`. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode
1Create preset information and verify HexString conversion works correctly: 1. Check a nested complex Cluster; 2. Check empty string parsing behavior.test1-HexStr conversion.vi✔
2Create preset information and verify ErrorString conversion works correctly: 1. Conversion of Error; 2. Conversion of No Error; 3. Empty string behavior.test2-ErrorStr conversion.vi✔
3Create preset information and verify SafeString conversion works correctly: 1. Empty string behavior (no conversion for empty string); 2. Behavior with special characters; 3. Behavior with carriage return.test3-SafeStr conversion.vi✔
4CSM - Argument Type.vi can correctly identify HexString/ErrorString/SafeString types.Integrated in test1,2,3✔
5Parameters sent from CSM1 to CSM2 are correctly carried into the TargetCSM, i.e., into the CSM.test4-ArgumentCanBeTakenToTargetModule.vi✔
+ Note: Only normal mode is tested between CSM1 and CSM2, other modes have been tested in the message test class. +
+ +3. **Response** + Verify the correctness of message response/return values between different modes (Normal Mode, SubModule Mode, System Level Mode, Worker Mode, Chain Mode, lilvbp Mode), including the transmission of error information, and aslo test the behavior of response/return values during **macro message** execution meets expectations under different circumstances. + Specific test case description is explained in the table below and test code is in `testcase-CSMResponse.lvclass`. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode Submodule Mode System-Level Mode Worker Mode Chain Mode lvlibp
1Basic message response function, already tested in message test class, including Sync/Async/AsyncNoRepTested✔✔✔✔✔✔
2CSM1 sends a message to CSM2, single message response. When an error occurs, it first enters the Error Handler, but still returns the Response of the message execution case.test1-ResponseWithError.vi✔✔✔✔✔✔
3Macro message execution returns the response of the last SubMessagetest2-MacroWithSubMessages.vi✔✔✔✔✔✔
4Macro message execution with PostStep messages returns the response of the last SubMessagetest3-MacroWithSubAndPostMessages.vi✔✔✔✔✔✔
5¹Macro message execution: if the last SubMessage sends a message to another module (sync/async with response/async no response), the final return value is emptytest4-MacroWithNonLocalSubMessages.vi✔✔✔✔✔✔
6Message response: Sync message API carries the name of the executing module, already tested in test3-SyncMessage_API.vi of the message test classTested✔✔✔✔✔✔
7In Response/Async Response, the source module name, message name, and message parameters can be obtained, already tested in Sync/Async/AsyncNoRep message test cases.Tested✔✔✔✔✔✔
8Message response with Error, already tested in Sync/Async/AsyncNoRep message test casesTested✔✔✔✔✔✔
+ ¹ Related issue tracking: + + https://github.com/NEVSTOP-LAB/Communicable-State-Machine/issues/547 + +

+ Note: CSM modes include Normal Mode, Submodule Mode, System-Level Mode, Worker Mode, Chain Mode, and lvlibp. All possible CSM mode relationships between CSM1 and CSM2 are included. +
+ +4. **Broadcast** + Test status, interrupt (high priority), and state change broadcast (state change is a unique broadcast mechanism provided by CSM) across different modes (Normal Mode, SubModule Mode, System Level Mode, Worker Mode, Chain Mode, Packed Project Library Mode), including registration, unregistration, and selective registration (both senders and receivers can flexibly decide priority). Additionally test scenarios where broadcast functionality is called outside the CSM framework, extending cross-framework compatibility. + Specific test case description is explained in the table below and test code is in `testcase-CSMBroadcast.lvclass`. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode Submodule Mode System-Level Mode Worker Mode Chain Mode lvlibp
1CSM1 throws Status, can use Register/Unregister internally or externally to control Status triggering the State bound to CSM2test1-LocalExternalStatusRegistration.vi✔✔✔✔✔✔
2CSM1 throws Status, can use API internally or externally to control Status triggering the State bound to CSM2test2-LocalExternalStatusRegistrationViaAPI.vi✔✔✔✔✔✔
3CSM1 throws Status, can use API internally or externally to control Status triggering the State bound to CSM2test24-MappingRelationshipByExternalRegistration_API.vi✔✔✔✔✔✔
4CSM1 throws Status, when subscribing externally with string syntax, the subscription does not disappear after CSM exitstest25-MappingRelationshipByExternalRegistration.vi✔✔✔✔✔✔
5CSM1 throws Status, when subscribing internally to its own State: if the subscriber name is explicitly written as CSM1, the subscription does not disappear after exit; if the subscriber name is omitted, the subscription is automatically removed after exit.test26-MappingRelationshipByLocalRegistration_WithSubcriberName.vi +

+test27-MappingRelationshipByLocalRegistration_WithoutSubcriberName.vi		✔✔✔✔✔✔
6CSM1 throws Status, can be subscribed to multiple States in multiple modules, all will be triggered automatically after throwingtest3-1ToNBroadcastStatus.vi✔✔✔✔✔✔
7CSM1 throws Status, can be subscribed in non-CSM using UserEventtest4-RegisterStatusFromNonCSM.vi✔✔✔✔✔✔
8CSM1/CSM3 throw different Statuses, can be subscribed to CSM2's State, both can trigger CSM2 to execute Statetest5-RegisterMultipleStatusesToOneState.vi✔✔✔✔✔✔
9When subscribing, Source Module Name can use * as a wildcard to subscribe to the same Status from multiple modules at once; unsubscribing from one module's Status does not affect otherstest6-AsteriskWildcardStatusRegistration.vi✔✔✔✔✔✔
10After successful subscription, CSM1 throws Status multiple times, the subscriber receives all State triggers without losstest15-LosslessRegisterStatusMultipleTimes.vi✔✔✔✔✔✔
11After successful subscription, CSM1 throws Status multiple times, the subscriber receives all State triggers without loss (subscribed in non-CSM using UserEvent)test16-LosslessRegisterStatusMultipleTimesNonCSM.vi✔✔✔✔✔✔
12The Argument of Status is the Argument of the triggered StateTested, see test1-LocalExternalStatusRegistration.vi✔✔✔✔✔✔
13The triggered Status can obtain Source State Name/Source module from Argument Infotest7-TestArgumentInfoOfTriggeredState_Status.vi✔✔✔✔✔✔
14CSM1 throws Interrupt, can be subscribed to multiple States in multiple modules, all will be triggered automatically after throwingtest19-1ToNInterruptStatus.vi✔✔✔✔✔✔
15CSM1 throws Interrupt, can be subscribed in non-CSM using Interrupt User Event; Status User Event will not triggertest21-RegisterInterruptFromNonCSM.vi✔✔✔✔✔✔
16CSM1 throws Status, subscribed as interrupt, can be subscribed in non-CSM using Interrupt User Event; Status User Event will not triggertest20-RegisterStatusAsInterruptFromNonCSM.vi + ✔✔✔✔✔✔
17CSM1 throws Interrupt, subscribed as Status, can be subscribed in non-CSM using Status User Event; Interrupt User Event will not triggertest22-RegisterInterruptAsStatusFromNonCSM.vi✔✔✔✔✔✔
18CSM1 does not throw Status, its State can use Register/Unregister internally or externally to control Status triggering the State bound to CSM2test8-LocalExternalStateRegistration.vi✔✔✔✔✔✔
19CSM1 does not throw Status, its State can use API internally or externally to control Status triggering the State bound to CSM2test9-LocalExternalStateRegistrationViaAPI.vi✔✔✔✔✔✔
20CSM1 does not throw Status, when subscribing externally to its State with string syntax, the subscription does not disappear after exittest29-MappingRelationshipByExternalRegistration_State.vi✔✔✔✔✔✔
21CSM1 does not throw Status, when subscribing externally to its State via API, the subscription does not disappear after exittest28-MappingRelationshipByExternalRegistration_API_State.vi✔✔✔✔✔✔
22CSM1 does not throw Status, when subscribing internally to its own State: if the subscriber name is explicitly written as CSM1, the subscription does not disappear after exit; if the subscriber name is omitted, the subscription is automatically removed after exit.test30-MappingRelationshipByLocalRegistration_WIthSubscriberName_State.vi +

+test31-MappingRelationshipByLocalRegistration_WIthoutSubscriberName_State.vi		✔✔✔✔✔✔
23CSM1 does not throw Status, its State can be subscribed to multiple States in multiple modules, all will be triggered automatically after throwingtest10-1ToNBroadcastState.vi✔✔✔✔✔✔
24CSM1 does not throw Status, its State can be subscribed in non-CSM using UserEventtest11-RegisterStatesFromNonCSM_State.vi✔✔✔✔✔✔
25CSM1/CSM3 have different States, can be subscribed to CSM2's State, both can trigger CSM2 to execute Statetest12-RegisterMultipleStatesToOneState.vi/td> + ✔✔✔✔✔✔
26When subscribing, Source Module Name can use * as a wildcard to subscribe to the same State from multiple modules at once; unsubscribing from one module's State does not affect otherstest13-AsteriskWildcardStateRegistration.vi✔✔✔✔✔✔
27After successful subscription, CSM1 throws State multiple times, the subscriber receives all State triggers without losstest17-LosslessRegisterStateMultipleTimes.vi✔✔✔✔✔✔
28After successful subscription, CSM1 throws State multiple times, the subscriber receives all State triggers without loss (subscribed in non-CSM using UserEvent)test16-LosslessRegisterStateMultipleTimesNonCSM.vi✔✔✔✔✔✔
29The Response of State is the Argument of the triggered StateTested, see test8-LocalExternalStateRegistration.vi✔✔✔✔✔✔
30The triggered State can obtain Source State Name/Source module from Argument Infotest14-TestArgumentInfoOfTriggeredState_State.vi✔✔✔✔✔✔
31Subscribe State as interrupt, in Non-CSM mode, events can only be obtained in interrupt User Event, not in Status User Eventtest23-RegisterStatusAsInterruptFromNonCSM_State.vi✔✔✔✔✔✔
+¹: The unit test VIs of this class are not sorted from top to bottom according to this table, but are sorted according to the actual test machine, especially the performance of the actual running machine for Git CI/CD. +

+ Note: CSM modes include Normal Mode, Submodule Mode, System-Level Mode, Worker Mode, Chain Mode, and lvlibp. All possible CSM mode relationships between CSM1 and CSM2 are included. +
+ +5. **Global Log** + Test global logging functionality across different modes (Normal Mode, SubModule Mode, System Level Mode, Worker Mode, Chain Mode, lilvbp), including module creation and destruction, state change, registration and unregistration, syn messages, async messages with reply, async messages without reply, broadcast, and user-defined log. + The CSM programming framework provides two implementation methods: Global Log Queue and Global Log User Event. This unit test class covers all possible scenarios for both implementations. + Specific test case description is explained in the table below and test code is in `testcase-CSMGlobalLog.lvclass`. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode Submodule Mode System-Level Mode Worker Mode Chain Mode lvlibp
1Module creation and destruction logs (module created/module destroyed) can be obtained through the global log queue, and the number of logs can be checked for correctnesstest1-ModuleCreatedDestroyed_Queue.vi✔✔✔✔✔✔
2Module state change logs (state change) can be obtained through the global log queue: sending a message via external API triggers an internal state change in the CSM module. Both the triggering message and the resulting state change can be seen in the global log.test2-StateChange_Queue.vi✔✔✔✔✔✔
3Subscription and unsubscription logs can be obtained through the global log queue. CSM module names in Worker and Chain modes must not have suffixes.test3-RegisterUnregister_Queue.vi✔✔✔✔✔✔
4Module message communication logs (message) can be obtained through the global log queue: sending a synchronous message via external API triggers an internal state in CSM1, which then sends a synchronous message to CSM2. Both messages should be strictly logged in the correct format.test4-Message_Queue.vi✔✔✔✔✔✔
5Module broadcast logs (broadcast) can be obtained through the global log queuetest5-Broadcast_Queue.vi✔✔✔✔✔✔
6Module high-priority broadcast logs (interrupt) can be obtained through the global log queuetest6-Interrupt_Queue.vi✔✔✔✔✔✔
7Module state broadcast logs (state) can be obtained through the global log queuetest7-StateBroadcast_Queue.vi✔✔✔✔✔✔
8Module custom user message logs can be obtained through the global log queuetest8-UserLog_Queue.vi✔✔✔✔✔✔
9Module Sync/Async/NoRep-Async message logs can be obtained through the global log queueTested, see test4-Message_Queue.vi✔✔✔✔✔✔
10Module creation and destruction logs (module created/module destroyed) can be obtained through global log custom events, and the number of logs can be checked for correctnesstest9-ModuleCreatedDestroyed_Event.vi✔✔✔✔✔✔
11Module state change logs (state change) can be obtained through global log custom events: sending a message via external API triggers an internal state change in the CSM module. Both the triggering message and the resulting state change can be seen in the global log.test10-StateChange_Event.vi✔✔✔✔✔✔
12Subscription and unsubscription logs can be obtained through global log custom events. CSM module names in Worker and Chain modes must not have suffixes.test11-RegisterUnregister_Event.vi✔✔✔✔✔✔
13Module message communication logs (message) can be obtained through global log custom eventstest12-Message_Event.vi✔✔✔✔✔✔
14Module broadcast logs (broadcast) can be obtained through global log custom eventstest13-Broadcast_Event.vi✔✔✔✔✔✔
15Module high-priority broadcast logs (interrupt) can be obtained through global log custom eventstest14-Interrupt_Event.vi✔✔✔✔✔✔
16Module state broadcast logs (state) can be obtained through global log custom eventstest15-StateBroadcast_Event.vi✔✔✔✔✔✔
17Module custom user message logs can be obtained through global log custom eventstest16-UserLog_Event.vi✔✔✔✔✔✔
18Module Sync/Async/NoRep-Async message logs can be obtained through global log custom eventsTested, see test12-Message_Event.vi✔✔✔✔✔✔
+ +Note: CSM modes include Normal Mode, Submodule Mode, System-Level Mode, Worker Mode, Chain Mode, and lvlibp. All possible CSM mode relationships between CSM1 and CSM2 are included. +
+ +6. **System Level Module** + Test the `CSM List Module.vi` API functionality by modifying the input Scope parameter to identify scenarios that include or exclude system-level modules. Other related system-level module functionalities have been covered in the Message class tests. + Specific test case description is explained in the table below and test code is in `testcase-CSMSystemLevelModule.lvclass`. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode Submodule Mode System-Level Mode Worker Mode Chain Mode lvlibp
1CSM List Module.vi by default cannot list system-level modules, but after changing the scope to 'all', they can be recognizedtest1-SystemLevelModuleInListModuleAPI.vi✔✔✔✔✔✔
2The message function of System-Level has already been tested in the Sync/Async/AsyncNoRep message test casesTested, see message class tests✔✔✔✔✔✔
+ +7. **SubModule** + Test the `CSM List SubModules.vi` API functionality to correctly find corresponding first-level or multi-level submodules(resursive) based on the input module/submodule names. + Specific test case description is explained in the table below and test code is in `testcase-CSMSubModule.lvclass`. + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Submodule Mode
1CSM List SubModules.vi: When UI, UI.a1 (not existing), UI.a2, UI.a1.b1, and UI.a2.b2 exist, it can correctly list the required submodules according to the input parameterstest1-ListSubModulesInDifferentSenarios.vi✔
+ +8. **Worker Mode** + Test data sharing among multiple worker nodes, ensuring data written externally can be read by all nodes via `CSM Attribute`. Other related functionalities have been covered in the Message class tests. + Specific test case description is explained in the table below and test code is in `testcase-CSMWorkerMode.lvclass`. + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Worker Mode
1All nodes share the same CSM Attribute data space; data written externally is read identically by all internal modulestest1-AllWorkerNodesShareTheSameData.vi✔
+ +9. **Chain Mode** + Test data sharing and message processing among multiple nodes, verify whether Allowed Messages defined by different nodes can be processed and report errors correctly, and test the sequence of node exit. Other related functionalities have been covered in the Message class tests. + Specific test case description is explained in the table below and test code is in `testcase-CSMChainMode.lvclass`. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Chain Mode
1All nodes share the same CSM Attribute data space. Data written externally is read identically by all internal modules.test1-AllChainNodesShareTheSameData.vi✔
2Three nodes (A->B->C), each with different Allowed Messages. Messages are sent to the corresponding allowed module; using the API to send synchronous messages returns the correct parameters.test2-DifferentChainNodesProcessDifferentAllowedMessages.vi✔
3Three nodes (A->B->C), with Allowed Messages combinations of AB, BC, AC, and ABC. Messages should be executed by the first node in the chain. Using the API to send synchronous messages returns the correct parameters.test3-FirstChainNodeProcessesAllowedMessages.vi✔
4Three nodes (A->B->C), with Allowed Messages defined. If no module can execute the message, the sender reports an error.test4-EndNodeHandlesErrorForNotAllowedMessages.vi✔
5Three nodes (A->B->C), each node broadcasts a message. After subscribing, the corresponding module's API is triggered; after unsubscribing, none can be triggered.test5-ChainNodeBroadcast.vi✔
6Three nodes (A->B->C). If the "Macro: Exit" command does not specify a node (i.e., uses the core name without the $ suffix), nodes should exit in order from the end to the head of the chain. If the command specifies a node, only that node exits and others are unaffected.test6-ChainNodeExitSequenceCheck.vi✔
+ +10. **Management API** + Test CSM built-in management APIs, such as `Module Status.vi`, verifying if they can correctly read module information (name, node count, etc.), and test the polymorphic VI with various filtering functions. Other related functionalities have been covered in the Message class tests. + Specific test case description is explained in the table below and test code is in `testcase-CSMManagementAPI.lvclass`. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode Submodule Mode System-Level Mode Worker Mode Chain Mode lvlibp
1After module instantiation, this interface can be used to read module information. Test whether all different Modes can be read and whether the number of nodes is correct. The number of items in the message queue does not need to be tested.test1-TestModuleStatusVI.vi✔✔✔✔✔✔
2Create a complex message list and test that the filter function only filters the corresponding messages. Test the filter function of each VI in the polymorphic VI. Actual sending is not required.test2-TestFilterJKISMStringQueueVI.vi✔✔✔✔✔✔
+ +11. **Non-CSM Caller Support API** + Test APIs that take effect when a module exits, such as `Module Exit Event.vi` and `Module Turns Invalid.vi`. Other related functionalities have been covered in the Message class tests. + Specific test case description is explained in the table below and test code is in `testcase-CSMNonCSMCallerSupportAPI.lvclass`. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode Submodule Mode System-Level Mode Worker Mode Chain Mode lvlibp
1Module exit can trigger the Exit Module event. In Worker and Chain modes, this event is triggered only when all modules have exited.test1-testModuleExitEventAPI.vi✔✔✔✔✔✔
2Module exit can trigger this status change. In Worker and Chain modes, this event is triggered only when all modules have exited.test2-testModuleTurnsInvalidAPI.vi✔✔✔✔✔✔
+ +12. **CSM Loop Support** + Test the loop mode supported by the CSM framework, verifying that a module can both receive and process external messages while running in a loop, and send messages to other modules without blocking the running loop. + Specific test case description is explained in the table below and test code is in `testcase-CSMAddonLoopSupport.lvclass`. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode Submodule Mode System-Level Mode lvlibp
1While running in Loop mode: 1. Can receive and process synchronous messages sent from outside; 2. Can also send synchronous messages to other modules.test1-ProcessSyncMessageInCSMLoop(SendAndReceive).vi✔✔✔✔
2While running in Loop mode: 1. Can receive and process asynchronous messages with reply sent from outside; 2. Can also send asynchronous messages with reply to other modules.test2-ProcessAsyncMessageWithReplyInCSMLoop(SendAndReceive).vi + ✔✔✔✔
3While running in Loop mode: 1. Can receive and process asynchronous messages without reply sent from outside; 2. Can also send asynchronous messages without reply to other modules.test3-ProcessAsyncMessageWithoutReplyInCSMLoop(SendAndReceive).vi + ✔✔✔✔
+ Note: The CSM (=worker and chain modes are special module patterns composed of multiple running nodes. Messages sent in these modes cannot reliably target a specific node to execute. When a node operates in worker or chain modes, it cannot be clearly instructed by messages to stop a loop. Therefore, it is not recommended to use the CSM Loop Support addon in worker and chain modes. Therefore, this testclass does not cover worker and chain modes. +
+ +--- + +## 🛡️ 3 Maintenance Notes + +To ensure the long-term maintenance and stable operation of this unit test suite, please read the following: + +1. **Broadcast Test Order** + It is recommended to place the Broadcast test class as the last class of the test suite to execute because it consumes many hardware resources. Improper testing may affect subsequent tests. + +2. **Add New Test Case** + If you need to add new test case, please first check the tail code of the current last test case in the corresponding test class. If restarting the CSM modules has been disabled, please enable it first. Then add the new test case as the last case and decide whether to restart the CSM modules or not in the tail code of this newly added test case. + +3. **Recommended Debugging Tool** + It is recommended to use the CSM's built-in debugging tool `Debug Console – DebugTool.vi`. We can use this tool to manually send messages between different modules, view return values, and perform advanced debugging by monitoring log performance parameters (such as logging handling speed, logging queue count). + +--- + +## 📜 4 License +This project follows the MIT License. + +--- + +## 🔗 5 Related Resources +- [NI LabVIEW Official Documentation](https://www.ni.com/labview) +- [CSM Framework Wiki](https://github.com/NEVSTOP-LAB/Communicable-State-Machine) +- [JKI VI Tester Toolkit](https://www.ni.com/zh-cn/support/downloads/tools-network/download.vi-tester-unit-test-framework.html#378053) \ No newline at end of file diff --git a/testcases/new/CSM_Unittest_README/CSM_Unittest_README(zh-cn).html b/testcases/new/CSM_Unittest_README/CSM_Unittest_README(zh-cn).html new file mode 100644 index 000000000..a8eb92499 --- /dev/null +++ b/testcases/new/CSM_Unittest_README/CSM_Unittest_README(zh-cn).html @@ -0,0 +1,1319 @@ + + + + + 可通信状态机 (CSM) 单元测试 + + + + + + + + + + + + + +

可通信状态机 (CSM) 单元测试

+

📖 1 项目简介

+

1.1 项目背景

+

本项目利用 JKI VI Tester 工具包开发了一套单元测试，用于测试并验证 可通信状态机 (CSM) 编程框架 的功能正确性。该单元测试为 CSM 的长期维护提供了可靠的功能验证保障。
+单元测试已集成至 Git CI/CD 平台，通过自动化测试流程完成测试并生成报告，帮助 CSM 框架开发人员快速定位问题、维护和调试。

+

1.2 安装环境

+ +
+

⚙️ 2 功能描述

+

以下两张图片分别展示了LabVIEW项目结构与JKI VI Tester测试工具界面：

+
+LabVIEW Project +JKI VI Tester
+

单元测试按照 CSM 框架功能分类，主要包括以下测试类：

+
    +
  1. 消息 (Message)
    +测试不同 CSM 模式间（普通模式、子模块模式、系统级模式、协作者模式、责任链模式、打包项目库模式）的消息传递。包括同步消息、异步有返回消息、异步无返回消息三类，验证消息是否能正确传达,消息携带参数，返回值以及错误信息是否能被正确携带。
    +具体测试项请见下方表格，代码详见 testcase-CSMMessage.lvclass。
    2. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 普通模式 子模块模式 系统级模式 协作者模式 责任链模式 打包项目库模式
1CSM1发送同步消息给CSM2，CSM2返回正确的Response, CSM1进入Response Case 处理返回test1-SyncMessage.vi✔✔✔✔✔✔
2CSM1发送同步消息给CSM2，CSM2执行出错，CSM1进入Response Case, 携带了Response和错误信息test2-SycnMessageWithError.vi✔✔✔✔✔✔
3CSM1使用API发送同步消息给CSM2，CSM2返回正确的Response, CSM1通过API拿到返回test3-SyncMessage_API.vi✔✔✔✔✔✔
4CSM1使用API发送同步消息给CSM2，CSM2执行出错，CSM1通过API拿到Response和错误信息test4-SyncMessageWithError_API.vi✔✔✔✔✔✔
5CSM1发送异步有返回消息给CSM2，CSM2返回正确的Response, CSM1进入Async Response 处理返回test5-AsyncMessageWithReply.vi✔✔✔✔✔✔
6CSM1发送异步有返回消息给CSM2，CSM2执行出错，CSM1进入Async Response, 携带了Response和错误信息test6-AsyncMessageWithReplyWithError.vi✔✔✔✔✔✔
7CSM1发送异步无返回消息给CSM2，检查确认CSM2执行，CSM1不处理返回test7-AsyncMessageWithoutReply.vi✔✔✔✔✔✔
8CSM1使用API发送异步无返回消息给CSM，检查确认调用方异步执行，不处理返回test8-AsyncMessageWithoutReply_API.vi✔✔✔✔✔✔
+ 备注：CSM模式包含普通模式、子模块模式、系统级模式、协作者模式、责任链模式、打包项目库模式，CSM1和CSM2之间包含所有可能的CSM模式对应关系。 +
+
    +
  1. 参数 (Argument)
    +在消息测试的基础上，进一步验证不同CSM模式间（普通模式、子模块模式、系统级模式、协作者模式、责任链模式、打包项目库模式）消息所携带的参数是否能正常传递。
    +具体测试项请见下方表格，代码详见 testcase-CSMArgument.lvclass。
    2. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 普通模式
1创建预设的信息，检查HexString转换没有问题 1.检查一个嵌套的复杂Cluster; 2. 检查空字符串解析行为test1-HexStr conversion.vi✔
2创建预设的信息，检查ErrorString转换没有问题 1. Error 的转换; 2. No Error 的转换; 3. 空字符串行为test2-ErrorStr conversion.vi✔
3创建预设的信息，检查SafeString转换没有问题 1. 空字符串行为，空字符串不做转换 2. 带有特殊字符的字符串行为；3. 有回车的行为test3-SafeStr conversion.vi✔
4CSM - Argument Type.vi 能够正常的识别 HexString/ErrorString/SafeString 的Type集成于test1,2,3✔
5CSM1发送到CSM2的参数，会正常的被携带到TargetCSM中，即CSM中test4-ArgumentCanBeTakenToTargetModule.vi✔
+ 备注：CSM1和CSM2之间只测试普通模式，其他的模式在消息类中已经测试。 +
+
    +
  1. 返回 (Response)
    +验证不同模式间（普通模式、子模块模式、系统级模式、协作者模式、责任链模式、打包项目库模式）消息返回值的正确性，包括错误信息的传递，以及宏消息执行时的返回值在不同情况下的表现是否符合预期。
    +具体测试项请见下方表格，代码详见testcase-CSMResponse.lvclass。
    2. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 普通模式 子模块模式 系统级模式 协作者模式 责任链模式 打包项目库模式
1普通的消息返回功能，已经在 包含Sync/Async/AsyncNoRep 的消息类测试过已测试✔✔✔✔✔✔
2CSM1发送消息给CSM2，单条消息的返回，当产生错误后，会首先进入Error Handler, 但是依然会返回消息执行case的Responsetest1-ResponseWithError.vi✔✔✔✔✔✔
3宏消息执行，会返回最后一条 SubMessage 的返回test2-MacroWithSubMessages.vi✔✔✔✔✔✔
4宏消息执行，包含PostStep的消息，会返回最后一条 SubMessage 的返回test3-MacroWithSubAndPostMessages.vi✔✔✔✔✔✔
5¹宏消息执行，如果SubMessage最后一条是发送消息到其他模块(同步/异步有返回/异步无返回)，最终返回值为空test4-MacroWithNonLocalSubMessages.vi✔✔✔✔✔✔
6消息返回，同步消息API会携带执行模块的名称，在消息测试类的test3-SyncMessage_API.vi已测已测试✔✔✔✔✔✔
7Response/Async Response 中，可以获取Source Module 名称、消息名称、消息参数，已经在 Sync/Async/AsyncNoRep 消息的 testcases 中测试过已测试✔✔✔✔✔✔
8消息返回携带Error的功能，已经在 Sync/Async/AsyncNoRep 消息的 testcases 中测试过已测试✔✔✔✔✔✔
+ ¹ 相关问题跟踪： + + https://github.com/NEVSTOP-LAB/Communicable-State-Machine/issues/547 + +

+ 备注：CSM模式包含普通模式、子模块模式、系统级模式、协作者模式、责任链模式、打包项目库模式，CSM1和CSM2之间包含所有可能的CSM模式对应关系。 +
+
    +
  1. 广播 (Broadcast)
    +测试不同模式间（普通模式、子模块模式、系统级模式、协作者模式、责任链模式、打包项目库模式）的信号广播（status）、中断广播（interrupt，高优先级，触发后优先处理）、状态变化广播（state change，CSM 独特的广播机制，支持更灵活的广播注册功能）的注册、反注册、选择性注册（发送方与接收方均可灵活决定优先级）。此外，还测试了非 CSM 框架调用广播功能的场景，扩展了跨框架的兼容性。
    +具体测试项请见下方表格，代码详见 testcase-CSMBroadcast.lvclass。
    2. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI¹ 普通模式 子模块模式 系统级模式 协作者模式 责任链模式 打包项目库模式
1CSM1抛出Status, 可以通过 Register/Unregister 在内部、外部，控制Status 触发 CSM2绑定的Statetest1-LocalExternalStatusRegistration.vi✔✔✔✔✔✔
2CSM1抛出Status, 可以通过 API 在内部、外部，控制Status 触发 CSM2绑定的Statetest2-LocalExternalStatusRegistrationViaAPI.vi✔✔✔✔✔✔
3CSM1抛出Status, 可以通过 API 在内部、外部，控制Status 触发 CSM2绑定的Statetest24-MappingRelationshipByExternalRegistration_API.vi✔✔✔✔✔✔
4CSM1抛出Status, 在外部使用语句订阅时，CSM退出后，订阅关系不会消失test25-MappingRelationshipByExternalRegistration.vi✔✔✔✔✔✔
5CSM1抛出Status, 在内部使用语句订阅到本模块的State时:如果明确写出订阅者名字为CSM1，退出后，订阅关系不会消失；如果省略订阅者名字，退出后，订阅关系会自动被移除；test26-MappingRelationshipByLocalRegistration_WithSubcriberName.vi +

+test27-MappingRelationshipByLocalRegistration_WithoutSubcriberName.vi		✔✔✔✔✔✔
6CSM1抛出Status, 可以被订阅到多个模块的多个状态，抛出后全部会自动触发test3-1ToNBroadcastStatus.vi✔✔✔✔✔✔
7CSM1抛出Status, 可以在非CSM中，使用UserEvent 进行订阅test4-RegisterStatusFromNonCSM.vi✔✔✔✔✔✔
8CSM1/CSM3 抛出不同的Status, 可以订阅到 CSM2 的State, 都能触发 CSM2 执行 Statetest5-RegisterMultipleStatusesToOneState.vi✔✔✔✔✔✔
9订阅时Source Module Name 可以使用 * 作为通配符，一次性订阅多个模块的同一个Status，可以取消订阅某一个module 的该Status,其他模块的不被影响test6-AsteriskWildcardStatusRegistration.vi✔✔✔✔✔✔
10订阅成功后，CSM1 抛出多次 Status, 订阅方会收到所有的State 触发，不会丢失test15-LosslessRegisterStatusMultipleTimes.vi✔✔✔✔✔✔
11订阅成功后，CSM1 抛出多次Status, 订阅方会收到所有的State 触发，不会丢失（非CSM中，使用UserEvent 进行订阅）test16-LosslessRegisterStatusMultipleTimesNonCSM.vi✔✔✔✔✔✔
12Status 的 Argument, 就是触发后的State 的Argument已测试，见test1-LocalExternalStatusRegistration.vi✔✔✔✔✔✔
13被触发的Status ,可以通过 Argument Info 中获取 Source State Name/ Source moduletest7-TestArgumentInfoOfTriggeredState_Status.vi✔✔✔✔✔✔
14CSM1抛出Interrupt, 可以被订阅到多个模块的多个状态，抛出后全部会自动触发test19-1ToNInterruptStatus.vi✔✔✔✔✔✔
15CSM1抛出Interrupt, 可以在非CSM 中，使用 Interrupt User Event 进行订阅获取，Status User Event 不会触发test21-RegisterInterruptFromNonCSM.vi✔✔✔✔✔✔
16CSM1抛出Status, 订阅为 interrupt, 可以在非CSM 中，使用 Interrupt User Event 进行订阅获取，Status User Event 不会触发test20-RegisterStatusAsInterruptFromNonCSM.vi + ✔✔✔✔✔✔
17CSM1抛出Interrupt, 订阅为 Status, 可以在非CSM 中，使用Status User Event 进行订阅获取，Interrupt User Event 不会触发test22-RegisterInterruptAsStatusFromNonCSM.vi✔✔✔✔✔✔
18CSM1不抛出Status,它的State, 可以通过 Regiseter/Unregister 在内部、外部，控制Status 触发 CSM2绑定的Statetest8-LocalExternalStateRegistration.vi✔✔✔✔✔✔
19CSM1不抛出Status,它的State, 可以通过 API 在内部、外部，控制Status 触发 CSM2绑定的Statetest9-LocalExternalStateRegistrationViaAPI.vi✔✔✔✔✔✔
20CSM1不抛出Status,它的State, 在外部使用语句订阅时，推出后，订阅关系不会消失test29-MappingRelationshipByExternalRegistration_State.vi✔✔✔✔✔✔
21CSM1不抛出Status,它的State, 在外部使用API订阅时，推出后，订阅关系不会消失test28-MappingRelationshipByExternalRegistration_API_State.vi✔✔✔✔✔✔
22CSM1不抛出Status,它的State, 在内部使用语句订阅到本模块的State时：如果明确写出订阅者名字为CSM1，退出后，订阅关系不会消失；如果省略订阅者名字，退出后，订阅关系会自动被移除；test30-MappingRelationshipByLocalRegistration_WIthSubscriberName_State.vi +

+test31-MappingRelationshipByLocalRegistration_WIthoutSubscriberName_State.vi		✔✔✔✔✔✔
23CSM1不抛出Status,它的State, 可以被订阅到多个模块的多个状态，抛出后全部会自动触发test10-1ToNBroadcastState.vi✔✔✔✔✔✔
24CSM1不抛出Status,它的State, 可以在非CSM中，使用UserEvent 进行订阅test11-RegisterStatesFromNonCSM_State.vi✔✔✔✔✔✔
25CSM1/CSM3 不同的State, 可以订阅到 CSM2 的State, 都能触发 CSM2 执行 Statetest12-RegisterMultipleStatesToOneState.vi/td> + ✔✔✔✔✔✔
26订阅时Source Module Name 可以使用 * 作为通配符，一次性订阅多个模块的同一个State，可以取消订阅某一个module 的该State,其他模块的不被影响test13-AsteriskWildcardStateRegistration.vi✔✔✔✔✔✔
27订阅成功后，CSM1 抛出多次 State, 订阅方会收到所有State 触发，不会丢失test17-LosslessRegisterStateMultipleTimes.vi✔✔✔✔✔✔
28订阅成功后，CSM1 抛出多次 State, 订阅方会收到所有State 触发，不会丢失（非CSM中，使用UserEvent 进行订阅）test16-LosslessRegisterStateMultipleTimesNonCSM.vi✔✔✔✔✔✔
29State 的 Response, 就是触发后的State 的Argument 已测试，见test8-LocalExternalStateRegistration.vi✔✔✔✔✔✔
30被触发的State ,可以通过 Argument Info 中获取 Source State Name/ Source moduletest14-TestArgumentInfoOfTriggeredState_State.vi✔✔✔✔✔✔
31将state 订阅为 interrupt, Non-CSM 模式下，只能在interrupt User Event 中获取事件，在 Status User Event 中无法获取队列test23-RegisterStatusAsInterruptFromNonCSM_State.vi✔✔✔✔✔✔
+¹：该类的单元测试vi未按照该表格从上至下顺序排序，而是按照实际测试机台，特别是Git CI/CD实际运行机台性能而做的排序。 +

+ 备注：CSM模式包含普通模式、子模块模式、系统级模式、协作者模式、责任链模式、打包项目库模式，CSM1和CSM2之间包含所有可能的CSM模式对应关系。 +
+
    +
  1. 全局日志 (Global Log)
    +测试不同模式下（普通模式、子模块模式、系统级模式、协作者模式、责任链模式、打包项目库模式）的全局日志功能，包括模块创建与销毁、状态轮转、注册与反注册、同步与异步消息、广播及用户自定义事件。
    +CSM编程框架提供两种实现方式：全局日志队列 (Global Log Queue) 与用户事件 (Global Log User Event)，该类单元测试覆盖了以上两种实现方式的所有可能场景。
    +具体测试项请见下方表格，代码详见 testcase-CSMGlobalLog.lvclass。
    2. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ +
测试项序号 测试项内容 对应测试项VI 普通模式 子模块模式 系统级模式 协作者模式 责任链模式 打包项目库模式
1可以通过全局日志队列获取模块创建和销毁的日志(module created/module destroyed)，并检查日志数量是否符合预期test1-ModuleCreatedDestroyed_Queue.vi✔✔✔✔✔✔
2可以通过全局日志队列获取模块状态轮转的日志(state change)： 通过外部API发送一条消息触发CSM模块内部状态变化(State Change), 可以在全局日志里既看到触发消息的日志，又可以看到被触发的状态变化test2-StateChange_Queue.vi✔✔✔✔✔✔
3可以通过全局日志队列获取订阅、取消订阅的日志, 协作者和责任链模式的CSM模块名不能带有后缀test3-RegisterUnregister_Queue.vi✔✔✔✔✔✔
4可以通过全局日志队列获得模块消息通讯的日志(messasge): 通过外部API发送一条同步消息触发CSM1模块内部状态，该内部状态里再发送一条同步消息给CSM2，检查这两条特定消息都按照严格的格式记录在日志里。test4-Message_Queue.vi✔✔✔✔✔✔
5可以通过全局日志队列获得模块发布广播的日志(broadcast)test5-Broadcast_Queue.vi✔✔✔✔✔✔
6可以通过全局日志队列获得模块发布高优先级广播的日志(interrupt)test6-Interrupt_Queue.vi✔✔✔✔✔✔
7可以通过全局日志队列获得模块状态广播(state)的日志test7-StateBroadcast_Queue.vi✔✔✔✔✔✔
8可以通过全局日志队列获得模块自定义用户消息的日志test8-UserLog_Queue.vi✔✔✔✔✔✔
9可以通过全局日志队列获得模块Sync/Async/NoRep-Async消息的日志已测试，见test4-Message_Queue.vi✔✔✔✔✔✔
10可以通过全局日志自定义事件获取模块创建和销毁的日志(module created/module destroyed),并检查日志数量是否符合预期test9-ModuleCreatedDestroyed_Event.vi✔✔✔✔✔✔
11可以通过全局日志自定义事件获取模块状态轮转的日志(state change): 通过外部API发送一条消息触发CSM模块内部状态变化(State Change), 可以在全局日志里既看到触发消息的日志，又可以看到被触发的状态变化test10-StateChange_Event.vi✔✔✔✔✔✔
12可以通过全局日志自定义事件获取订阅、取消订阅的日志, 协作者和责任链模式的CSM模块名不能带有后缀test11-RegisterUnregister_Event.vi✔✔✔✔✔✔
13可以通过全局日志自定义事件获得模块消息通讯的日志(messasge)test12-Message_Event.vi✔✔✔✔✔✔
14可以通过全局日志自定义事件获得模块发布广播的日志(broadcast)test13-Broadcast_Event.vi✔✔✔✔✔✔
15可以通过全局日志自定义事件获得模块发布高优先级广播的日志(interrupt)test14-Interrupt_Event.vi✔✔✔✔✔✔
16可以通过全局日志自定义事件获得模块状态广播(state)的日志test15-StateBroadcast_Event.vi✔✔✔✔✔✔
17可以通过全局日志自定义事件获得模块自定义用户消息的日志test16-UserLog_Event.vi✔✔✔✔✔✔
18可以通过全局日志自定义事件获得模块Sync/Async/NoRep-Async消息的日志 已测试，见test12-Message_Event.vi✔✔✔✔✔✔
+

备注：CSM模式包含普通模式、子模块模式、系统级模式、协作者模式、责任链模式、打包项目库模式，CSM1和CSM2之间包含所有可能的CSM模式对应关系。 +

+
    +
  1. 系统级模块 (System Level Module)
    +测试 CSM List Module.viAPI 功能，通过修改输入 Scope参数，识别包含或不包含系统级模块的场景。其它相关系统级模块功能已包含在消息（Message）类测试过。
    +具体测试项请见下方表格，代码详见 testcase-CSMSystemLevelModule.lvclass。
    2. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 普通模式 子模块模式 系统级模式 协作者模式 责任链模式 打包项目库模式
1CSM List Module.vi 默认不能列出来 systemlevel module, 但是修改 scope 为 all 后，可以识别出来test1-SystemLevelModuleInListModuleAPI.vi✔✔✔✔✔✔
2SystemLevel的消息功能，已经在 Sync/Async/AsyncNoRep 消息的 testcases 中测试过已测试，见消息类测试✔✔✔✔✔✔
+
    +
  1. 子模块 (SubModule)
    +测试 CSM List SubModules.vi API 功能，根据输入的模块/子模块名称，正确找出对应的一级或多级子模块（recursive）。
    +具体测试项请见下方表格，代码详见 testcase-CSMSubModule.lvclass。
    2. +
+ + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 子模块模式
1CSM List SubModules.vi 在 UI, UI.a1(不存在), UI.a2, UI.a1.b1, UI.a2.b2 存在的情况下，可以根据输入参数，正确的罗列出需要的 Submoduletest1-ListSubModulesInDifferentSenarios.vi✔
+
    +
  1. 协作者模式 (Worker Mode)
    +测试多个协作者节点间的数据共享，确保外部写入的数据能被所有节点/模块通过 CSM Attribute 读取。其它相关功能已包含在消息（Message）类测试过。
    +具体测试项请见下方表格，代码详见 testcase-CSMWorkerMode.lvclass。
    2. +
+ + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 协作者模式
1节点之间共享相同的CSM Attribute 数据空间，外部写入数据，内部所有模块读取的数据相同test1-AllWorkerNodesShareTheSameData.vi✔
+
    +
  1. 责任链模式 (Chain Mode)
    +测试多个节点间的数据共享与消息处理，验证不同节点定义的允许消息 (Allowed Messages) 是否能正确处理与报错，并测试节点退出时的顺序。其它相关功能已包含在消息（Message）类测试过。
    +具体测试项请见下方表格，代码详见 testcase-CSMChainMode.lvclass。
    2. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 责任链模式
1节点之间共享相同的CSM Attribute 数据空间，外部写入数据，内部所有模块读取的数据相同test1-AllChainNodesShareTheSameData.vi✔
23个节点（A->B->C)，定义节点的Allowed Messages，互不相同的允许的消息，会发送到对应允许的模块运行；使用API发送同步消息，可以携带回正确的参数test2-DifferentChainNodesProcessDifferentAllowedMessages.vi✔
33个节点（A->B->C)，定义节点的Allowed Messages，AB, BC, AC, ABC 组合允许的消息，应该由链条端头的节点执行, 使用API发送同步消息，可以携带回正确的参数 test3-FirstChainNodeProcessesAllowedMessages.vi✔
43个节点（A->B->C)，定义节点的Allowed Messages, 没有可以执行的模块，由消息发送方报错test4-EndNodeHandlesErrorForNotAllowedMessages.vi✔
53个节点（A->B->C)，不同的节点都发出一个广播，订阅后，都能触发对应绑定模块的API, 取消订阅后，任意一个都不能触发test5-ChainNodeBroadcast.vi✔
63个节点（A->B->C)，如果使用”Macro: Exit“命令不显性明确哪个节点，而是用不带$后缀的核心名字退出时，需按照从链条底端到端头的顺序依次退出；如果使用”Macro: Exit“命令显性明确哪个节点，则只退出该节点模块，其余节点模块不受影响test6-ChainNodeExitSequenceCheck.vi✔
+
    +
  1. 管理接口 (Management API)
    +测试 CSM 内置管理接口，如 Module Status.vi，验证其是否能正确读取模块信息（名称、节点数量等），并测试带有多种过滤功能的多态 VI。其它相关功能已包含在消息（Message）类测试过。
    +具体测试项请见下方表格，代码详见 testcase-CSMManagementAPI.lvclass。
    2. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 普通模式 子模块模式 系统级模式 协作者模式 责任链模式 打包项目库模式
1模块实例化后，通过此接口可以读取模块的信息，测试所有不同的Mode是否能够读出，并且node个数是否正确，消息队列的数据个数可以不测test1-TestModuleStatusVI.vi✔✔✔✔✔✔
2创造一个复杂的消息列表，测试过滤功能只会过滤到对应的消息，测试多态VI里的每一个VI对应的过滤功能，不需要实际发送test2-TestFilterJKISMStringQueueVI.vi✔✔✔✔✔✔
+
    +
  1. 非 CSM 调用支持接口 (Non-CSM Caller Support API)
    +测试模块退出时生效的接口 API，如 Module Exit Event.vi 和 Module Turns Invalid.vi。其它相关功能已包含在消息（Message）类测试过。
    +具体测试项请见下方表格，代码详见 testcase-CSMNonCSMCallerSupportAPI.lvclass。
    2. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 普通模式 子模块模式 系统级模式 协作者模式 责任链模式 打包项目库模式
1模块的退出能够触发Exit模块事件，协作者和责任链模式，在全部模块退出时才会触发此事件test1-testModuleExitEventAPI.vi✔✔✔✔✔✔
2模块的退出能够触发此状态修改，协作者和责任链模式，在全部模块退出时才会触发此事件test2-testModuleTurnsInvalidAPI.vi✔✔✔✔✔✔
+
    +
  1. CSM 循环支持 (CSM Loop Support)
    +测试 CSM 框架支持的循环模式，验证模块在循环运行中既能接收外部消息并处理，又能向其他模块发送消息而不发生阻塞。
    +具体测试项请见下方表格，代码详见 testcase-CSMAddonLoopSupport.lvclass。
    2. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 普通模式 子模块模式 系统级模式 打包项目库模式
1Loop 模式运行中，1. 可以接收外部发送的同步消息并相应处理；2.也可以发送同步消息到其他模块；test1-ProcessSyncMessageInCSMLoop(SendAndReceive).vi✔✔✔✔
2Loop 模式运行中，1. 可以接收外部发送的异步有返回消息并相应处理；2.也可以发送异步有返回消息到其他模块； test2-ProcessAsyncMessageWithReplyInCSMLoop(SendAndReceive).vi + ✔✔✔✔
3Loop 模式运行中，1. 可以接收外部发送的异步无返回消息并相应处理；2.也可以发送异步无返回消息到其他模块； test3-ProcessAsyncMessageWithoutReplyInCSMLoop(SendAndReceive).vi + ✔✔✔✔
+ 备注：CSM 的协作者模式(worker) 和 责任链(chain)模式，是由多个运行的节点组成特殊的模块，发送的消息，并不能明确的让某个节点执行。当某节点使用此模式时，就不能明确的使用消息通知它停止循环，因此，不建议在协作者模式(worker) 和 责任链(chain)模式中使用CSM LOOP Support,固该类单元测试不包含协作者模式和责任链模式的测试。 +
+
+

🛡️3 维护注意事项

+

为确保该单元测试的长期维护与稳定运行，请注意以下事项：

+
    +
  1. +

    广播测试顺序
    +广播 (Broadcast) 测试类建议放置为最后一个类执行，因为其占用硬件资源较多，若测试不当可能影响后续测试。

    +
    2. +
  2. +

    新增测试项规范
    +如需添加新的测试项，请先检查对应测试类的最后一个测试项的尾部代码，如已禁用重新启动 CSM 模块，请先启用，再在最后添加新的测试项，并酌情决定是否在新增测试项结尾代码处重新启动模块。

    +
    3. +
  3. +

    调试工具推荐
    +建议使用 CSM 自带的调试工具 Debug Console – DebugTool.vi。调试人员可使用该工具在不同模块间手动发送消息、查看返回值，并通过监测日志性能参数（如日志处理速度、队列数量）进行高级调试。

    +
    4. +
+
+

📜4 许可证

+

本项目遵循 MIT License。

+
+

🔗 5 相关资源

+ + + + + + \ No newline at end of file diff --git a/testcases/new/CSM_Unittest_README/CSM_Unittest_README(zh-cn).md b/testcases/new/CSM_Unittest_README/CSM_Unittest_README(zh-cn).md new file mode 100644 index 000000000..5d9b8e370 --- /dev/null +++ b/testcases/new/CSM_Unittest_README/CSM_Unittest_README(zh-cn).md @@ -0,0 +1,1180 @@ +# 可通信状态机 (CSM) 单元测试 + +## 📖 1 项目简介 + +### 1.1 项目背景 +本项目利用 **JKI VI Tester** 工具包开发了一套单元测试，用于测试并验证 **可通信状态机 (CSM) 编程框架** 的功能正确性。该单元测试为 CSM 的长期维护提供了可靠的功能验证保障。 +单元测试已集成至 **Git CI/CD 平台**，通过自动化测试流程完成测试并生成报告，帮助 CSM 框架开发人员快速定位问题、维护和调试。 + +### 1.2 安装环境 +- Windows 10 OS +- NI LabVIEW 2017 (32-bit) +- JKI VI Tester （[JKI VI Tester Toolkit for LabVIEW - VIPM 下载](https://www.ni.com/zh-cn/support/downloads/tools-network/download.vi-tester-unit-test-framework.html#378053）)） + +--- + +## ⚙️ 2 功能描述 + +以下两张图片分别展示了LabVIEW项目结构与JKI VI Tester测试工具界面： +
+LabVIEW Project +JKI VI Tester
+ +单元测试按照 CSM 框架功能分类，主要包括以下测试类： + +1. **消息 (Message)** + 测试不同 CSM 模式间（普通模式、子模块模式、系统级模式、协作者模式、责任链模式、打包项目库模式）的消息传递。包括同步消息、异步有返回消息、异步无返回消息三类，验证消息是否能正确传达,消息携带参数，返回值以及错误信息是否能被正确携带。 + 具体测试项请见下方表格，代码详见 `testcase-CSMMessage.lvclass`。 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 普通模式 子模块模式 系统级模式 协作者模式 责任链模式 打包项目库模式
1CSM1发送同步消息给CSM2，CSM2返回正确的Response, CSM1进入Response Case 处理返回test1-SyncMessage.vi✔✔✔✔✔✔
2CSM1发送同步消息给CSM2，CSM2执行出错，CSM1进入Response Case, 携带了Response和错误信息test2-SycnMessageWithError.vi✔✔✔✔✔✔
3CSM1使用API发送同步消息给CSM2，CSM2返回正确的Response, CSM1通过API拿到返回test3-SyncMessage_API.vi✔✔✔✔✔✔
4CSM1使用API发送同步消息给CSM2，CSM2执行出错，CSM1通过API拿到Response和错误信息test4-SyncMessageWithError_API.vi✔✔✔✔✔✔
5CSM1发送异步有返回消息给CSM2，CSM2返回正确的Response, CSM1进入Async Response 处理返回test5-AsyncMessageWithReply.vi✔✔✔✔✔✔
6CSM1发送异步有返回消息给CSM2，CSM2执行出错，CSM1进入Async Response, 携带了Response和错误信息test6-AsyncMessageWithReplyWithError.vi✔✔✔✔✔✔
7CSM1发送异步无返回消息给CSM2，检查确认CSM2执行，CSM1不处理返回test7-AsyncMessageWithoutReply.vi✔✔✔✔✔✔
8CSM1使用API发送异步无返回消息给CSM，检查确认调用方异步执行，不处理返回test8-AsyncMessageWithoutReply_API.vi✔✔✔✔✔✔
+ 备注：CSM模式包含普通模式、子模块模式、系统级模式、协作者模式、责任链模式、打包项目库模式，CSM1和CSM2之间包含所有可能的CSM模式对应关系。 +
+ + +2. **参数 (Argument)** + 在消息测试的基础上，进一步验证不同CSM模式间（普通模式、子模块模式、系统级模式、协作者模式、责任链模式、打包项目库模式）消息所携带的参数是否能正常传递。 + 具体测试项请见下方表格，代码详见 `testcase-CSMArgument.lvclass`。 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 普通模式
1创建预设的信息，检查HexString转换没有问题 1.检查一个嵌套的复杂Cluster; 2. 检查空字符串解析行为test1-HexStr conversion.vi✔
2创建预设的信息，检查ErrorString转换没有问题 1. Error 的转换; 2. No Error 的转换; 3. 空字符串行为test2-ErrorStr conversion.vi✔
3创建预设的信息，检查SafeString转换没有问题 1. 空字符串行为，空字符串不做转换 2. 带有特殊字符的字符串行为；3. 有回车的行为test3-SafeStr conversion.vi✔
4CSM - Argument Type.vi 能够正常的识别 HexString/ErrorString/SafeString 的Type集成于test1,2,3✔
5CSM1发送到CSM2的参数，会正常的被携带到TargetCSM中，即CSM中test4-ArgumentCanBeTakenToTargetModule.vi✔
+ 备注：CSM1和CSM2之间只测试普通模式，其他的模式在消息类中已经测试。 +
+ + +3. **返回 (Response)** + 验证不同模式间（普通模式、子模块模式、系统级模式、协作者模式、责任链模式、打包项目库模式）消息返回值的正确性，包括错误信息的传递，以及**宏消息**执行时的返回值在不同情况下的表现是否符合预期。 + 具体测试项请见下方表格，代码详见`testcase-CSMResponse.lvclass`。 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 普通模式 子模块模式 系统级模式 协作者模式 责任链模式 打包项目库模式
1普通的消息返回功能，已经在 包含Sync/Async/AsyncNoRep 的消息类测试过已测试✔✔✔✔✔✔
2CSM1发送消息给CSM2，单条消息的返回，当产生错误后，会首先进入Error Handler, 但是依然会返回消息执行case的Responsetest1-ResponseWithError.vi✔✔✔✔✔✔
3宏消息执行，会返回最后一条 SubMessage 的返回test2-MacroWithSubMessages.vi✔✔✔✔✔✔
4宏消息执行，包含PostStep的消息，会返回最后一条 SubMessage 的返回test3-MacroWithSubAndPostMessages.vi✔✔✔✔✔✔
5¹宏消息执行，如果SubMessage最后一条是发送消息到其他模块(同步/异步有返回/异步无返回)，最终返回值为空test4-MacroWithNonLocalSubMessages.vi✔✔✔✔✔✔
6消息返回，同步消息API会携带执行模块的名称，在消息测试类的test3-SyncMessage_API.vi已测已测试✔✔✔✔✔✔
7Response/Async Response 中，可以获取Source Module 名称、消息名称、消息参数，已经在 Sync/Async/AsyncNoRep 消息的 testcases 中测试过已测试✔✔✔✔✔✔
8消息返回携带Error的功能，已经在 Sync/Async/AsyncNoRep 消息的 testcases 中测试过已测试✔✔✔✔✔✔
+ ¹ 相关问题跟踪： + + https://github.com/NEVSTOP-LAB/Communicable-State-Machine/issues/547 + +

+ 备注：CSM模式包含普通模式、子模块模式、系统级模式、协作者模式、责任链模式、打包项目库模式，CSM1和CSM2之间包含所有可能的CSM模式对应关系。 +
+ + +4. **广播 (Broadcast)** + 测试不同模式间（普通模式、子模块模式、系统级模式、协作者模式、责任链模式、打包项目库模式）的信号广播（status）、中断广播（interrupt，高优先级，触发后优先处理）、状态变化广播（state change，CSM 独特的广播机制，支持更灵活的广播注册功能）的注册、反注册、选择性注册（发送方与接收方均可灵活决定优先级）。此外，还测试了非 CSM 框架调用广播功能的场景，扩展了跨框架的兼容性。 + 具体测试项请见下方表格，代码详见 `testcase-CSMBroadcast.lvclass`。 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI¹ 普通模式 子模块模式 系统级模式 协作者模式 责任链模式 打包项目库模式
1CSM1抛出Status, 可以通过 Register/Unregister 在内部、外部，控制Status 触发 CSM2绑定的Statetest1-LocalExternalStatusRegistration.vi✔✔✔✔✔✔
2CSM1抛出Status, 可以通过 API 在内部、外部，控制Status 触发 CSM2绑定的Statetest2-LocalExternalStatusRegistrationViaAPI.vi✔✔✔✔✔✔
3CSM1抛出Status, 可以通过 API 在内部、外部，控制Status 触发 CSM2绑定的Statetest24-MappingRelationshipByExternalRegistration_API.vi✔✔✔✔✔✔
4CSM1抛出Status, 在外部使用语句订阅时，CSM退出后，订阅关系不会消失test25-MappingRelationshipByExternalRegistration.vi✔✔✔✔✔✔
5CSM1抛出Status, 在内部使用语句订阅到本模块的State时:如果明确写出订阅者名字为CSM1，退出后，订阅关系不会消失；如果省略订阅者名字，退出后，订阅关系会自动被移除；test26-MappingRelationshipByLocalRegistration_WithSubcriberName.vi +

+test27-MappingRelationshipByLocalRegistration_WithoutSubcriberName.vi		✔✔✔✔✔✔
6CSM1抛出Status, 可以被订阅到多个模块的多个状态，抛出后全部会自动触发test3-1ToNBroadcastStatus.vi✔✔✔✔✔✔
7CSM1抛出Status, 可以在非CSM中，使用UserEvent 进行订阅test4-RegisterStatusFromNonCSM.vi✔✔✔✔✔✔
8CSM1/CSM3 抛出不同的Status, 可以订阅到 CSM2 的State, 都能触发 CSM2 执行 Statetest5-RegisterMultipleStatusesToOneState.vi✔✔✔✔✔✔
9订阅时Source Module Name 可以使用 * 作为通配符，一次性订阅多个模块的同一个Status，可以取消订阅某一个module 的该Status,其他模块的不被影响test6-AsteriskWildcardStatusRegistration.vi✔✔✔✔✔✔
10订阅成功后，CSM1 抛出多次 Status, 订阅方会收到所有的State 触发，不会丢失test15-LosslessRegisterStatusMultipleTimes.vi✔✔✔✔✔✔
11订阅成功后，CSM1 抛出多次Status, 订阅方会收到所有的State 触发，不会丢失（非CSM中，使用UserEvent 进行订阅）test16-LosslessRegisterStatusMultipleTimesNonCSM.vi✔✔✔✔✔✔
12Status 的 Argument, 就是触发后的State 的Argument已测试，见test1-LocalExternalStatusRegistration.vi✔✔✔✔✔✔
13被触发的Status ,可以通过 Argument Info 中获取 Source State Name/ Source moduletest7-TestArgumentInfoOfTriggeredState_Status.vi✔✔✔✔✔✔
14CSM1抛出Interrupt, 可以被订阅到多个模块的多个状态，抛出后全部会自动触发test19-1ToNInterruptStatus.vi✔✔✔✔✔✔
15CSM1抛出Interrupt, 可以在非CSM 中，使用 Interrupt User Event 进行订阅获取，Status User Event 不会触发test21-RegisterInterruptFromNonCSM.vi✔✔✔✔✔✔
16CSM1抛出Status, 订阅为 interrupt, 可以在非CSM 中，使用 Interrupt User Event 进行订阅获取，Status User Event 不会触发test20-RegisterStatusAsInterruptFromNonCSM.vi + ✔✔✔✔✔✔
17CSM1抛出Interrupt, 订阅为 Status, 可以在非CSM 中，使用Status User Event 进行订阅获取，Interrupt User Event 不会触发test22-RegisterInterruptAsStatusFromNonCSM.vi✔✔✔✔✔✔
18CSM1不抛出Status,它的State, 可以通过 Regiseter/Unregister 在内部、外部，控制Status 触发 CSM2绑定的Statetest8-LocalExternalStateRegistration.vi✔✔✔✔✔✔
19CSM1不抛出Status,它的State, 可以通过 API 在内部、外部，控制Status 触发 CSM2绑定的Statetest9-LocalExternalStateRegistrationViaAPI.vi✔✔✔✔✔✔
20CSM1不抛出Status,它的State, 在外部使用语句订阅时，推出后，订阅关系不会消失test29-MappingRelationshipByExternalRegistration_State.vi✔✔✔✔✔✔
21CSM1不抛出Status,它的State, 在外部使用API订阅时，推出后，订阅关系不会消失test28-MappingRelationshipByExternalRegistration_API_State.vi✔✔✔✔✔✔
22CSM1不抛出Status,它的State, 在内部使用语句订阅到本模块的State时：如果明确写出订阅者名字为CSM1，退出后，订阅关系不会消失；如果省略订阅者名字，退出后，订阅关系会自动被移除；test30-MappingRelationshipByLocalRegistration_WIthSubscriberName_State.vi +

+test31-MappingRelationshipByLocalRegistration_WIthoutSubscriberName_State.vi		✔✔✔✔✔✔
23CSM1不抛出Status,它的State, 可以被订阅到多个模块的多个状态，抛出后全部会自动触发test10-1ToNBroadcastState.vi✔✔✔✔✔✔
24CSM1不抛出Status,它的State, 可以在非CSM中，使用UserEvent 进行订阅test11-RegisterStatesFromNonCSM_State.vi✔✔✔✔✔✔
25CSM1/CSM3 不同的State, 可以订阅到 CSM2 的State, 都能触发 CSM2 执行 Statetest12-RegisterMultipleStatesToOneState.vi/td> + ✔✔✔✔✔✔
26订阅时Source Module Name 可以使用 * 作为通配符，一次性订阅多个模块的同一个State，可以取消订阅某一个module 的该State,其他模块的不被影响test13-AsteriskWildcardStateRegistration.vi✔✔✔✔✔✔
27订阅成功后，CSM1 抛出多次 State, 订阅方会收到所有State 触发，不会丢失test17-LosslessRegisterStateMultipleTimes.vi✔✔✔✔✔✔
28订阅成功后，CSM1 抛出多次 State, 订阅方会收到所有State 触发，不会丢失（非CSM中，使用UserEvent 进行订阅）test16-LosslessRegisterStateMultipleTimesNonCSM.vi✔✔✔✔✔✔
29State 的 Response, 就是触发后的State 的Argument 已测试，见test8-LocalExternalStateRegistration.vi✔✔✔✔✔✔
30被触发的State ,可以通过 Argument Info 中获取 Source State Name/ Source moduletest14-TestArgumentInfoOfTriggeredState_State.vi✔✔✔✔✔✔
31将state 订阅为 interrupt, Non-CSM 模式下，只能在interrupt User Event 中获取事件，在 Status User Event 中无法获取队列test23-RegisterStatusAsInterruptFromNonCSM_State.vi✔✔✔✔✔✔
+¹：该类的单元测试vi未按照该表格从上至下顺序排序，而是按照实际测试机台，特别是Git CI/CD实际运行机台性能而做的排序。 +

+ 备注：CSM模式包含普通模式、子模块模式、系统级模式、协作者模式、责任链模式、打包项目库模式，CSM1和CSM2之间包含所有可能的CSM模式对应关系。 +
+ + +5. **全局日志 (Global Log)** + 测试不同模式下（普通模式、子模块模式、系统级模式、协作者模式、责任链模式、打包项目库模式）的全局日志功能，包括模块创建与销毁、状态轮转、注册与反注册、同步与异步消息、广播及用户自定义事件。 + CSM编程框架提供两种实现方式：全局日志队列 (Global Log Queue) 与用户事件 (Global Log User Event)，该类单元测试覆盖了以上两种实现方式的所有可能场景。 + 具体测试项请见下方表格，代码详见 `testcase-CSMGlobalLog.lvclass`。 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 普通模式 子模块模式 系统级模式 协作者模式 责任链模式 打包项目库模式
1可以通过全局日志队列获取模块创建和销毁的日志(module created/module destroyed)，并检查日志数量是否符合预期test1-ModuleCreatedDestroyed_Queue.vi✔✔✔✔✔✔
2可以通过全局日志队列获取模块状态轮转的日志(state change)： 通过外部API发送一条消息触发CSM模块内部状态变化(State Change), 可以在全局日志里既看到触发消息的日志，又可以看到被触发的状态变化test2-StateChange_Queue.vi✔✔✔✔✔✔
3可以通过全局日志队列获取订阅、取消订阅的日志, 协作者和责任链模式的CSM模块名不能带有后缀test3-RegisterUnregister_Queue.vi✔✔✔✔✔✔
4可以通过全局日志队列获得模块消息通讯的日志(messasge): 通过外部API发送一条同步消息触发CSM1模块内部状态，该内部状态里再发送一条同步消息给CSM2，检查这两条特定消息都按照严格的格式记录在日志里。test4-Message_Queue.vi✔✔✔✔✔✔
5可以通过全局日志队列获得模块发布广播的日志(broadcast)test5-Broadcast_Queue.vi✔✔✔✔✔✔
6可以通过全局日志队列获得模块发布高优先级广播的日志(interrupt)test6-Interrupt_Queue.vi✔✔✔✔✔✔
7可以通过全局日志队列获得模块状态广播(state)的日志test7-StateBroadcast_Queue.vi✔✔✔✔✔✔
8可以通过全局日志队列获得模块自定义用户消息的日志test8-UserLog_Queue.vi✔✔✔✔✔✔
9可以通过全局日志队列获得模块Sync/Async/NoRep-Async消息的日志已测试，见test4-Message_Queue.vi✔✔✔✔✔✔
10可以通过全局日志自定义事件获取模块创建和销毁的日志(module created/module destroyed),并检查日志数量是否符合预期test9-ModuleCreatedDestroyed_Event.vi✔✔✔✔✔✔
11可以通过全局日志自定义事件获取模块状态轮转的日志(state change): 通过外部API发送一条消息触发CSM模块内部状态变化(State Change), 可以在全局日志里既看到触发消息的日志，又可以看到被触发的状态变化test10-StateChange_Event.vi✔✔✔✔✔✔
12可以通过全局日志自定义事件获取订阅、取消订阅的日志, 协作者和责任链模式的CSM模块名不能带有后缀test11-RegisterUnregister_Event.vi✔✔✔✔✔✔
13可以通过全局日志自定义事件获得模块消息通讯的日志(messasge)test12-Message_Event.vi✔✔✔✔✔✔
14可以通过全局日志自定义事件获得模块发布广播的日志(broadcast)test13-Broadcast_Event.vi✔✔✔✔✔✔
15可以通过全局日志自定义事件获得模块发布高优先级广播的日志(interrupt)test14-Interrupt_Event.vi✔✔✔✔✔✔
16可以通过全局日志自定义事件获得模块状态广播(state)的日志test15-StateBroadcast_Event.vi✔✔✔✔✔✔
17可以通过全局日志自定义事件获得模块自定义用户消息的日志test16-UserLog_Event.vi✔✔✔✔✔✔
18可以通过全局日志自定义事件获得模块Sync/Async/NoRep-Async消息的日志 已测试，见test12-Message_Event.vi✔✔✔✔✔✔
+ +备注：CSM模式包含普通模式、子模块模式、系统级模式、协作者模式、责任链模式、打包项目库模式，CSM1和CSM2之间包含所有可能的CSM模式对应关系。 +
+ +6. **系统级模块 (System Level Module)** + 测试 `CSM List Module.vi`API 功能，通过修改输入 Scope参数，识别包含或不包含系统级模块的场景。其它相关系统级模块功能已包含在消息（Message）类测试过。 + 具体测试项请见下方表格，代码详见 `testcase-CSMSystemLevelModule.lvclass`。 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 普通模式 子模块模式 系统级模式 协作者模式 责任链模式 打包项目库模式
1CSM List Module.vi 默认不能列出来 systemlevel module, 但是修改 scope 为 all 后，可以识别出来test1-SystemLevelModuleInListModuleAPI.vi✔✔✔✔✔✔
2SystemLevel的消息功能，已经在 Sync/Async/AsyncNoRep 消息的 testcases 中测试过已测试，见消息类测试✔✔✔✔✔✔
+ + +7. **子模块 (SubModule)** + 测试 `CSM List SubModules.vi` API 功能，根据输入的模块/子模块名称，正确找出对应的一级或多级子模块（recursive）。 + 具体测试项请见下方表格，代码详见 `testcase-CSMSubModule.lvclass`。 + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 子模块模式
1CSM List SubModules.vi 在 UI, UI.a1(不存在), UI.a2, UI.a1.b1, UI.a2.b2 存在的情况下，可以根据输入参数，正确的罗列出需要的 Submoduletest1-ListSubModulesInDifferentSenarios.vi✔
+ +8. **协作者模式 (Worker Mode)** + 测试多个协作者节点间的数据共享，确保外部写入的数据能被所有节点/模块通过 `CSM Attribute` 读取。其它相关功能已包含在消息（Message）类测试过。 + 具体测试项请见下方表格，代码详见 `testcase-CSMWorkerMode.lvclass`。 + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 协作者模式
1节点之间共享相同的CSM Attribute 数据空间，外部写入数据，内部所有模块读取的数据相同test1-AllWorkerNodesShareTheSameData.vi✔
+ + +9. **责任链模式 (Chain Mode)** + 测试多个节点间的数据共享与消息处理，验证不同节点定义的允许消息 (Allowed Messages) 是否能正确处理与报错，并测试节点退出时的顺序。其它相关功能已包含在消息（Message）类测试过。 + 具体测试项请见下方表格，代码详见 `testcase-CSMChainMode.lvclass`。 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 责任链模式
1节点之间共享相同的CSM Attribute 数据空间，外部写入数据，内部所有模块读取的数据相同test1-AllChainNodesShareTheSameData.vi✔
23个节点（A->B->C)，定义节点的Allowed Messages，互不相同的允许的消息，会发送到对应允许的模块运行；使用API发送同步消息，可以携带回正确的参数test2-DifferentChainNodesProcessDifferentAllowedMessages.vi✔
33个节点（A->B->C)，定义节点的Allowed Messages，AB, BC, AC, ABC 组合允许的消息，应该由链条端头的节点执行, 使用API发送同步消息，可以携带回正确的参数 test3-FirstChainNodeProcessesAllowedMessages.vi✔
43个节点（A->B->C)，定义节点的Allowed Messages, 没有可以执行的模块，由消息发送方报错test4-EndNodeHandlesErrorForNotAllowedMessages.vi✔
53个节点（A->B->C)，不同的节点都发出一个广播，订阅后，都能触发对应绑定模块的API, 取消订阅后，任意一个都不能触发test5-ChainNodeBroadcast.vi✔
63个节点（A->B->C)，如果使用”Macro: Exit“命令不显性明确哪个节点，而是用不带$后缀的核心名字退出时，需按照从链条底端到端头的顺序依次退出；如果使用”Macro: Exit“命令显性明确哪个节点，则只退出该节点模块，其余节点模块不受影响test6-ChainNodeExitSequenceCheck.vi✔
+ +10. **管理接口 (Management API)** + 测试 CSM 内置管理接口，如 `Module Status.vi`，验证其是否能正确读取模块信息（名称、节点数量等），并测试带有多种过滤功能的多态 VI。其它相关功能已包含在消息（Message）类测试过。 + 具体测试项请见下方表格，代码详见 `testcase-CSMManagementAPI.lvclass`。 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 普通模式 子模块模式 系统级模式 协作者模式 责任链模式 打包项目库模式
1模块实例化后，通过此接口可以读取模块的信息，测试所有不同的Mode是否能够读出，并且node个数是否正确，消息队列的数据个数可以不测test1-TestModuleStatusVI.vi✔✔✔✔✔✔
2创造一个复杂的消息列表，测试过滤功能只会过滤到对应的消息，测试多态VI里的每一个VI对应的过滤功能，不需要实际发送test2-TestFilterJKISMStringQueueVI.vi✔✔✔✔✔✔
+ + +11. **非 CSM 调用支持接口 (Non-CSM Caller Support API)** + 测试模块退出时生效的接口 API，如 `Module Exit Event.vi` 和 `Module Turns Invalid.vi`。其它相关功能已包含在消息（Message）类测试过。 + 具体测试项请见下方表格，代码详见 `testcase-CSMNonCSMCallerSupportAPI.lvclass`。 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 普通模式 子模块模式 系统级模式 协作者模式 责任链模式 打包项目库模式
1模块的退出能够触发Exit模块事件，协作者和责任链模式，在全部模块退出时才会触发此事件test1-testModuleExitEventAPI.vi✔✔✔✔✔✔
2模块的退出能够触发此状态修改，协作者和责任链模式，在全部模块退出时才会触发此事件test2-testModuleTurnsInvalidAPI.vi✔✔✔✔✔✔
+ + +12. **CSM 循环支持 (CSM Loop Support)** + 测试 CSM 框架支持的循环模式，验证模块在循环运行中既能接收外部消息并处理，又能向其他模块发送消息而不发生阻塞。 + 具体测试项请见下方表格，代码详见 `testcase-CSMAddonLoopSupport.lvclass`。 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 普通模式 子模块模式 系统级模式 打包项目库模式
1Loop 模式运行中，1. 可以接收外部发送的同步消息并相应处理；2.也可以发送同步消息到其他模块；test1-ProcessSyncMessageInCSMLoop(SendAndReceive).vi✔✔✔✔
2Loop 模式运行中，1. 可以接收外部发送的异步有返回消息并相应处理；2.也可以发送异步有返回消息到其他模块； test2-ProcessAsyncMessageWithReplyInCSMLoop(SendAndReceive).vi + ✔✔✔✔
3Loop 模式运行中，1. 可以接收外部发送的异步无返回消息并相应处理；2.也可以发送异步无返回消息到其他模块； test3-ProcessAsyncMessageWithoutReplyInCSMLoop(SendAndReceive).vi + ✔✔✔✔
+ 备注：CSM 的协作者模式(worker) 和 责任链(chain)模式，是由多个运行的节点组成特殊的模块，发送的消息，并不能明确的让某个节点执行。当某节点使用此模式时，就不能明确的使用消息通知它停止循环，因此，不建议在协作者模式(worker) 和 责任链(chain)模式中使用CSM LOOP Support,固该类单元测试不包含协作者模式和责任链模式的测试。 +
+ + + +--- + +## 🛡️3 维护注意事项 + +为确保该单元测试的长期维护与稳定运行，请注意以下事项： + +1. **广播测试顺序** + 广播 (Broadcast) 测试类建议放置为最后一个类执行，因为其占用硬件资源较多，若测试不当可能影响后续测试。 + +2. **新增测试项规范** + 如需添加新的测试项，请先检查对应测试类的最后一个测试项的尾部代码，如已禁用重新启动 CSM 模块，请先启用，再在最后添加新的测试项，并酌情决定是否在新增测试项结尾代码处重新启动模块。 + +3. **调试工具推荐** + 建议使用 CSM 自带的调试工具 `Debug Console – DebugTool.vi`。调试人员可使用该工具在不同模块间手动发送消息、查看返回值，并通过监测日志性能参数（如日志处理速度、队列数量）进行高级调试。 + +--- + +## 📜4 许可证 +本项目遵循 MIT License。 + +--- + +## 🔗 5 相关资源 +- [NI LabVIEW 官方文档](https://www.ni.com/labview) +- [CSM 框架 Wiki](https://github.com/NEVSTOP-LAB/Communicable-State-Machine) +- [JKI VI Tester Toolkit](https://www.ni.com/zh-cn/support/downloads/tools-network/download.vi-tester-unit-test-framework.html#378053) + + diff --git a/testcases/new/CSM_Unittest_README/Pictures/JKI_VI_Tester.png b/testcases/new/CSM_Unittest_README/Pictures/JKI_VI_Tester.png new file mode 100644 index 000000000..4bfd3574b Binary files /dev/null and b/testcases/new/CSM_Unittest_README/Pictures/JKI_VI_Tester.png differ diff --git a/testcases/new/CSM_Unittest_README/Pictures/LabVIEW_Project.png b/testcases/new/CSM_Unittest_README/Pictures/LabVIEW_Project.png new file mode 100644 index 000000000..98bf59274 Binary files /dev/null and b/testcases/new/CSM_Unittest_README/Pictures/LabVIEW_Project.png differ diff --git a/testcases/new/CSM_Unittest_README/Tables/table10_ManagementAPI(en-us).md b/testcases/new/CSM_Unittest_README/Tables/table10_ManagementAPI(en-us).md new file mode 100644 index 000000000..cebc36e3d --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table10_ManagementAPI(en-us).md @@ -0,0 +1,35 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode Submodule Mode System-Level Mode Worker Mode Chain Mode lvlibp
1After module instantiation, this interface can be used to read module information. Test whether all different Modes can be read and whether the number of nodes is correct. The number of items in the message queue does not need to be tested.test1-TestModuleStatusVI.vi✔✔✔✔✔✔
2Create a complex message list and test that the filter function only filters the corresponding messages. Test the filter function of each VI in the polymorphic VI. Actual sending is not required.test2-TestFilterJKISMStringQueueVI.vi✔✔✔✔✔✔
diff --git a/testcases/new/CSM_Unittest_README/Tables/table10_ManagementAPI(zh-cn).md b/testcases/new/CSM_Unittest_README/Tables/table10_ManagementAPI(zh-cn).md new file mode 100644 index 000000000..073f4475b --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table10_ManagementAPI(zh-cn).md @@ -0,0 +1,35 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 普通模式 子模块模式 系统级模式 协作者模式 责任链模式 打包项目库模式
1模块实例化后，通过此接口可以读取模块的信息，测试所有不同的Mode是否能够读出，并且node个数是否正确，消息队列的数据个数可以不测test1-TestModuleStatusVI.vi✔✔✔✔✔✔
2创造一个复杂的消息列表，测试过滤功能只会过滤到对应的消息，测试多态VI里的每一个VI对应的过滤功能，不需要实际发送test2-TestFilterJKISMStringQueueVI.vi✔✔✔✔✔✔
diff --git a/testcases/new/CSM_Unittest_README/Tables/table11_NonCallerSupportAPI(en-us).md b/testcases/new/CSM_Unittest_README/Tables/table11_NonCallerSupportAPI(en-us).md new file mode 100644 index 000000000..1044d122c --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table11_NonCallerSupportAPI(en-us).md @@ -0,0 +1,35 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode Submodule Mode System-Level Mode Worker Mode Chain Mode lvlibp
1Module exit can trigger the Exit Module event. In Worker and Chain modes, this event is triggered only when all modules have exited.test1-testModuleExitEventAPI.vi✔✔✔✔✔✔
2Module exit can trigger this status change. In Worker and Chain modes, this event is triggered only when all modules have exited.test2-testModuleTurnsInvalidAPI.vi✔✔✔✔✔✔
diff --git a/testcases/new/CSM_Unittest_README/Tables/table11_NonCallerSupportAPI(zh-cn).md b/testcases/new/CSM_Unittest_README/Tables/table11_NonCallerSupportAPI(zh-cn).md new file mode 100644 index 000000000..9f7c0ced6 --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table11_NonCallerSupportAPI(zh-cn).md @@ -0,0 +1,35 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 普通模式 子模块模式 系统级模式 协作者模式 责任链模式 打包项目库模式
1模块的退出能够触发Exit模块事件，协作者和责任链模式，在全部模块退出时才会触发此事件test1-testModuleExitEventAPI.vi✔✔✔✔✔✔
2模块的退出能够触发此状态修改，协作者和责任链模式，在全部模块退出时才会触发此事件test2-testModuleTurnsInvalidAPI.vi✔✔✔✔✔✔
diff --git a/testcases/new/CSM_Unittest_README/Tables/table12_CSMLoopSupport(en-us).md b/testcases/new/CSM_Unittest_README/Tables/table12_CSMLoopSupport(en-us).md new file mode 100644 index 000000000..0bd860a94 --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table12_CSMLoopSupport(en-us).md @@ -0,0 +1,45 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode Submodule Mode System-Level Mode lvlibp
1While running in Loop mode: 1. Can receive and process synchronous messages sent from outside; 2. Can also send synchronous messages to other modules.test1-ProcessSyncMessageInCSMLoop(SendAndReceive).vi✔✔✔✔
2While running in Loop mode: 1. Can receive and process asynchronous messages with reply sent from outside; 2. Can also send asynchronous messages with reply to other modules.test2-ProcessAsyncMessageWithReplyInCSMLoop(SendAndReceive).vi + ✔✔✔✔
3While running in Loop mode: 1. Can receive and process asynchronous messages without reply sent from outside; 2. Can also send asynchronous messages without reply to other modules.test3-ProcessAsyncMessageWithoutReplyInCSMLoop(SendAndReceive).vi + ✔✔✔✔
+ Note: The CSM (=worker and chain modes are special module patterns composed of multiple running nodes. Messages sent in these modes cannot reliably target a specific node to execute. When a node operates in worker or chain modes, it cannot be clearly instructed by messages to stop a loop. Therefore, it is not recommended to use the CSM Loop Support addon in worker and chain modes. Therefore, this testclass does not cover worker and chain modes. +
diff --git a/testcases/new/CSM_Unittest_README/Tables/table12_CSMLoopSupport(zh-cn).md b/testcases/new/CSM_Unittest_README/Tables/table12_CSMLoopSupport(zh-cn).md new file mode 100644 index 000000000..5598af62f --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table12_CSMLoopSupport(zh-cn).md @@ -0,0 +1,45 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 普通模式 子模块模式 系统级模式 打包项目库模式
1Loop 模式运行中，1. 可以接收外部发送的同步消息并相应处理；2.也可以发送同步消息到其他模块；test1-ProcessSyncMessageInCSMLoop(SendAndReceive).vi✔✔✔✔
2Loop 模式运行中，1. 可以接收外部发送的异步有返回消息并相应处理；2.也可以发送异步有返回消息到其他模块； test2-ProcessAsyncMessageWithReplyInCSMLoop(SendAndReceive).vi + ✔✔✔✔
3Loop 模式运行中，1. 可以接收外部发送的异步无返回消息并相应处理；2.也可以发送异步无返回消息到其他模块； test3-ProcessAsyncMessageWithoutReplyInCSMLoop(SendAndReceive).vi + ✔✔✔✔
+ 备注：CSM 的协作者模式(worker) 和 责任链(chain)模式，是由多个运行的节点组成特殊的模块，发送的消息，并不能明确的让某个节点执行。当某节点使用此模式时，就不能明确的使用消息通知它停止循环，因此，不建议在协作者模式(worker) 和 责任链(chain)模式中使用CSM LOOP Support,固该类单元测试不包含协作者模式和责任链模式的测试。 +
diff --git a/testcases/new/CSM_Unittest_README/Tables/table1_Message(en-us).md b/testcases/new/CSM_Unittest_README/Tables/table1_Message(en-us).md new file mode 100644 index 000000000..b8d77f14f --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table1_Message(en-us).md @@ -0,0 +1,106 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode Submodule Mode System-Level Mode Worker Mode Chain Mode lvlibp
1CSM1 sends a synchronous message to CSM2, CSM2 returns the correct reply, CSM1 enters Response Case to process the reply infotest1-SyncMessage.vi✔✔✔✔✔✔
2CSM1 sends a synchronous message to CSM2, CSM2 encounters an error, CSM1 enters Response Case carrying the Response and error informationtest2-SycnMessageWithError.vi✔✔✔✔✔✔
3CSM1 uses API to send a synchronous message to CSM2, CSM2 returns the correct Response, CSM1 obtains the return via APItest3-SyncMessage_API.vi✔✔✔✔✔✔
4CSM1 uses API to send a synchronous message to CSM2, CSM2 encounters an error, CSM1 obtains the Response and error information via APItest4-SyncMessageWithError_API.vi✔✔✔✔✔✔
5CSM1 sends an asynchronous message with reply to CSM2, CSM2 returns the correct Response, CSM1 enters Async Response to process the replytest5-AsyncMessageWithReply.vi✔✔✔✔✔✔
6CSM1 sends an asynchronous message with reply to CSM2, CSM2 encounters an error, CSM1 enters Async Response carrying the Response and error informationtest6-AsyncMessageWithReplyWithError.vi✔✔✔✔✔✔
7CSM1 sends an asynchronous message without reply to CSM2, verifies that CSM2 executes, CSM1 does not process the replytest7-AsyncMessageWithoutReply.vi✔✔✔✔✔✔
8CSM1 uses API to send an asynchronous message without reply to CSM, verifies that the caller executes asynchronously, does not process the replytest8-AsyncMessageWithoutReply_API.vi✔✔✔✔✔✔
+ Note: CSM modes include Normal Mode, Submodule Mode, System-Level Mode, Worker Mode, Chain Mode, and lvlibp. All possible CSM mode relationships between CSM1 and CSM2 are covered. +
diff --git a/testcases/new/CSM_Unittest_README/Tables/table1_Message(zh-cn) - Copy.md b/testcases/new/CSM_Unittest_README/Tables/table1_Message(zh-cn) - Copy.md new file mode 100644 index 000000000..f665faa74 --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table1_Message(zh-cn) - Copy.md @@ -0,0 +1,106 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 普通模式 子模块模式 系统级模式 协作者模式 责任链模式 打包项目库模式
1CSM1发送同步消息给CSM2，CSM2返回正确的Response, CSM1进入Response Case 处理返回test1-SyncMessage.vi✔✔✔✔✔✔
2CSM1发送同步消息给CSM2，CSM2执行出错，CSM1进入Response Case, 携带了Response和错误信息test2-SycnMessageWithError.vi✔✔✔✔✔✔
3CSM1使用API发送同步消息给CSM2，CSM2返回正确的Response, CSM1通过API拿到返回test3-SyncMessage_API.vi✔✔✔✔✔✔
4CSM1使用API发送同步消息给CSM2，CSM2执行出错，CSM1通过API拿到Response和错误信息test4-SyncMessageWithError_API.vi✔✔✔✔✔✔
5CSM1发送异步有返回消息给CSM2，CSM2返回正确的Response, CSM1进入Async Response 处理返回test5-AsyncMessageWithReply.vi✔✔✔✔✔✔
6CSM1发送异步有返回消息给CSM2，CSM2执行出错，CSM1进入Async Response, 携带了Response和错误信息test6-AsyncMessageWithReplyWithError.vi✔✔✔✔✔✔
7CSM1发送异步无返回消息给CSM2，检查确认CSM2执行，CSM1不处理返回test7-AsyncMessageWithoutReply.vi✔✔✔✔✔✔
8CSM1使用API发送异步无返回消息给CSM，检查确认调用方异步执行，不处理返回test8-AsyncMessageWithoutReply_API.vi✔✔✔✔✔✔
+ 备注：CSM模式包含普通模式、子模块模式、系统级模式、协作者模式、责任链模式、打包项目库模式，CSM1和CSM2之间包含所有可能的CSM模式对应关系。 +
diff --git a/testcases/new/CSM_Unittest_README/Tables/table1_Message(zh-cn).md b/testcases/new/CSM_Unittest_README/Tables/table1_Message(zh-cn).md new file mode 100644 index 000000000..f665faa74 --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table1_Message(zh-cn).md @@ -0,0 +1,106 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 普通模式 子模块模式 系统级模式 协作者模式 责任链模式 打包项目库模式
1CSM1发送同步消息给CSM2，CSM2返回正确的Response, CSM1进入Response Case 处理返回test1-SyncMessage.vi✔✔✔✔✔✔
2CSM1发送同步消息给CSM2，CSM2执行出错，CSM1进入Response Case, 携带了Response和错误信息test2-SycnMessageWithError.vi✔✔✔✔✔✔
3CSM1使用API发送同步消息给CSM2，CSM2返回正确的Response, CSM1通过API拿到返回test3-SyncMessage_API.vi✔✔✔✔✔✔
4CSM1使用API发送同步消息给CSM2，CSM2执行出错，CSM1通过API拿到Response和错误信息test4-SyncMessageWithError_API.vi✔✔✔✔✔✔
5CSM1发送异步有返回消息给CSM2，CSM2返回正确的Response, CSM1进入Async Response 处理返回test5-AsyncMessageWithReply.vi✔✔✔✔✔✔
6CSM1发送异步有返回消息给CSM2，CSM2执行出错，CSM1进入Async Response, 携带了Response和错误信息test6-AsyncMessageWithReplyWithError.vi✔✔✔✔✔✔
7CSM1发送异步无返回消息给CSM2，检查确认CSM2执行，CSM1不处理返回test7-AsyncMessageWithoutReply.vi✔✔✔✔✔✔
8CSM1使用API发送异步无返回消息给CSM，检查确认调用方异步执行，不处理返回test8-AsyncMessageWithoutReply_API.vi✔✔✔✔✔✔
+ 备注：CSM模式包含普通模式、子模块模式、系统级模式、协作者模式、责任链模式、打包项目库模式，CSM1和CSM2之间包含所有可能的CSM模式对应关系。 +
diff --git a/testcases/new/CSM_Unittest_README/Tables/table2_Argument(en-us).md b/testcases/new/CSM_Unittest_README/Tables/table2_Argument(en-us).md new file mode 100644 index 000000000..4aa0f5817 --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table2_Argument(en-us).md @@ -0,0 +1,43 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode
1Create preset information and verify HexString conversion works correctly: 1. Check a nested complex Cluster; 2. Check empty string parsing behavior.test1-HexStr conversion.vi✔
2Create preset information and verify ErrorString conversion works correctly: 1. Conversion of Error; 2. Conversion of No Error; 3. Empty string behavior.test2-ErrorStr conversion.vi✔
3Create preset information and verify SafeString conversion works correctly: 1. Empty string behavior (no conversion for empty string); 2. Behavior with special characters; 3. Behavior with carriage return.test3-SafeStr conversion.vi✔
4CSM - Argument Type.vi can correctly identify HexString/ErrorString/SafeString types.Integrated in test1,2,3✔
5Parameters sent from CSM1 to CSM2 are correctly carried into the TargetCSM, i.e., into the CSM.test4-ArgumentCanBeTakenToTargetModule.vi✔
+ Note: Only normal mode is tested between CSM1 and CSM2, other modes have been tested in the message test class. +
\ No newline at end of file diff --git a/testcases/new/CSM_Unittest_README/Tables/table2_Argument(zh-cn).md b/testcases/new/CSM_Unittest_README/Tables/table2_Argument(zh-cn).md new file mode 100644 index 000000000..60770afe1 --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table2_Argument(zh-cn).md @@ -0,0 +1,44 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 普通模式
1创建预设的信息，检查HexString转换没有问题 1.检查一个嵌套的复杂Cluster; 2. 检查空字符串解析行为test1-HexStr conversion.vi✔
2创建预设的信息，检查ErrorString转换没有问题 1. Error 的转换; 2. No Error 的转换; 3. 空字符串行为test2-ErrorStr conversion.vi✔
3创建预设的信息，检查SafeString转换没有问题 1. 空字符串行为，空字符串不做转换 2. 带有特殊字符的字符串行为；3. 有回车的行为test3-SafeStr conversion.vi✔
4CSM - Argument Type.vi 能够正常的识别 HexString/ErrorString/SafeString 的Type集成于test1,2,3✔
5CSM1发送到CSM2的参数，会正常的被携带到TargetCSM中，即CSM中test4-ArgumentCanBeTakenToTargetModule.vi✔
+ 备注：CSM1和CSM2之间只测试普通模式，其他的模式在消息类中已经测试。 +
diff --git a/testcases/new/CSM_Unittest_README/Tables/table3_Response(en-us).md b/testcases/new/CSM_Unittest_README/Tables/table3_Response(en-us).md new file mode 100644 index 000000000..613286eb2 --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table3_Response(en-us).md @@ -0,0 +1,111 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode Submodule Mode System-Level Mode Worker Mode Chain Mode lvlibp
1Basic message response function, already tested in message test class, including Sync/Async/AsyncNoRepTested✔✔✔✔✔✔
2CSM1 sends a message to CSM2, single message response. When an error occurs, it first enters the Error Handler, but still returns the Response of the message execution case.test1-ResponseWithError.vi✔✔✔✔✔✔
3Macro message execution returns the response of the last SubMessagetest2-MacroWithSubMessages.vi✔✔✔✔✔✔
4Macro message execution with PostStep messages returns the response of the last SubMessagetest3-MacroWithSubAndPostMessages.vi✔✔✔✔✔✔
5¹Macro message execution: if the last SubMessage sends a message to another module (sync/async with response/async no response), the final return value is emptytest4-MacroWithNonLocalSubMessages.vi✔✔✔✔✔✔
6Message response: Sync message API carries the name of the executing module, already tested in test3-SyncMessage_API.vi of the message test classTested✔✔✔✔✔✔
7In Response/Async Response, the source module name, message name, and message parameters can be obtained, already tested in Sync/Async/AsyncNoRep message test cases.Tested✔✔✔✔✔✔
8Message response with Error, already tested in Sync/Async/AsyncNoRep message test casesTested✔✔✔✔✔✔
+ ¹ Related issue tracking: + + https://github.com/NEVSTOP-LAB/Communicable-State-Machine/issues/547 + +

+ Note: CSM modes include Normal Mode, Submodule Mode, System-Level Mode, Worker Mode, Chain Mode, and lvlibp. All possible CSM mode relationships between CSM1 and CSM2 are included. +
diff --git a/testcases/new/CSM_Unittest_README/Tables/table3_Response(zh-cn).md b/testcases/new/CSM_Unittest_README/Tables/table3_Response(zh-cn).md new file mode 100644 index 000000000..331bfa237 --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table3_Response(zh-cn).md @@ -0,0 +1,112 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 普通模式 子模块模式 系统级模式 协作者模式 责任链模式 打包项目库模式
1普通的消息返回功能，已经在 包含Sync/Async/AsyncNoRep 的消息类测试过已测试✔✔✔✔✔✔
2CSM1发送消息给CSM2，单条消息的返回，当产生错误后，会首先进入Error Handler, 但是依然会返回消息执行case的Responsetest1-ResponseWithError.vi✔✔✔✔✔✔
3宏消息执行，会返回最后一条 SubMessage 的返回test2-MacroWithSubMessages.vi✔✔✔✔✔✔
4宏消息执行，包含PostStep的消息，会返回最后一条 SubMessage 的返回test3-MacroWithSubAndPostMessages.vi✔✔✔✔✔✔
5¹宏消息执行，如果SubMessage最后一条是发送消息到其他模块(同步/异步有返回/异步无返回)，最终返回值为空test4-MacroWithNonLocalSubMessages.vi✔✔✔✔✔✔
6消息返回，同步消息API会携带执行模块的名称，在消息测试类的test3-SyncMessage_API.vi已测已测试✔✔✔✔✔✔
7Response/Async Response 中，可以获取Source Module 名称、消息名称、消息参数，已经在 Sync/Async/AsyncNoRep 消息的 testcases 中测试过已测试✔✔✔✔✔✔
8消息返回携带Error的功能，已经在 Sync/Async/AsyncNoRep 消息的 testcases 中测试过已测试✔✔✔✔✔✔
+ ¹ 相关问题跟踪： + + https://github.com/NEVSTOP-LAB/Communicable-State-Machine/issues/547 + +

+ 备注：CSM模式包含普通模式、子模块模式、系统级模式、协作者模式、责任链模式、打包项目库模式，CSM1和CSM2之间包含所有可能的CSM模式对应关系。 +
diff --git a/testcases/new/CSM_Unittest_README/Tables/table4_Broadcast(en-us).md b/testcases/new/CSM_Unittest_README/Tables/table4_Broadcast(en-us).md new file mode 100644 index 000000000..c82edbc8b --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table4_Broadcast(en-us).md @@ -0,0 +1,366 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode Submodule Mode System-Level Mode Worker Mode Chain Mode lvlibp
1CSM1 throws Status, can use Register/Unregister internally or externally to control Status triggering the State bound to CSM2test1-LocalExternalStatusRegistration.vi✔✔✔✔✔✔
2CSM1 throws Status, can use API internally or externally to control Status triggering the State bound to CSM2test2-LocalExternalStatusRegistrationViaAPI.vi✔✔✔✔✔✔
3CSM1 throws Status, can use API internally or externally to control Status triggering the State bound to CSM2test24-MappingRelationshipByExternalRegistration_API.vi✔✔✔✔✔✔
4CSM1 throws Status, when subscribing externally with string syntax, the subscription does not disappear after CSM exitstest25-MappingRelationshipByExternalRegistration.vi✔✔✔✔✔✔
5CSM1 throws Status, when subscribing internally to its own State: if the subscriber name is explicitly written as CSM1, the subscription does not disappear after exit; if the subscriber name is omitted, the subscription is automatically removed after exit.test26-MappingRelationshipByLocalRegistration_WithSubcriberName.vi +

+test27-MappingRelationshipByLocalRegistration_WithoutSubcriberName.vi		✔✔✔✔✔✔
6CSM1 throws Status, can be subscribed to multiple States in multiple modules, all will be triggered automatically after throwingtest3-1ToNBroadcastStatus.vi✔✔✔✔✔✔
7CSM1 throws Status, can be subscribed in non-CSM using UserEventtest4-RegisterStatusFromNonCSM.vi✔✔✔✔✔✔
8CSM1/CSM3 throw different Statuses, can be subscribed to CSM2's State, both can trigger CSM2 to execute Statetest5-RegisterMultipleStatusesToOneState.vi✔✔✔✔✔✔
9When subscribing, Source Module Name can use * as a wildcard to subscribe to the same Status from multiple modules at once; unsubscribing from one module's Status does not affect otherstest6-AsteriskWildcardStatusRegistration.vi✔✔✔✔✔✔
10After successful subscription, CSM1 throws Status multiple times, the subscriber receives all State triggers without losstest15-LosslessRegisterStatusMultipleTimes.vi✔✔✔✔✔✔
11After successful subscription, CSM1 throws Status multiple times, the subscriber receives all State triggers without loss (subscribed in non-CSM using UserEvent)test16-LosslessRegisterStatusMultipleTimesNonCSM.vi✔✔✔✔✔✔
12The Argument of Status is the Argument of the triggered StateTested, see test1-LocalExternalStatusRegistration.vi✔✔✔✔✔✔
13The triggered Status can obtain Source State Name/Source module from Argument Infotest7-TestArgumentInfoOfTriggeredState_Status.vi✔✔✔✔✔✔
14CSM1 throws Interrupt, can be subscribed to multiple States in multiple modules, all will be triggered automatically after throwingtest19-1ToNInterruptStatus.vi✔✔✔✔✔✔
15CSM1 throws Interrupt, can be subscribed in non-CSM using Interrupt User Event; Status User Event will not triggertest21-RegisterInterruptFromNonCSM.vi✔✔✔✔✔✔
16CSM1 throws Status, subscribed as interrupt, can be subscribed in non-CSM using Interrupt User Event; Status User Event will not triggertest20-RegisterStatusAsInterruptFromNonCSM.vi + ✔✔✔✔✔✔
17CSM1 throws Interrupt, subscribed as Status, can be subscribed in non-CSM using Status User Event; Interrupt User Event will not triggertest22-RegisterInterruptAsStatusFromNonCSM.vi✔✔✔✔✔✔
18CSM1 does not throw Status, its State can use Register/Unregister internally or externally to control Status triggering the State bound to CSM2test8-LocalExternalStateRegistration.vi✔✔✔✔✔✔
19CSM1 does not throw Status, its State can use API internally or externally to control Status triggering the State bound to CSM2test9-LocalExternalStateRegistrationViaAPI.vi✔✔✔✔✔✔
20CSM1 does not throw Status, when subscribing externally to its State with string syntax, the subscription does not disappear after exittest29-MappingRelationshipByExternalRegistration_State.vi✔✔✔✔✔✔
21CSM1 does not throw Status, when subscribing externally to its State via API, the subscription does not disappear after exittest28-MappingRelationshipByExternalRegistration_API_State.vi✔✔✔✔✔✔
22CSM1 does not throw Status, when subscribing internally to its own State: if the subscriber name is explicitly written as CSM1, the subscription does not disappear after exit; if the subscriber name is omitted, the subscription is automatically removed after exit.test30-MappingRelationshipByLocalRegistration_WIthSubscriberName_State.vi +

+test31-MappingRelationshipByLocalRegistration_WIthoutSubscriberName_State.vi		✔✔✔✔✔✔
23CSM1 does not throw Status, its State can be subscribed to multiple States in multiple modules, all will be triggered automatically after throwingtest10-1ToNBroadcastState.vi✔✔✔✔✔✔
24CSM1 does not throw Status, its State can be subscribed in non-CSM using UserEventtest11-RegisterStatesFromNonCSM_State.vi✔✔✔✔✔✔
25CSM1/CSM3 have different States, can be subscribed to CSM2's State, both can trigger CSM2 to execute Statetest12-RegisterMultipleStatesToOneState.vi/td> + ✔✔✔✔✔✔
26When subscribing, Source Module Name can use * as a wildcard to subscribe to the same State from multiple modules at once; unsubscribing from one module's State does not affect otherstest13-AsteriskWildcardStateRegistration.vi✔✔✔✔✔✔
27After successful subscription, CSM1 throws State multiple times, the subscriber receives all State triggers without losstest17-LosslessRegisterStateMultipleTimes.vi✔✔✔✔✔✔
28After successful subscription, CSM1 throws State multiple times, the subscriber receives all State triggers without loss (subscribed in non-CSM using UserEvent)test16-LosslessRegisterStateMultipleTimesNonCSM.vi✔✔✔✔✔✔
29The Response of State is the Argument of the triggered StateTested, see test8-LocalExternalStateRegistration.vi✔✔✔✔✔✔
30The triggered State can obtain Source State Name/Source module from Argument Infotest14-TestArgumentInfoOfTriggeredState_State.vi✔✔✔✔✔✔
31Subscribe State as interrupt, in Non-CSM mode, events can only be obtained in interrupt User Event, not in Status User Eventtest23-RegisterStatusAsInterruptFromNonCSM_State.vi✔✔✔✔✔✔
+¹: The unit test VIs of this class are not sorted from top to bottom according to this table, but are sorted according to the actual test machine, especially the performance of the actual running machine for Git CI/CD. +

+ Note: CSM modes include Normal Mode, Submodule Mode, System-Level Mode, Worker Mode, Chain Mode, and lvlibp. All possible CSM mode relationships between CSM1 and CSM2 are included. +
diff --git a/testcases/new/CSM_Unittest_README/Tables/table4_Broadcast(zh-cn).md b/testcases/new/CSM_Unittest_README/Tables/table4_Broadcast(zh-cn).md new file mode 100644 index 000000000..b08d02738 --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table4_Broadcast(zh-cn).md @@ -0,0 +1,366 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI¹ 普通模式 子模块模式 系统级模式 协作者模式 责任链模式 打包项目库模式
1CSM1抛出Status, 可以通过 Register/Unregister 在内部、外部，控制Status 触发 CSM2绑定的Statetest1-LocalExternalStatusRegistration.vi✔✔✔✔✔✔
2CSM1抛出Status, 可以通过 API 在内部、外部，控制Status 触发 CSM2绑定的Statetest2-LocalExternalStatusRegistrationViaAPI.vi✔✔✔✔✔✔
3CSM1抛出Status, 可以通过 API 在内部、外部，控制Status 触发 CSM2绑定的Statetest24-MappingRelationshipByExternalRegistration_API.vi✔✔✔✔✔✔
4CSM1抛出Status, 在外部使用语句订阅时，CSM退出后，订阅关系不会消失test25-MappingRelationshipByExternalRegistration.vi✔✔✔✔✔✔
5CSM1抛出Status, 在内部使用语句订阅到本模块的State时:如果明确写出订阅者名字为CSM1，退出后，订阅关系不会消失；如果省略订阅者名字，退出后，订阅关系会自动被移除；test26-MappingRelationshipByLocalRegistration_WithSubcriberName.vi +

+test27-MappingRelationshipByLocalRegistration_WithoutSubcriberName.vi		✔✔✔✔✔✔
6CSM1抛出Status, 可以被订阅到多个模块的多个状态，抛出后全部会自动触发test3-1ToNBroadcastStatus.vi✔✔✔✔✔✔
7CSM1抛出Status, 可以在非CSM中，使用UserEvent 进行订阅test4-RegisterStatusFromNonCSM.vi✔✔✔✔✔✔
8CSM1/CSM3 抛出不同的Status, 可以订阅到 CSM2 的State, 都能触发 CSM2 执行 Statetest5-RegisterMultipleStatusesToOneState.vi✔✔✔✔✔✔
9订阅时Source Module Name 可以使用 * 作为通配符，一次性订阅多个模块的同一个Status，可以取消订阅某一个module 的该Status,其他模块的不被影响test6-AsteriskWildcardStatusRegistration.vi✔✔✔✔✔✔
10订阅成功后，CSM1 抛出多次 Status, 订阅方会收到所有的State 触发，不会丢失test15-LosslessRegisterStatusMultipleTimes.vi✔✔✔✔✔✔
11订阅成功后，CSM1 抛出多次Status, 订阅方会收到所有的State 触发，不会丢失（非CSM中，使用UserEvent 进行订阅）test16-LosslessRegisterStatusMultipleTimesNonCSM.vi✔✔✔✔✔✔
12Status 的 Argument, 就是触发后的State 的Argument已测试，见test1-LocalExternalStatusRegistration.vi✔✔✔✔✔✔
13被触发的Status ,可以通过 Argument Info 中获取 Source State Name/ Source moduletest7-TestArgumentInfoOfTriggeredState_Status.vi✔✔✔✔✔✔
14CSM1抛出Interrupt, 可以被订阅到多个模块的多个状态，抛出后全部会自动触发test19-1ToNInterruptStatus.vi✔✔✔✔✔✔
15CSM1抛出Interrupt, 可以在非CSM 中，使用 Interrupt User Event 进行订阅获取，Status User Event 不会触发test21-RegisterInterruptFromNonCSM.vi✔✔✔✔✔✔
16CSM1抛出Status, 订阅为 interrupt, 可以在非CSM 中，使用 Interrupt User Event 进行订阅获取，Status User Event 不会触发test20-RegisterStatusAsInterruptFromNonCSM.vi + ✔✔✔✔✔✔
17CSM1抛出Interrupt, 订阅为 Status, 可以在非CSM 中，使用Status User Event 进行订阅获取，Interrupt User Event 不会触发test22-RegisterInterruptAsStatusFromNonCSM.vi✔✔✔✔✔✔
18CSM1不抛出Status,它的State, 可以通过 Regiseter/Unregister 在内部、外部，控制Status 触发 CSM2绑定的Statetest8-LocalExternalStateRegistration.vi✔✔✔✔✔✔
19CSM1不抛出Status,它的State, 可以通过 API 在内部、外部，控制Status 触发 CSM2绑定的Statetest9-LocalExternalStateRegistrationViaAPI.vi✔✔✔✔✔✔
20CSM1不抛出Status,它的State, 在外部使用语句订阅时，推出后，订阅关系不会消失test29-MappingRelationshipByExternalRegistration_State.vi✔✔✔✔✔✔
21CSM1不抛出Status,它的State, 在外部使用API订阅时，推出后，订阅关系不会消失test28-MappingRelationshipByExternalRegistration_API_State.vi✔✔✔✔✔✔
22CSM1不抛出Status,它的State, 在内部使用语句订阅到本模块的State时：如果明确写出订阅者名字为CSM1，退出后，订阅关系不会消失；如果省略订阅者名字，退出后，订阅关系会自动被移除；test30-MappingRelationshipByLocalRegistration_WIthSubscriberName_State.vi +

+test31-MappingRelationshipByLocalRegistration_WIthoutSubscriberName_State.vi		✔✔✔✔✔✔
23CSM1不抛出Status,它的State, 可以被订阅到多个模块的多个状态，抛出后全部会自动触发test10-1ToNBroadcastState.vi✔✔✔✔✔✔
24CSM1不抛出Status,它的State, 可以在非CSM中，使用UserEvent 进行订阅test11-RegisterStatesFromNonCSM_State.vi✔✔✔✔✔✔
25CSM1/CSM3 不同的State, 可以订阅到 CSM2 的State, 都能触发 CSM2 执行 Statetest12-RegisterMultipleStatesToOneState.vi/td> + ✔✔✔✔✔✔
26订阅时Source Module Name 可以使用 * 作为通配符，一次性订阅多个模块的同一个State，可以取消订阅某一个module 的该State,其他模块的不被影响test13-AsteriskWildcardStateRegistration.vi✔✔✔✔✔✔
27订阅成功后，CSM1 抛出多次 State, 订阅方会收到所有State 触发，不会丢失test17-LosslessRegisterStateMultipleTimes.vi✔✔✔✔✔✔
28订阅成功后，CSM1 抛出多次 State, 订阅方会收到所有State 触发，不会丢失（非CSM中，使用UserEvent 进行订阅）test16-LosslessRegisterStateMultipleTimesNonCSM.vi✔✔✔✔✔✔
29State 的 Response, 就是触发后的State 的Argument 已测试，见test8-LocalExternalStateRegistration.vi✔✔✔✔✔✔
30被触发的State ,可以通过 Argument Info 中获取 Source State Name/ Source moduletest14-TestArgumentInfoOfTriggeredState_State.vi✔✔✔✔✔✔
31将state 订阅为 interrupt, Non-CSM 模式下，只能在interrupt User Event 中获取事件，在 Status User Event 中无法获取队列test23-RegisterStatusAsInterruptFromNonCSM_State.vi✔✔✔✔✔✔
+¹：该类的单元测试vi未按照该表格从上至下顺序排序，而是按照实际测试机台，特别是Git CI/CD实际运行机台性能而做的排序。 +

+ 备注：CSM模式包含普通模式、子模块模式、系统级模式、协作者模式、责任链模式、打包项目库模式，CSM1和CSM2之间包含所有可能的CSM模式对应关系。 +
diff --git a/testcases/new/CSM_Unittest_README/Tables/table5_GlobalLog(en-us).md b/testcases/new/CSM_Unittest_README/Tables/table5_GlobalLog(en-us).md new file mode 100644 index 000000000..334902ab0 --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table5_GlobalLog(en-us).md @@ -0,0 +1,217 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode Submodule Mode System-Level Mode Worker Mode Chain Mode lvlibp
1Module creation and destruction logs (module created/module destroyed) can be obtained through the global log queue, and the number of logs can be checked for correctnesstest1-ModuleCreatedDestroyed_Queue.vi✔✔✔✔✔✔
2Module state change logs (state change) can be obtained through the global log queue: sending a message via external API triggers an internal state change in the CSM module. Both the triggering message and the resulting state change can be seen in the global log.test2-StateChange_Queue.vi✔✔✔✔✔✔
3Subscription and unsubscription logs can be obtained through the global log queue. CSM module names in Worker and Chain modes must not have suffixes.test3-RegisterUnregister_Queue.vi✔✔✔✔✔✔
4Module message communication logs (message) can be obtained through the global log queue: sending a synchronous message via external API triggers an internal state in CSM1, which then sends a synchronous message to CSM2. Both messages should be strictly logged in the correct format.test4-Message_Queue.vi✔✔✔✔✔✔
5Module broadcast logs (broadcast) can be obtained through the global log queuetest5-Broadcast_Queue.vi✔✔✔✔✔✔
6Module high-priority broadcast logs (interrupt) can be obtained through the global log queuetest6-Interrupt_Queue.vi✔✔✔✔✔✔
7Module state broadcast logs (state) can be obtained through the global log queuetest7-StateBroadcast_Queue.vi✔✔✔✔✔✔
8Module custom user message logs can be obtained through the global log queuetest8-UserLog_Queue.vi✔✔✔✔✔✔
9Module Sync/Async/NoRep-Async message logs can be obtained through the global log queueTested, see test4-Message_Queue.vi✔✔✔✔✔✔
10Module creation and destruction logs (module created/module destroyed) can be obtained through global log custom events, and the number of logs can be checked for correctnesstest9-ModuleCreatedDestroyed_Event.vi✔✔✔✔✔✔
11Module state change logs (state change) can be obtained through global log custom events: sending a message via external API triggers an internal state change in the CSM module. Both the triggering message and the resulting state change can be seen in the global log.test10-StateChange_Event.vi✔✔✔✔✔✔
12Subscription and unsubscription logs can be obtained through global log custom events. CSM module names in Worker and Chain modes must not have suffixes.test11-RegisterUnregister_Event.vi✔✔✔✔✔✔
13Module message communication logs (message) can be obtained through global log custom eventstest12-Message_Event.vi✔✔✔✔✔✔
14Module broadcast logs (broadcast) can be obtained through global log custom eventstest13-Broadcast_Event.vi✔✔✔✔✔✔
15Module high-priority broadcast logs (interrupt) can be obtained through global log custom eventstest14-Interrupt_Event.vi✔✔✔✔✔✔
16Module state broadcast logs (state) can be obtained through global log custom eventstest15-StateBroadcast_Event.vi✔✔✔✔✔✔
17Module custom user message logs can be obtained through global log custom eventstest16-UserLog_Event.vi✔✔✔✔✔✔
18Module Sync/Async/NoRep-Async message logs can be obtained through global log custom eventsTested, see test12-Message_Event.vi✔✔✔✔✔✔
+ +Note: CSM modes include Normal Mode, Submodule Mode, System-Level Mode, Worker Mode, Chain Mode, and lvlibp. All possible CSM mode relationships between CSM1 and CSM2 are included. +
diff --git a/testcases/new/CSM_Unittest_README/Tables/table5_GlobalLog(zh-cn).md b/testcases/new/CSM_Unittest_README/Tables/table5_GlobalLog(zh-cn).md new file mode 100644 index 000000000..98d4365cb --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table5_GlobalLog(zh-cn).md @@ -0,0 +1,217 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 普通模式 子模块模式 系统级模式 协作者模式 责任链模式 打包项目库模式
1可以通过全局日志队列获取模块创建和销毁的日志(module created/module destroyed)，并检查日志数量是否符合预期test1-ModuleCreatedDestroyed_Queue.vi✔✔✔✔✔✔
2可以通过全局日志队列获取模块状态轮转的日志(state change)： 通过外部API发送一条消息触发CSM模块内部状态变化(State Change), 可以在全局日志里既看到触发消息的日志，又可以看到被触发的状态变化test2-StateChange_Queue.vi✔✔✔✔✔✔
3可以通过全局日志队列获取订阅、取消订阅的日志, 协作者和责任链模式的CSM模块名不能带有后缀test3-RegisterUnregister_Queue.vi✔✔✔✔✔✔
4可以通过全局日志队列获得模块消息通讯的日志(messasge): 通过外部API发送一条同步消息触发CSM1模块内部状态，该内部状态里再发送一条同步消息给CSM2，检查这两条特定消息都按照严格的格式记录在日志里。test4-Message_Queue.vi✔✔✔✔✔✔
5可以通过全局日志队列获得模块发布广播的日志(broadcast)test5-Broadcast_Queue.vi✔✔✔✔✔✔
6可以通过全局日志队列获得模块发布高优先级广播的日志(interrupt)test6-Interrupt_Queue.vi✔✔✔✔✔✔
7可以通过全局日志队列获得模块状态广播(state)的日志test7-StateBroadcast_Queue.vi✔✔✔✔✔✔
8可以通过全局日志队列获得模块自定义用户消息的日志test8-UserLog_Queue.vi✔✔✔✔✔✔
9可以通过全局日志队列获得模块Sync/Async/NoRep-Async消息的日志已测试，见test4-Message_Queue.vi✔✔✔✔✔✔
10可以通过全局日志自定义事件获取模块创建和销毁的日志(module created/module destroyed),并检查日志数量是否符合预期test9-ModuleCreatedDestroyed_Event.vi✔✔✔✔✔✔
11可以通过全局日志自定义事件获取模块状态轮转的日志(state change): 通过外部API发送一条消息触发CSM模块内部状态变化(State Change), 可以在全局日志里既看到触发消息的日志，又可以看到被触发的状态变化test10-StateChange_Event.vi✔✔✔✔✔✔
12可以通过全局日志自定义事件获取订阅、取消订阅的日志, 协作者和责任链模式的CSM模块名不能带有后缀test11-RegisterUnregister_Event.vi✔✔✔✔✔✔
13可以通过全局日志自定义事件获得模块消息通讯的日志(messasge)test12-Message_Event.vi✔✔✔✔✔✔
14可以通过全局日志自定义事件获得模块发布广播的日志(broadcast)test13-Broadcast_Event.vi✔✔✔✔✔✔
15可以通过全局日志自定义事件获得模块发布高优先级广播的日志(interrupt)test14-Interrupt_Event.vi✔✔✔✔✔✔
16可以通过全局日志自定义事件获得模块状态广播(state)的日志test15-StateBroadcast_Event.vi✔✔✔✔✔✔
17可以通过全局日志自定义事件获得模块自定义用户消息的日志test16-UserLog_Event.vi✔✔✔✔✔✔
18可以通过全局日志自定义事件获得模块Sync/Async/NoRep-Async消息的日志 已测试，见test12-Message_Event.vi✔✔✔✔✔✔
+ +备注：CSM模式包含普通模式、子模块模式、系统级模式、协作者模式、责任链模式、打包项目库模式，CSM1和CSM2之间包含所有可能的CSM模式对应关系。 +
diff --git a/testcases/new/CSM_Unittest_README/Tables/table6_SystemLevelModule(en-us).md b/testcases/new/CSM_Unittest_README/Tables/table6_SystemLevelModule(en-us).md new file mode 100644 index 000000000..f6fadaf7c --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table6_SystemLevelModule(en-us).md @@ -0,0 +1,35 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Normal Mode Submodule Mode System-Level Mode Worker Mode Chain Mode lvlibp
1CSM List Module.vi by default cannot list system-level modules, but after changing the scope to 'all', they can be recognizedtest1-SystemLevelModuleInListModuleAPI.vi✔✔✔✔✔✔
2The message function of System-Level has already been tested in the Sync/Async/AsyncNoRep message test casesTested, see message class tests✔✔✔✔✔✔
diff --git a/testcases/new/CSM_Unittest_README/Tables/table6_SystemLevelModule(zh-cn).md b/testcases/new/CSM_Unittest_README/Tables/table6_SystemLevelModule(zh-cn).md new file mode 100644 index 000000000..6c6da1c5c --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table6_SystemLevelModule(zh-cn).md @@ -0,0 +1,35 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 普通模式 子模块模式 系统级模式 协作者模式 责任链模式 打包项目库模式
1CSM List Module.vi 默认不能列出来 systemlevel module, 但是修改 scope 为 all 后，可以识别出来test1-SystemLevelModuleInListModuleAPI.vi✔✔✔✔✔✔
2SystemLevel的消息功能，已经在 Sync/Async/AsyncNoRep 消息的 testcases 中测试过已测试，见消息类测试✔✔✔✔✔✔
diff --git a/testcases/new/CSM_Unittest_README/Tables/table7_SubModule(en-us).md b/testcases/new/CSM_Unittest_README/Tables/table7_SubModule(en-us).md new file mode 100644 index 000000000..2eebd1e81 --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table7_SubModule(en-us).md @@ -0,0 +1,14 @@ + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Submodule Mode
1CSM List SubModules.vi: When UI, UI.a1 (not existing), UI.a2, UI.a1.b1, and UI.a2.b2 exist, it can correctly list the required submodules according to the input parameterstest1-ListSubModulesInDifferentSenarios.vi✔
diff --git a/testcases/new/CSM_Unittest_README/Tables/table7_SubModule(zh-cn).md b/testcases/new/CSM_Unittest_README/Tables/table7_SubModule(zh-cn).md new file mode 100644 index 000000000..dbf7fb806 --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table7_SubModule(zh-cn).md @@ -0,0 +1,14 @@ + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 子模块模式
1CSM List SubModules.vi 在 UI, UI.a1(不存在), UI.a2, UI.a1.b1, UI.a2.b2 存在的情况下，可以根据输入参数，正确的罗列出需要的 Submoduletest1-ListSubModulesInDifferentSenarios.vi✔
diff --git a/testcases/new/CSM_Unittest_README/Tables/table8_WorkerMode(en-us).md b/testcases/new/CSM_Unittest_README/Tables/table8_WorkerMode(en-us).md new file mode 100644 index 000000000..f2307a91b --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table8_WorkerMode(en-us).md @@ -0,0 +1,14 @@ + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Worker Mode
1All nodes share the same CSM Attribute data space; data written externally is read identically by all internal modulestest1-AllWorkerNodesShareTheSameData.vi✔
diff --git a/testcases/new/CSM_Unittest_README/Tables/table8_WorkerMode(zh-cn).md b/testcases/new/CSM_Unittest_README/Tables/table8_WorkerMode(zh-cn).md new file mode 100644 index 000000000..1208bd04c --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table8_WorkerMode(zh-cn).md @@ -0,0 +1,14 @@ + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 协作者模式
1节点之间共享相同的CSM Attribute 数据空间，外部写入数据，内部所有模块读取的数据相同test1-AllWorkerNodesShareTheSameData.vi✔
diff --git a/testcases/new/CSM_Unittest_README/Tables/table9_ChainMode(en-us).md b/testcases/new/CSM_Unittest_README/Tables/table9_ChainMode(en-us).md new file mode 100644 index 000000000..ee4a35f53 --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table9_ChainMode(en-us).md @@ -0,0 +1,46 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Test Case No. Test Case Description Test Case VI Chain Mode
1All nodes share the same CSM Attribute data space. Data written externally is read identically by all internal modules.test1-AllChainNodesShareTheSameData.vi✔
2Three nodes (A->B->C), each with different Allowed Messages. Messages are sent to the corresponding allowed module; using the API to send synchronous messages returns the correct parameters.test2-DifferentChainNodesProcessDifferentAllowedMessages.vi✔
3Three nodes (A->B->C), with Allowed Messages combinations of AB, BC, AC, and ABC. Messages should be executed by the first node in the chain. Using the API to send synchronous messages returns the correct parameters.test3-FirstChainNodeProcessesAllowedMessages.vi✔
4Three nodes (A->B->C), with Allowed Messages defined. If no module can execute the message, the sender reports an error.test4-EndNodeHandlesErrorForNotAllowedMessages.vi✔
5Three nodes (A->B->C), each node broadcasts a message. After subscribing, the corresponding module's API is triggered; after unsubscribing, none can be triggered.test5-ChainNodeBroadcast.vi✔
6Three nodes (A->B->C). If the "Macro: Exit" command does not specify a node (i.e., uses the core name without the $ suffix), nodes should exit in order from the end to the head of the chain. If the command specifies a node, only that node exits and others are unaffected.test6-ChainNodeExitSequenceCheck.vi✔
diff --git a/testcases/new/CSM_Unittest_README/Tables/table9_ChainMode(zh-cn).md b/testcases/new/CSM_Unittest_README/Tables/table9_ChainMode(zh-cn).md new file mode 100644 index 000000000..7572e5723 --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table9_ChainMode(zh-cn).md @@ -0,0 +1,46 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI 责任链模式
1节点之间共享相同的CSM Attribute 数据空间，外部写入数据，内部所有模块读取的数据相同test1-AllChainNodesShareTheSameData.vi✔
23个节点（A->B->C)，定义节点的Allowed Messages，互不相同的允许的消息，会发送到对应允许的模块运行；使用API发送同步消息，可以携带回正确的参数test2-DifferentChainNodesProcessDifferentAllowedMessages.vi✔
33个节点（A->B->C)，定义节点的Allowed Messages，AB, BC, AC, ABC 组合允许的消息，应该由链条端头的节点执行, 使用API发送同步消息，可以携带回正确的参数 test3-FirstChainNodeProcessesAllowedMessages.vi✔
43个节点（A->B->C)，定义节点的Allowed Messages, 没有可以执行的模块，由消息发送方报错test4-EndNodeHandlesErrorForNotAllowedMessages.vi✔
53个节点（A->B->C)，不同的节点都发出一个广播，订阅后，都能触发对应绑定模块的API, 取消订阅后，任意一个都不能触发test5-ChainNodeBroadcast.vi✔
63个节点（A->B->C)，如果使用”Macro: Exit“命令不显性明确哪个节点，而是用不带$后缀的核心名字退出时，需按照从链条底端到端头的顺序依次退出；如果使用”Macro: Exit“命令显性明确哪个节点，则只退出该节点模块，其余节点模块不受影响test6-ChainNodeExitSequenceCheck.vi✔
diff --git a/testcases/new/CSM_Unittest_README/Tables/table_bold.md b/testcases/new/CSM_Unittest_README/Tables/table_bold.md new file mode 100644 index 000000000..742623194 --- /dev/null +++ b/testcases/new/CSM_Unittest_README/Tables/table_bold.md @@ -0,0 +1,53 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
测试项序号 测试项内容 对应测试项VI
1 CSM1发送同步消息给CSM2，CSM2返回正确的Response, CSM1进入Response Case 处理返回 test1-SyncMessage.vi
2 CSM1发送同步消息给CSM2，CSM2执行出错，CSM1进入Response Case, 携带了Response和错误信息 test2-SycnMessageWithError.vi
3 CSM1使用API发送同步消息给CSM2，CSM2返回正确的Response, CSM1通过API拿到返回 test3-SyncMessage_API.vi
4 CSM1使用API发送同步消息给CSM2，CSM2执行出错，CSM1通过API拿到Response和错误信息 test4-SyncMessageWithError_API.vi
5 CSM1发送异步有返回消息给CSM2，CSM2返回正确的Response, CSM1进入Async Response 处理返回 test5-AsyncMessageWithReply.vi
6 CSM1发送异步有返回消息给CSM2，CSM2执行出错，CSM1进入Async Response, 携带了Response和错误信息 test6-AsyncMessageWithReplyWithError.vi
7 CSM1发送异步无返回消息给CSM2，检查确认CSM2执行，CSM1不处理返回 test7-AsyncMessageWithoutReply.vi
8 CSM1使用API发送异步无返回消息给CSM，检查确认调用方异步执行，不处理返回 test8-AsyncMessageWithoutReply_API.vi
\ No newline at end of file