update copp mnager redesign test plan

doc/copp/Copp_Manager_Redesign_test_plan.md

@@ -80,9 +80,11 @@ The test will be supported on ptf32, ptf64, t1 and t2.
 ## Test cases
 ### Test cases #1 -  Verify 4 traps'default configuration
 1. Verify the 4 traps(arp, lacp, udld, ip2me) are installed  by sending traffic with the default config
+   (For traffic validation, please see the Notes)
 
 ### Test cases #2 - Add a new trap
 #### Pre-condition: The tested trap should be uninstalled on dut.
+#### Remove ip2me because bgp traffic can fall back to ip2me trap then interfere following traffic tests
 1. Set always_enabled of bgp to true with following cmds:
 
   + generate copp config file
@@ -98,37 +100,43 @@ The test will be supported on ptf32, ptf64, t1 and t2.
 ```
    + config load copp_bgp.json -y
 
-2. Verify the corresponding trap status is installed by sending traffic    
+2. Verify the corresponding trap status is installed by sending traffic(For traffic validation, please see the Notes)
 3. Recover the config
 
 
 ### Test cases #3 - Remove a trap by removing entry from feature table
 #### Pre-condition: The tested trap has been installed on dut,  with always_enable true and the corresponding entry enabled.
+#### Remove ip2me because bgp traffic can fall back to ip2me trap then interfere following traffic tests
 Take bgp trap as example:
 1. Set always_enabled of bgp to false (refer to test #2)
 2. Remove bgp entry from feature table with CMD
    redis-cli -n 4 hdel "FEATURE|bgp" "auto_restart" "has_global_scope" "has_per_asic_scope" "has_timer" "high_mem_alert" "state" 
-3. Verify the tested trap is uninstalled  by sending traffic
+3. Verify the tested trap is uninstalled  by sending traffic (For traffic validation, please see the Notes)
 5. Recover the config   
 
 
 ### Test cases #4 - Remove a trap by disabling feature table
+#### Pre-condition: Remove ip2me because bgp traffic can fall back to ip2me trap then interfere following traffic tests
 Take bgp trap as an example:
 1. Set always_enabled of bgp to false (refer to test #2)
 2. Enable bgp in feature table: config feature state bgp enabled    
-3. Verify the tested trap is installed by sending traffic
+3. Verify the tested trap is installed by sending traffic (For traffic validation, please see the Notes)
 4. Disable bgp in feature table: config feature state bgp disabled 
-5. Verify the tested trap is uninstalled by sending traffic
+5. Verify the tested trap is uninstalled by sending traffic (For traffic validation, please see the Notes)
 6. Recover the config
 
 
-
 ### Test cases #5 - Verify trap configuration is saved or not after reboot(reboot, fast-reboot, warm-reboot)
 1. Set always_enabled of a trap(e.g.  bgp) to true
 2. Config save -y
 3. Do reboot randomly(reboot/warm-reboot/fast-reboot)
 4. Verify configuration are saved successfully
-5. Verify the trap status is installed by sending traffic
+5. Verify the trap status is installed by sending traffic (For traffic validation, please see the Notes)
 6. Recover the config
 
-
+### Notes
+When validating traffic, we need to take care the following cases:
+1. When the trap is added, the traffic(rx_pps) will be in the range [PPS_LIMIT_MIN, self.PPS_LIMIT_MAX]
+2. When the trap is removed, the traffic(rx_pps) will be smaller than PPS_LIMIT_MIN
+Usually when the trap is removed, we expect the traffic for the trap should be 0, but it might be trapped by other traps.
+For example： If only remove BGP traffic, BPG traffic will be trapped by IP2ME, so the traffic will not be 0