ID | Title | Description | Number |
---|---|---|---|
10 | Control Channel | Verifies establishment of a control channel, version negotiation, and device behavior when the control channel is lost. | 13 |
40 | Controller to Switch Messages | Verifies the device under test is able to match on the thirteen OXM types marked as required in table 11 of the OpenFlow v1.3 Specification. | 21 |
50 | Flow Table Miss | Verifies the basic behavior of packets, which fail to match against any standard flow table entry (non table miss entry). | 5 |
60 | Flow Table Matching | Verifies the device under test is able to match on the thirteen OXM types marked as required in table 11 of the OpenFlow v1.3 Specification. | 14 |
80 | Flow Table Match Prerequisites | Verifies the behavior of OXM types and their corresponding prerequisites. | 7 |
90 | Flow Table Match Combinations | Verifies the behavior of various combinations of OXM types used in a single flow entry. | 1 |
100 | Flow Table Actions | Verifies that all actions a device MUST support are correctly implemented. The output action is the only action type required for Basic Single Table conformance, which requires the output action to work with the following reserved ports; OFPP_IN_PORT, OFPP_ALL, OFPP_TABLE (for packet out messages only), and OFPP_CONTROLLER. | 9 |
130 | Flow Table Actions Set | Verifies the correct behavior of the action set, due to most action set tests require more than a single table to properly execute, a majority of test suite 130 is excluded from the Basic Single Table conformance requirements. | 2 |
140 | Flow Table Modifications | Verifies the behavior of flow modification messages with a focus on testing overlapping flows, flow flags, and flow commands. | 19 |
150 | Flow Table Errors | Verifies the correct implementation of error messages associated with flow modification messages. | 21 |
180 | Counters | Verifies the behavior of counters marked as required in table 5 of the v1.3 OpenFlow Specification. | 6 |
200 | Protocol Messages 1 | Verifies the basic behavior of each OpenFlow message type. | 13 |
210 | Port Structure Protocol Message | Verifies the ofp_port structure's various fields. To satisfy the Basic Single Table requirements, an OpenFlow-enabled device MUST pass this 210.50. All other test cases are duplicates, which have been implicitly tested in other test suites and thus removed. | 1 |
230 | Action Header Protocol Message | Verifies the ofp_action_header structure's various fields. | 3 |
250 | Switch Config Protocol Message | Verifies the ofp_switch_config structure's various fields. | 2 |
260 | Flow Mod Protocol Message | Verifies ofp_flow_mod structure's various fields, overlapping flow entries, flow removed messages, strict/ non strict flow modifications, flow deletions, additional constraints on modifications, flow deletions (output, and cookie). | 23 |
300 | Multipart Reply Protocol Message | Verifies the ofp_multipart_request structure's various fields. Particularly to test multipart flags, features, statistics, and port descriptions. | 13 |
310 | Multipart Reply Section One | Verifies the correct implementation of the fields contained in each of the following message structs: ofp_desc, ofp_flow_stats_request, ofp_flow_stats, ofp_aggregate_stats_request, ofp_aggregate_stats_reply. | 19 |
320 | Multipart Reply Section Two | Verifies the correct implementation of the fields contained in each of the following message structs: ofp_desc, ofp_flow_stats_request, ofp_flow_stats, ofp_aggregate_stats_request, ofp_aggregate_stats_reply. | 25 |
330 | Multipart Reply Section Three | Verifies the correct implementation of the fields contained in each of the following message structs: ofp_table_feature_prop_oxm, oxm_ids. | 8 |
340 | Multipart Reply Section Four | Verifies the correct implementation of the fields contained in each of the following message structs: ofp_port_stats_request, ofp_port_stats, and ofp_port. | 26 |
380 | Multipart Reply Section Five | Verifies the correct implementation of the fields contained in each of the following message structs: ofp_queue_stats, ofp_get_queue_config_request, and ofp_packet_queue. | 6 |
390 | Packet Out Protocol Message | Verifies the device correctly implements the packet out message type. | 6 |
410 | Packet In Protocol Message | Verifies that the device correctly implements the packet in message type. | 12 |
420 | Flow Removed Protocol Message | Verifies that the device correctly implements port status and flow removed message types. | 10 |
430 | Error Messages Section One | Verifies that device correctly implements various required error messages. Devices maybe unable to trigger specific error messages. Results of these test cases MAY be recorded as 'Not Applicable'. | 26 |
440 | Error Messages Section Two | Verifies that the device correctly implements various required error messages. In some cases, the DUT may not support the tested field or bits. In these cases, it MUST respond with the expected error messages. Some devices may be unable to trigger specific error messages. The results of these test cases MAY be marked as ‘Not Applicable’. | 29 |
450 | Symmetric Messages | Verifies that the device correctly implements various symmetric message types including ofp_hello, ofp_echo_request / ofp_echo_reply, and OUIs included in experimenter message types. | 3 |
Title | Description |
---|---|
CLI Check_Interface Add VLAN Mode - Hybrid | Verify CLI whether it maintains Hybrid VLAN tagged |
CLI Check_Interface Add VLAN Mode - Access | Verify CLI whether it maintains Access VLAN tagged |
CLI Check_Interface Add VLAN Mode - Trunk | Verify CLI whether it maintains Hybrid Trunk tagged |
CLI Check_Interface Add VLAN Mode - Tunnel | Verify CLI whether it maintains Hybrid Tunnel tagged |
CLI Check_PVID_VLAN in database | Verify CLI System whether shows" Ingress UnTagged VLAN number" |
CLI Check_PVID_VLAN not in database | Verify CLI System whether shows error message |
CLI Check_VLAN ID_In Range | Configure out of range VLAN ID to verify CLI System whether shows VLAN number |
CLI Check_VLAN ID_Out of Range | Configure out of range VLAN ID to verify CLI System whether shows error message |
CLI Check_Maximum quantity of VLAN tagged | To test the maximum quantity of VLAN tagged |
CLI Check_Interface Delete VLAN Mode | Verify CLI System whether Delete VLAN tagged |
CLI Check_Ingress Filtering - Enable | Verify CLI System whether enable ingress filtering |
CLI Check_Ingress Filtering parameter | To determine the value(s) of the Enable Ingress Filtering parameter that are supported by the DUT. |
CLI Check_Ingress Filtering - Disable | Verify CLI System whether disable ingress filtering |
CLI Check_TPID - 0x8100 | Verify CLI System whether shows "VLAN tpid 0x8100" |
CLI Check_TPID - 0x88a8 | Verify CLI System whether shows "VLAN tpid 0x88a8" |
CLI Check_TPID - 0x9100 | Verify CLI System whether shows "VLAN tpid 0x9100" |
CLI Check_TPID - 0x9200 | Verify CLI System whether shows "VLAN tpid 0x9200" |
CLI Check_Port-based VLAN- Binding quantity maximum VLAN to a port | Verify CLI System whether binding quantity maximum VLAN to a port |
CLI Check_GVRP Configure | Verify CLI whether it maintains GVRP setup |
Function Test_GVRP Configured through Management | To verify that the DUT properly supports the configuration of the QinQ through management. |
Function Test_QinQ Configured through Management | To verify that the DUT properly supports the configuration of the GVRP through management. |
Function Test_Trunk VLAN Configured through Management | To verify that the DUT properly supports the configuration of the Trunk VLAN through management. |
Function Test_Access VLAN Configured through Management | To verify that the DUT properly supports the configuration of the Access VLAN through management. |
Function Test_Enable Ingress Filtering | To determine the value(s) of the Enable Ingress Filtering parameter that are supported by the DUT. |
Function Test_PVID Configured through Management | To verify that the DUT properly supports the configuration of the PVID through management. |
Function Test_PVID Assigned to a Port in no VLAN Member Set | To verify that the DUT properly supports the default PVID when a Port is not in any VLANs. |
Function Test_Acceptable Frame Types Parameter | To determine the value(s) of the Acceptable Frame Types Parameter that the DUT supports. |
Function Test_Minimum Frame Size | To verify that the DUT forwards untagged and tagged frames of minimum size and discards frames less than the minimum size. |
Function Test_Maximum Tagged Size | To verify that the DUT forwards VLAN-tagged frames of maximum size and discards those with a size greater than this maximum. |
Untagging Minimum-Sized Tagged Frames | To verify that the DUT properly untags and forwards VLAN-tagged frames of minimum size |
Function Test_Bad FCS Received | To verify that the DUT correctly discards received frames that contain an invalid FCS. |
Function Test_VLANs with MSTP | To verify that the DUT properly interacts with MSTP when using VLANs |
Title | Description |
---|---|
CLI Check_Default Parameters ID_Retries/Timeout for Reply/ Dead Time/Key String | To verify that the DUT properly supports the default Parameters |
CLI Check_Port Setting | Verify CLI whether it maintains "Port setting feature" |
CLI Check_Global 802.1x setting | To verify that the DUT properly supports the Global 802.1x setting |
CLI Check_Radius Server setting | To verify that the DUT properly supports the Radius Server setting |
CLI Check_Guest VLAN Setting | To verify that the DUT properly supports the Guest VLAN Setting |
CLI Check_AAA Setting_New Login Authentication | To verify that the DUT properly supports the 802.1X AAA Setting for New Login Authentication |
CLI Check_AAA Setting_New Enable Authentication | To verify that the DUT properly supports the 802.1X AAA Setting for New Enable Authentication |
CLI Check_Access Setting_Console | To verify that the DUT properly supports the 802.1X Access Setting for Console using |
CLI Check_Access Setting_Telnet | To verify that the DUT properly supports the 802.1X Access Setting for Telnet using |
CLI Check_Access Setting_HTTP | To verify that the DUT properly supports the 802.1X Access Setting for HTTP using |
CLI Check_Interface vlan | To verify that the DUT properly supports the 802.1X Management VLAN setting for Interface vlan |
CLI Check_IP Address Mode | To verify that the DUT properly supports the 802.1X Management VLAN setting for IP Address Mode |
CLI Check_SSL and TLS v1.0 | To verify that the DUT properly supports the 802.1X HTTPS setting for SSL and TLS v1.0 |
CLI Check_SSH v1/v2 | To verify that the DUT properly supports the 802.1X SSH setting |
CLI Check_Port Security setting | To verify that the DUT properly supports the Port Security setting |
CLI Check_Storm Control setting | To verify that the DUT properly supports the Storm Control setting |
CLI Check_Protected Port setting_Add Profile of Traffic | To verify that the DUT properly supports the Protected Port setting for Add Profile of Traffic |
CLI Check_Protected Port setting_Add Profile of Protocol | To verify that the DUT properly supports the Protected Port setting for Add Profile of Protocol |
CLI Check_Protected Port setting_Group on specific port | To verify that the DUT properly supports the Protected Port setting for Group on specific port |
CLI Check_Dos Prevention setting_TCP Flooding | To verify that the DUT properly supports the Dos Prevention setting for TCP Flooding |
CLI Check_Dos Prevention setting_UDP Flooding | To verify that the DUT properly supports the Dos Prevention setting for UDP Flooding |
CLI Check_Dos Prevention setting_Smurf Attack | To verify that the DUT properly supports the Dos Prevention setting for Smurf Attack |
Function Test_Port-based function | To verify that the Device could pass the Authentication and get IP by Port-based setting. |
Function Test_Guest VLAN function | To verify that the Device1 could ping to Device2, and MAC Address of Device2 belong to VLAN 1 by Guest VLAN setting. |
Function Test_Local Account Management_use Console Login Authentication | To verify that the DUT properly supports the Local Account Management for Login Authentication |
Function Test_Local Account Management_use Console Enable Authentication | To verify that the DUT properly supports the Local Account Management for Enable Authentication |
Function Test_Local Account Management_use Telnet Login Authentication | To verify that the DUT properly supports the Local Account Management for Login Authentication |
Function Test_Local Account Management_use Telnet Enable Authentication | To verify that the DUT properly supports the Local Account Management for Enable Authentication |
Function Test_Local Account Management_use HTTP Login Authentication | To verify that the DUT properly supports the Local Account Management for Login Authentication |
Function Test_Local Account Management_use HTTP Enable Authentication | To verify that the DUT properly supports the Local Account Management for Enable Authentication |
Function Management VLAN | To verify that both Device1 and Device2 could access Switch via HTTP and Telnet. |
Function Test_HTTPS with SSL and TLS v1.0 | To verify that the Device could access https://switch’s IP ,but there will be warning message during access. |
Function Test_HTTPS with SSL and TLS v1.0_Login Authentication | To verify that the Device could login switch by HTTPS. |
Function Test_SSH v1/v2 | To verify that SSH connection could be established by putty successfully. |
Function Test_SSH v1/v2_Login Authentication | To verify that PC could login switch by SSH. |
Function Test_Port Security | To verify that Ping from Device 2 to Device1 should be still OK, and Device1 should receive Trap packets. |
Function Test_Storm Control_Broadcast Control | To verify that storm control is limiting the rate of traffic on the interface by Broadcast control. |
Function Test_Storm Control_Multicast Control | To verify that storm control is limiting the rate of traffic on the interface by Multicast Control. |
Function Test_Storm Control_Unknown Unicast Control | To verify that storm control is limiting the rate of traffic on the interface by Unknown Unicast Control. |
Function Test_Protected Port | To verify that the Ping between Device1 and Device2 should (not) be OK by Bi-Direction. |
Function Test_Dos Prevention_Echo/Chargen Attack | To verify that the DUT properly supports the Dos Prevention setting for Echo/Chargen Attack. |
Function Test_Dos Prevention_TCP Flooding Attack | To verify that the DUT properly supports the Dos Prevention setting for TCP Flooding Attack. |
Function Test_Dos Prevention_UDP Flooding Attack | To verify that the DUT properly supports the Dos Prevention setting for UDP Flooding Attack. |
Function Test_Dos Prevention_Smurf Attack | To verify that the DUT properly supports the Dos Prevention setting for Smurf Attack. |
Title | Description |
---|---|
CLI Check_MAC-based | To verify that the Creation of ACL MAC-based rule by CLI and validating the rules on Switch. |
CLI Check_IPv4-based | To verify that the Creation of ACL IPv4-based rule by CLI and validating the rules on Switch. |
CLI Check_IPv6-based | To verify that the Creation of ACL IPv6-based rule by CLI and validating the rules on Switch. |
CLI Check_Mixing | To verify that the Creation of ACL Mixing rule by CLI and validating the rules on Switch. |
CLI Check_Maximum | To verify that the Creation of ACL Maximum quantity by CLI and validating the rules on Switch. |
Title | Description |
---|---|
CLI Check_Port group to the limit | To verify that the Creation of LAG Group Maximum quantity by CLI |
CLI Check_Ports to one group to the limit | To verify that the Creation of LAG Ports to one group to the limit by CLI |
CLI Check_Load Balance Algorithm | To verify that the Creation of LAG Load Balance Algorithm by CLI. |
CLI Check_LAG Port Setting | To verify that the Creation of ACL Port Setting. |
Function Check_Port group to the limit | To verify that the Creation of LAG Group Maximum quantity by CLI |
Function Check_Ports to one group to the limit | To verify that the Creation of LAG Ports to one group to the limit by CLI |
Function Check_Port Binding lag | To verify the Link Aggregation test case is designed to test the data transmit/receive functionality in Link Aggregation mode. |
Function Check_LACP Backup Port | To verify that the Creation of LACP Backup Port by CLI. |
ACTS provides several network attack functions, through simple steps of setting, allowing users to easily construct the desired attack behavior and attack the target. The test report contains the determination of the attack result and the record of the attack process, providing users with detailed information about the attack.
In addition to controlling the Agent to send and receive packets, the Controller, as a
central control platform, can also control external test equipment to remote external test
equipment to send and receive packets, then analyze and generate reports after completion.
Through related functions, the Controller can also retrieve the report content of the
external test equipment and reassemble it into the data required by the user for
judgment.
ACTS supports multiple brands and multiple versions and can control multiple versions of
external test equipment on the same Controller to improve platform integration efficiency.
Are you still manually turning on specific services exclusively for testing use?
ACTS Controller has built-in multiple service servers, add a specified service activation
step in the test case, ACTS will automatically activate the service during the testing
process for subsequent testing steps.
The built-in server directly provides services, no need to adjust test case-related
parameters due to changes in the service server network configuration, reducing unnecessary
work for testers.
The ACTS Agent series has a built-in packet generator that provides generation, comparison and packet playback functions, including L2, L3, L4, L7 packets and user-defined packets. A graphical interface is used to make it easier for testers to understand the contents of the packet.
Remote Access is a connection test function, including CLI and Web connection. Through functions such as sending instructions and comparing device return messages, supplemented by other functions (such as using Packet Generate to send packets), the steps are combined into the test case we designed.
Utility plays the role of a toolbox, providing logical judgment functions such as four arithmetic operations, time tools, and if else, loop, repeat, random and other logical judgment functions to assist test developers in composing test projects according to test plans.
With the current technological advancement, the trend of network virtualization is
unstoppable, more complex network equipment connections, more network equipment needs to be
tested. Therefore, for network test engineers, how to design network test topology has
become a big issue.
ACTS provides a graphical interaction to setup network test topology, which can clearly
describe the connection of the test lines used for computers, servers, networks, and
security equipment, users can easily setup the network test topology.
When editing the network test topology, you can check the test projects you want to compare and press compare to get the comparison result according to the graphical content.
User scenario:
The department wants to develop an automated test environment for network equipment, but
often encounters the following problems, which greatly increases the difficulty of executing
and maintaining automated tests when constructing automated tests:
ACTS provides network test topology virtualization and test project variable application, so that the differences between the corresponding Port, CLI and test equipment versions of the test project can be solved by virtual or variable methods to implement 24/7 uninterrupted automated test.
ACTS uses plain text to edit automated test cases, just like testers writing test plans, inputting the command set and pass condition of the device under test, setting capturing and parsing of test packets, and web page testing of the device under test, etc. Without learning any programming language, you can easily edit the test cases to compose a complete and fully automated test project.
Regarding test automation, most of them are now implemented by writing test scripts. In the current development and automation test environment, it takes many engineers who are familiar with programming languages to achieve full test automation, leading to a low automation ratio of the company. Test engineers generally focus on being familiar with Protocol, understanding Function, creating and improving test plans, rather than understanding the entire system program architecture. The test project editing process provided by ACTS is the same as writing Test Plan. Test engineers do not need to spend extra time to learn program languages and communicate with program engineers, which greatly improves the automation ratio.
You can setup test topologies edit test cases to create test project content. You can also arrange test schedules based on test dates and resources to form a 24/7 uninterrupted test project schedule.
After the test project is completed, a test report can be generated, including Project Summary, Topology, Cases Summary and Cases Steps, so that you can clearly know the events that occurred during the execution and the results after the execution. The test report export format can be chosen from DOCX, XLS or PDF, and the export content items and charts can be selected optionally and customized.
ACTS report comparison lets you easily understand the differences in the execution results of test projects to facilitate the analysis of product hardware and software issues. This type of analysis information can help you compare whether the test results are consistent with the same hardware under different firmware or the same firmware under different hardware.
When comparing test projects, you can check the test project you want to compare and press Compare to get the comparison result according to the icon indication.
Icon | Description |
---|---|
The comparison results of the test case of selected projects are Pass. | |
highlight_off | The comparison results of the test case in this row are inconsistent. |
error_outline | The comparison results of the test case in this row are Error. |
warning_amber | The comparison results of the test case in this row are Fail, and Fail is in the same step. |
warning_amber priority_high | The comparison results of the test case in this row are Fail, but Fail is in a different step. |
The output report is a CSV file, which includes:
User scenario:
After the tester is required to complete the firmware test of this version of the product,
he must compare it with the test results of the previous version of the firmware. However,
the test project is usually composed of hundreds of test cases. If you want to sort out the
test project to find the difference in the results of the test cases can even be compared to
see if there is a difference in the steps of the Fail when the test case results are all
Fail. For example, manual comparison and evaluation take 1 week.
The Compare function of ACTS lets you sort out the difference easily and quickly. You can
even query each detail of the test case through the test result link.
When ACTS edits an automated test project, just like a tester writing a test plan, many steps are repetitive when writing. If you write the steps as reusable components in ACTS Macro, you can save a lot of time for rewriting.
Service | Description |
---|---|
Web Test Case |
|
CLI Test Case |
|
Function Test |
|
Conformance Test | Provide various network protocol tests according to customer needs, and priced according to the agreement. |
Performance Test | Provide various network performance tests according to customer needs, and priced based on each network performance item. |
Users | The number of users who can login at the same time. |
Technical Support | User guides, contact information, usage issues, maintenance progress, software updates and other rights. |